Hacker News Reader

Comment by jimbob45 | Hacker News Reader

No one has ever been able to explain to me why I should use Haskell instead of something else. I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

I know Carmack has presented a case to code in a pure functional style here https://www.gamasutra.com/view/news/169296/Indepth_Functiona... but that somewhat precludes the necessity of switching to another language from C++. Further, he advocates for a new keyword 'pure' to assist the compiler like const does, perhaps not knowing that const doesn't actually help the compiler out in practice.

View on HN

> but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

I would add that the elitist signaling that is rampant in functional programming in general and the Haskell community in particular is also not helpful.

I guess that's the main problem.

And look, defining a problem functionally works great on 10% of the cases, but it complicates some 40% of other cases (very imprecise numbers).

The world is not functional, as it turns out. And a lot of those cases where you can write functionally don't gain much from a performance or correctness perspective compared to the procedural version

> The world is not functional

What does this even mean? If the world is not functional, then what is it? Is the world procedural? And what world are we talking about? Our planet, physically? Are you then discounting the worlds of mathematics and logic? You don’t gain performance? What performance? Program execution speed? Development pace and time to market?

Compared to the procedural version? Is your view that procedural programming is inherently better — for any definition of the word — regardless of context? Would SQL queries be easier to write if we told the query planner what to do? Is the entire field of logic programming — and by extension expert systems and AI — just a big waste of time?

So many vague aphorisms which do nothing to further the debate. And Haskellers are the ones getting called “elitist”!

It's not vague, processors are still procedural. Network, disk, terminals, they all have side effects. Memory and disk are limited.

SQL queries are exactly one of those cases where functional expression of a problem outperforms the procedural expression, and that's why they're used where it matters.

Are you suggesting functional programming is somehow so resource intensive that it is impractical to use? Or that functional programming makes effectful work impractical?

Because neither of those are true.

You’ve conceded that SQL queries are one case where a functional approach is more ergonomic (after first asserting that the world is not functional, whatever that means). Why aren’t there other cases? Are you sure there aren’t other cases? One could argue that a functional approach maps more practically and ergonomically for the majority of general programming work than other mainstream approach.

> Are you suggesting functional programming is somehow so resource intensive that it is impractical to use? Or that functional programming makes effectful work impractical? Because neither of those are true.

No, I'm saying the functional abstraction doesn't work or is clunky in a lot of cases and that Haskell's approach of making it the core of the language is misguided (Lisp is less opinionated than Haskell for one).

> One could argue that a functional approach maps more practically and ergonomically for the majority of general programming work than other mainstream approach.

They could argue, but they would be wrong.

SQL works because it's a strict abstraction on a very defined problem.

Functional is great when all you're thinking about is numbers or data structures.

But throw in some form of IO or even random numbers and you have to leave the magical functional world.

And you know why SQL works so fine? Because there are a lot of people working hard in C/C++ doing kernel and low-level work so that the "magic" is not lost on the higher level abstractions. And can you work without a GC?

> I'm saying the functional abstraction doesn't work or is clunky in a lot of cases and that Haskell's approach of making it the core of the language is misguided

Functional programming certainly doesn't work literally everywhere, but to say Haskell's design is "misguided" is your opinion, and it's one that some of the biggest names in the industry reject. How much experience do you have designing programming languages? Or even just building non-trivial systems in Haskell? Judging by the evident ignorance masked with strong opinions I'd say around about the square root of diddly-nothing.

> But throw in some form of IO or even random numbers and you have to leave the magical functional world.

Wrong. Functional programming handles IO and randomness just fine.

> And you know why SQL works so fine? Because there are a lot of people working hard in C/C++ doing kernel and low-level work so that the "magic" is not lost on the higher level abstractions

Are you suggesting there aren't a lot of people working hard on GHC? Because if you are — and you seem to be — then again you would be wrong.

This 1000 times.

The reason SQL (really - relational algebra) works so well is precisely because relational data is strongly normalized [1].

But the data is only a model of reality, not reality itself. And when your immutable model of reality needs to be updated strong normalisation is a curse, not a blessing. The data structure is the code structure in a strongly-typed system[2]

Strong normalisation makes change very expensive.

[1] https://en.wikipedia.org/wiki/Normalization_property_(abstra...

[2] https://en.wikipedia.org/wiki/Code_as_data

> processors are still procedural

Exactly. I don't know why Haskell fanboys insist on abstracting us so far from the machine. Declarative programming is really unhelpful because it says nothing about the order in which code executes.

We live in a mutable physical universe that corresponds to a procedural program. One thing happens after another according to the laws of physics (which are the procedural program for our universe). Electrons move one after another around circuits. Instructions in the CPU happen one after another according to the procedural machine code.

The universe would never consider running 2020 before 2019 and a CPU will never execute later instructions before earlier instructions.

Haskell fanboys talk about immutable data structures like it's beneficial to go back in time and try again. But it's a bad fit for the CPU. The CPU would never run some code and then decide it wants to go back and have another go.

> The universe would never consider running 2020 before 2019 and a CPU will never execute later instructions before earlier instructions.

Except thanks to a compile-time optimization.

And ooo-execution that happens at _runtime_.

> Exactly. I don't know why Haskell fanboys insist on abstracting us so far from the machine.

I believe it is because abstractions are the way we have always made progress. Is the C code that's so close to the machine not just an abstraction of the underlying assembly, which is an abstraction of the micro operations of your particular processor, which in turn is an abstraction of the gate operations? The abstractions allow us to offload a significant part of mental task. Imagine trying to write an HTML web page in C. Sure it's doable with a lot of effort, but is it as simple as writing it using abstractions such as the DOM?

> We live in a mutable physical universe that corresponds to a procedural program. One thing happens after another according to the laws of physics (which are the procedural program for our universe).

You just proved why abstractions are useful. "One thing happens after another" is simply our abstraction of what actually happens, as demonstrated by e.g. the quantum eraser experiment [1][2].

[1] https://en.wikipedia.org/wiki/Delayed-choice_quantum_eraser

[2] https://www.youtube.com/watch?v=8ORLN_KwAgs

>I believe it is because abstractions are the way we have always made progress.

>The abstractions allow us to offload a significant part of mental task

Edge/corner cases in our abstractions is also how propagation of uncertainty[1] happens. You can't off-load error-correction [2]

[1] https://en.wikipedia.org/wiki/Propagation_of_uncertainty

[2] https://en.wikipedia.org/wiki/Quantum_error_correction

I'm not sure what you mean by "You can't off-load error-correction". In the case of classical computing, we do off-load error-correction (I don't have to worry about bit flips while typing this). In the case of quantum computing, if we couldn't offload error-correction, an algorithm such as Shor's wouldn't be able to written down without explicitly taking error-correction into account. Yet, it abstracts this away and simply assumes that the logical qubits it works with don't have any errors.

You're saying a lot of wrong things about CPUs. CPUs do execute instructions "out-of-order", and they do speculative execution and rollback and have another go. Branch prediction is an example.

All of this is possible only with careful bookkeeping of the microarchitectural state. I agree the CPU is a stateful object. But even at the lowest level of interface we have with the CPU, machine code, there are massive gains from moving away from a strict procedural execution to something slightly more declarative. The hardware looks at a window of, say, 10 instructions, deduces the intent, and executes the 10 instructions in a better order, which has the same effect. (And yes, it's hard for me to wrap my head around it, but there is a benefit from doing this dynamically at runtime in addition to whatever compile-time analysis.) In short, it is beneficial to go back and have another go.

This was demonstrated also in https://snr.stanford.edu/salsify/. If you encode a frame of video, but your network is all of the sudden to slow, you might desire to encode that frame at a lower quality. Because these codecs are extremely stateful (that's now temporal compression works), you have to be very careful about managing the state so for can "go back and have another go".

I am less confident about it, but what you say about the universe also seems wrong. What physical laws do you know take the form of specifying the next state in terms of the preceding state? And literally many of them are time-reversible.

Thanks. It was an attempt at parody but apparently I didn't lay it on thick enough. I'll try to up my false-statements-per-paragraph count next time.

What you wrote about CPUs many people believe, and many simpler CPUs operate like that. So it was difficult for me to detect as parody. Sorry that I missed it! It's funny in hindsight.

Not sure what the parody was in computing 2020 before 2019.

> Instructions in the CPU happen one after another

https://en.wikipedia.org/wiki/Superscalar_processor

> a CPU will never execute later instructions before earlier instructions

https://en.wikipedia.org/wiki/Out-of-order_execution

> The CPU would never run some code and then decide it wants to go back and have another go

https://en.wikipedia.org/wiki/Speculative_execution

Actually the FP fanboys, all the way back to those IBM mainframes where Lisp ran.

Even C abstracts the machine, the ISO C standard is written for an abstract machine, not high level Assembly like many think it is.

Abstracting the maching is wonderfull, it means that my application, if coded properly, can scale from a single CPU to a multicore CPU + coupled with GPGPU, distributed across a data cluster.

Have a look at Feynamm's Connection Machines.

>> The world is not functional

> What does this even mean? If the world is not functional, then what is it?

The world is full of special cases, of corner cases, of exceptions, of holes, of particular conditions, of differences for first or last element, and other irregularities; it is also full of sequential events. Applying a function to a starting set, to produce a resulting set or value is very lean with clean nice mathematical objects and relations, but not with many real-world problems.

> And Haskellers are the ones getting called “elitist”!

Well, one may say that answering with questions could fit the bill...

> The world is full of special cases, of corner cases, of exceptions, of holes, of particular conditions, of differences for first or last element, and other irregularities; it is also full of sequential events.

True

> Applying a function to a starting set, to produce a resulting set or value is very lean with clean nice mathematical objects and relations

True

> but not with many real-world problems.

Debatable, but in any case a non-sequitur. Are you sure you're talking about functional languages as they're used in reality?

I once wrote a translator between an absurdly messy XML schema called FpML (Financial products Markup Language) and a heterogeneous collection of custom data types with all sorts of "special cases, corner cases, exceptions, holes, etc.". I wrote it in Haskell. It was a perfect fit.

https://en.wikipedia.org/wiki/FpML

Yes. All of which are modelled in Haskell in a pretty straightforward manner. I’d argue Haskell models adversity like this better than most languages.

> but not with many real-world problems.

Haskell is a general purpose language. People use it to solve real world problems every day. I do. My colleagues do. A huge amount of people do.

> Well, one may say that answering with questions could fit the bill...

I see. So trying to define the terms to enable constructive discourse is elitist. Got it.

If you want me to be more concrete and assertive, fine. No problem. Here we go.

You are wrong.

> The world is not functional, as it turns out.

Have you watched the talk "Are we there yet?" by Rich Hickey? He makes a convincing case, referencing the philosophy of Alfred North Whitehead, that "the world is functional".

http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

In a functional world persistence (e.g memory) cannot be a thing.

The case is convincing, but it requires you to reject your own, human, faculties.

Makes the use/expression of language rather awkward when you can't remember any words.

Thanks for your input, Euthyphro!

My knack for spotting performative contradictions didn't sway you towards Deskartes?

> In a functional world persistence (e.g memory) cannot be a thing.

Why not?

To give a functional Haskell flavoured example, I can use the Reader and Writer monads (which are functional) to create a whole bunch of operations which write to and read from a shared collection of data. That feels a lot like memory to me.

Indeed, the Reader monad is defined as:

> Computations which read values from a shared environment.

I just don't understand the whole "you can't have memory / order of operations / persistence / whatever else" as an argument against functional concepts when they have been implemented in functional ways decades ago. The modern Haskell implementation of the writer monad is an implementation of 1995 paper.

Edit: it looks like who I responded to doesn't actually want to have a reasonable discussion, but for anyone else reading along, it's entirely possible to have functional "state" or "memory" - what makes it functional is that the state / memory must be explicitly acknowledged.

Trying do dismiss functional computation in this way is essentially a no true Scotsman; functional computation is useless because it can't do X (X being memory or persistence or whatever), but when someone presents a functional computation that does do X, it's somehow not a "real" functional computation precisely because it does X. Redefining functional computation as "something that can't do X" doesn't help anyone, and doesn't actually help with discussing the pros and cons of functional programming since you're not actually discussing functional computation but some inaccurate designed-to-be-useless definition mislabeled as functional computation.

What is this thing that you reading from and writing to?

It sounds mutable.

I’m sorry if immutability is a new concept to you, but you can read from one state, and write to a new state.

There you go. No mutation!

Writing state is the definition of mutation.

It's what all data storage systems do.

An immutable data store sounds pretty useless.

https://en.wikipedia.org/wiki/Persistence_%28computer_scienc...

It’s fine for you to think that. That’s not going to stop other people from finding these concepts useful though.

Once again, you are free to ignore the things you don’t understand. Your trolling is mostly harmless.

>you are free to ignore the things you don’t understand

Is that why you are ignoring the complexity behind persistence/mutability/state?

Even the Abstract Turing machine has ticker tape you know...

Interesting point. Lambda calc is equivalent, where the expression can be seen as equivalent to the ticker tape. So when a reduction occurs in lambda calculus, it's just like a group of symbols being interpreted and overwritten. But the thing is, no one has to overwrite the symbols to "reduce" them. It's just a space (memory) optimization. Usually to calculate something (you're fully correct by the way) we do overwrite symbols. The point of using immutable style is simply to make sure that references don't become overwritten. It sucks to have x+2=8 and x+2=-35.4 within the same scope, right? Especially when the code that overwrote x was in a separate file in an edge case condition you didn't consider.

>what makes it functional is that the state / memory must be explicitly acknowledged

Isn't state/memory assumed by default when talking about computation?

What kind of computations you can perform on a Turing machine without a ticker tape?

Lambda calculus, for example, has no ticker tape.

What kind of computations can you perform with Lambda calculus without any input variables?

What are you applying your α-conversion and β-reduction operations to?

I like hickey but a lot of his examples are data driven domains where we can indeed model the world in functional or accounting-like terms.

Where this falls short is domains that are extremely ill-suited to keeping track of past states over time (his identity idea) simply because it would break performance or be hard to model in those terms, say simulations, game development, directly working with hardware and so on.

Much of his argument relies on the GC and internal implementation being able to optimise away the inefficiences of the functional model that needs to recreate new entities over and over, but this simply is not always enough.

This also is very obvious if you look into the domains where Clojure or other declarative functional languages have success, it's almost always business logic / data pipeline work.

edit: And in fact a lot of his most salient points aren't really as much about functional programming as they are about lose coupling and dynamic typing. A lot of his criticism of state and identity in languages like Java isn't related to Java not being functional, it's related to Java breaking with the idea of late binding and treating objects as receivers of messages rather than "do-ers".

> it would break performance or be hard to model in those terms, say simulations, game development, directly working with hardware and so on

Performance seems to be the problem there more than the model not fitting. And Rich’s answer would probably be that Clojure isn’t the right tool for those tasks in the same way that any general-purpose GC’d language isn’t.

Modeling a game or sim as a successive series of immutable states sounds great to me, so I’m curious where you see a mismatch with them. Abstracting hardware properties this way sounds useful too, but I’ve not worked with it enough to comment.

>Modeling a game or sim as a successive series of immutable states sounds great to me, so I’m curious where you see a mismatch with them.

because I don't really think the functional model describes it in an intuitive way. You can model a sim or game at a high level like worldstate1 -> worldstate2 etc.. but it doesn't really tell you much, because often you don't really care what the state was a second ago anyway in particular not in its entirety, and because at that high level of abstraction you don't really get any useful information out of it, so there's no point in tracking it in the same way it makes sense to track a medical history or a bunch of business transactions.

Rather instead of thinking of games or sims as high level abstract transitioning states we tend to reason about them as a sort of network of persistent agents or submodules and that lends itself much closer to a OO or message based view of the world.

I think in many systems that are highly complex and change very incrementally reasoning about things in terms of functions doesn't really tell you much. You can for example reason about a person as like say a billion states through time but there's not much benefit to it at least to me.

That makes sense, and the actor model (well, entity-behavior, which is fairly close) has been what I reached for in the past when doing game dev.

I agree that looking at a whole worldstate at once is unlikely to be useful. But I do see great value in keeping state changes isolated to the edges of a system, and acting upon it with pure functions. If you have the means to easily get at the piece of state tree that you’re interested in, you can reason more clearly about how each piece of a simulation reacts to changes by just feeding the relevant state chunk to it and seeing what comes back. That takes more work to set up or repeat if each agent tracks its own internal state.

I haven’t used Clojure to make a game before, so I’m speculating here. I find myself avoiding internal state by habit lately, though of course “collections of relevant functions” are valuable tools. I just lean towards using namespaced functions instead of objects with methods.

A lot of what's done in software eventually ends up getting hardware support. Our current von-Neumann/modified-Harvard hardware architectures are old and it's precisely thinking outside these lines that will lead to non-local maxima.

your just stating claims without any evidence.

Actually, according to quantum physics, the world is functional. The Universe can be described by completely by a function (the universal wave function) and is completely time-reversible; you can run it forwards or backwards because it has no side-effects.

The collapse of a wave function into a single state that apparently happens on observation is as far as we know non-deterministic. The wave function itself is a probability amplitude. So I think it's a misinterpretation to say that "the universe can be described completely by a function" when everything we can actually know about the universe is observable and has necessarily collapsed from a probability amplitude of possible states into the observed state.

My interpretation is the exact opposite. Newtonian physics suggests the fundamentally deterministic world that QM can't because in the latter the only thing that is deterministic is probabilities.

Collapse of a wave function occurs when one wave becomes entangled with another. If I shine a photon on a particle to measure it, and the particle emits a photon back to me, I am now entangled with that particle through mutual interaction. But to a distant observer, there is no wave collapse. If our universe is purely quantum and exists alone (not being bumped into by other universes), then its wave function would just be evolving unitarily according to it's Hermitian - totally deterministically (the wave function, that is).

I don't know what it means for the universe to be "purely quantum", or what it means to be a "distant observer" yet somehow not interacting. A wave function in itself is not observable. Is it real? Definitional. Is it a physical phenomenon? Dubious. All we know is that as a model it is consistent with what we observe. What actually can be measured (and can reasonably be considered real and physical in that sense) can only be predicted probabilistically using quantum mechanics. It's like saying that I can perfectly predetermine the outcome of a dice roll—it's between one and six.

By that standard every programming language is functional, since the compiled program is a function.

Since I got downvoted let me elaborate: it isn’t relevant that the universe is a function. What matters is whether the universe can be modeled better as the composition of pure functions or as some stateful composition (e.g. interacting stateful objects).

Programming languages aren’t about the final result but about how you decompose the result into modular abstractions.

Absolutely. "I'm just not smart enough to use mainstream languages" - "In fact we both know you are very smart. But, as we've just learned, also not competent enough to hide your elitist signaling in subtlety".

Wait, how is saying “I’m just not smart enough to X” elitist signaling?

If I tell someone “I’m not smart enough to use php”, I’m admitting a weakness. I genuinely don’t have the mental capacity to keep details straight when using it. If I tried to use php for at a job, I’d move at such low velocity that I’d get PIP’d.

Or like saying “I can’t write code without automated tests.” there are genuinely people who, if they try to write code without tests get stuck for hours and don’t know how to move forward.

I’d think someone this is the same sentiment. I’m willing to believe that the Haskell community is elitist in other ways. But how is “I’m not smart enough to X.” An expression of that?

"My brain is 100% pure logic so I can't deal with the unholy messes of the unwashed masses. In fact I'm so smart that I didn't even notice that many many things are much harder to write in this language that requires you to think about unrelated math things, because I solve them for breakfast"

How does "I'm not smart enough" turn into "I'm so smart"?

I didn't think it was that subtle, but different people have different sensors I guess.

It doesn't seem subtle. It seems like a dramatic transmutation from one meaning ("I have a need") into another totally different meaning ("other people are less worthy of respect").

I don't know, if you say "I'm just not smart enough" as a mathematician that is more interested in Functors and Monads and Yonedas than solving actual engineering problems, then there is definitely deception and signaling going on. IMO.

So, I agree that it is totally possible and maybe common for someone to ignore the business impact of their work. More engineers should read https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr... and understand that ultimately their role in their organisation is to Cut Costs/Risks or Grow Revenue/Impact. But being having a commercial or UX mindset doesn't make your brain more effective at using any given tool.

Imagine a programmer who, when she studies Haskell, discovers that the way it resembles category theory provides really effective mental affordances to her memory. She feels that Haskell's formalism makes it easier for her to have a clear mental model. When she writes and reads Haskell, she can predict what that code does to data and her predictions are largely correct. She feels confident in her understanding. This means that if she has a business goal she needs to fulfil, she's confident she can estimate that task, communicate about with stakeholders its complexity. and execute it.

Imagine that this programmer, when she starts to study PHP, does not find similar affordances. She finds it difficult to build a conceptual structure of it in her head. She finds that she forgets things or overlooks things when she tries to write PHP. If she tries to predict how a piece of code she writes in it behaves, she frequently is wrong. She feels very nervous about it. Consequently, when asked to plan adding a feature to a PHP task, she doesn't feel she's got a good enough grasp of her tools to answer. She worries about the risk to the business of her blowing past estimates and leaving making errors in production.

She tells someone "I don't think I'm smart enough to write PHP".

1) Is this statement a lie? 2) Is this statement elitist? 3) Is she a person who could exist?

What if her positive feelings about Haskell lead her to evangelise it in a way that ignores the fact that another person's brain might work in a different way to hers. She claims to this other person that Haskell is easy.

4) Does that statement make her elitist?

-----

My answers: No, No, Yes, Kinda yea.

"My coding practises are so good, I can't even write it the bad way anymore."

Yeah, the elitist attitude around the language is a shame. Haskell is actually pretty easy to learn and teach, and is very useful in certain domains.

Functional programming is just one of the paradigms, and useful in it's own domain. Its not a end all solution to everything.

> Haskell is actually pretty easy to learn and teach

What are you basing this on?

I must concede that it is my own experience

This is what has killed Scala. It was a fine pragmatic hybrid language which perfectly combined FP and OOP. Now it is attacked by hordes of type astronauts which will look down to you if you are not using Tagless Final, Cats, or whatever new fad is now in vogue.

If you (or anybody else) haven't given up on Scala just yet, have a look at ZIO

https://github.com/zio/zio/

It's a fresh, and pragmatic too, take on how to do pure functional programming, but without advanced concepts (like higher-kinded types).

could be (and maybe even has been) ported over to other languages besides Scala

Yes, Zio is really interesting. Unfortunately, its author has been recently outed from the community for political reasons (and there is too much drama in Scala community in general). I only hope that the dust will settle someday.

Just wait to see where it will take Kotlin with its Scala refugees.

https://arrow-kt.io/

The people making this library aren't Scala refugees - they're a Scala shop that uses Kotlin on Android only, so they decided to bring over their idioms.

Stand corrected, but doesn't change the fact of what is coming to Kotlin as well.

> a fine pragmatic hybrid language which perfectly combined FP and OOP

Ah, so Common Lisp then?

As a counterpoint when wanting to promote any of the "new wave" (even though Haskell isn't new) languages like Haskell, Go, or Rust for certain use cases it's become too common lately for people to dismiss it as evangelism (or indeed, elitism), and that is also unfortunate in my opinion.

I never got a sense of evangelism or elitism from Go advocates

Yeah, they don't need to evangelize it, they just have the critical mass to use it everywhere and the rest of us have to deal with their garbage.

Really? Might i ask which places are you visiting, where you see this behaviour? I have rarely seen elitist behaviour in r/haskell or freenode #haskell. Mostly i see people complaining about eliticism on HN.

GP complains that nobody can explain to him why he should switch to Haskell, but when somebody tries, that's "elitist signaling"?!

You know what, use whatever makes you happy, while we continue to avoid success at all cost.

It depends on how it's done. If the explanation is "Because strongly-typed FP is the One Right Way, and you're stupid to use anything else", that's elitist signalling. If it's "because these certain kinds of errors simply go away, without other kinds of errors becoming more common", then it's not.

> I get answers about idempotence and list comprehension and strong typing which are great tactics but I never get the sense that they fit into an overarching strategy for how my life will be made easier by using Haskell.

First, I suppose those three things fit together in the sense that they make list comprehensions safe and fast.

But as you say, Haskell isn't the only language that gives you that.

I think the killer feature of haskell is that the community went through ridiculous contortions and pain to get rid of side effects.

Which means that Haskell programs exclude certain kinds of bugs - so it's not just that you can program in a functional style, but that you can be fairly certain there's no "shifting sands" under your functions.

On the other hand, I see many haskell programmers say that the powerful type checker forces them to think a bit differently, and perhaps harder, when writing - with the result that once the type signature fits, the function tends to "just work".

Anyway, I never did really enjoy Haskell - not as much as StandardML anyway. Sadly there doesn't seem to be any sml with good real-world libraries, so I've not really been using that either, outside of university :/

Perhaps looking at one of the few popular haskell utilities, and see if you feel Haskell is a good fit? I'm honestly not certain myself.

https://github.com/jgm/pandoc/blob/master/src/Text/Pandoc/Re...

Haskell's type system works best for me in allowing fearless changes, even significant ones to the core of a code base. The compiler won't let me overlook something.

A comprehensive test suite would achieve the same thing, but I'm rarely confident that my test suites are truly comprehensive.

If you're having trouble justifying the switch to Haskell and are primarily concerned with systems programming, I'd recommend try out a language like Rust. Many of the features present in Rust were inspired by Haskell, and there is quite a bit of overlap between the communities.

As far as Haskell itself goes I've written a little in the past in comments on here about why it's useful:

https://news.ycombinator.com/item?id=20111321

https://news.ycombinator.com/item?id=20260095

These days when I want to start a new project the decision on whether to use Haskell or Rust is the biggest consideration I make -- the expressiveness and safety and correctness Haskell can provide versus the raw speed, ease of build, memory safety rust provides.

Now I don't know Haskell particularly well but I have found another language I'm focusing on, that people basically have the same question about.

For me, the quest is to be able to build more with less effort, with less bugs and make things more maintainable for the future. For this, I've found Clojure (of the 10+ languages I've professionally worked in) to be the best one, but like all the rest of the languages, it doesn't fit every single use case. But most of them, so far at least.

I could go on and on giving you arguments for/against, but I think these goals are the same for most programmers who aim to learn/use some of the lesser known languages.

I think it has a lot to do with taste; you really need to like typing and abstracting everything; which I do in C# (no stringy types unless i'm in a blistering hurry) because I get paid to program C# because I actually find this very beneficial, but not limited to Haskell; Haskell taught me to do it to extremes though which, in my opinion, is what you are basically asking. That 'elitist' community in Haskell teaches a lot of abstractions, that, once practically understood, for me, give a great amount of power (which, for me again, means a far better understanding of large codebases and easy adding of features. For me that would answer the question you ask as a lot (most) of these are just very hard (not impossible which is why we see more and more of them, but not at the speed the Haskell community introduces them) to move to other languages.

Short answer: Because of the features you mentioned, You will be able to write code which is correct, self documenting, and achievable in fewer lines of code[.].

Your life won't be easier if you solve problems, because solving problems is hard. But you get a lot of benefits from using any language which has features similar to Haskell because of the above reasons. If you are into programming language research, compilers, theorem provers etc, Haskell comes with a lot of idioms, features and tools that it is a viable language for the tasks at hand.

[.] a lot of languages rightly claim it like lisps and modern lisp derivatives, but Haskell brings with it a top of the line type system, (imo) a clearer syntax and tooling than OCaml, and a decent support from the industry and the academia..

It’s self documenting if you consider a type signature to be documentation.

In addition to type signatures, the whole syntactical outlook resembles mathematical definitions.

This comment misses the point of the article, which argues against a urban legend that Haskell is too difficult "unless you are this tall" (a Phd, an E.T., a superhuman). I also had a shot at explaining why people are already tall enough in a past short "comic strip" [0]. I think the article makes a good job re-assuring the urban legends are a myth.

Now. there are many reasons why one would want to use Haskell. For instance, to have fun, to understand better some pattern, to write expanding-brain memes, or, because they are good at solving problems with it. It is fine if your reasons do not intersect with other people's reasons. You can try finding answers whether Haskell matches your reasons in some other essays [1,2,3]. Maybe it is true for many people that their needs and desires are entirely covered with their own toolset. As a curious/optimistic person I find it incredibly pedant to say I'll never ever need to learn/use something (there's different goodness in everything).

Personally, practicing Haskell led me to appreciate the importance and trade-offs that occur when isolating/interleaving side-effects. Similarly, it gave me some vocabulary to articulate my thoughts about properties of systems. Both are super important in the large when you architect softwares and systems. There are other ways to learn that (e.g., a collection of specialized languages), but at least for me, Haskell helped me build an intuition around these topics. That said, the prevalence of negative and derailing comments in discusions about Haskell can be demotivating (but our industry is like this ️).

[0] https://patrickmn.com/software/the-haskell-pyramid/ [1] https://www.snoyman.com/blog/2017/12/what-makes-haskell-uniq... [2] https://www.tweag.io/posts/2019-09-06-why-haskell-is-importa... [3] http://blog.vmchale.com/article/functional-haskell

"Idempotence, list comprehension and strong typing", efficient communication is done succinctly through terminology.

Idempotence eliminates the need for a whole bunch of retry and error checking code, which themselves are often highly stateful and susceptible to race conditions and bugs.

List comprehensions can make allow for certain guarantees about parallelizing which is becoming ever more relevant as processors scale with threads / cores rather than clock speed. All without explicit programmer intervention.

Strong typing means the compiler can check types at compile time rather than runtime - this (largly) eliminates entire classes of errors before they happen. If errors happen at compile time, the programmer fixes it, if errors happen at runtime the user gets annoyed.

These are just trivial examples of some of the benefits of these technologies - see how these strategies eliminate not single errors but entire classes of errors. Selecting the right technologies means less bugs, less headaches for users, less support calls, less firefighting, and THAT is how your life will be easier with Haskell, for example

Idempotence means spending days thinking about how to rewrite large parts of your application to get in "stateful" actions (for example, logging?) or how to make your list processing actually fast (hint, it doesn't work with lists). Idempotence makes it extremely hard to control when something actually happens or how much memory is used.

Strong typing means you'll spend your time waiting for the compiler to finish, or thinking how to unwrap this monad stack in a way that doesn't suck. It also means large parts of your app will have very unstable interfaces with way too many dependencies, you'll constantly be fighting with cabal or whatever, you'll often have to do busy work to keep track with external dependencies, you'll constantly be tempted to represent a different or additional subset of your invariants in the type system using the newest fancy language extension (that slows your compiles down even further, and may have subtle interactions with some of the other extensions you're already using).

> Idempotence means spending days thinking about how to rewrite large parts of your application to get in "stateful" actions (for example, logging?) or how to make your list processing actually fast (hint, it doesn't work with lists).

Idempotence isn't a golden hammer, it's not suitable for every task. It is suitable for 1 way purchase code, increasing robustness in faulty networks, initializations. It's not suitable for logging.

It's not suitable for making list processing fast (that was some guarantees of list comprehensions, I think you got confused there)

> Idempotence makes it extremely hard to control when something actually happens or how much memory is used.

No it doesn't, that's totally wrong. Idempotence doesn't dictate execution time or memory used, it's not an implementation detail it's an abstraction level higher than that : it's a system strategy. This sounds like you're confusing idempotence with lazy evaluation.

> Strong typing means you'll spend your time waiting for the compiler to finish,

Compilers are really fast these days, only compiling the changes. "Waiting for compiler to finish" hasn't been a problem since the 90's, even on larger codebases (100,000+ LOC).

Also - So you cant be bothered to wait for the compiler to check your code, then the entity that's going to do it will be your users, in production. So maybe you can spend the time you saved not waiting for the compiler answering the support tickets coming in?

> thinking how to unwrap this monad stack in a way that doesn't suck

Subjective, no examples. This is just whining.

> It also means large parts of your app will have very unstable interfaces with way too many dependencies, you'll constantly be fighting with cabal or whatever, you'll often have to do busy work to keep track with external dependencies, you'll constantly be tempted to represent a different or additional subset of your invariants in the type system using the newest fancy language extension (that slows your compiles down even further, and may have subtle interactions with some of the other extensions you're already using)

Unstable interfaces with way too many dependencies is not a language problem it's a system design problem. It sounds like you have inexperienced software architects making poor decisions.

Wow, either this language has significantly transformed since I last worked in it 3 years ago, or you need a reality check.

Won't reply to everything you've said, but just one little thing that I remember vividly. I was trying to get this 300-400 lines basic OpenGL setup code to work. Each time I made a little change it took 10+ seconds to compile. I went with the minimal types needed to interface with this OpenGL library, which was nothing fancy by Haskell standards, but just a "straightforward" C wrapper.

GHC is fairly slow for a compiler, and Haskell has no separation of interface and implementation, so small changes can have big consequences.

Template Haskell is the worst for it, but I did have a code generator produce code that took about 25G of memory to compile recently, which was very, very slow on a 16Gb machine ;)

> Strong typing means you'll spend your time waiting for the compiler to finish

You can see this is false by running ghc in type-check-only mode ("-fno-code"). Type checking is less than 10% of compile time. If Haskell takes a long time to compile it has nothing to do with types.

(and you mean "static typing")

I can't try out your suggestion right now because I've basically quit this ecosystem. But I would be careful about making any generalizations if the user can do significant computations at compile time.

> (and you mean "static typing")

Let's not split hairs. And I think "strong" is actually what I want to say (maybe better: "advanced" or "complex"). C also has "static typing" and I explicitly don't mean a simple type system like that.

> I would be careful about making any generalizations if the user can do significant computations at compile time.

Indeed, and with some language extensions type checking may never terminate! But library code only has to be compiled once and if you write code that takes a long time to type check that's on you. Bog standard type safe Haskell 2010 code type checks in the blink of an eye.

If your argument is "advanced type system features are too seductive for people to avoid" then I'd be more inclined to agree with you. But that's not what you said.

> > (and you mean "static typing")

> Let's not split hairs.

Well, Python has strong typing and doesn't take long to compile. Perhaps you meant "some advanced features of Haskell's type system". If so I'd agree with you. But don't discourage people from Haskell by making false statements about it and then accuse me of splitting hairs.

Ok, I appreciate the refinements, and I think we agree.

It's just a solid mature programming language.

There are plenty of those, though, and most others seem to make both getting started and doing practical things a lot easier.

Its actually very easy to get started with Haskell. Just install the Haskell platform and you have the environment.

I don't mean installing it, I mean learning the language as a beginner (already a programmer). I've had a couple of goes at it in years past, without success.

If you are into books, I recommend http://haskellbook.com/

After reading it, the language just clicked with me, although it is for complete beginners, it is a great read nonetheless.

Doing practical stuff like webdev, apps etc is a bit trickier, partly because Haskell is not the first language of choice for these kinds of projects, and thus lacks much needed documentation for starting up and best practices in those spheres.

From that article:

"I do believe that there is real value in pursuing functional programming, but it would be irresponsible to exhort everyone to abandon their C++ compilers and start coding in Lisp, Haskell, or, to be blunt, any other fringe language."

Even Carmack has a subliminal jab at languages on the basis of popularity from time to time lol

For me, the reason is rather simple- every single program I wrote in Haskell, once successfully compiled, ran correctly.

If someone from the 50s told you "no one has ever been able to explain to me why I should use stored-program computers instead of my cables and plugboards", what would your answer be?

Maybe your answer will be that that the stored program is an abstraction of the cables and plugboards, so you can be more productive.

Today, there are several additional layers of abstraction on top of that, functional programming is one of them.

Reply on news.ycombinator.com