Hacker News Reader

Comment by twblalock | Hacker News Reader

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?

View on HN

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.

> 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.

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.

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.)

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?

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.

Non sequitur. Excel shows that declarative systems can be popular and easily accessible by non-programmers. Not that any declarative system will automatically be popular!

It is an interesting observation that declarative logic apparently is more intuitive to non-programmers than it is to programmers trained in imperative programming.

To me a more likely explanation is that non-Turing-complete languages are easier to understand overall, but among Turing-complete languages, imperative is easier to understand. The popularity data seems to bear it out.

Isn't Excel Turing-complete?

> 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.

I think that comes from their mathematics background.

I'd like to wheel out the "left handed scissors" argument again; the large and persistent arguments over what is most intuitive should be taken as evidence that different people find different things intuitive or comfortable.

Which is more natural to use, a symmetrical mouse or one with a slight bend to it in a comma shape to more closely fit being held in the right hand? What happens when a left handed person picks it up?

Excel works around IO problem by not having IO. User enters data into cells and the program works on them "not knowing" how the data got there.

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.

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.)

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.

Cooking recipes are interesting - I often note how un-imperative (or at least, implicitly parallelised) they can be throughout, e.g.

- Wash the rice - Boil the rice gently for 20 mins - Whilst the rice is cooking, sauté the finely diced onions.. - Before they've turned brown...

And this only increases with the experience of the chefs involved. When an experienced chef discusses a dish with another experienced chef, they will talk in common high-level abstractions like roux and emulsifier without going into detail in how to first make those components.

And then at the next level up is complete base recipes, like "this is essentially a bearnaise except with _____" or "you start with a ______ but instead of _____ you _____". So the recipes are expressed with combinators over modifiers and existing recipes.

Love it.

This reminds me of a website called Cooking For Engineers[1] which uses diagrams to represent the parallel and sequential parts of a recipe (e.g. [2]).

[1] http://www.cookingforengineers.com/

[2] http://www.cookingforengineers.com/recipe/172/Pan-Pizza/trn

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_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?

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.

Logic programming comes the closest. (Not that the goal is fully achieved yet.)

Or you have a library and then just write

     new Sandwich

> 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)

Yes I've basically reached the same conclusion, unless we have a major shift in how programming itself works (AI assisted or more declarative like I said or whatever). It goes further than business/marketing though, even programmers do it to themselves.

Many languages have a package repository like CPAN for Perl, but you'll still find multiple modules trying to do the same thing but slightly differently, and even when there's a clear winner there's often a lot of complexity in using it.

Some things like sending an email are relatively well handled while others like XML parsing have a lot of warts. Then you get that urge to rewrite because there's no possible reason it has to be this complicated, and you become what you hate and add to the mess :)

> It goes further than business/marketing though, even programmers do it to themselves

that is true as well... something of a blind-spot since it happens right under our nose (or maybe said better, right behind out eyes where we cant see it)

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.

> 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.

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.

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.

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.p...

> 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.

What work could you not get done in Haskell?

Technical answer: Hard real-time systems.

Non-technical answer: Handing over your implementation to an average programmer.

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.

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).

Reply on news.ycombinator.com