3 ms·

In Erlang, instead of calling it Offensive Programming they call it "Let it Crash". A very valuable concept either way: if a function encounters an error and c

In Erlang, instead of calling it Offensive Programming they call it "Let it Crash". A very valuable concept either way: if a function encounters an error and can't somehow resolve it and still do its work successfully, then it should fail and not do something else.

macintux 6y ago
Agreed. Among the other fantastic things about Erlang, the fact that = is effectively an assertion means that unlike other languages where you turn off assertions in production, Erlang retains them in every environment.
pjbk 6y ago
Based on my experience, many, many, many headaches would be saved if this advice was followed more closely. IMHO defensive techniques including recovery should be placed in runtime monitors and supervisors, not in underpinning code which should have a minimum set of behaviors. It should also be kept as simple as possible to avoid code bloat and help reviewers and tools like static analyzers do their job. Old computing hardware was designed like that. Then software attempted to replicate hardware "exceptions", however not realizing that the model was intrinsically different and completely exploding in intricacies dealing with interrupts, stacks, memory management and threads. In a similar way, supervisors should be as decoupled as possible from the target code to provide reliability and avoid overall system complexity, with their own set of narrowed down requirements. Sadly our industry is plagued with historical, ad-hoc programming techniques that are not relevant anymore or were plain empirical bad advice in first place. For example, blindly relying on stateful paradigms, or side effects by design or as an acceptable consequence of certain programming idioms.
alpaca128 6y ago
And it's valuable in other languages as well. Not many things are as frustrating as silent failures in some library. And it's still one of my biggest gripes with JavaScript that when it encounters an error there's a good chance it just keeps on running in some undefined state, hiding the root cause of the problem.

macintux 6y ago

Agreed. Among the other fantastic things about Erlang, the fact that = is effectively an assertion means that unlike other languages where you turn off assertions in production, Erlang retains them in every environment.

pjbk 6y ago

Based on my experience, many, many, many headaches would be saved if this advice was followed more closely. IMHO defensive techniques including recovery should be placed in runtime monitors and supervisors, not in underpinning code which should have a minimum set of behaviors. It should also be kept as simple as possible to avoid code bloat and help reviewers and tools like static analyzers do their job. Old computing hardware was designed like that. Then software attempted to replicate hardware "exceptions", however not realizing that the model was intrinsically different and completely exploding in intricacies dealing with interrupts, stacks, memory management and threads. In a similar way, supervisors should be as decoupled as possible from the target code to provide reliability and avoid overall system complexity, with their own set of narrowed down requirements. Sadly our industry is plagued with historical, ad-hoc programming techniques that are not relevant anymore or were plain empirical bad advice in first place. For example, blindly relying on stateful paradigms, or side effects by design or as an acceptable consequence of certain programming idioms.

alpaca128 6y ago

And it's valuable in other languages as well. Not many things are as frustrating as silent failures in some library. And it's still one of my biggest gripes with JavaScript that when it encounters an error there's a good chance it just keeps on running in some undefined state, hiding the root cause of the problem.