3 ms·
Niklaus Wirth's "Good Ideas, Through the Looking Glass" is an interesting read on language design (I started reading from section 4): https://pdfs.semanticscho
by augustk 9y ago
Niklaus Wirth's "Good Ideas, Through the Looking Glass" is an interesting read on language design (I started reading from section 4):
https://pdfs.semanticscholar.org/10bd/dc49b85196aaa6715dd46843d9dcffa38358.pdf https://pdfs.semanticscholar.org/10bd/dc49b85196aaa6715dd468...
"Actually, a language is not so much characterized by what it allows to program, but more so by what it prevents from being expressed. Quoting the late E. W. Dijkstra, the programmer’s most difficult, daily task is to not mess things up. It seems to me that the first and noble duty of a language is to help in this eternal struggle."
- DonaldFisk 9y agoThanks. A quote often attributed to Dijkstra is "Object-oriented programming is an exceptionally bad idea which could only have originated in California," but the article you refer to makes quite clear he was aware of its Norwegian origins, and that he considers it a small and oversold addition to imperative programming, rather than a bad idea. I note he wasn't very keen on functional programming (6.1) or logic programming (6.2) (and by implication non-imperative languages in general) because they don't fit well onto the hardware currently available. But that limits you to imperative languages, whose code is much more difficult to test for correctness. I accept that preventing programming errors is important, but also think that languages should be designed for the problems they're intended to solve, whether or not that's a good fit for current hardware. If it isn't a good fit, I'd argue that the problem is with the hardware.
- mpweiher 9y agoWhich is why Alan Kay famously quipped about "The Wirth school of non-programming".
- AnimalMuppet 9y agoWirth has some valid points. And yet, reading that reminded me of why I hate Wirth-designed languages so much. Wirth says, "Here's the one right way to do it, and the language will not permit you to do otherwise." He even brags in this paper that Oberon's ability to write everything (except the storage manager and device drivers) without using language loopholes is "the most significant progress in language design over 40 years". C++, by contrast, gives you the preferred way to do things, but also gives you the escape hatch if you need it. And Stroustrup, writing the C++ book, says that there is no one right way to program, but "here is an approach that has worked for some people." I prefer Stroustrup's humbler and less dictatorial approach. I've been trapped by Wirth's idea of "the one right way" before, and it's hard to get out of. You have to fight the language to do what you need to do, because the language doesn't think you should be able to do it. And of course the better the language is at stopping you from doing what it thinks you shouldn't do, the harder it makes it when you actually need to do one of those things.