I think for many folks Haskell is too big of a gulp all at once. It's not that it's too hard (I think that's a bit of a myth). It's that it's just too different. It's hard for an experienced Java programmer to go from being highly productive to seriously struggling to even solve FizzBuzz in Haskell, let alone dealing with lazy IO and various terms and concepts that don't show up anywhere else like monad transformer stacks.
In my experience, this is where languages like Elm come in and are extremely valuable. This is also why I think Elm is much more important than PureScript. I've recently had a lot of success advocating for and using Elm for an internal tool at work. We've now got several thousand lines of pure Elm code, and for the most part everybody has been incredibly impressed with the overall Elm development experience. I'll also say that the tool ended up being a lot more powerful and feature-rich than originally planned because Elm made it so easy to keep expanding and improving the application.
Java -> Elm -> Haskell/PureScript is a much more enjoyable path for many than Java -> Haskell. It also feels a lot more motivated. Use Elm for a while, and you see many of the strengths of Haskell, but you also see many of the weaknesses of Elm. Once you've seen those weaknesses, you'll be happy to find that Haskell solves most of them. Now you have a concrete reason to look at Haskell, and that can make a big difference.
noredink's json-decode-pipeline [1] seems better than what Elm offers out of the box, but it still feels like a lot of ceremony for something mundane. People building webapps [2] to help users generate boilerplate code seems like a hint something's wrong, isn't it?
A quick Googling suggests Data.Aeson [1] is the popular library in Haskell land. Does it rank better on what I was hoping for (succinctness, ease of use)? If yes, would it be reachable within Elm, or are some Haskell constructs missing in Elm to achieve a similar experience?
[1] https://hackage.haskell.org/package/aeson-0.6.1.0/docs/Data-...
https://github.com/codygman/concise-json-parsing-in-haskell/...
Please give feedback if you don't mind. I'd also like to wait a bit before officially sharing with wider audiences then this comment gets.
Keep in mind that part one is "haskell/lens as explicit as possible" which is why I suggested looking at part two to draw conclusions.
Edit: just looked at elm decoder pipeline and it looks very similar to aeson.
The key difference with Aeson is this line:
> deriving (Generic, Show)
Because of this, it's not necessary in that example to even write the JSON decoder manually. The compiler can generate it on its own. I don't personally know of any way to achieve this in Elm, as Elm doesn't have typeclasses and what's effectively happening here is that an instance of the FromJSON typeclass is being computed by the compiler.
A very similar trick is possible in PureScript:
But it would also be a "step up". You would feel better than with Java and you would have an easier adoption than Haskell. And in a couple years, you would add a Haskell dependency to them. And then a bit more. And in a decade you will have help clean the mess we are in a bit.
Have a goal. Try to find a path to reach it. Look at how to improve things :)
I know for a fact that both the Elm and Elixir and Rust community would be really happy to help both the transition and evolving the tooling if needed. Come talk to us. Try to make your life a bit better :)
(I do not know well the OCaml community, but i bet you would also find helpful people there)
- How does Haskell fare with large projects that use APIs that are inherently stateful, like OpenGL? Don't things get messy and ugly as the pure world of Haskell is being tainted?
- How do I optimise Haskell code without having studied the language for decades? I had a lecture where we were taught Haskell, so I know the language, but darn, even a simple hash map seems to be so very complex in the language. The fact that everything is a linked list (bad for caching & performance) and everything gets copied around really turns me off.
Haskell is excellent at handling state. "Pure" doesn't mean no state, it means all state is handled explicitly in a type-safe way.
> How do I optimise Haskell code without having studied the language for decades?
It requires learning some new things, but honestly when I worked at a company that used Haskell I didn't really have to worry about this much. You occasionally make some things strict and there are some good heuristics about when this is needed, but overall it just didn't come up often.
> I had a lecture where we were taught Haskell, so I know the language
No you don't. You can learn Python in a lecture if you know Ruby; you can't learn Haskell in a lecture unless you already knew SML or OCaml, and even then probably not.
> The fact that everything is a linked list (bad for caching & performance) and everything gets copied around really turns me off.
Everything isn't a linked list in production code. It's easy to swap lists out for vectors wherever it's correct to do so, because you can write almost all of your code generalized to the necessary type class rather than specific to one single container type. Real Haskell code performs well, poorly-performing code is just used for examples when teaching beginners because it's easier and introduces fewer things at once.
I just want to emphasize this part because it's really quite true, as someone who came to it from F#/OCaml.
The thing with learning "haskell", is that there's faar more to it than learning the basic language constructs. You can learn haskell the language in about a day, but you can't really learn haskell the paradigm/philosophy/mathematical discipline in a day, much less actually program haskell that quickly.
That being said, it's not as difficult as it's made out to be, the mountain you need to climb is much shorter than people realize. The issue is largely one of jargon, and getting used to using and thinking in all the new terms and concepts that really have few equivalents in other languages.
That would be a compelling reason as to why it's not popular. This basically means your programming experience is not transferable, leaving it as a weird side language that some people stumble into due to uncommon factors.
Saying the experience is "not transferable" is looking at it the wrong way. Learning the discipline behind haskell isn't even remotely the same kind of beast as learning how to use a niche legacy framework in COBOL for example.
It's a lot more akin to learning to read human language for the first time, because all it's doing is familiarizing you with patterns that exist in code and computation, independent of Haskell. The actual language part of the haskell equation is literally the least relevant/significant, because what it teaches you is to recognize mathematical/computational patterns that you can find in any language, despite the difficulty of expressing some of those concepts succinctly in some languages (e.g. java).
The biggest thing that's 'not transferable' is the ability to communicate the high level patterns to others who haven't gained literacy with that particular branch of mathematics/CS yet. But that's true of all sciences and mathematics. You can call it a "weird side language", but that's kinda doing it a disservice as a language that's intended to express complex relationships and computational patterns in the most general way possible.
The word "pure" gets thrown around with regards to haskell, but most of its draw and apparent purity, isn't the same as the technical definition of it being a "pure" functional functional language.
This "pure" functional aspect is more of a quirk that you get used to working with, rather than a noticeable feature.
I would argue that the seeming 'purity' most haskellers love about the language, has to do with it's ability to cleanly and flexibly model domains without fear of refactoring, or worrying about fitting them to strict opinionated frameworks. This is because the language is flexible enough to let you really model your thoughts however you want, regardless of what they'll be plugging into. Meaning that you can focus 'purely' on the business logic.
So no, the 'purity' shouldn't be affected very much in large projects.
> The fact that everything is a linked list (bad for caching & performance) and everything gets copied around really turns me off.
It sounds more like you're inadvertently looking to shoehorn your existing mental model of how "performant code should work" into Haskell, rather than looking into how "performance with haskell" is achieved. Haskell works on a fairly different paradigm, so you can't just make assumptions about it like that. For example, hashmaps are largely unnecessary in Haskell, and you find out why the more you use it. The linked lists in haskell are also not much of a concern, because they're already highly optimized, due to the fact that they have to handle being infinitely large, not to mention that there are other data structure readily available if needed. Overall, haskell is already quite performant,and you can turn it's laziness features off wherever you want if you really have a hard time reasoning about is lazy evaluation performance anyway.
I use Haskell quite a bit and I don't know what you would use instead of a strict hashmap for something like O(1) lookups in an application to correct spelling. Do you?
The pure world of Haskell does not get tainted. Monads help manage the inherent messiness better. As for your question, perhaps this glut example I quickly found and skimmed will help:
http://www.arcadianvisions.com/blog/2011/modern-opengl-with-...
- How do I optimise Haskell code without having studied the language for decades?
Optimizing is where I've been having trouble with lately. You need to understand laziness, inlining, and reading basic core imo.
For understanding laziness, read a few tutorials. Then use the ghci debugger as described in the ghc manual. Play around by adding BangPatterns based on educated guesses from any intuition you formed on how laziness works.
For understanding basic optimization (Space and time):
http://book.realworldhaskell.org/read/profiling-and-optimiza...
For understanding core, read/watch in this order:
http://www.haskellforall.com/2012/10/hello-core.html
http://blog.ezyang.com/2011/04/tracing-the-compilation-of-he...
https://skillsmatter.com/skillscasts/6495-keynote-from-simon... (go back over after watching above)
http://www.stephendiehl.com/posts/ghc_03.html
Try generating core for some Haskell code you want to know about. Tie what you've learned to core generated from Haskell code that solves one of your real world problems.
https://ghc.haskell.org/trac/ghc/ticket/11710
Another good tip is to use the ghc option `-ddump-rule-firings` to see if code gets inlined or otherwise optimized.
Keep fighting the good fight! I'm happy to hear that you took the initiative to host meetups and participate in reading groups.
Also checkout eta since it's Haskell but interops with the JVM:
https://github.com/typelead/eta
You are a haskeller writing Java, I'm a haskeller writing Go ;)
Eventually I arrived at Haskell after strongly considering Clojure, and I'm very happy about what I've learned and my new way of approaching programming complexity. Unfortunately there is nowhere else to go from here since I can't find employment as a Haskell programmer. OCaml, F#, Scala, Elixir, and Elm all feel like a step back. Now I'm a Java programmer and quite miserable. I feel hampered by the language nearly everyday in terms of how easily I can express my thoughts in code. Haskell isn't perfect but is the best fit for my mathematical mindset.
I am trying to lead by example. I help host my city's Haskell meetup and contribute to a Haskell reading group. The path is lonely, my co-workers poke fun at me, and don't care to put in any effort to understand what I have to say. I love teaching and explaining things but there is zero interest because the machine keeps moving. Not many at the office even enjoy Java but are resigned to do it for our large pool of enterprise clients. All in all each work day is a void I put 8 hours into, which is fine, compared to most working conditions; it causes no suffering beyond the lacuna.
I'm past the stage of trying to convince other programmers anything. I recognize many are happy with their tools. I yearn for that happiness and don't seek to spread my misery. I offer my time to those who are interested and want to learn more.
Anyway, this article nails it, Haskell has advantages but they aren't enough to change things without the infrastructure the author is building. I look forward to being an early adapter of Unision and continue to remain hopeful for the future despite the long odds.