6 ms·

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

by zwnow 2y ago

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.
    - layer8 2y ago
      HTTP APIs are just an interface. The application behind it can be almost anything.
    - AnimalMuppet 2y ago
      > > One with lots of persistent mutable state. > You mean like a database? No, I mean like a routing switcher for a TV station. You have a set of inputs and a set of outputs, and you have various sources of control, and you have commands to switch outputs to different inputs. And when one source of control makes a change, you have to update all the other sources of control about the change, so that they have a current view of the world. The state of the current connections is the fundamental thing in the program - more even than controlling the hardware is.
      - youerbt 2y ago
        Thanks. This does sound like a state machine, though, but the devil is probably in the details. Yes, here Haskell is probably a bad choice, and something where direct memory manipulation is bread and butter should do better. Which is completely fine; Haskell is a high level language. But in your example, PHP is also a bad choice, and alas, it dwarfs Haskell in popularity. I can't really think of where PHP is a great fit, but Haskell isn't.
      - mrkeen 2y ago
        Sounds like you want green threads, a concurrent runtime, and best-in-class synchronisation primitives.
- zwnow 2y ago
  I don't have a math background. Without a math background, you will have a bad time with Haskell.
  - tome 2y ago
    There are many successful Haskellers without a math background.
  - TuringTest 2y ago
    Haskell can be taught as recursive programming, learning about accumulator parameters and high order functions. A background in logic (which most programmers have to some degree) is more useful than an approach in math in that regard.
  - yakshaving_jgt 2y ago
    What are you trying to achieve by spreading fear, uncertainty, and doubt here? I don't have a math background. I failed high school maths. I've been working as a professional Haskell programmer for several years. What you are saying is just demonstrably not true. So why are you saying it?
seanparsons 2y ago
I always maintain that this is just familiarity, Haskell is in truth quite a simple language. It's just that the way it works isn't similar to the languages most people have started with.
- agumonkey 2y ago
  I believe there's a strange boundary around the idea of simple vs easy (to quote rich hickey) and I don't know how to call it.. (or if somebody named it before) functional and logical languages are indeed very simple, small core, very general laws.. (logic, recursion, some types) but grokking this requires unplugging from a certain kind of reality. Most people live in the land of tools, syntax and features .. they look paradoxically both simpler than sml/haskell so people are seduced by them, yet more complex at the same time (class systems are often large and full of exceptions) but that also makes it like they're learning something advanced, (and familiar, unlike greek single variables and categ-oids :).
- chongli 2y ago
  Maybe at its core, but Haskell in the wild is monstrously complex because of all the language extensions. Many different people use different sets of extensions so you have to learn them to understand what’s going on!
  - tome 2y ago
    Not really, the vast majority of extensions just relax unnecessary restrictions. And these days it's easy to just enable GHC2021 or GHC2024 and be happy.
- liontwist 2y ago
  Familiarity is a part, but abstract reasoning is fundamentally harder than concrete. Understanding the map signature in Haskell is more difficult than any C construct. Now do IO monad.
  - cartoffal 2y ago
    > Understanding the map signature in Haskell is more difficult than any C construct. This is obviously false. The map type signature is significantly easier to understand than pointers, referencing and dereferencing. I am an educator in computer science - the former takes about 30-60 seconds to grok (even in Haskell, though it translates to most languages, and even the fully generalised fmap), but it is a rare student that fully understands the latter within a full term of teaching.
BeetleB 2y ago
> With the downside of 99% of all devs not understanding anything. I would imagine that probably the majority of Haskell devs would understand it, which is all that matters. 99% of the population doesn't understand anything in Perl, either. That's not a mark against Perl.
deleted 2y ago
[deleted]

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

by 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.
  - layer8 2y ago
    HTTP APIs are just an interface. The application behind it can be almost anything.
  - AnimalMuppet 2y ago
    > > One with lots of persistent mutable state. > You mean like a database? No, I mean like a routing switcher for a TV station. You have a set of inputs and a set of outputs, and you have various sources of control, and you have commands to switch outputs to different inputs. And when one source of control makes a change, you have to update all the other sources of control about the change, so that they have a current view of the world. The state of the current connections is the fundamental thing in the program - more even than controlling the hardware is.
    - youerbt 2y ago
      Thanks. This does sound like a state machine, though, but the devil is probably in the details. Yes, here Haskell is probably a bad choice, and something where direct memory manipulation is bread and butter should do better. Which is completely fine; Haskell is a high level language. But in your example, PHP is also a bad choice, and alas, it dwarfs Haskell in popularity. I can't really think of where PHP is a great fit, but Haskell isn't.
    - mrkeen 2y ago
      Sounds like you want green threads, a concurrent runtime, and best-in-class synchronisation primitives.
zwnow 2y ago
I don't have a math background. Without a math background, you will have a bad time with Haskell.
- tome 2y ago
  There are many successful Haskellers without a math background.
- TuringTest 2y ago
  Haskell can be taught as recursive programming, learning about accumulator parameters and high order functions. A background in logic (which most programmers have to some degree) is more useful than an approach in math in that regard.
- yakshaving_jgt 2y ago
  What are you trying to achieve by spreading fear, uncertainty, and doubt here? I don't have a math background. I failed high school maths. I've been working as a professional Haskell programmer for several years. What you are saying is just demonstrably not true. So why are you saying it?

seanparsons 2y ago

I always maintain that this is just familiarity, Haskell is in truth quite a simple language. It's just that the way it works isn't similar to the languages most people have started with.

agumonkey 2y ago
I believe there's a strange boundary around the idea of simple vs easy (to quote rich hickey) and I don't know how to call it.. (or if somebody named it before) functional and logical languages are indeed very simple, small core, very general laws.. (logic, recursion, some types) but grokking this requires unplugging from a certain kind of reality. Most people live in the land of tools, syntax and features .. they look paradoxically both simpler than sml/haskell so people are seduced by them, yet more complex at the same time (class systems are often large and full of exceptions) but that also makes it like they're learning something advanced, (and familiar, unlike greek single variables and categ-oids :).
chongli 2y ago
Maybe at its core, but Haskell in the wild is monstrously complex because of all the language extensions. Many different people use different sets of extensions so you have to learn them to understand what’s going on!
- tome 2y ago
  Not really, the vast majority of extensions just relax unnecessary restrictions. And these days it's easy to just enable GHC2021 or GHC2024 and be happy.
liontwist 2y ago
Familiarity is a part, but abstract reasoning is fundamentally harder than concrete. Understanding the map signature in Haskell is more difficult than any C construct. Now do IO monad.
- cartoffal 2y ago
  > Understanding the map signature in Haskell is more difficult than any C construct. This is obviously false. The map type signature is significantly easier to understand than pointers, referencing and dereferencing. I am an educator in computer science - the former takes about 30-60 seconds to grok (even in Haskell, though it translates to most languages, and even the fully generalised fmap), but it is a rare student that fully understands the latter within a full term of teaching.

BeetleB 2y ago

> With the downside of 99% of all devs not understanding anything. I would imagine that probably the majority of Haskell devs would understand it, which is all that matters. 99% of the population doesn't understand anything in Perl, either. That's not a mark against Perl.

deleted 2y ago

[deleted]