5 ms·

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 mos

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.
  - catlifeonmars 2y ago
    That’s an unfair comparison because these are two unrelated concepts. In many languages, pointers are abstracted away anyway. Something more analogous would be map vs a range loop.
    - Sardtok 2y ago
      Well, he responded to someone saying the type signature of map was more complicated than ANY C construct.
      - catlifeonmars 2y ago
        Fair point
    - dhruvrajvanshi 2y ago
      And I'd say the average React or Java developer these days understands both pretty well. It's the default way to render a list of things in React. Java streams are also adopted quite well in my experience. I wouldn't say one is more difficult than the other. IMO `map` is a really bad example for the point that OP is trying to make, since it's almost everywhere these days. FlatMap might be a better example, but people call `.then` on Promises all the time. I think it might just be familiarity at this point. Generally, programming has sort of become more `small f` functional. I'd call purely functional languages like Haskell Capital F Functional, which are still quite obscure.
  - 2y ago
layer8 2y ago
People intuitively expect things to happen imperatively (and eagerly). Imperativeness is deeply ingrained in our daily experience, due to how we interact with the world. While gaining familiarity helps, I’m not convinced that having imperative code as the non-default case that needs to be marked specially in the code and necessitates higher-order types is good ergonomics for a general-purpose programming language.
- BeetleB 2y ago
  > People intuitively expect things to happen imperatively (and eagerly). Eagerly? Yes. Imperatively? Not as much as SW devs tend to think. When the teacher tells you to sort the papers alphabetically, he's communicating functionally, not imperatively. When the teacher tells you to separate the list of papers by section, he's communicating functionally, not imperatively. When he tells you to sum up the scores on all the exams, and partition by thresholds (90% and above is an A, 80% above and above is a B, etc), he's communicating functionally, not imperatively. No one expects to be told to do it in a "for loop" style: "Take a paper, add up the scores, and if it is more than 90%, put it in this pile. If it is between 80-90%, put it in this pile, ... Then go and do the same to the next paper." People usually don't talk that way.
  - 3836293648 2y ago
    Well, declaratively, not functionally. But point mostly stands
  - layer8 2y ago
    You’re talking about what vs. how, but imperative vs. pure-functional is both about the how, not the what. When you’re explaining someone how to sort physical objects, they will think in terms of “okay I’ll do x [a physical mutable state change] and then I’ll have achieved physical state y, and then I’ll do z (etc.)”.
  - CRConrad 2y ago
    Nope. The fact that he's telling you a high-level command is irrelevant. (If you didn't know what “sort the papers” means, he'd have to tell you in more detail; it's just the difference between calling your built-in sort routine or coding it.) Anyway: He's telling you to do something, and you do it. It doesn't get more imperative than that.

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.
- catlifeonmars 2y ago
  That’s an unfair comparison because these are two unrelated concepts. In many languages, pointers are abstracted away anyway. Something more analogous would be map vs a range loop.
  - Sardtok 2y ago
    Well, he responded to someone saying the type signature of map was more complicated than ANY C construct.
    - catlifeonmars 2y ago
      Fair point
  - dhruvrajvanshi 2y ago
    And I'd say the average React or Java developer these days understands both pretty well. It's the default way to render a list of things in React. Java streams are also adopted quite well in my experience. I wouldn't say one is more difficult than the other. IMO `map` is a really bad example for the point that OP is trying to make, since it's almost everywhere these days. FlatMap might be a better example, but people call `.then` on Promises all the time. I think it might just be familiarity at this point. Generally, programming has sort of become more `small f` functional. I'd call purely functional languages like Haskell Capital F Functional, which are still quite obscure.
- 2y ago

layer8 2y ago

People intuitively expect things to happen imperatively (and eagerly). Imperativeness is deeply ingrained in our daily experience, due to how we interact with the world. While gaining familiarity helps, I’m not convinced that having imperative code as the non-default case that needs to be marked specially in the code and necessitates higher-order types is good ergonomics for a general-purpose programming language.

BeetleB 2y ago
> People intuitively expect things to happen imperatively (and eagerly). Eagerly? Yes. Imperatively? Not as much as SW devs tend to think. When the teacher tells you to sort the papers alphabetically, he's communicating functionally, not imperatively. When the teacher tells you to separate the list of papers by section, he's communicating functionally, not imperatively. When he tells you to sum up the scores on all the exams, and partition by thresholds (90% and above is an A, 80% above and above is a B, etc), he's communicating functionally, not imperatively. No one expects to be told to do it in a "for loop" style: "Take a paper, add up the scores, and if it is more than 90%, put it in this pile. If it is between 80-90%, put it in this pile, ... Then go and do the same to the next paper." People usually don't talk that way.
- 3836293648 2y ago
  Well, declaratively, not functionally. But point mostly stands
- layer8 2y ago
  You’re talking about what vs. how, but imperative vs. pure-functional is both about the how, not the what. When you’re explaining someone how to sort physical objects, they will think in terms of “okay I’ll do x [a physical mutable state change] and then I’ll have achieved physical state y, and then I’ll do z (etc.)”.
- CRConrad 2y ago
  Nope. The fact that he's telling you a high-level command is irrelevant. (If you didn't know what “sort the papers” means, he'd have to tell you in more detail; it's just the difference between calling your built-in sort routine or coding it.) Anyway: He's telling you to do something, and you do it. It doesn't get more imperative than that.