9 ms·

I gave a talk that goes more into what makes imperative programming better with Haskell compared to traditional imperative languages. https://speakerdeck.com/aj

I gave a talk that goes more into what makes imperative programming better with Haskell compared to traditional imperative languages. https://speakerdeck.com/ajnsit/supercharged-imperative-programming-with-haskell-and-fp https://speakerdeck.com/ajnsit/supercharged-imperative-progr... In a nutshell, first class effects and built in set of patterns for composing them get rid of boilerplate code. Combine that with type safety and you can churn out relatively bug free code very fast.

amelius 2y ago
When will we get the best of both worlds where the imperative parts of a Haskell program run at C++/Rust speeds?
- dismalaf 2y ago
  Probably never since Haskell is always copying and GC'ing data...
  - amelius 2y ago
    Well, you could implement (in Haskell) a separate heap for (all or some of the) imperative code.
- lmm 2y ago
  We've had Scala for about 20 years. (Is the JVM quite C++/Rust speed? No. But it's close enough for any realistic use case)
  - deleted 2y ago
    [deleted]
zwnow 2y ago
With the downside of 99% of all devs not understanding anything. Sure haskell may be a great language, but even greater languages are accessible.
- haskman 2y ago
  Accessibility is not an issue. It takes only a little bit of effort to get productive with a Haskell codebase. I think it's more of a mental block because the language is different from what one might be used to. What Haskell needs, and doesn't have, is a compelling reason for people to make that small effort (i.e. the killer usecase).
  - AnimalMuppet 2y ago
    "Relatively bug free code very fast" sounds like a killer use case to me. So why hasn't it happened? Some possibilities: 1. People are just ignorant/unenlightened. 2. Haskell is too hard to use for most people. I think that different programmers think in different ways, and therefore find different languages to be "natural". To those whom Haskell fits, it really fits, and they have a hard time understanding why it isn't that way for everyone, so they wind up at 1. But for those who it doesn't fit, it's this brick wall that never makes sense. (Yes, this is about the same as 1, just seen from the other side. It says the problem is the language, not the people - the language really doesn't fit most people very well, and we can change languages easier than we can change people.) 3. Haskell isn't a good fit for many kinds of programming. The kind of programs where it fits, it's like a superpower. The kinds where it doesn't, though, it's like picking your nose with boxing gloves on. (Shout out to Michael Pavlinch, from whom I stole that phrase.) What kinds of programs fit? "If you can think of your program like a pipe" is the best explanation I've seen - if data flows in, gets transformed, flows out. What kind of program doesn't fit? One with lots of persistent mutable state. Especially, one where the persistent mutable state is due to the problem, not just to the implementation. Myself, I lean toward a combination of 2 and 3.
    - youerbt 2y ago
      > So why hasn't it happened? 4. History. In those types of discussions, there are always "rational" arguments presented, but this one is missing. > One with lots of persistent mutable state. You mean like a database? I don't see a problem here. In fact, there is a group of programs large enough, that Haskell fits nicely, that it cannot be 3; REST/HTTP APIs. This is pretty much your data goes in, data goes out.
thdhhghgbhy 2y ago
> first class effects There's not really first class effects though, ultimately just IO.
- sfvisser 2y ago
  They’re first class in the sense that they can be described, stored, computed, separated etc from pure functions. Fair to call them first class.
  - thdhhghgbhy 2y ago
    Koka has first class effects, but I think we have different interpretations of the statement above. Could you please clarify what you mean by 'stored'?
- tome 2y ago
  Effect systems like effectful and Bluefin absolutely provide first class effects, ultimately not too dissimilar to Koka.
  - thdhhghgbhy 2y ago
    Okay, might be definitional, but when I think of 'first class', I think of something baked in to the language. So in Haskell's case, in the Prelude I suppose.
    - tome 2y ago
      That's kind of the opposite of what functional programmers mean by "first class", or at least orthogonal. "Functions are first class" means that they don't have any special treatment, relative to other entities. They're not really a special "built-in" thing. You can just pass them around and operate on them like an other sorts of values.
tome 2y ago
Thanks for sharing, I really liked that!

amelius 2y ago

When will we get the best of both worlds where the imperative parts of a Haskell program run at C++/Rust speeds?

dismalaf 2y ago
Probably never since Haskell is always copying and GC'ing data...
- amelius 2y ago
  Well, you could implement (in Haskell) a separate heap for (all or some of the) imperative code.
lmm 2y ago
We've had Scala for about 20 years. (Is the JVM quite C++/Rust speed? No. But it's close enough for any realistic use case)
- deleted 2y ago
  [deleted]

zwnow 2y ago

With the downside of 99% of all devs not understanding anything. Sure haskell may be a great language, but even greater languages are accessible.

haskman 2y ago
Accessibility is not an issue. It takes only a little bit of effort to get productive with a Haskell codebase. I think it's more of a mental block because the language is different from what one might be used to. What Haskell needs, and doesn't have, is a compelling reason for people to make that small effort (i.e. the killer usecase).
- AnimalMuppet 2y ago
  "Relatively bug free code very fast" sounds like a killer use case to me. So why hasn't it happened? Some possibilities: 1. People are just ignorant/unenlightened. 2. Haskell is too hard to use for most people. I think that different programmers think in different ways, and therefore find different languages to be "natural". To those whom Haskell fits, it really fits, and they have a hard time understanding why it isn't that way for everyone, so they wind up at 1. But for those who it doesn't fit, it's this brick wall that never makes sense. (Yes, this is about the same as 1, just seen from the other side. It says the problem is the language, not the people - the language really doesn't fit most people very well, and we can change languages easier than we can change people.) 3. Haskell isn't a good fit for many kinds of programming. The kind of programs where it fits, it's like a superpower. The kinds where it doesn't, though, it's like picking your nose with boxing gloves on. (Shout out to Michael Pavlinch, from whom I stole that phrase.) What kinds of programs fit? "If you can think of your program like a pipe" is the best explanation I've seen - if data flows in, gets transformed, flows out. What kind of program doesn't fit? One with lots of persistent mutable state. Especially, one where the persistent mutable state is due to the problem, not just to the implementation. Myself, I lean toward a combination of 2 and 3.
  - youerbt 2y ago
    > So why hasn't it happened? 4. History. In those types of discussions, there are always "rational" arguments presented, but this one is missing. > One with lots of persistent mutable state. You mean like a database? I don't see a problem here. In fact, there is a group of programs large enough, that Haskell fits nicely, that it cannot be 3; REST/HTTP APIs. This is pretty much your data goes in, data goes out.

thdhhghgbhy 2y ago

> first class effects There's not really first class effects though, ultimately just IO.

sfvisser 2y ago
They’re first class in the sense that they can be described, stored, computed, separated etc from pure functions. Fair to call them first class.
- thdhhghgbhy 2y ago
  Koka has first class effects, but I think we have different interpretations of the statement above. Could you please clarify what you mean by 'stored'?
tome 2y ago
Effect systems like effectful and Bluefin absolutely provide first class effects, ultimately not too dissimilar to Koka.
- thdhhghgbhy 2y ago
  Okay, might be definitional, but when I think of 'first class', I think of something baked in to the language. So in Haskell's case, in the Prelude I suppose.
  - tome 2y ago
    That's kind of the opposite of what functional programmers mean by "first class", or at least orthogonal. "Functions are first class" means that they don't have any special treatment, relative to other entities. They're not really a special "built-in" thing. You can just pass them around and operate on them like an other sorts of values.

tome 2y ago

Thanks for sharing, I really liked that!