3 ms·

"Another lesson we should have learned from the recent past is that the development of richer or more powerful programming languages was a mistake in the sense

"Another lesson we should have learned from the recent past is that the development of richer or more powerful programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages." -- "The Humble Programmer" https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...

shakow 5y ago
The problem is that the complexity in computing is intrinsically irreducible. Sure, you can get nice nifty little languages, but then the latent complexity will be transferred into the program itself (e.g. program length, cyclomatic complexity, etc.) rather than in the language; that's why although they can technically do the same thing, we have a spectrum of languages ranging from assembly to APL. Practically, it's exactly what comes out of the infamous Rust vs. Go debate: for instance, the former prefers a short and concise albeit arguably more complex encoding and processing of the errors based on a monadic type, whereas the other leans toward a simpler, but more verbose, double return value + if/else/early return. Chose your poison.
pcwalton 5y ago
Is it complexity, or is it the result of the simplification of unifying expressions and statements in most cases?
kubb 5y ago
I mean the fact that you can do funny stuff with the syntax rules and the type system doesn't disqualify their usefulness. Rust's type system is impressive as it enables enforcing powerful constraints over how the code is allowed to execute, eliminating whole classes of bugs, and enabling elegant, zero-cost abstraction over swathes of algorithms and data structures, which in turn lets you have high quality libraries that provide to-the-point solutions for so many of the common tasks that a developer will deal with day to day. A more elegant language that solves the problems that Rust solves, with a production-ready implementation and a good ecosystem hasn't been presented to the world yet. It's to be expected that if you want to benefit from its advantages, you need to pay the cost of dealing with a more complex language. On the other hand paying the cost of being exposed to more concepts pays off by giving you more flexibility to craft simple solutions. Complexity of a project can vastly exceed that of the language the project is written it. In that case the cognitive cost of using more advanced tools to manage that complexity is a boon in the long run. This is analogous to any kind of more sophisticated technology, e.g. you can argue that a scythe is easier to use than a harvester, but with a big enough field, if you have the option, you'll go for the latter.
fanf2 5y ago
Dijkstra is best read as food for thought, since he is more often interesting than right.
TheDudeMan 5y ago
"I see a great future for very systematic and very modest programming languages." He was right; there was a great future for that (and everything else in computing). But perhaps he didn't anticipate the FAR greater corporate appetite for functionality. The next feature is paramount. Who will code this next feature? The only path was richer and more powerful languages.
- exikyut 5y ago
  The only winning move in this particular configuration of the game is not to play. But this game's configuration requires us to play, compels us to play. And so we play to lose, to continue the game.

shakow 5y ago

The problem is that the complexity in computing is intrinsically irreducible. Sure, you can get nice nifty little languages, but then the latent complexity will be transferred into the program itself (e.g. program length, cyclomatic complexity, etc.) rather than in the language; that's why although they can technically do the same thing, we have a spectrum of languages ranging from assembly to APL. Practically, it's exactly what comes out of the infamous Rust vs. Go debate: for instance, the former prefers a short and concise albeit arguably more complex encoding and processing of the errors based on a monadic type, whereas the other leans toward a simpler, but more verbose, double return value + if/else/early return. Chose your poison.

pcwalton 5y ago

Is it complexity, or is it the result of the simplification of unifying expressions and statements in most cases?

kubb 5y ago

I mean the fact that you can do funny stuff with the syntax rules and the type system doesn't disqualify their usefulness. Rust's type system is impressive as it enables enforcing powerful constraints over how the code is allowed to execute, eliminating whole classes of bugs, and enabling elegant, zero-cost abstraction over swathes of algorithms and data structures, which in turn lets you have high quality libraries that provide to-the-point solutions for so many of the common tasks that a developer will deal with day to day. A more elegant language that solves the problems that Rust solves, with a production-ready implementation and a good ecosystem hasn't been presented to the world yet. It's to be expected that if you want to benefit from its advantages, you need to pay the cost of dealing with a more complex language. On the other hand paying the cost of being exposed to more concepts pays off by giving you more flexibility to craft simple solutions. Complexity of a project can vastly exceed that of the language the project is written it. In that case the cognitive cost of using more advanced tools to manage that complexity is a boon in the long run. This is analogous to any kind of more sophisticated technology, e.g. you can argue that a scythe is easier to use than a harvester, but with a big enough field, if you have the option, you'll go for the latter.

fanf2 5y ago

Dijkstra is best read as food for thought, since he is more often interesting than right.

TheDudeMan 5y ago

"I see a great future for very systematic and very modest programming languages." He was right; there was a great future for that (and everything else in computing). But perhaps he didn't anticipate the FAR greater corporate appetite for functionality. The next feature is paramount. Who will code this next feature? The only path was richer and more powerful languages.

exikyut 5y ago
The only winning move in this particular configuration of the game is not to play. But this game's configuration requires us to play, compels us to play. And so we play to lose, to continue the game.