5 ms·

> So what does unique value proposition does GHC have left? Possibly the GHC runtime system, but it's not as sexy to pitch in a blog post like this. The point

> So what does unique value proposition does GHC have left? Possibly the GHC runtime system, but it's not as sexy to pitch in a blog post like this. The point is that programming in a pure language with typed side effects and immutable data dramatically reduces the size of the state space that must be reasoned about. This makes programming significantly easier (especially over the long term). Of the languages that support this programming style Haskell remains the one with the largest library ecosystem, most comprehensive documentation, and most optimised compiler. I love lean and use it professionally, but it is nowhere near the usability of Haskell when it comes to being a production ready general purpose language.

dataflow 2y ago
> dramatically reduces the size of the state space that must be reasoned about True > This makes programming significantly easier (especially over the long term) Not true. (As in, the implication is not true.) There are many many factors that affect ease of programming and the structure of the stage space is just one of them.
- tkz1312 2y ago
  It’s true that things like docs and error messages are also important, but the fundamental task of understanding and reasoning about code is significantly easier if you restrict yourself to pure functions over immutable data.
  - dataflow 2y ago
    No, I didn't mean docs and error messages, I meant even more basic things. Like sheer code size, visual noise, and intuitiveness, to give a few examples. There's no free lunch, everything is a tradeoff. Just because you're constraining the program's state space that doesn't imply you're making the code more succinct or intuitive. You could easily be adding a ton of distracting noise or obscuring the core logic with all your awesome static typing.
    - tkz1312 2y ago
      I think the relative importance of syntax compared to actual semantics when it comes to ease of understanding is probably rather low. Either way Haskell is also probably the language that lets you produce the most succinct code of anything that could be reasonably be used in production.
      - lemonwaterlime 2y ago
        > Haskell is also probably the language that lets you produce the most succinct code It is. Haskell has the low verbosity of scripting languages like Ruby and Python while letting you manage applications that would otherwise be written in high verbosity languages like C++, Java, and Rust.
        ykonstant 2y ago
        Idris and Lean have a similar advantage; once you get past the general notation, the code syntax is very smooth and easy to follow.
        tkz1312 2y ago
        Totally. ML style syntax is just so much cleaner than the curly braces / semicolon orthodoxy.
User23 2y ago
When you start mathematically characterizing state spaces it quickly becomes apparent that pure functional languages advantage over imperative ones is more a matter of the poor design of popular imperative languages rather than an intrinsic difference. That (in)famous goto paper isn't really about spaghetti code, it's about how on Earth do you mathematically define the semantics of any statement in a language with unrestricted goto. If any continuation can follow literally anything then you're pretty much in no man's land. On the other hand imperative code is easy and natural to reason about when it uses a small set of well defined primitives. If that sounds surprising, consider how mathematical logic itself, especially obviously in the calculational proof style, is essentially a series of assignment statements.
- tkz1312 2y ago
  I’m not quite sure what the point is here. I agree that well written imperative code can be easy to read, and that it’s often the natural style for many problems. I just think it’s always better to use that style in a system that makes the available context explicit and enforces a strict discipline via the type system (e.g. a State monad). Regarding semantics my experience is that defining formal semantics for languages with unrestricted mutation (or even worse aliased pointers into mutable state) than one that avoids those features.

dataflow 2y ago

> dramatically reduces the size of the state space that must be reasoned about True > This makes programming significantly easier (especially over the long term) Not true. (As in, the implication is not true.) There are many many factors that affect ease of programming and the structure of the stage space is just one of them.

tkz1312 2y ago
It’s true that things like docs and error messages are also important, but the fundamental task of understanding and reasoning about code is significantly easier if you restrict yourself to pure functions over immutable data.
- dataflow 2y ago
  No, I didn't mean docs and error messages, I meant even more basic things. Like sheer code size, visual noise, and intuitiveness, to give a few examples. There's no free lunch, everything is a tradeoff. Just because you're constraining the program's state space that doesn't imply you're making the code more succinct or intuitive. You could easily be adding a ton of distracting noise or obscuring the core logic with all your awesome static typing.
  - tkz1312 2y ago
    I think the relative importance of syntax compared to actual semantics when it comes to ease of understanding is probably rather low. Either way Haskell is also probably the language that lets you produce the most succinct code of anything that could be reasonably be used in production.
    - lemonwaterlime 2y ago
      > Haskell is also probably the language that lets you produce the most succinct code It is. Haskell has the low verbosity of scripting languages like Ruby and Python while letting you manage applications that would otherwise be written in high verbosity languages like C++, Java, and Rust.
      - ykonstant 2y ago
        Idris and Lean have a similar advantage; once you get past the general notation, the code syntax is very smooth and easy to follow.
        tkz1312 2y ago
        Totally. ML style syntax is just so much cleaner than the curly braces / semicolon orthodoxy.

User23 2y ago

When you start mathematically characterizing state spaces it quickly becomes apparent that pure functional languages advantage over imperative ones is more a matter of the poor design of popular imperative languages rather than an intrinsic difference. That (in)famous goto paper isn't really about spaghetti code, it's about how on Earth do you mathematically define the semantics of any statement in a language with unrestricted goto. If any continuation can follow literally anything then you're pretty much in no man's land. On the other hand imperative code is easy and natural to reason about when it uses a small set of well defined primitives. If that sounds surprising, consider how mathematical logic itself, especially obviously in the calculational proof style, is essentially a series of assignment statements.

tkz1312 2y ago
I’m not quite sure what the point is here. I agree that well written imperative code can be easy to read, and that it’s often the natural style for many problems. I just think it’s always better to use that style in a system that makes the available context explicit and enforces a strict discipline via the type system (e.g. a State monad). Regarding semantics my experience is that defining formal semantics for languages with unrestricted mutation (or even worse aliased pointers into mutable state) than one that avoids those features.