On Saturday, 28 June 2025 at 15:20:44 UTC, WraithGlade wrote:
There are very few imposed structural "best practices" that are genuinely universal in my experience. Good naming of variables would be a rare example of a universally good practice, in my opinion, but in contrast even pervasive and nearly universally advocated systems (such as OOP for many years in the past few decades) have turned out (from a deeper language design perspective) to ultimately be riddled with false assumptions and thus the structure imposed by such systems when reified and scaled up to real software systems has often caused more harm than good.
I tend to agree. John Hughes wrote in his famous [Why Functional Programming Matters](https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf)
If omitting assignment statements brought such enormous benefits then Fortran programmers would have been doing it for twenty years. It is a logical impossibility to make a language more powerful by omitting features, no matter how bad they may be.
Even a functional programmer should be dissatisfied with these so-called advantages, because they give no help in exploiting the power of functional languages.
It’s helpful to draw an analogy between functional and structured programming. In the past, the characteristics and advantages of structured programming have been summed up more or less as follows. Structured programs contain no goto statements. Blocks in a structured program do not have multiple entries or exits. Structured programs are more tractable mathematically than their unstructured counterparts. These “advantages” of structured programming are very similar in spirit to the “advantages” of functional programming we discussed earlier. They are essentially negative statements, and have led to much fruitless argument about “essential gotos” and so on.
With the benefit of hindsight, it’s clear that these properties of structured programs, although helpful, do not go to the heart of the matter. The most important difference between structured and unstructured programs is that structured programs are designed in a modular way. Modular design brings with it great productivity improvements.
The absence of gotos, and so on, has very little to do with this.
If the only thing you can say is "that's bad practice" then you don't have a sensible argument. It's no better than proof by example. "It holds in these six examples, QED." The designer of a language doesn't have the knowledge required to universally declare something a bad practice that should be avoided. The language spec is not a linter and it shouldn't be a substitute for code review and sensible programming practice.
