| I think there is reasonable consensus about some software engineering best practices: 1. Avoid action-at-a-distance and side-effects that are hard to reason about. 2. Use immutable objects and values rather than references and pointers. 3. Avoid intricate control flow with many branches. 4. Greater isolation of processes/threads (actor model). 5. Use systems and platforms with simple and strong guarantees (e.g. ACID) that are easy to reason about. Special cases and nuances to the underlying platform should be avoided. 6. Use tools with good support for static analysis (e.g. a good type system with a compiler that can understand it). Exceptions seem to violate #1, #3, and #6. These rules only apply to software engineering; that is, the reliability, robustness, long-term maintainability, and total project development cost (including maintenance and support). Of course, there are other considerations, such as: performance, the time to achieve the minimum viable product, how much developers like the tools, how "hackable" it is, or utility for research purposes. These other concerns may be a good reason to violate the above rules. |