3 ms·

> Very rigid languages take less effort in learning, but at the same time can require the developer to spend a lot more time and effort expressing certain thing

> Very rigid languages take less effort in learning, but at the same time can require the developer to spend a lot more time and effort expressing certain things. See Java. I do not think of Java as a language with few nuances. Null references, broken covariance for arrays, two non-orthogonal notions of modularity (class-based: public, protected and private; package-based: default visibility), value semantics for primitives vs. reference semantics for everything else... it is all very nuanced! Plus, for all the supposed rigidity, you can break type safety via reflection. On the other hand, Haskell and Standard ML (especially the latter!) strike me as very simple languages, with a far more rigid notion of safety than Java programmers could ever dream of, but which nevertheless afford lots of expressivity. Far more than either Python or Java.

Mithaldu 13y ago
Good answer. :) I'd like to point out that nuance density is dependant not only on the language as a whole, but also on the area of a language you're looking at. Compared with Perl's Moo/se Java's object system is ridiculously small and simple, which is corroborated by things that are extremely simple in Perl OO taking pages upon pages of code in Java. As for Haskell, do consider that while the base of it is quite simple, just like Lisp; it also has the massive ball-of-wax that is monads, which people have been trying for years to explain simply. [1] [1] (Though this is mostly because most people trying either don't have the required humbleness to admit they're a hotfix to a core failing of Haskell, or don't dare explain it in those terms.)
- catnaroek 13y ago
  > As for Haskell, do consider that while the base of it is quite simple, just like Lisp Lisp is only syntactically simple. (Admittedly, it is syntactically the simplest.) Semantically, it is still a mess. > it also has the massive ball-of-wax that is monads, which people have been trying for years to explain simply. [1] That is a weird thing to say. Monads are simple: an endofunctor "T : C -> C" with two natural transformations "pure : 1_C -> T" and "join : T^2 -> T", satisfying three coherence laws that basically say "the Kleisli construction yields a category". Of course, explaining monads in terms of "bind" instead of "join" is bound (pun not intended) to result in a huge amount of fail. > [1] (Though this is mostly because most people trying either don't have the required humbleness to admit they're a hotfix to a core failing of Haskell, or don't dare explain it in those terms.) It is not a hotfix. It is a feature. Haskell's segregation of effects makes it possible to reason about effects in a compositional manner, using equational reasoning.
  - Mithaldu 13y ago
    > Monads are simple: ... Ahahaha, please tell me that was meant to be comedy and that you're actually aware of the simple explanation. :D
    - catnaroek 13y ago
      My understanding of the notion of "simple" is based on the following principles: 1. Short definitions are preferable to long ones. 2. Reusable generic definitions are preferable to overspecific ones. 3. Case analysis should be kept to the bare minimum necessary. The notion of "monad" fits these principles perfectly: 1. "A monad is a monoid in the category of endofunctors." Short and to the point. 2. You cannot possibly get anything more reusable and generic than category theory. (Contrast with "instanceof" and reflection breaking type safety, and essentially depending on luck and the stars being aligned in order to work.) 3. There is no case analysis whatsoever in the definition. (Contrast with: "if a pointer is invalid, dereferencing it is undefined behavior, otherwise...", "if a downcast is invalid, performing it will result in a ClassCastException being thrown, otherwise...") Note that my understanding of "simple" actually encourages abstraction (for the benefit of genericity), rather than dissuade it. Abstraction might make things less "easy" (this is subjective, though), but in no way does it make things less "simple" (this is objective).
      - Mithaldu 13y ago
        I literally cannot tell whether you're still being funny or serious. Poe's law is in full effect. (It's still pretty funny to me either way.) That said, try: Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs. Monads are the house rules you bring to your Monopoly game to make it fun. (Yes, that means Haskell is not a fully functional language, it's just more functional than most.)

Mithaldu 13y ago

Good answer. :) I'd like to point out that nuance density is dependant not only on the language as a whole, but also on the area of a language you're looking at. Compared with Perl's Moo/se Java's object system is ridiculously small and simple, which is corroborated by things that are extremely simple in Perl OO taking pages upon pages of code in Java. As for Haskell, do consider that while the base of it is quite simple, just like Lisp; it also has the massive ball-of-wax that is monads, which people have been trying for years to explain simply. [1] [1] (Though this is mostly because most people trying either don't have the required humbleness to admit they're a hotfix to a core failing of Haskell, or don't dare explain it in those terms.)

catnaroek 13y ago
> As for Haskell, do consider that while the base of it is quite simple, just like Lisp Lisp is only syntactically simple. (Admittedly, it is syntactically the simplest.) Semantically, it is still a mess. > it also has the massive ball-of-wax that is monads, which people have been trying for years to explain simply. [1] That is a weird thing to say. Monads are simple: an endofunctor "T : C -> C" with two natural transformations "pure : 1_C -> T" and "join : T^2 -> T", satisfying three coherence laws that basically say "the Kleisli construction yields a category". Of course, explaining monads in terms of "bind" instead of "join" is bound (pun not intended) to result in a huge amount of fail. > [1] (Though this is mostly because most people trying either don't have the required humbleness to admit they're a hotfix to a core failing of Haskell, or don't dare explain it in those terms.) It is not a hotfix. It is a feature. Haskell's segregation of effects makes it possible to reason about effects in a compositional manner, using equational reasoning.
- Mithaldu 13y ago
  > Monads are simple: ... Ahahaha, please tell me that was meant to be comedy and that you're actually aware of the simple explanation. :D
  - catnaroek 13y ago
    My understanding of the notion of "simple" is based on the following principles: 1. Short definitions are preferable to long ones. 2. Reusable generic definitions are preferable to overspecific ones. 3. Case analysis should be kept to the bare minimum necessary. The notion of "monad" fits these principles perfectly: 1. "A monad is a monoid in the category of endofunctors." Short and to the point. 2. You cannot possibly get anything more reusable and generic than category theory. (Contrast with "instanceof" and reflection breaking type safety, and essentially depending on luck and the stars being aligned in order to work.) 3. There is no case analysis whatsoever in the definition. (Contrast with: "if a pointer is invalid, dereferencing it is undefined behavior, otherwise...", "if a downcast is invalid, performing it will result in a ClassCastException being thrown, otherwise...") Note that my understanding of "simple" actually encourages abstraction (for the benefit of genericity), rather than dissuade it. Abstraction might make things less "easy" (this is subjective, though), but in no way does it make things less "simple" (this is objective).
    - Mithaldu 13y ago
      I literally cannot tell whether you're still being funny or serious. Poe's law is in full effect. (It's still pretty funny to me either way.) That said, try: Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs. Monads are the house rules you bring to your Monopoly game to make it fun. (Yes, that means Haskell is not a fully functional language, it's just more functional than most.)