3 ms·

The author is obviously a fan of B&D languages. (http://catb.org/jargon/html/B/bondage-and-discipline-language.html http://catb.org/jargon/html/B/bondage-and-di

The author is obviously a fan of B&D languages. (http://catb.org/jargon/html/B/bondage-and-discipline-language.html http://catb.org/jargon/html/B/bondage-and-discipline-languag...) There's nothing wrong with preferring a little B&D, but it's a shame that there are still masochists in this day and age that claim other languages are "broken" because they don't spank you often enough.

Zak 18y ago
I don't think that's quite it. The author seems to like languages that let programs be as close to provably correct as possible. He also admits that, for some problems, this is a mistake. I used to hate static typing with a passion, and I'm still a pretty big Lisp fan, but I've recently taken up Haskell. Many of the examples in this post use Haskell as an example of the right thing, and I'm really starting to see the advantages. Certain common errors are caught by the compiler, and impure operations show up in a function's type signature, reducing the chances of any spooky action at a distance. Ultimately, I think there's a tradeoff between flexibility and correctness. How much of each to choose depends on the parameters of the project. Some languages try to allow a choice, especially with regard to typing discipline. Haskell offers Data.Dynamic. Common Lisp has optional type declarations and compiler warnings for obvious type errors. There's a post about formalizing such things as "gradual typing" (http://news.ycombinator.com/item?id=556794 http://news.ycombinator.com/item?id=556794).
barrkel 18y ago
There are reasons why compilers for static languages complain so much for those uneducated in their type systems: because the constructs they are rejecting have, on balance, been determined to be unsound by the languages' designers. And most of the time, these decisions are correct. In each language, however, there are usually a few exceptions, most of which are the result of learning over time. For example, Pascal over-uses nominal type equality, which is particularly pernicious with arrays, and, in classical Pascal, strings (fixed-length arrays of chars). And in Java, requiring most possible exceptions to be part of the interface specification is a flaw resulting from a misunderstanding about exceptions: Java seems to feel that no exception should be ignored, while they should actually almost never be caught. And then there are abhorrences like C++, where historical forces have combined to give the language user more power than they can comfortably wield, or can be comfortably implemented in any given compiler.

Zak 18y ago

I don't think that's quite it. The author seems to like languages that let programs be as close to provably correct as possible. He also admits that, for some problems, this is a mistake. I used to hate static typing with a passion, and I'm still a pretty big Lisp fan, but I've recently taken up Haskell. Many of the examples in this post use Haskell as an example of the right thing, and I'm really starting to see the advantages. Certain common errors are caught by the compiler, and impure operations show up in a function's type signature, reducing the chances of any spooky action at a distance. Ultimately, I think there's a tradeoff between flexibility and correctness. How much of each to choose depends on the parameters of the project. Some languages try to allow a choice, especially with regard to typing discipline. Haskell offers Data.Dynamic. Common Lisp has optional type declarations and compiler warnings for obvious type errors. There's a post about formalizing such things as "gradual typing" (http://news.ycombinator.com/item?id=556794 http://news.ycombinator.com/item?id=556794).

barrkel 18y ago

There are reasons why compilers for static languages complain so much for those uneducated in their type systems: because the constructs they are rejecting have, on balance, been determined to be unsound by the languages' designers. And most of the time, these decisions are correct. In each language, however, there are usually a few exceptions, most of which are the result of learning over time. For example, Pascal over-uses nominal type equality, which is particularly pernicious with arrays, and, in classical Pascal, strings (fixed-length arrays of chars). And in Java, requiring most possible exceptions to be part of the interface specification is a flaw resulting from a misunderstanding about exceptions: Java seems to feel that no exception should be ignored, while they should actually almost never be caught. And then there are abhorrences like C++, where historical forces have combined to give the language user more power than they can comfortably wield, or can be comfortably implemented in any given compiler.