Awesome, hope you enjoy it. :)

score 2 · canonical

It has been very much worth it for me (I’m an ex-lisper).

I wrote a guide for learning Haskell, I’d be pleased if it can help at all: https://github.com/bitemyapp/learnhaskell

score 4 · canonical

My point is, it would be nice to see some articles like this where the solution stays within canonical Haskell

Using the right data structure for the job is one example of this. (List -> Vector, using real graph library rather than homespun adjacency list, matrix libs)

I don’t think any Haskellers see selective application of strictness or unpacking as not being Haskell. Lazy is the right default, but sometimes strictness is wanted. There’s no uniquely Haskell-y way to write Haskell. Haskell is an ensemble language of multiple paradigms and tools for solving problems. It’s the combination thereof that is Haskell. Consider our concurrency/synchronization primitives. Nobody has anything that rich yet also performant and easy to use.

Speaking personally, I can’t write reliable concurrent software unless I’m using Haskell!

Example. You are trying to write a streaming parser. Lets say you did it with Strings and lazy functions. Probably not great perf-wise. Why?

1. Well, the laziness might not be appropriate - you want to immediately force the thunks as you process the data. So you want a streaming library. Like conduit or pipes.

2. You used String. String is a linked list…don’t do that :) - so you use bytestring.

3. You homespun your own parser lib. Don’t do that. So you use Attoparsec.

Then you realize libraries like this or this do what you wanted to begin with.

Writing fast code in Haskell, for most beginners, is about knowing what libraries and abstractions to use. I don’t know anybody that has write to “dons” style code as you see in the shootout. The numerics stack somebody is writing for Haskell is infinitely more Haskell-y than that.

80% of the perf advice I end up giving people boils down to “stop using List/String (Which is List of Char)”.

score 4 · canonical

requires doing it twice

More the case when you’re first learning. You learn to anticipate what you’ll want with experience and the laziness is a non-issue for most Haskell code out there. Much like how you learn patterns, anticipate the application of approaches in the languages you know.

Whole-heartedly worth it for me, the complexity management (able to scale to larger projects), runtime efficiency, compiled binaries, Best-of-our-industry concurrency kit, best type system that isn’t costly time wise, etc etc

I came to Haskell from Clojure. I spent more time futzing around with perf and laziness in Clojure than I do Haskell :)

score 5 · canonical

Working on the Haskell book still. Up to 44 pages of rough content hammered out.

Met with a buddy to hammer out reshaping my guide for learning Haskell into something appropriate for Haskell.org

Dist-sys meetup tomorrow. Local Haskell class Friday. Work on my monad transformers talk (going to be ripping off Tony Morris’ talk on transformers aggressively here).

score 2 · canonical

Leaning on “pragmatism” probably isn’t the angle you want to take given it’s (anti) intellectual pedigree: http://en.wikipedia.org/wiki/Pragmatism

That aside, if we mean a focus on what is practical, it seems unlikely to be practical to make a human do the work a compiler could do. You can do a lot better than Go these days. You could do a lot better than Go 10 years ago.

There are things I like about Go. Binaries and cheap threading come to mind. But to ignore the work PL has done to make entire classes of problems history is a perpetuating the “Null value billion dollar mistake”. Golang’s type system is near useless and emblematic of the sort of type system that dyn-langers wanted to escape to begin with.

score 3 · canonical