9 ms·
I spent several years learning and using Haskell professionally and I have to say it was a waste. Almost nothing has carried over to what companies use or want
by ilovecaching 5y ago
I spent several years learning and using Haskell professionally and I have to say it was a waste. Almost nothing has carried over to what companies use or want day to day, nor did it really help me to understand computers at a deeper level Erlang taught me about concurrency patterns which are actually useful in the real world, C/Rust taught me the abstractions presented by the hardware, locking, etc. but Haskell taught me something completely irrelevant to furthering my career or my skill as a software engineer.
I think that it’s an interesting side hustle and if people enjoy playing with it more power to them, but most of Haskell is driven by language enthusiasts and researchers who have no eye for practicality. Everything is done for its own sake, such as whether something can be done through derivation via HKTs etc. A lot of it comes down to it being an excuse to play with math rather than write programs. The way that it’s oversold as the solution to all bugs is based on an understanding of society that doesn’t match with reality, nor the needs of the modern programmer.
So what is an IO Monad? It’s a clever trap to get you to spend your time getting a poor man’s degree in category theory when you could be studying how computers really work.
- bedobi 5y agoBit 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.
- kqr 5y agoI 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.
- ilovecaching 5y agoWriting 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.
- azurelake 5y agoI 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!
- ilovecaching 5y agoIt'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.
- kqr 5y agoI 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.
- azurelake 5y agoThe parent comment said "C lineage", not C.
- azurelake 5y agoYeah, 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.
- Alekhine 5y agoI 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.
- ilovecaching 5y ago> 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.
- ipnon 5y agoTotally 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.
- ilovecaching 5y agoI 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).
- the_af 5y ago"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.
- chii 5y ago"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.
- tome 5y agoI’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?
- dllthomas 5y ago
- _query 5y agoHaskell can also be very useful for practical real world programs, not just researchers. Check out IHP: https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/ This might change your mind a bit :-)
- js8 5y ago> 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.
- youerbt 5y agoI 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.
- kaba0 5y agoLet’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.