Comment by sandhundred | Hacker News Reader

Comment by sandhundred | Hacker News Reader

Parent Full thread

I struggle with this. After years of studying OO and design patterns in Ruby and JavaScript I was having troubling building complex asynchronous systems and stumbled into Go. I saw the value of types for managing that complexity and the runtime for supporting asynchronous primitives, but internally was very limited by the lack of generics for things like collections and higher order control flow for things like error handling.

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.

I've been in a pretty similar situation.

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.

I tried Elm with much enthusiasm, but ended up putting it aside it for now (0.17) after being bored by JSON decoding (of big, deeply nested API response objects). Could there be a way to more succinctly (declaratively?) express my data types and keep Elm's awesome typing/compiler guarantees, but avoiding the painful construction of repetitive, nested, boring decoders?

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?

[1] https://github.com/NoRedInk/elm-decode-pipeline

[2] http://noredink.github.io/json-to-elm/

I agree that this is a great example of Elm's shortcomings. I'm not an Elm expert but I don't know anything better than json-decode-pipeline.

If you (or other passersby) have experience in how JSON decoding is achieved in Haskell (or other statically-typed functional languages), I'd be curious to read some sort of comparison with Elm.

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

Wasn't quite ready to release this, but it seems relevant so see part two here:

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.

Current version: https://hackage.haskell.org/package/aeson-1.1.0.0/docs/Data-...

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:

http://www.purescript.org/learn/generic/

An even smaller first step is Java -> RxJava, to start thinking in streams of data and transformations of that data.

This is the case for me. I simply don't have the time to invest in a technology that I keep hearing great things about, but from which I don't see many interesting things being built. I don't mean to knock on Haskell; I'd like to learn it, I just can't justify the time. I'm hoping to get there eventually, perhaps by pursuing Rust more or checking out Reason/OCaml, but I don't have many applications that could benefit from functional languages (at least not functional languages that are markedly slower than the languages I'm building things with today).

My advise : baby steps. Yes Elixir or Ocaml or Rust or Elm would be a "step back" (i would disagree for the erlang ecosystem. No type system but the paradigm is as solid. Just widely different. There is a reason SPJ or John Hughes are close to the erlang community).

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)

I have two questions for you:

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

> Don't things get messy and ugly as the pure world of Haskell is being tainted?

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.

> you can't learn Haskell in a lecture unless you already knew SML or OCaml, and even then probably not.

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.

> The thing with learning "haskell", is that there's faar more to it than learning the basic language constructs

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.

Oh it almost certainly is the main reason why it isn't popular. Then again, that is also the same reason why abstract mathematics in general isn't popular.

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.

> Don't things get messy and ugly as the pure world of Haskell is being tainted?

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.

> For example, hashmaps are largely unnecessary in Haskell, and you find out why the more you use it.

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?

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?

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.

http://stackoverflow.com/questions/6121146/reading-ghc-core

A bug report that is a good example of how to read core, at least it seemed easy to tie the very simplistic code to the expanded core in combination with the commentary.

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.

The thing is that the amount of developers in the world is growing fast so most people need simple tools to get started. Once the field matures people will want to be able to express themselves more fluently, the whole reason languages like Haskell are getting more popular is because this is already happening.

Keep fighting the good fight! I'm happy to hear that you took the initiative to host meetups and participate in reading groups.

You can probably get a Haskell job if relocating is an option.

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

Haskell is beautiful in its way, but it isn't the only game in town. Try some other languages that are similar in philosophy but have different strengths than Haskell. You'll be a lot happier and you'll also stand a better chance of convincing your coworkers to try Haskell for some things.

I hope you find your ideal Haskell job soon.

Reply on news.ycombinator.com