Hacker News Reader

I have the opposite experience. A year of using Haskell for my side projects taught me more about how to make code production ready than years of Java.

But I suppose it depends on the environment you end up with. All the Java I did was with people where you could get away with murder in the code. All the Haskell I did was with people who carefully consider network failure, memory usage, readability, timeouts, pathological logging loops, etc., and would push back on code that isn't easy to use, maintain, and troubleshoot.

Writing good code is mostly language agnostic. Where the brain power in computing tends to flow to is hard or interesting problems (I say tends because money is also a factor), so you're going to find smart people concentrated in different places. I've been very fortunate to have worked with many groups containing the best and brightest in the software industry and I was never held back by letting go of Haskell.

I don't think I even know what you mean by 'how computers really work'. Isn't the point of languages to create abstractions so I don't need to learn how a CPU works?

I understand why Haskell will never become the language of industry. Lazy evaluation, a hundred and one extensions, the fact you would need to retrain everybody... but I'm not really interested in that. Haskell is a place for ideas, not really practicality. This has been gone over time and again.

The reason I use Haskell for personal projects is because they all end up being very few lines of code compared to imperative versions, and it usually just works. For me that's enough benefit to learn it.

It would be nice if an ML language actually became popular at some point. But that won't be for a long time.

> Isn't the point of languages to create abstractions so I don't need to learn how a CPU works?

This is the entire problem with Haskell. This isn't the reality we live in. In our world there's a concrete need to understand performance at the level of the hardware and the kernel. Let's not even talk about compilers, which have to make many tradeoffs and often produce sub-optimal code without human guidance. The kernel itself doesn't always make the right decisions on where to place workloads, how to balance IRQs, moving tasks between cores, etc.

If you want to become a better software engineer, learn how your computer actually runs code, don't learn Haskell.

Edit:

It's not letting me respond to your reply directly, so here is my reply:

We all have different experiences in the industry, but my experience has been that I often need to diagnose and solve performance issues that involve using perf, ftrace, bpf, pprof, etc. I'm not saying we should all write C, I'm saying that you need to know how to look under the hood when you're using a language that does more work for you. Understanding how to look under the hood (again this is my experience) and know what you're looking at is far more important than mastering high level language concepts. You can change out the language, but the kernel, hardware, etc. remain the same. It's also important to understand these things because security is only becoming more important and attackers exploit the gaps in your knowledge. Spectre was a huge deal and it requires an understanding of how a pipeline works, how your program interacts with the cache, etc. If I ask you how to find out how may instructions your program ran, how many branches it took, how many branch mispredicts there were, if it was exhibiting false sharing, etc. could you tell me? You can't optimize something or know if you're being attacked if you don't understand how things work or what the baselines are.

I don't think this is even a Haskell criticism as much as it is a software engineer criticism. You can be ignorant about hardware in most languages, especially Python.

Going by what you've said, it sounds like you want the industry to return to C/C++ for everything.

As for Haskell, I'm not experienced enough to make a real defense of it, but I've been told the compiler is pretty damn good. It's a decently fast language. I don't know how it compares to something like Go, and of course for very high-performance needs you probably shouldn't use it, but letting it take over isn't the worst thing in the world, and you can still use knowledge of hardware to make it faster.

But if that's not enough, just use Rust or something. It's basically Haskell-lite anyway.

Laziness by default makes it extremely hard to reason about performance, at least for me. So Rust is actually far closer to C/C++ than Haskell lite in terms of being able to think about how the code you write maps to the physical machine.

> You can be ignorant about hardware in most languages, especially Python

You're thinking in terms of languages and not systems. If you've ever built systems at scale, you'll know that abstractions break down. The best of us write leaky abstractions. When the time comes to debug a leaky abstraction, you need to open up the hood. This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc. That's when you need to break down the abstraction layers and break out tools like iperf or Wireshark.

Languages like Haskell create such a different execution model (with monads and lazy execution) that it makes it really hard to break through its abstractions and understand what's going on.

I've had similar experiences to the author. I've written Haskell for fun and worked in Scala. Most of the folks who have your viewpoint have (in my experience) not worked in a situation where these issues come up. Either the scale of the problem is low so powerful abstractions are more powerful than deconstructing them or they work in problem domains where standards around correctness are a lot lower and programmer happiness is paramount. But if you've ever been in a position where you need to write a high-scale or high-reliability application, languages with highly abstract execution models prove more a liability than an asset. In that regard both Erlang and Rust offer a much more concrete execution model that's a lot easier to reason about than Haskell or monadic Scala offers, at least in my experience.

> This means checking how many connections are open, checking whether you're flushing too often to disk, checking if your DB queries are locking up tables, checking when you're thrashing CPU, checking if you're not pooling a connection properly, etc.

I’m not sure what you mean. Industrial Haskell users can and do check all of these things like their Python and C++ counterparts.

It's not that they don't check those things, it's that Haskell's tower of abstractions makes it much harder to figure out where issues are coming up. In most apps at most you're dealing with GC time other than your actual operations. In Haskell you're dealing with laziness and monad composition atop just GC time.

If I want to brute force a problem on an underpowered machine, I need to focus on pushing its exact limits. But if I want to solve a very complex problem, I need to not be distracted by them. I like Rust but I’m not sure how often the extra specificity from the dev pays for itself in hardware.

Other than the constraint of time, low level systems understanding and Haskell are orthogonal and not at odds. Why not both?

>"Isn't the point of languages to create abstractions so I don't need to learn how a CPU works?"

In a world where CPU is infinitely fast and has infinitely large RAM

it's not binary - an abstraction makes for easier, lowers the barrier (in the sense that you can get away with knowing less but still can make it work).

>I don't think I even know what you mean by 'how computers really work'.

Haskell is a top down language. It is an abstraction over a variation of typed lambda calculus. The compiler compiles haskell into this lambda calculus and then has to figure out how to efficiently evaluate the terms. One can argue that with a "sufficiently smart compiler" it can make things run fast. Unfortunately, this is not really the case and it is not easy to reason what code is being generated for what you write. Are optimizations like deforestation kicking in? There are also plenty of abstractions that the Haskell community gets excited over even though they come with performance impacts. These abstractions may be entertaining, but they are not necessarily practical. If you go deeper in the rabbit hole of FP you might find people talking about how with homotopy type theory a compiler could recognize code and substitute it with a more "optimal" version. Unfortunately, a mythical "sufficiently smart compiler" does not exist and even if it did the compile time would be impacted in trying to optimize your programs.

The "how computers really work" argument is that languages should instead be abstractions over the CPU (or other hardware devices) instead of abstraction over computation itself (alternatively you could also see it as an abstraction over graph reduction based hardware but since we aren't running it on such hardware that is problematic). In the real world we have real concerns about resource usages such as processing time and memory. Abstractions over the CPU makes it easier to have a general idea on what the code that is being generated looks like.

It may be the case that your use case is not that sensitive to performance or memory usage so continue to have fun using Haskell. As you said Haskell is "not really practical." To your point of Haskell having very few lines of code compared to imperative version I feel that is likely just a matter of what is in the standard library / what libraries you used.

That line of reasoning may have been ok 2 decades ago, but the current CPU model isn’t necessarily serial either, anymore.

Sure, you can express nigh everything in C++, but defaults matter — a parallel algorithm may well be in the “worth it to implement” category for Haskell, and be in the “no way that we can make it work” category for some lower level language.

Don’t get me wrong, sure, the memory model of haskell may also not be the best which has probably the biggest performance impact, but I really don’t think that there is as much of a difference between comparable high level languages to haskell, so it can absolutely be a good choice for certain applications.

>but the current CPU model isn’t necessarily serial either, anymore.

It is still largely serial. If you are concerned about the dependencies of the actual instructions themselves (since the CPU can use this information to execute multiple instructions at the same time) in order to optimize something you will be very concerned about being able to predict / look at / influence the code generation.

>a parallel algorithm may well be in the “worth it to implement” category for Haskell

>“no way that we can make it work” category for some lower level language.

I disagree. It is mainly a matter of having libraries available that makes it easy. If a library was made for Haskell that makes parallel algorithms easy to implement a similar library could be made for C++ or whatever to do the same thing.

And who owns what, when will it be deallocated, etc?

Even in rust it is not as comfortable as in a higher level language - it is not accidental that where maximal performance isn’t needed GC-d languages are used predominantly in the industry.

>>a parallel algorithm may well be in the “worth it to implement” category for Haskell

>>“no way that we can make it work” category for some lower level language.

> I disagree. It is mainly a matter of having libraries available that makes it easy. If a library was made for Haskell that makes parallel algorithms easy to implement a similar library could be made for C++ or whatever to do the same thing.

This does not match my experience. Haskell encourages you to write code in a way that makes parallelism much easier and less likely to bite you (pure functions and immutability everywhere). I've added parallelism to Haskell code that was written without really thinking about parallelism by changing 2 important lines (and trivial changes to a few places in the same file). I can't imagine it being that straightforward if the code had been in C++.

Haskell can also be very useful for practical real world programs, not just researchers. Check out IHP: https://ihp.digitallyinduced.com/ This might change your mind a bit :-)

Totally agree with you here: Haskell is only good for programming in the theoretical language of computation, something like the pure lambda calculus. This is an easier way to think logically for some people. For others it's simpler to conceptualize in the physical language of computation, something like shifting the tape back and forth on the Turing machine. In this case C++ and Erlang win the day without questions. Haskell is cool (and even rumored to be useful) but there may never be a world changing unicorn using it as their daily driver.

I can't recommend Erlang enough as a way to teach concurrency. It was far ahead of its time while still being an incredibly practical language compared to Haskell, which I attribute to the fact that it was built to solve a specific problem (keeping telecom equipment running forever).

"Only good for programming in the theoretical language of computation"?

How do you explain the use of Haskell or Haskell-like languages in High Frequency Trading?

Haskell is being used in the industry with great success, yet this myth continues that it can only be used in academia. Puzzling.

"It's hard to understand, and i've never needed to use it myself in my daily work - must be only useful for academia" - a very commonly held belief.

I’m about as big a Haskell fanboy as they come but I’m skeptical about this recent claim floating around that Haskell is used for HFT. It’s used in finance, yes, but I’ve never heard of it used in HFT. Do you have any concrete references for that?

Yes, my friend worked in a UK based HFT firm which employed Haskell. Don't remember the name and I don't know if it's ok if I disclosed it if I did.

Good to know! I guess they must be very secretive. I wish I knew who they are. I'd like to work for them :)

For an exceptionally loose definition of "used", some years back I defined my testing setup in Haskell at a place doing HFT...

I have learned a ton of things that didn't carry over to what I do in the industry. That doesn't make those useless, unpractical theoretical BS.

The issue with your POV is, IMO, that you lack imagination for how vast the industry really is. There are millions of problems that are being solved with Python, PHP, Java, you name it, that can as well be done with Haskell. And constraining those solutions through the lens of "how computers really work" is unpractical, theoretical BS.

I have a similar experience and I agree. I think there is a solid, relatively practical language hiding under all the language extensions, but the never ending desire of the community to solve problems of abstraction vs. real user problems makes it a dead end in terms of time spent.

And funnily enough, the time I've spent really learning shell/awk/sed (pretty much the exact opposite of Haskell!) was one of the best investments of my career!

It's funny, but also easy to unravel I think. Haskell sits diametrically across from the C lineage of languages that focus on practicality first and foremost. It's hard to beat practical value versus theoretical value.

I also almost mentioned that I think language extensions are one of the things that hold it back the most from being more than a research project. But deciding what set of extensions are needed to make the language practical is probably a difficult problem for anyone to solve.

I would object that C focuses on practicality.

If you mean for the compiler writer, sure, C is very practical for someone who wants to make a compiler. But I'm afraid people might read your comment as saying C is practical for writing applications.

The parent comment said "C lineage", not C.

Yeah, and a real problem is how they "poison" the ecosystem. If the community was one that strongly encouraged libraries and frameworks to stick to Haskell2010, I might still consider using it.

> Almost nothing has carried over to what companies use or want day to day

I wonder what is your view on functions and local variables? Do you find structuring programs with them useful or just an academic exercise?

I had the "privilege" to work with assembler programs, written in 1970s and 1980s, that were mostly one big procedure, with a huge bunch of shared global variables. Back then, it was very efficient way to program (that's why it was used), and down to metal. But it was unmaintainable mess.

(And that's what we want from a compiler - to transform program from maintainable and somewhat abstract description down to unmaintainable spaghetti that can be, however, executed very efficiently.)

Pure functional programs are just taking it step further, saying that most functions shouldn't need full access to their execution environment (operating system). The result is, supposedly, even more maintainable programs.

Let’s be honest with ourselves: like 90% of the whole industry is writing CRUD apps, which are complex the same way history is — there is plenty of detail, differing accounts of how one thing happened, but in the end, the actual process is quite trivial. It could be an excel table if it scaled and would have nice to use interface for end users. While these programs definitely have depth and long-running projects grown to such size that no one person can hold it in their head, I have to say they are not difficult to program at all. So they can be written in literally everything.

But let’s take a compiler backend or a JIT compiler — you may very well need much more powerful abstractions for these, and having the language help you with that can be a huge boost. In this area, the concepts you may have learned would definitely apply much more often.

Bit too harsh but I can see where you're coming from. Kotlin with the Arrow library for Functional Programming is a nice balance between nice guarantees and correctness of Haskell and practicality IMO.