7 ms·

Honestly I feel like Haskell and OCaml are severely over-engineered and overly focus on nuance far too much these concepts and ideas can be expressed in a more

Honestly I feel like Haskell and OCaml are severely over-engineered and overly focus on nuance far too much these concepts and ideas can be expressed in a more concise and legible manner in mathematical notation than the programming languages used as examples here.

wyager 9y ago
Haskell is an incredibly simple language with only a few core constructions. You have ADTs/pattern matching and lambda abstraction/application and that's basically it. Everything else in the standard language is (usually straightforward) syntactic sugar around those two concepts. This includes the vast majority of data structures, monads, etc. All the other things that people use exist as (individually) extremely simple extensions that you can learn in isolation in a few minutes. Haskell is possibly the least over-engineered language out there; it's almost as if laziness (no pun intended) was a guiding principle when building the language. Ocaml is more complicated, but I'd still consider it vasty simpler than C++ or Java (as long as you ignore ocaml's object layer).
- Volt 9y ago
  If Haskell is so simple, why is GHC so big? I see your claim repeated often on HN, but I think it's disingenuous.
  - mej10 9y ago
    Because GHC isn't a compiler for just "Haskell -- the standardized language". It also implements a huge number of optional language extensions.
  - mikekchar 9y ago
    Hopefully other people more knowledgeable will answer, but there are a couple things that are pretty obvious off the top of my head: - lazy evaluation - type inference - ridiculous amounts of programmer tools (it *derives* type classes for you!!!) - lots of experimental ideas that are in the compiler but that people don't really use (it's a research tool after all). The language is simple from a conceptual standpoint. Not every thing in the compiler is there simply to support expression of an idea. Quite a lot of it is there to help the programmer. I think there is something to be said for the idea of writing a similar language which has a less monolithic set of tools (although, to be fair, I have not look at the architecture of GHC at all, so maybe it is really beautiful under the hood). The point is that I don't think that you can necessarily equate the simplicity of expression with the complexity of the tools.
  - xrange 9y ago
    Does GHC still come with a copy of GCC and Perl? Hugs is pretty small: https://www.haskell.org/hugs/ https://www.haskell.org/hugs/
  - tathougies 9y ago
    A compiler takes one language (usually higher level) and transforms it into another (usually lower level). GHC, like C, go, or rust compilers, compiles to assembler, a very low-level and complicated language. One would expect that a system to transform a simple high level language into a complicated low level language would would grow proportional to how simple and high level the source language is. Thus, a very simple, high-level language ought to have a larger compiler than a more complicated, lower-level language. Indeed, we see this in real life. Writing a haskell compiler is a fairly big undertaking whereas a C compiler could be written in a few days. This is because C is complicated, but low-level, and Haskell is simple, but high-level. Let's not confuse the simplicity of translation with the simplicity of semantics.
    - qznc 9y ago
      I believe a toy Haskell compiler could be made with comparable effort to toy C compilers. Admittedly, I cannot find people making toy Haskell compilers. What makes Haskell higher-level than C? Garbage collection does not really complicate the compiler if you just use BoehmGC. You can use a simple subset of assembly instead of the full complicated set. Toy C compilers do this, e.g. by treating x86 as a stack machine.
  - jlouis 9y ago
    Simple languages often require complex compilers if they are to run fast. You need to do more analysis of the program structure to squeeze out performance.
- ihm 9y ago
  I take issue with your claim that OCaml is more complicated than Haskell. It has a much simpler core language (roughly Hindley-Milner + ADTs + GADTs + modules) whereas Haskell has Hindley-Milner, ADTs, GADTs, backpack, type families, type classes (plus several mutually inconsistent extensions related to them), new types, "roles", and more.
  - mej10 9y ago
    This is a weird comment since you've purposefully included many Haskell extensions that are in no way part of the "core" language. Hindley-milner, ADTs, type classes, and laziness are core i.e. part of Haskell 2010. GADTs aren't even part of core Haskell. So I guess it is simpler than Ocaml after all!
    - ihm 9y ago
      I intended the phrase "core" to refer to aspects of the language which are commonly used, leaving aside less frequently used or more obscure GHC extensions like existential quantification, functional dependencies, implicit params, etc, etc. Which language features that I mentioned do you not think are commonly used in Haskell?
      - mej10 9y ago
        Backpack, for example, was _literally_ only released in the latest version of GHC. Do you just glance over the subreddit occasionally or something? That would explain your list. You list things that aren't part of the Haskell standard and just claim that they are "core" while not even listing all of the _actually core_ features of OCaml -- all of its OO parts.
  - wyager 9y ago
    You're leaving out a ton of complexity present in ocaml, including first-class mutable references and all their consequences (including broken polymorphism under eta-reduction), order-dependent evaluation, side effectful imports, etc.. Extensions are also common in production ocaml code. I agree the typeclass stuff in Haskell can get complicated, but the more abstruse typeclass features are used about as much as the similarly abstruse ocaml object system. It's usually quite straightforward, just like ocaml modules are usually (but not always) quite straightforward.
- mej10 9y ago
  Since I am calling out the responses to you, I feel like I should do the same here. > All the other things that people use exist as (individually) extremely simple extensions that you can learn in isolation in a few minutes. If by "learn" you mean you can type in something that is the correct syntax, sure... but in terms of actually learning how to use them to model problems? Come on... > Haskell is possibly the least over-engineered language out there Javascript is pretty under-engineered. But more seriously there are several real contenders here in Smalltalk, older Scheme standards, and Go (though again that may be considered under-engineered).
- naasking 9y ago
  > Ocaml is more complicated You have Haskell and OCaml backwards. Certainly Haskell's semantics might seem simpler, but that doesn't make it simpler to program in, which seems to be what you're saying.
  - nv-vn 9y ago
    It's also important to distinguish modern Haskell from what's specified in the Haskell standards. Modern Haskell is basically 100% dependent on GHC's language extensions [1], and as soon as you factor these in the language is vastly more complex than OCaml. [1] https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/lang.html https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_gui...
  - wyager 9y ago
    You're right, I'm only talking about how complicated the core language is, not how hard it is to use. Having worked professionally with both, I'd say OCaml has a gentler learning curve, but you have to do more work forever after getting over the curve.
    - naasking 9y ago
      > I'd say OCaml has a gentler learning curve, but you have to do more work forever after getting over the curve. Why do you suppose that is? Lack of type classes/overloading?
      - wyager 9y ago
        That's a big part of it. If you want to serialzie a list of optional ints, you're going to have to write something like List.serialize (Option.serialize Int.serialize) my_list Whereas in Haskell it's just serialize myList This also shows up with equality and comparison, numeric operators, etc. (which beyond being syntactically inconvenient also makes data structures trickier to use ,usually with a somewhat convoluted functorized data structure module). There are also some things about the language that break composability. For example, the presence of mutable references means you can't compose polymorphic functions (sounds weird, I know), which is inconvenient. It basically boils down to less ability to front-load work by creating good abstractions.
- jstimpfle 9y ago
  EDIT: I have removed what I said about what I think how usable the language is, because it's off-topic. I'm not sure it's the least over-engineered language. What you say is like saying that C is simple because there is only memory and functions! Or, to take from for example https://argumate.tumblr.com/post/118013166244/python-what-if-everything-was-a-dict-java-what https://argumate.tumblr.com/post/118013166244/python-what-if... Python: What if everything was a dict? Java: What if everything was an object? JavaScript: What if everything was a dict *and* an object? C: What if everything was a pointer? APL: What if everything was an array? Tcl: What if everything was a string? Prolog: What if everything was a term? LISP: What if everything was a pair? Scheme: What if everything was a function? Haskell: What if everything was a monad? Assembly: What if everything was a register? But in any case, there are typically lots and lots of details (Haskell is no exception), and they matter. And also, it takes a lot of experience to get anything of quality done! I like what Jonathan Blow calls this pattern: "Big Agenda language". It might make a programmer's life harder if the language is so opinionated. (Start here: https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ) He specifically named Haskell, Java, and a few others, as being guilty of that, and being less usable for sticking to ideological purity.
  - gizmo686 9y ago
    I agree that Haskell is made more difficult than necessary by sticking to purity so tightly [0] Having said that, Haskell is very much not built around the question "what if everything was a monad". Monadic IO wasn't even a thing until Haskell 1.3 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fhistory-of-haskell%2Fhistory.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [0] Although this is, in large part, forced by its unfortunate choice of being lazy. It has also, arguably, forced advances in PL research that would have been avoided had Haskell added first class support for imperative programming.
    - jstimpfle 9y ago
      I agree with you, and disagree with my quote! There are various of these types of lists on the web and I just picked the first I could find, arguably not the best.
- pron 9y ago
  > Haskell is an incredibly simple language with only a few core constructions. The number of constructs has absolutely nothing to do with what people mean by "simplicity of language", although language designers are often confused about this point because they obviously care about the number of constructs. For example, a Turing machine, or even some cellular automata like the game of life, are also extraordinarily simple (much more than Haskell), and yet no one would think to call programming in them simple, and the programming patterns that would emerge if we were forced to, while no doubt very clever, would likely very much deserve the term "over engineered". What matters, then, is not how a language is built, but what programming patterns emerge over time in programs that are written in that language.
tathougies 9y ago
This post has nothing to do with the Haskell or OCaml language. These languages simply be the most obvious ones in which to do language research. Oleg is describing an embedded language. One could embed the language in C++, Python, Java, or any other language. It's just easier and more concise to express nuanced concepts in OCaml and Haskell and other functional languages.

wyager 9y ago

Haskell is an incredibly simple language with only a few core constructions. You have ADTs/pattern matching and lambda abstraction/application and that's basically it. Everything else in the standard language is (usually straightforward) syntactic sugar around those two concepts. This includes the vast majority of data structures, monads, etc. All the other things that people use exist as (individually) extremely simple extensions that you can learn in isolation in a few minutes. Haskell is possibly the least over-engineered language out there; it's almost as if laziness (no pun intended) was a guiding principle when building the language. Ocaml is more complicated, but I'd still consider it vasty simpler than C++ or Java (as long as you ignore ocaml's object layer).

Volt 9y ago
If Haskell is so simple, why is GHC so big? I see your claim repeated often on HN, but I think it's disingenuous.
- mej10 9y ago
  Because GHC isn't a compiler for just "Haskell -- the standardized language". It also implements a huge number of optional language extensions.
- mikekchar 9y ago
  Hopefully other people more knowledgeable will answer, but there are a couple things that are pretty obvious off the top of my head: - lazy evaluation - type inference - ridiculous amounts of programmer tools (it *derives* type classes for you!!!) - lots of experimental ideas that are in the compiler but that people don't really use (it's a research tool after all). The language is simple from a conceptual standpoint. Not every thing in the compiler is there simply to support expression of an idea. Quite a lot of it is there to help the programmer. I think there is something to be said for the idea of writing a similar language which has a less monolithic set of tools (although, to be fair, I have not look at the architecture of GHC at all, so maybe it is really beautiful under the hood). The point is that I don't think that you can necessarily equate the simplicity of expression with the complexity of the tools.
- xrange 9y ago
  Does GHC still come with a copy of GCC and Perl? Hugs is pretty small: https://www.haskell.org/hugs/ https://www.haskell.org/hugs/
- tathougies 9y ago
  A compiler takes one language (usually higher level) and transforms it into another (usually lower level). GHC, like C, go, or rust compilers, compiles to assembler, a very low-level and complicated language. One would expect that a system to transform a simple high level language into a complicated low level language would would grow proportional to how simple and high level the source language is. Thus, a very simple, high-level language ought to have a larger compiler than a more complicated, lower-level language. Indeed, we see this in real life. Writing a haskell compiler is a fairly big undertaking whereas a C compiler could be written in a few days. This is because C is complicated, but low-level, and Haskell is simple, but high-level. Let's not confuse the simplicity of translation with the simplicity of semantics.
  - qznc 9y ago
    I believe a toy Haskell compiler could be made with comparable effort to toy C compilers. Admittedly, I cannot find people making toy Haskell compilers. What makes Haskell higher-level than C? Garbage collection does not really complicate the compiler if you just use BoehmGC. You can use a simple subset of assembly instead of the full complicated set. Toy C compilers do this, e.g. by treating x86 as a stack machine.
- jlouis 9y ago
  Simple languages often require complex compilers if they are to run fast. You need to do more analysis of the program structure to squeeze out performance.
ihm 9y ago
I take issue with your claim that OCaml is more complicated than Haskell. It has a much simpler core language (roughly Hindley-Milner + ADTs + GADTs + modules) whereas Haskell has Hindley-Milner, ADTs, GADTs, backpack, type families, type classes (plus several mutually inconsistent extensions related to them), new types, "roles", and more.
- mej10 9y ago
  This is a weird comment since you've purposefully included many Haskell extensions that are in no way part of the "core" language. Hindley-milner, ADTs, type classes, and laziness are core i.e. part of Haskell 2010. GADTs aren't even part of core Haskell. So I guess it is simpler than Ocaml after all!
  - ihm 9y ago
    I intended the phrase "core" to refer to aspects of the language which are commonly used, leaving aside less frequently used or more obscure GHC extensions like existential quantification, functional dependencies, implicit params, etc, etc. Which language features that I mentioned do you not think are commonly used in Haskell?
    - mej10 9y ago
      Backpack, for example, was _literally_ only released in the latest version of GHC. Do you just glance over the subreddit occasionally or something? That would explain your list. You list things that aren't part of the Haskell standard and just claim that they are "core" while not even listing all of the _actually core_ features of OCaml -- all of its OO parts.
- wyager 9y ago
  You're leaving out a ton of complexity present in ocaml, including first-class mutable references and all their consequences (including broken polymorphism under eta-reduction), order-dependent evaluation, side effectful imports, etc.. Extensions are also common in production ocaml code. I agree the typeclass stuff in Haskell can get complicated, but the more abstruse typeclass features are used about as much as the similarly abstruse ocaml object system. It's usually quite straightforward, just like ocaml modules are usually (but not always) quite straightforward.
mej10 9y ago
Since I am calling out the responses to you, I feel like I should do the same here. > All the other things that people use exist as (individually) extremely simple extensions that you can learn in isolation in a few minutes. If by "learn" you mean you can type in something that is the correct syntax, sure... but in terms of actually learning how to use them to model problems? Come on... > Haskell is possibly the least over-engineered language out there Javascript is pretty under-engineered. But more seriously there are several real contenders here in Smalltalk, older Scheme standards, and Go (though again that may be considered under-engineered).
naasking 9y ago
> Ocaml is more complicated You have Haskell and OCaml backwards. Certainly Haskell's semantics might seem simpler, but that doesn't make it simpler to program in, which seems to be what you're saying.
- nv-vn 9y ago
  It's also important to distinguish modern Haskell from what's specified in the Haskell standards. Modern Haskell is basically 100% dependent on GHC's language extensions [1], and as soon as you factor these in the language is vastly more complex than OCaml. [1] https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/lang.html https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_gui...
- wyager 9y ago
  You're right, I'm only talking about how complicated the core language is, not how hard it is to use. Having worked professionally with both, I'd say OCaml has a gentler learning curve, but you have to do more work forever after getting over the curve.
  - naasking 9y ago
    > I'd say OCaml has a gentler learning curve, but you have to do more work forever after getting over the curve. Why do you suppose that is? Lack of type classes/overloading?
    - wyager 9y ago
      That's a big part of it. If you want to serialzie a list of optional ints, you're going to have to write something like List.serialize (Option.serialize Int.serialize) my_list Whereas in Haskell it's just serialize myList This also shows up with equality and comparison, numeric operators, etc. (which beyond being syntactically inconvenient also makes data structures trickier to use ,usually with a somewhat convoluted functorized data structure module). There are also some things about the language that break composability. For example, the presence of mutable references means you can't compose polymorphic functions (sounds weird, I know), which is inconvenient. It basically boils down to less ability to front-load work by creating good abstractions.
jstimpfle 9y ago
EDIT: I have removed what I said about what I think how usable the language is, because it's off-topic. I'm not sure it's the least over-engineered language. What you say is like saying that C is simple because there is only memory and functions! Or, to take from for example https://argumate.tumblr.com/post/118013166244/python-what-if-everything-was-a-dict-java-what https://argumate.tumblr.com/post/118013166244/python-what-if... Python: What if everything was a dict? Java: What if everything was an object? JavaScript: What if everything was a dict *and* an object? C: What if everything was a pointer? APL: What if everything was an array? Tcl: What if everything was a string? Prolog: What if everything was a term? LISP: What if everything was a pair? Scheme: What if everything was a function? Haskell: What if everything was a monad? Assembly: What if everything was a register? But in any case, there are typically lots and lots of details (Haskell is no exception), and they matter. And also, it takes a lot of experience to get anything of quality done! I like what Jonathan Blow calls this pattern: "Big Agenda language". It might make a programmer's life harder if the language is so opinionated. (Start here: https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ) He specifically named Haskell, Java, and a few others, as being guilty of that, and being less usable for sticking to ideological purity.
- gizmo686 9y ago
  I agree that Haskell is made more difficult than necessary by sticking to purity so tightly [0] Having said that, Haskell is very much not built around the question "what if everything was a monad". Monadic IO wasn't even a thing until Haskell 1.3 https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/history.pdf?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fhistory-of-haskell%2Fhistory.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... [0] Although this is, in large part, forced by its unfortunate choice of being lazy. It has also, arguably, forced advances in PL research that would have been avoided had Haskell added first class support for imperative programming.
  - jstimpfle 9y ago
    I agree with you, and disagree with my quote! There are various of these types of lists on the web and I just picked the first I could find, arguably not the best.
pron 9y ago
> Haskell is an incredibly simple language with only a few core constructions. The number of constructs has absolutely nothing to do with what people mean by "simplicity of language", although language designers are often confused about this point because they obviously care about the number of constructs. For example, a Turing machine, or even some cellular automata like the game of life, are also extraordinarily simple (much more than Haskell), and yet no one would think to call programming in them simple, and the programming patterns that would emerge if we were forced to, while no doubt very clever, would likely very much deserve the term "over engineered". What matters, then, is not how a language is built, but what programming patterns emerge over time in programs that are written in that language.

tathougies 9y ago

This post has nothing to do with the Haskell or OCaml language. These languages simply be the most obvious ones in which to do language research. Oleg is describing an embedded language. One could embed the language in C++, Python, Java, or any other language. It's just easier and more concise to express nuanced concepts in OCaml and Haskell and other functional languages.