8 ms·

I like that Haskell exists, but stuff like this article demonstrates why it isn't adopted widely. Imperative programming is the most natural thing for people.

I like that Haskell exists, but stuff like this article demonstrates why it isn't adopted widely. Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." Some languages take that model and run with it, and add features that are not "pure" but let people get work done. We all know which ones those are. If you work in industry they are the ones you use. Haskell rejects the imperative model, yet it attempts to appear imperative to be palatable to more people while retaining a pure functional model under the hood. But that causes it to be criticized by the pure-minded. So who is it for?

danidiaz 7y ago
I think the position that do-notation is harmful is nowadays in the minority. Personally, I prefer it to long chains of monadic operators. It proved so convenient that there are extensions like "ApplicativeDo" that let you use do-notation in contexts other than monadic: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-ApplicativeDo https://downloads.haskell.org/~ghc/latest/docs/html/users_gu... > Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." I'm not sure. For example, do users of Excel really care in which order the cells are calculated, beyond the order imposed by the data dependencies they have defined?
mrkeen 7y ago
What work could you not get done in Haskell?
- MaxBarraclough 7y ago
  Technical answer: Hard real-time systems. Non-technical answer: Handing over your implementation to an average programmer.
  - jbotz 7y ago
    Try handing your rust implementation over to a Java programmer. Or even your C implementation, which might be worse because they might think they can hack it, but are likely to introduce nasty and hard to find bugs. With Haskell, once they've learned enough Haskell to be able to understand some of your code, if they modify it and it compiles it's (more) likely to be correct.
felixyz 7y ago
I think you're right that imperative semantics are natural for people in some contexts, but far from all the time. For someone who has worked hard day after day for years to fit all kinds of problems into an imperative mould, it will of course appear more "natural" than for others. Cooking recipes are good examples of imperative "scripts", and for the most part it would be silly to try to write them in a declarative style. But note that they too often contain declarative formulas, like "if the pancakes stick to the pan, use more butter". It's the most natural thing in the world to add such regulative rules. There is no mention of exactly when this rule should be applied, in the sense of where it fits into a sequence, and trying to formulate it that way would be cumbersome. It's a big drawback for the industry languages you allude to (and for the software industry as a whole) that there is no simple way to integrate such rules into programs. (I suppose aspect oriented programming is/was an attempt at that.) You can also read through the rules for any board game. They typically consist of a mix of imperative, sequential instructions, regulative rules, and constraints. Why? Because that is the most natural thing.
- spindle 7y ago
  I agree. System configuration is a good example of something that's not naturally imperative - hence the success of NixOS and other declarative configuration tools. ("Success" in the sense that they work really well. I realise they haven't taken over the world.)
  - tetha 7y ago
    Monitoring feels like that as well. You usually end up with a more imperative part to execute a check or to pull data and push it to a monitoring system. "Call this API / read this file. For each line / json key, mangle into monitoring format. Add in missing metadata. Push all resulting lines to monitoring ingress host". Beyond that, our icinga has a very declarative config file. "This is host foo.local, it runs a tomcat with application X and a mysql and backups". The system then goes ahead and figures out what kind of checks might be necessary for an application X, or backups.
- deleted 7y ago
  [deleted]
noelwelsh 7y ago
You're misunderstanding Haskell and do-notation. Haskell does not "[attempt] to appear imperative to be palatable to more people". Haskell has to have a way of handling effects because no useful program can be written without effects. Even if that is as simple as printing output on completion, that is still an effect. Haskell furthermore needs to integrate effects into the language in such as way it does not break the substitution model of evaluation because 1) that's the goal of Haskell as defined back in 1992-ish and 2) order of evaluation is hard to reason about in a lazy language. Monads are Haskell's solution to this, and do-notation is syntax that makes monads easier to use. There is nothing here to do with popularity. Furthermore, claims that "Imperative programming is the most natural thing for people" is not true. All programming is an artificial construction. There is no "naturalness" to be found here, only familiarity and prior experience. In my experience non-programmers take easily to functional programming. Experienced imperative programmers may struggle a bit.
goto11 7y ago
> it attempts to appear imperative to be palatable to more people I doubt that was the reasoning, given the Haskell slogan of "Avoid success at all costs". Imperative is most natural when you have mutable state and side effect. Haskell does not deny that. But even imperative languages (anything above assembler) have both statements and expressions. Haskell just tries to move as much as possible to expressions, and reduce and isolate mutable state and side effects.
raverbashing 7y ago
The way I see it, they try to separate the "pure" from the "imperative" world but the imperative world is like trying to write a completely different language. Then they try to "make it easy" through some constructs like 'do' and >>= but it still feels like controlling an airplane using an Atari joystick. In language and API design it seems it's very easy to shoot yourself in the foot and create problems that wouldn't exist in the first place had a more sensible approach been taken (which I agree it is hard sometimes).
otabdeveloper4 7y ago
> Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." No way. Have you ever mentored technical people who aren't specifically trained programmers by education? These kinds of people will have no problem writing huge SQL queries with joins nested four levels deep, or pages and pages of declarative Pandas or R code using weird transformation and filter logic, but they'll have humongous problems understanding simple loops or variable assignment. Another data point to consider: Excel is the most popular programming environment in the world, and it's also declarative, not imperative.
- cousin_it 7y ago
  Yes, Excel and SQL are widely used by non-programmers due to some engineering quality. But whatever that quality is, Haskell (very narrowly used even by programmers) doesn't seem to share it.
  - otabdeveloper4 7y ago
    I'm trying to say that whatever makes Haskell unpopular, it's not its declarative nature. Whoever manages to make a purely declarative general-purpose programming language will be a technological superstar, because for normal non-programmer folks it would be the ideal gateway to programming. (That said, I don't think it's possible. 'General purpose' implies some sort of Turing completeness, i.e., recursion or loops, which immediately makes it impossible to reason about in normal declarative terms.)
    - pjc50 7y ago
      You would have to add some kind of statefulness, which I suspect is the thing that those people are having trouble reasoning about (and which is also an argument for making things immutable even in imperative languages!). "Statecharts"? Some other kind of boxes-and-arrows Moore/Mealy machine visualisation?
    - wwright 7y ago
      I think we can be a little more optimistic than that. I agree that it’s probably a white whale to try to build a language which is fully declarative 100% of the time, but if we can make something that is simple and declarative 80% of the time, but falls back to something as graceful as Python for the other 20%, that may be enough to have a really big impact.
hnick 7y ago
I also like that it exists. It's interesting if nothing else. > Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." I think back to the sandwich example most of us had in CS class. Step by step, how do you make a sandwich? And then the teacher will always trip us up with a step we forgot. The problem is that with current computer programming, you can't just say "Make me a sandwich" you have to specify it in excruciating detail. Naturally, an imperative form suits this. But if we could in fact get sandwich making right, roll it out via code-reuse, and collapse that into one command, a more functional style might suit. Say what you want to achieve, instead of how to achieve it, and suddenly the order matters a bit less. Let the computer care about that. Maybe that's not possible with current architectures or programming languages, I don't know. It would be nice though.
- felixyz 7y ago
  Logic programming comes the closest. (Not that the goal is fully achieved yet.)
- benibela 7y ago
  Or you have a library and then just write new Sandwich
- andrekandre 7y ago
  > But if we could in fact get sandwich making right, roll it out via code-reuse, and collapse that into one command, a more functional style might suit. Say what you want to achieve, instead of how to achieve it, and suddenly the order matters a bit less. Let the computer care about that. Maybe that's not possible with current architectures or programming languages... the problem is business/marketing imo once you've made your sandwich making declaritive, safe, and predictable, business will always ask for a sandwich with some crazy requirement like "also dispenses ketchup at 2am" or "can also be used as a substitute for morning coffee"... things it was never intended to do i feel the world of programming will never find a "one true way" and will always be a mess because our assumptions are always changing and never static (at least as long as we are chasing the next dollar at least)
nilkn 7y ago
I don’t think I’d judge the language too much based on this article. It’s over a decade old and modern Haskell has progressed quite a bit since then. During the 2010s the language community really shifted towards becoming more practical. It certainly has still maintained an academic element too but that side of things doesn’t dominate nearly as much anymore.
lmm 7y ago
> Haskell rejects the imperative model, yet it attempts to appear imperative to be palatable to more people while retaining a pure functional model under the hood. But that causes it to be criticized by the pure-minded. The point of do notation is to rebuild imperative programming atop a rigorous foundation. Haskell is a deliberately flexible language: if you want to do imperative programming in it, you can (as long as you do it properly). But most users eventually find that the imperative model isn't actually something you want or need, even if you thought you did when you started. > So who is it for? People for whom the defect rate of traditional imperative programming is too high, or for whom achieving an acceptable defect rate in a traditional language takes too much time.
wwright 7y ago
IMO, imperative programming is only intuitive for imperative tasks. Many common programming tasks may be imperative, but many are not. Looking up a product number, placing that product in cart, and checking out is a naturally imperative flow. Humans would think about this somewhat imperatively and iteratively if they were doing it in the real world. However, other tasks like formatting or searching data are usually not intuitively imperative in my experience. As programmers, we build a habit for translating these ideas to imperative sequences, but I don’t think that’s obvious to people who haven’t practiced it. Compare a regular expression to a 40 line manually-written matching algorithm. If you ignore syntax, I think many people would agree that the regular expression which directly describes the goal is more intuitive to think about than the imperative machinery that achieves the same thing.
exdsq 7y ago
Actually this is wrong - for example one study [0] shows only 12% of non-programmers approach problems like this while 54% use event-based approaches. Anecdotally, I've found good mathematicians who come to programming after their studies tend to dislike imperative systems too. http://alumni.cs.ucr.edu/~ratana/PaneRatanamahatanaMyers00.pdf http://alumni.cs.ucr.edu/~ratana/PaneRatanamahatanaMyers00.p...
ashtonkem 7y ago
Honestly, I think that the reason why Haskell never got adopted is that they never really tried. A ton of the decisions over the years they’ve made would’ve been insane for an industry language, but appear to have been non-problematic for their goals. What would’ve happened if they’d tried is an interesting counter factual. My biggest problem with Haskell is that is damn near impossible for me to mentally parse. I always end up liberally sprinkling my code with parenthesis and “$” hoping to make the compiler happy. I never managed to develop a mental framework to help me out here.

danidiaz 7y ago

I think the position that do-notation is harmful is nowadays in the minority. Personally, I prefer it to long chains of monadic operators. It proved so convenient that there are extensions like "ApplicativeDo" that let you use do-notation in contexts other than monadic: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-ApplicativeDo https://downloads.haskell.org/~ghc/latest/docs/html/users_gu... > Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." I'm not sure. For example, do users of Excel really care in which order the cells are calculated, beyond the order imposed by the data dependencies they have defined?

mrkeen 7y ago

What work could you not get done in Haskell?

MaxBarraclough 7y ago
Technical answer: Hard real-time systems. Non-technical answer: Handing over your implementation to an average programmer.
- jbotz 7y ago
  Try handing your rust implementation over to a Java programmer. Or even your C implementation, which might be worse because they might think they can hack it, but are likely to introduce nasty and hard to find bugs. With Haskell, once they've learned enough Haskell to be able to understand some of your code, if they modify it and it compiles it's (more) likely to be correct.

felixyz 7y ago

I think you're right that imperative semantics are natural for people in some contexts, but far from all the time. For someone who has worked hard day after day for years to fit all kinds of problems into an imperative mould, it will of course appear more "natural" than for others. Cooking recipes are good examples of imperative "scripts", and for the most part it would be silly to try to write them in a declarative style. But note that they too often contain declarative formulas, like "if the pancakes stick to the pan, use more butter". It's the most natural thing in the world to add such regulative rules. There is no mention of exactly when this rule should be applied, in the sense of where it fits into a sequence, and trying to formulate it that way would be cumbersome. It's a big drawback for the industry languages you allude to (and for the software industry as a whole) that there is no simple way to integrate such rules into programs. (I suppose aspect oriented programming is/was an attempt at that.) You can also read through the rules for any board game. They typically consist of a mix of imperative, sequential instructions, regulative rules, and constraints. Why? Because that is the most natural thing.

spindle 7y ago
I agree. System configuration is a good example of something that's not naturally imperative - hence the success of NixOS and other declarative configuration tools. ("Success" in the sense that they work really well. I realise they haven't taken over the world.)
- tetha 7y ago
  Monitoring feels like that as well. You usually end up with a more imperative part to execute a check or to pull data and push it to a monitoring system. "Call this API / read this file. For each line / json key, mangle into monitoring format. Add in missing metadata. Push all resulting lines to monitoring ingress host". Beyond that, our icinga has a very declarative config file. "This is host foo.local, it runs a tomcat with application X and a mysql and backups". The system then goes ahead and figures out what kind of checks might be necessary for an application X, or backups.
deleted 7y ago
[deleted]

noelwelsh 7y ago

You're misunderstanding Haskell and do-notation. Haskell does not "[attempt] to appear imperative to be palatable to more people". Haskell has to have a way of handling effects because no useful program can be written without effects. Even if that is as simple as printing output on completion, that is still an effect. Haskell furthermore needs to integrate effects into the language in such as way it does not break the substitution model of evaluation because 1) that's the goal of Haskell as defined back in 1992-ish and 2) order of evaluation is hard to reason about in a lazy language. Monads are Haskell's solution to this, and do-notation is syntax that makes monads easier to use. There is nothing here to do with popularity. Furthermore, claims that "Imperative programming is the most natural thing for people" is not true. All programming is an artificial construction. There is no "naturalness" to be found here, only familiarity and prior experience. In my experience non-programmers take easily to functional programming. Experienced imperative programmers may struggle a bit.

goto11 7y ago

> it attempts to appear imperative to be palatable to more people I doubt that was the reasoning, given the Haskell slogan of "Avoid success at all costs". Imperative is most natural when you have mutable state and side effect. Haskell does not deny that. But even imperative languages (anything above assembler) have both statements and expressions. Haskell just tries to move as much as possible to expressions, and reduce and isolate mutable state and side effects.

raverbashing 7y ago

The way I see it, they try to separate the "pure" from the "imperative" world but the imperative world is like trying to write a completely different language. Then they try to "make it easy" through some constructs like 'do' and >>= but it still feels like controlling an airplane using an Atari joystick. In language and API design it seems it's very easy to shoot yourself in the foot and create problems that wouldn't exist in the first place had a more sensible approach been taken (which I agree it is hard sometimes).

otabdeveloper4 7y ago

> Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." No way. Have you ever mentored technical people who aren't specifically trained programmers by education? These kinds of people will have no problem writing huge SQL queries with joins nested four levels deep, or pages and pages of declarative Pandas or R code using weird transformation and filter logic, but they'll have humongous problems understanding simple loops or variable assignment. Another data point to consider: Excel is the most popular programming environment in the world, and it's also declarative, not imperative.

cousin_it 7y ago
Yes, Excel and SQL are widely used by non-programmers due to some engineering quality. But whatever that quality is, Haskell (very narrowly used even by programmers) doesn't seem to share it.
- otabdeveloper4 7y ago
  I'm trying to say that whatever makes Haskell unpopular, it's not its declarative nature. Whoever manages to make a purely declarative general-purpose programming language will be a technological superstar, because for normal non-programmer folks it would be the ideal gateway to programming. (That said, I don't think it's possible. 'General purpose' implies some sort of Turing completeness, i.e., recursion or loops, which immediately makes it impossible to reason about in normal declarative terms.)
  - pjc50 7y ago
    You would have to add some kind of statefulness, which I suspect is the thing that those people are having trouble reasoning about (and which is also an argument for making things immutable even in imperative languages!). "Statecharts"? Some other kind of boxes-and-arrows Moore/Mealy machine visualisation?
  - wwright 7y ago
    I think we can be a little more optimistic than that. I agree that it’s probably a white whale to try to build a language which is fully declarative 100% of the time, but if we can make something that is simple and declarative 80% of the time, but falls back to something as graceful as Python for the other 20%, that may be enough to have a really big impact.

hnick 7y ago

I also like that it exists. It's interesting if nothing else. > Imperative programming is the most natural thing for people. "Do this, then that, then that, in that order." I think back to the sandwich example most of us had in CS class. Step by step, how do you make a sandwich? And then the teacher will always trip us up with a step we forgot. The problem is that with current computer programming, you can't just say "Make me a sandwich" you have to specify it in excruciating detail. Naturally, an imperative form suits this. But if we could in fact get sandwich making right, roll it out via code-reuse, and collapse that into one command, a more functional style might suit. Say what you want to achieve, instead of how to achieve it, and suddenly the order matters a bit less. Let the computer care about that. Maybe that's not possible with current architectures or programming languages, I don't know. It would be nice though.

felixyz 7y ago
Logic programming comes the closest. (Not that the goal is fully achieved yet.)
benibela 7y ago
Or you have a library and then just write new Sandwich
andrekandre 7y ago
> But if we could in fact get sandwich making right, roll it out via code-reuse, and collapse that into one command, a more functional style might suit. Say what you want to achieve, instead of how to achieve it, and suddenly the order matters a bit less. Let the computer care about that. Maybe that's not possible with current architectures or programming languages... the problem is business/marketing imo once you've made your sandwich making declaritive, safe, and predictable, business will always ask for a sandwich with some crazy requirement like "also dispenses ketchup at 2am" or "can also be used as a substitute for morning coffee"... things it was never intended to do i feel the world of programming will never find a "one true way" and will always be a mess because our assumptions are always changing and never static (at least as long as we are chasing the next dollar at least)

nilkn 7y ago

I don’t think I’d judge the language too much based on this article. It’s over a decade old and modern Haskell has progressed quite a bit since then. During the 2010s the language community really shifted towards becoming more practical. It certainly has still maintained an academic element too but that side of things doesn’t dominate nearly as much anymore.

lmm 7y ago

> Haskell rejects the imperative model, yet it attempts to appear imperative to be palatable to more people while retaining a pure functional model under the hood. But that causes it to be criticized by the pure-minded. The point of do notation is to rebuild imperative programming atop a rigorous foundation. Haskell is a deliberately flexible language: if you want to do imperative programming in it, you can (as long as you do it properly). But most users eventually find that the imperative model isn't actually something you want or need, even if you thought you did when you started. > So who is it for? People for whom the defect rate of traditional imperative programming is too high, or for whom achieving an acceptable defect rate in a traditional language takes too much time.

wwright 7y ago

IMO, imperative programming is only intuitive for imperative tasks. Many common programming tasks may be imperative, but many are not. Looking up a product number, placing that product in cart, and checking out is a naturally imperative flow. Humans would think about this somewhat imperatively and iteratively if they were doing it in the real world. However, other tasks like formatting or searching data are usually not intuitively imperative in my experience. As programmers, we build a habit for translating these ideas to imperative sequences, but I don’t think that’s obvious to people who haven’t practiced it. Compare a regular expression to a 40 line manually-written matching algorithm. If you ignore syntax, I think many people would agree that the regular expression which directly describes the goal is more intuitive to think about than the imperative machinery that achieves the same thing.

exdsq 7y ago

Actually this is wrong - for example one study [0] shows only 12% of non-programmers approach problems like this while 54% use event-based approaches. Anecdotally, I've found good mathematicians who come to programming after their studies tend to dislike imperative systems too. http://alumni.cs.ucr.edu/~ratana/PaneRatanamahatanaMyers00.pdf http://alumni.cs.ucr.edu/~ratana/PaneRatanamahatanaMyers00.p...

ashtonkem 7y ago

Honestly, I think that the reason why Haskell never got adopted is that they never really tried. A ton of the decisions over the years they’ve made would’ve been insane for an industry language, but appear to have been non-problematic for their goals. What would’ve happened if they’d tried is an interesting counter factual. My biggest problem with Haskell is that is damn near impossible for me to mentally parse. I always end up liberally sprinkling my code with parenthesis and “$” hoping to make the compiler happy. I never managed to develop a mental framework to help me out here.