[Kenji]

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.

[nbouscal]

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

[axlprose]

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

[jack9]

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

[axlprose]

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.

[axlprose]

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

[codygman]

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

[codygman]

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

[codygman]

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.