Repeatable Execution - Mark Seemann - NDC Copenhagen 2022

What should applications log? Much enterprise code has logging code liberally sprinkled over it. Often, too much. Programmers log lots of things out of fear of not being able to troubleshoot problems that might occur in production. Even if you log a lot, however, how do you know that you haven’t missed a piece of crucial information?
In this talk, I’ll discuss a formal method for deciding what to log, and what you don’t need to log. Learning from functional programming, distinguishing between pure and impure code holds the key to such decisions. Examples will be mainly in C#, with some Haskell as well. No knowledge of Haskell is necessary.
Check out more of our featured speakers and talks at
www.ndcconfere...
ndccopenhagen....

[@xybersurfer]

very interesting! the only problem i can see is that the amount of impure data that needs to be logged, can become quite large when dealing with a database especially. i guess you have to limit testing to your own system as usual. it's good that Mark pointed out that he doesn't normally create that replay machinery, because i was already thinking it would be unproductive

[@Endomorphism]

Mark! Great talk as always

[@djchrisi]

16:14 . No, this is not deterministic. Since the method is not provided with a specific IFormatProvider object it will use the current culture and god knows what this is been set to.

[@torstenmohrin2207]

CurrentCulture is one of the worst global variables in .NET.

[@mackie1001]

Good spot! Establishing if something is pure or not in .Net requires pretty deep understanding of what you're looking at. Maybe a good rule of thumb is "look at all the overloads and be as specific as possible"

[@MarkSeemann]

Indeed, the CurrentCulture makes DateTime.TryParse subtly non-deterministic. It's not that I'm not aware of this issue, but I chose to gloss over that subtlety for didactic reasons. I sometimes simplify for educational reasons, but I try to do it only to a degree where the detail is largely irrelevant. The fix for this issue is to use an overload that specifically states which IFormatProvider to use, or to use TryParseExact. This makes the code look more complicated, but otherwise doesn't change the overall message of the talk. That's the reason I decided to pretend that the simpler code is deterministic. This may have been the wrong decision. Putting together a talk is an art, not a science.

[@science_and_technology6]

What are the complete steps to create a PayPal adder money program?

[@arootube]

You know?