Haskell for a New Decade [pdf]

> Your 3 months is 5 years for someone trying to learn on their own in their spare time.

I learned the key parts of Haskell in 3 months of my spare time from university (where I had much less spare time than I have now in industry). And that was at a time where learning Haskell was much harder than it is now; today there are a lot of really detailed books, tutorials, and videos available, tooling works out of the box with few surprises, and error messsages are way better.

Of course learning in your spare time does not give you as much practical experience and feedback as you get on a job, but it gets you enough to get into such a job.

> You don't have to try and pick apart the online knowledge.

Not any more.

* Step 1, buy a beginner book and work through it.

* Step 2, work through FP Complete's [1] Applied Haskell Syllabus (https://www.fpcomplete.com/haskell/syllabus/). This will make you comfortable with most day-to-day data structures, techniques, testing, benchmarking and so on.

* Step 3, practice building some small applications that you think companies will actually need. Web servers, input validation, streaming data processing, and so on. It doesn't have to be fancy or use "cool" techniques, it just has to be /useful/.

* Optional Step 4, for extra hireability: Become better-than-average in a specific topic. This could be testing, performance, developer tooling, documentation, web stuff, anything that gets your juices flowing. Do a bit of open-source work in that area. Go to some meetups or conferences to see who's hiring, what they are doing, and what might be useful for them

> I want to understand Lens?

Again, you don't need to do that to get a job. I've conducted ~ 40 technical interviews for filling Haskell positions for various companies, and none required this. What is required is that you can do normal /useful/ things, with the high amount of correctness, clarity, refactorability, and reliability that Haskell provides.

Haskell, like mathematics, knitting, and C++, offers near infinite avenues of special topics that you can deep-dive into if you want. People talk about those at meetups because they excite them. But you don't have to do that to build useful software or get a job.

[1] This is the consulting company as part of which I gave most of aforementioned training. It makes most of the training material publicly available.

I got that, and it's an often-heard argument, which is why I stated that it worked as described for other companies as well.

Ah, I use https everywhere.

None of the languages that let you achieve certain top qualities (top performance, proven correctness, concurrency, compactness, etc) are trivial or "feel natural". Haskell, Rust, APL / K / Q, Erlang, hell, even C++ and Scala (though these two are unnecessarily bloated). You got to study and internalize concepts that underlie them, change your way of thinking.

This is because reality is not intuitive, too.

Take natural numbers. They are utterly intuitive. Three-year-olds can grasp them. But as you try to calculate more and more complex things in the real world, you discover the need in counter-intuitive concepts like zero, negative numbers, fractions, even the aptly named irrational numbers. If you try to calculate √3 using the intuitive natural numbers, your solution will be rather approximate.

Same thing with many "intuitive" languages, from Basic-80 to ES6. You can solve a number of problems with them, but many solutions end up inexact and full of holes. In a lot of cases, this is acceptable, or seen as acceptable.

But when you need tools for a precise solution, you have to study some "advanced concepts" (another word for math) and take a language like Haskell which support them. Sometimes you end up with something as unwieldy as your average three-story analytic formula, but this is often not a shortcoming of the language but the nature of your problem domain, described correctly.

I've been paid to write Lisp most of my career. Most new languages I check out seem like some variant of C or a dumbed-down version of Lisp. Haskell is the only one that seems like an actual upgrade from Lisp, in that there are things you can do in Haskell that would be quite difficult to shoehorn into Lisp without changing Lisp in fundamental ways. (A statement I never thought I would make before I found Haskell.) The full panoply of monads for example. Automatic currying for another. A true lambda-functional language that does not need parentheses and makes no compromises for their absence for yet another.

All this does not make me want to abandon Lisp for Haskell; Lisp is still more practical for most of my needs. But if I had to write a parser I'd probably first write it in Haskell and then translate it to Lisp, because Haskell expands the way you think about hard programming problems -- even beyond the realm to which Lisp expands it.