
Learning Haskell is no harder than learning any other programming language - nuriaion
https://williamyaoh.com/posts/2019-10-05-you-are-already-smart-enough.html
======
li4ick
The biggest lie about Haskell is that it's easy to learn. No it's not, and I
do use it at work. Sure, it's not THAT difficult to get a basic understanding
until you get to the usual Functor, Applicative, Monad stuff, which you can
understand if you imagine them as context bubbles. Once you put something into
a side-effect bubble (IO), you cannot take it out, so you're obligated to work
inside of that bubble. This analogy should get you far enough. You're now
ready to build toy projects.

But, even if you finish the Haskell
Book([http://haskellbook.com](http://haskellbook.com)), which is like 1300
pages, you're still going to be unable to contribute to a serious code base.
Anyone who says otherwise is lying. Now, you have to understand at least 20
language extensions which you find randomly at the top of files {-# LANGUAGE
ExtensionHere #-}. Now you have to understand how to really structure a
program as either a stack of monad transformers, or free monads or anything
else. Then you get into concurrency and to do that you have to understand how
Haskell actually works, what non-strict computation does etc. etc. Otherwise
you're going to get some nasty behaviour.

You think I'm done? Let's get to Lens. You can use Lens after a relatively
short time of reading the docs. But to understand Lens? Very few people
actually understand Lens.

Don't get me wrong, Haskell has spoiled me, and I don't really want to touch
any other language (I still like Clojure, Rust, Python, Erlang). Once you get
past that the language is a joy to use.

~~~
yakshaving_jgt
You don’t need to understand the internals of a thing to use the thing.

~~~
barrkel
This has not been my experience of using technology effectively. Without an
understanding of the implementation details, you inevitably use something
inefficiently or for not quite the right purpose.

I cannot imagine anyone using a database effectively on any significant amount
of data without understanding indexes, how different joins work, why join
order is important, what effect join orders have on performance, etc. Get to a
certain scale and it's not enough to know about indexes; you need to
understand the structure of b-trees, disk I/O performance, how CPU cache
performance affects b-tree navigation even when index is cached in memory, how
to use compound indexes effectively to reduce random access through the index,
etc.

The constraints of CPU and memory never go away, and if you're trying to scale
something, you're going to be limited on either or both of those resources.
That in turn forces you to understand execution and memory behaviour of the
abstractions you're working with. All abstractions leak when pushed.

~~~
tome
> I cannot imagine anyone using a database effectively on any significant
> amount of data without understanding indexes, how different joins work, why
> join order is important, what effect join orders have on performance, etc.

But conversely you probably didn't have to understand what filesystem the
database runs on, whether it is in a RAID array, whether the network
connection was over Ethernet or T1, etc.

All abstractions leak. The question is _how_ leaky they are. In my experience
Haskell abstractions are much less leaky than most.

~~~
barrkel
I did and do; when performance at the database level isn't right, you need to
look into OS stats, I/O stats, disk stats (the SAN is an area ripe for
unexpected contention, RAID5/6 act like a single spindle and inhibit random
access in ways that RAID1 or RAID10 don't, stripe length in RAID5/6 bloats the
size of small writes, etc.), but I had to stop somewhere :)

~~~
yakshaving_jgt
> but I had to stop somewhere

Why? You seem unsatisfied with any of the previous layers of abstraction, so
where does it end? When can I truly call myself a user of a database?

~~~
ukj
When you don't have to fix it when it stops servicing requests, or worry about
scaling workloads.

When you treat it as a black-to-grey box, not a grey-to-white box.

------
octagonal
Coincidentally: it’s also the only programming language I know of where
someone has written a lengthy blog post about how I’m in fact, _not_ too dumb
to comprehend it.

~~~
giancarlostoro
I didnt think about how hard Haskell is because I never forced myself to learn
it. It just didnt interest me. With Java or C# I can make so many things with
minimal friction. The other language that people talk about being hard is
Rust. I am going to assume theres blog posts about it not being hard.

I like that with Go or Erlang everything I learned 5 or more years ago has
still stuck to me. With D I can be effective quickly. With Rust I struggle a
bit. Rust is probably great for building a web browser but doing backend web
development feels way more work than Go or even Python (CherryPy). Haskell I
dont even remember a darn thing anymore.

------
alkonaut
Haskell was used in the first programming class at university and that was
excellent. Some people that already know how to program had to throw their
preconceptions out the window. So everyone was either a novice at programming
entirely or at least a novice at functional programming. It wasn’t problem at
all. I’d argue most students wrote better code in that class than they did in
the imperative/OO classes that followed. _Especially_ the students that
weren’t (and likely never did become) programmers.

The thing about imperative and OO programming is that it’s hard to do _well_.
I honestly havent seen more than 1/10 developers write ”good” OO code even
after 10 or 15 years as professionals. Large scale OO is a cognitive load that
requires extreme focus, skill and talent. I prefer functional (or OO using an
extreme functional discipline like all immutable types etc) because _I don’t
have that talent, focus and skill_.

My point isn’t that Haskell should be the language of choice. I think it’s a
great language but I think e.g laziness makes it too hard to reason about
performance and behavior. Today I’d recommend F# I think.

~~~
Mirioron
And how many people dropped out of CS because of that first Haskell course? I
saw plenty of people struggling with Python initially and I know exactly how
they felt later when we had to learn Haskell.

I think if I had to learn Haskell first, then I would've just given up at the
start.

~~~
nh2
Where I did my CS degree (Imperial College London) , Haskell is the first
language taught (before Java and C).

To my knowledge across 4 years there, nobody ever dropped out because of the
Haskell.

People usually struggled with the maths instead.

People also did not have more problems getting Haskell concepts right than
linked list modification in Java.

~~~
Mirioron
They might not drop out specifically because of Haskell, but I don't see how
it wouldn't be a contributing factor. The Haskell course here was pretty much
just a struggle for almost everyone that took it.

~~~
Jhsto
Mind the opposite: finishing a bachelor's without ever having to deal with a
functional language.

I've met a lot of people (at work and post-grad) who have graduated from
colleges without an idea of what a functional language is or the concepts
behind them. I don't blame them, but its a pity to find so many workarounds in
legacy code which could have benefited from functions as parameters and less
state in general.

------
hobofan
That just reads as:

"You are already smart enough to write Haskell"... if you accept that you are
too dumb for most of Haskell and are therefore okay with being cut off from
most of its ecosystem.

Digging into a dependency due to a bug or custom feature is something that
usually happens on any bigger project of mine. If I have to expect that I
won't be able to work in a dependencies codebase because it will most likely
contain (multiple) concepts that I won't be able to understand, then that's a
big no-no.

~~~
kungito
I have only done Haskell during college and my friend is doing Haskell in web
backend in production so I'd say I have a pretty good feeling about the skill
gap in Haskell. There are many concepts that he tries to explain to me which I
don't get 100% but it really does feel like all I need is more time. It was
like that at first with monads and then phantom types, row types, hkt etc. I'd
say the biggest detractor for people is that it takes more than 1 blog post
and 1 hobby project to comprehend everything. It may take 1-2 years to learn
all the concepts. To me the beautiful thing is that the concepts learned
aren't some language quirks but instead general programming/math concepts
which you simply cannot think about in simpler languages like C#. With all
that, I'm still heavily put off from Haskell by all the tooling and I just
can't let go of the comfort of working in Visual Studio. In 10 years I hope
either C# gets some of my favorite things from Haskell like HKT and better
inferrence or Haskell gets better tooling and broader ecosystem. My bet is on
the former but gafter keeps postponing HKTs spec after spec.

~~~
pwm
If you feel like messing around with Haskell again for an afternoon then
install VSCode with ghcide (and a syntax highlighting plugin ofc). You might
get surprised ;)

~~~
verttii
Are you using that? Doing Haskell on vscode has been a painful experience for
me.

~~~
pwm
Yep, all my team has switched to VSCode+ghcide and so far we're in love with
it. Mind you ghcide is brand new, so this luxury of having a 21st century
Haskell IDE did not exists even just a few months ago. Before we used ghcid
with whichever editor (eg. Vim/Emacs/VSCode).

~~~
verttii
Thanks, I'll switch to it now based on your recommendation. Desperately want a
decent Haskell editing setup, the bad tooling is killing my productivity and
making me consider quitting Haskell.

Edit: Ok so I tried it. Template Haskell seems to break it, which my projects
use heavily. And does not even report syntax errors in some files. Seems like
yet another dead end for me as an editor setup, unfortunately.

~~~
pwm
Ah yes TH. That’s imho the last biggie in the way of total awesomeness. See
this ticket: [https://github.com/digital-
asset/ghcide/issues/34](https://github.com/digital-asset/ghcide/issues/34)

~~~
verttii
Got it, I'll keep an eye on this. Thanks for this recommendation!

------
jimbob45
No one has ever been able to explain to me why I should use Haskell instead of
something else. I get answers about idempotence and list comprehension and
strong typing which are great tactics but I never get the sense that they fit
into an overarching strategy for how my life will be made easier by using
Haskell.

I know Carmack has presented a case to code in a pure functional style here
[https://www.gamasutra.com/view/news/169296/Indepth_Functiona...](https://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php)
but that somewhat precludes the necessity of switching to another language
from C++. Further, he advocates for a new keyword 'pure' to assist the
compiler like const does, perhaps not knowing that const doesn't actually help
the compiler out in practice.

~~~
rumanator
> but I never get the sense that they fit into an overarching strategy for how
> my life will be made easier by using Haskell.

I would add that the elitist signaling that is rampant in functional
programming in general and the Haskell community in particular is also not
helpful.

~~~
raverbashing
I guess that's the main problem.

And look, defining a problem functionally works great on 10% of the cases, but
it complicates some 40% of other cases (very imprecise numbers).

The world is not functional, as it turns out. And a lot of those cases where
you can write functionally don't gain much from a performance or correctness
perspective compared to the procedural version

~~~
yakshaving_jgt
> The world is not functional

What does this even mean? If the world is not functional, then what is it? Is
the world procedural? And what world are we talking about? Our planet,
physically? Are you then discounting the worlds of mathematics and logic? You
don’t gain performance? What performance? Program execution speed? Development
pace and time to market?

Compared to the procedural version? Is your view that procedural programming
is inherently better — for any definition of the word — regardless of context?
Would SQL queries be easier to write if we told the query planner what to do?
Is the entire field of logic programming — and by extension expert systems and
AI — just a big waste of time?

So many vague aphorisms which do nothing to further the debate. And Haskellers
are the ones getting called “elitist”!

~~~
raverbashing
It's not vague, processors are still procedural. Network, disk, terminals,
they all have side effects. Memory and disk are limited.

SQL queries are exactly one of those cases where functional expression of a
problem outperforms the procedural expression, and that's why they're used
where it matters.

~~~
tome
> processors are still procedural

Exactly. I don't know why Haskell fanboys insist on abstracting us so far from
the machine. Declarative programming is really unhelpful because it says
nothing about the order in which code executes.

We live in a mutable physical universe that corresponds to a procedural
program. One thing happens after another according to the laws of physics
(which are the procedural program for our universe). Electrons move one after
another around circuits. Instructions in the CPU happen one after another
according to the procedural machine code.

The universe would never consider running 2020 before 2019 and a CPU will
never execute later instructions before earlier instructions.

Haskell fanboys talk about immutable data structures like it's beneficial to
go back in time and try again. But it's a bad fit for the CPU. The CPU would
never run some code and then decide it wants to go back and have another go.

~~~
gugagore
You're saying a lot of wrong things about CPUs. CPUs do execute instructions
"out-of-order", and they do speculative execution and rollback and have
another go. Branch prediction is an example.

All of this is possible only with careful bookkeeping of the
microarchitectural state. I agree the CPU is a stateful object. But even at
the lowest level of interface we have with the CPU, machine code, there are
massive gains from moving away from a strict procedural execution to something
slightly more declarative. The hardware looks at a window of, say, 10
instructions, deduces the intent, and executes the 10 instructions in a better
order, which has the same effect. (And yes, it's hard for me to wrap my head
around it, but there is a benefit from doing this dynamically at runtime in
addition to whatever compile-time analysis.) In short, it is beneficial to go
back and have another go.

This was demonstrated also in
[https://snr.stanford.edu/salsify/](https://snr.stanford.edu/salsify/). If you
encode a frame of video, but your network is all of the sudden to slow, you
might desire to encode that frame at a lower quality. Because these codecs are
extremely stateful (that's now temporal compression works), you have to be
very careful about managing the state so for can "go back and have another
go".

I am less confident about it, but what you say about the universe also seems
wrong. What physical laws do you know take the form of specifying the next
state in terms of the preceding state? And literally many of them are time-
reversible.

~~~
tome
Thanks. It was an attempt at parody but apparently I didn't lay it on thick
enough. I'll try to up my false-statements-per-paragraph count next time.

~~~
gugagore
What you wrote about CPUs many people believe, and many simpler CPUs operate
like that. So it was difficult for me to detect as parody. Sorry that I missed
it! It's funny in hindsight.

Not sure what the parody was in computing 2020 before 2019.

------
yomly
Imagine you spent a career learning the piano. Would you expect to pick up the
violin as if you were an expert?

Would it be reasonable to declare violin sucks! I've played piano for 30
years, vibrato is so hard it must be wrong, tell me why I should learn the
violin?

Actually probably a lot will come with you, your dexterity and music theory
will be quite useful, as will your ear.

But really, the instruments are very different and if you want to level up
your sense of pitch or really learn how to _sing_ a melody, the violin can be
great for that...

~~~
cuddlecake
Are you replying to the wrong link? The link is about programming fyi

~~~
yomly
I'm trying to draw analogy to maybe something less inflammatory.

Most of us here are programmers, a lot of us professionals.

Music is the output of musicians, as perhaps code is the output of
programmers.

But music comes in all kinds of flavours: classical vs jazz vs pop

Performance vs composition

Recital vs improvisation

And then choice of instrument within any of those areas.

I feel a lot of people misplace their aversion to Haskell because they fail to
recognize how _different_ Haskell is.

It's a bit like when English speakers think Chinese is a "hard" language. It's
not, linguistically it's actually a pretty simple language (whether the script
is easy/hard is up for grabs...)

Actually Chinese is just _different_ to English so you have few anchors and
familiar friends to base things off so it feels hard cos you're starting
afresh, like a child. And yet children of a china manage quite fine learning
chinese....

Meanwhile, ask a Spanish speaker about their experiences learning
Portuguese...

------
kccqzy
There is some utility in carving out a subset of a language to make the
remaining part easy to comprehend and easy to contribute to. C++ is a large
and complicated language but every team seems to be using a different subset
of it. The same thing would happen with Haskell. Every one might have a
different idea of where to draw the line for restricting advanced features.
The author might decide that Haskell 98 plus OverloadedStrings is good enough.
That's a valid stylistic choice. I would have drawn the line further; I
personally think features to simulate dependent types aren't worth it (think
singletons or DataKinds or TypeInType) but lens is absolutely necessary even
though it is difficult for beginners to understand. But ask a colleague of
mine, and you might receive a response that we should embrace complicated
type-level programming like the kind seen in Servant, but instead restrict
TemplateHaskell. All these are valid stylistic choices but they fragment the
community. And eventually debugging other people's code bases (say
dependencies) you would sooner or later have to face features you don't use.

Let us not forget the roots of Haskell as a research language where ideas in
functional programming are to be tried out. When it emerged in the 1980s it
was literally because a committee wanted a solid foundation to replace a
disparate mélange of functional programming languages. It succeeded in that,
and immediately introduced new features then considered highly novel (e.g.
type classes). In this sense, Haskell will never be as practical and pragmatic
as Go, where moderately modern language features aren't even in the language.
Choosing a language like Go could be a valid choice, and so is choosing a
language like Haskell.

------
gassah_qwert
Haskell is no doubt an interesting language. I have yet to work on a project
where it was the obvious choice but I’ve played around with it enough to like
it.

What I don’t like are some (not all) of the people who use Haskell and talk
about it online. They can be incredibly obnoxious. Haskell is not a tool they
work with, it’s their entrance to a _class_ of software engineers that you’re
not capable of being part of.

Just for the record: Anyone can learn Haskell. If you’re struggling with it
that’s because of a tooling / literature issue. Haskell people (even the nice
ones) are bad at explaining the language. The tooling isn’t very friendly and
the language is a shit sandwich to debug.

The concepts therein are no more difficult to grasp than any other in
programming. Is a Monad a box or a burrito? Please stop. It’s a language
feature that allows you to do certain things more concisely than the
alternative. Stop pretending it’s magic and show people how to use it and
_why_ they should. Stop drawing pictures.

No, algebraic data types are not hard to understand. You just make a big deal
out of them because you think the word algebraic sounds cool.

I could keep going but I think I’ve made my point.

Dear Haskell people: Get over yourselves. Do not mistake the larger software
community’s disinterest in your pet language for their inability to use it.
That’s simply not the case. If people _had_ to use it even ‘lowly js devs’
would master it.

Everyone else: If you haven’t used it already it is a very cool language and
worth learning even if just for personal edification. Don’t let the self
appointed high priests turn you off. Don’t expect their help either.

~~~
tome
Sorry you've experienced this obnoxious behaviour. I've been in the community
for years and never seen it. Maybe I'm not hanging out in the same places as
you or I have some sort of unconscious bias that means I don't notice it.

Could you link me to an example? I have some measure of authority in the
community and would like to help decrease the amount of obnoxiousness but I
can't unless I know where it happens.

> Dear Haskell people: Get over yourselves. Do not mistake the larger software
> community’s disinterest in your pet language for their inability to use it.
> That’s simply not the case. If people had to use it even ‘lowly js devs’
> would master it.

This is really interesting because the Haskell community I hang out with
(mostly on Reddit) would _love_ it if "lowly js devs" would master it. In fact
we all too often get told by non-Haskellers that "Haskell will never succeed
because it's too hard for most programmers to learn"!

~~~
CJefferson
Well, what about this article? It claims I just have to understand 4 basic
concepts to replace java, python and Ruby.

Great, so using those simple properties let's reimplement Eclipse. Let me use
tensor flow. Replace my Ruby on rail website.

~~~
tome
I can see how (certain interpretations of) it could be considered _wrong_. I'm
failing to see condescension.

~~~
CJefferson
The condescension is the authors assumption that this is right, and a tiny
fraction of haskell can replace all uses of other major programming languages.

This to me (as a non haskell user) implies other languages can't have anything
interesting to offer, as they can be so trivially replaced. That is the type
of attitude I see from haskell programmers.

~~~
tome
I see. Interpretations of that particular passage range from all the way from
trivially true (Turing completeness) to trivially false (I can't build
anything that uses Ruby on Rails in Haskell). Certainly there are some
intermediate interpretations, like the one you suggest, by which it is
condescending.

------
nickbauman
I remember Rob Pike unveiling Go at a Google talk years ago and some Googler
got up and said "why would Go be better than Haskel?" and Rob said "Because I
can't understand Haskel source code and I'm pretty sure you could understand
Go source code right now."

~~~
arendtio
I think this is still one of the strongest selling points for Go. It is a
pretty solid language with a few basic concepts which are repeated constantly.
Sure, it doesn't have generics, error handling is a mess and the language
design isn't as consistent as it should be.

But what it does, is pushing everybody to write simple code which is easy to
understand. So many times I found the documentation (of some library) to be
incomplete, but jumping right into the code answered the questions I had. I
can't say that about every language.

~~~
nickbauman
Totally agree. When I first encountered Go, I kinda hated it for its
lugubrious combination of being rather "braindead" and opinionated about being
braindead at the same time. Typing it every day gave me flashbacks of
programming Java circa JDK 1.4 (before the compiler-only based generics were
introduced in 1.5, which I still believe didn't solve enough problems for the
complexity it added). In short, it felt like a step backward.

But after seeing its gc performance sitting at the single-digit ms timeframes
with huge heaps (60 gigabytes!) I realized I needed to hold my nose.

What helped me make peace with it is its automated testing story. It's baked
into the language in a way I've rarely seen in any other runtime.

------
ducaale
Blog post that explains Functors, Applicatives, And Monads in pictures
[http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...](http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html)

~~~
goto11
Condescending tutorials seem to be an integrated part of Haskell culture. The
rationale might be that people who don't already know Haskell should to talked
to like kids. "Don't be scared, a monad is just like a Burrito!" and so on.

I can't recollect I have ever learned a programming concept through metaphors.
The only way I have learned concepts is though solving tasks in a language and
thereby learning to use the tools available.

I actually think Haskell is a very enjoyable language, but there is a culture
around it which treats the type concepts (arrows, monads etc.) like goals in
themselves rather than tools to achieve something useful.

~~~
AnthonBerg
The only condescension I see in Haskell-related discussion is condescension
towards Haskell _ers_ , claiming that Haskellers are condescending and say
condescending things like writing condescending tutorials.

As I see it it’s actually not very nice.

With the utmost respect, truly, humbly: I am against this custom that it’s
just fine to call well-meaning people for condescending. As it appears to me,
claiming condescendence is more of a statement of the claimant, but this is
still an unfortunate custom. Who are we _really_ to claim condescension?
Really?

The article linked to in the post starts off with quotes from people who
directly state that they feel like they would need to be smarter to use
Haskell. It’s a common thing. The article addresses that. It is literally the
opposite of condescension.

Then there’s the burrito tutorials with pictures. I for one actually think in
weird abstract sloppy metaphors and colors. My head really is full of burritos
and inaccuracies. I was helped enormously by the burrito concept. Textbooks
generally don’t speak in burritos. I work with people to whom the burrito
class of analogies is not helpful. They think in a more direct and crystalline
way. I wish I were more like them. And I try try to be. And I can. And it
makes me better. And I really do think I also bring something to the table by
spraying flaming burrito concepts and lateral jumps into the team zeitgeist.

~~~
goto11
> I was helped enormously by the burrito concept.

OK fair enough, I can only speak for myself and the way I learn concepts. The
way I learn a new language or platform is always to try to write a real
program that does something. I am only able to lean concepts when I can see
their usefulness. But I should recognize that other people learn in different
ways.

~~~
AnthonBerg
I want to add that I actually do see how it comes across as condescending.
After this exchange and thinking about what you wrote. idk, like, “Here, look
at these kiddie pictures, those are suitable for you, and then I’ll withhold
the real work ok?”

------
bryanrasmussen
If learning it is no harder than any other programming language that presumes
that every other programming language is equally easy to learn. Furthermore it
assumes that people have an equally easy job learning whatever language they
learn.

Neither one of these conditions are remotely indicated by research on the
subject, therefore the statement is false.

Also I did try learning Haskell at one point and I found it harder than some
other languages, I would say I found it Erlang level hard which I tried at
about the same time( about 2009) but I think Erlang has a little more
inclusiveness to their community IMHO

~~~
yakshaving_jgt
> Neither one of these conditions are remotely indicated by research on the
> subject, therefore the statement is false.

What is the standard unit of measurement for quantifying just how difficult a
language is to learn? Is there a standard unit of measurement for quantifying
the competence of a person learning a programming language?

~~~
bryanrasmussen
I'm pretty sure the field is too young to have developed a standard unit of
measurement of either of these things, if there were such units their creation
would be one of the stunning intellectual achievements of mankind in recent
history and would have such obvious benefits to many other parts of human
endeavor that I would expect it would be a field more investment heavy than
machine learning at the moment.

However it has been shown that there are people who seem more attuned to
different learning styles, styles of programming, there are differences in
difficulty between first language acquisition and later (dependent on language
similarity, language domain), and many other studies regarding programming
language learning that it can be said not everyone learns equally well every
language, and not every language is equally as learnable.

~~~
yakshaving_jgt
> it can be said not everyone learns equally well every language, and not
> every language is equally as learnable.

I think that’s reasonable, but the question is then at what point does a
language become sufficiently difficult that it no longer provides a good
return on investment? And to what degree of proficiency must one achieve in a
language in order to productively use it?

It doesn’t take a long time to learn all of Elm, and you can be productive in
it quickly.

It takes a _very_ long time to learn all of Haskell, but it does not take a
very long time to be productive with it.

~~~
bryanrasmussen
totally agreed, and I suppose in Paul Graham's concept of a Blub programming
language there might be a language that is difficult to become proficient in
but allows you to achieve things that would not be reasonably achievable in
other languages.

------
aaronmu
The company I work for defaults to F# when choosing tech for a specific
project.

We defaulted to PHP and C# in the past.

We have quite some experience training people who just graduated and even
people with backgrounds outside of tech.

Training someone from zero to autonomously writing production code is a lot
easier in F# compared to PHP and C#.

We educate people in Elm and Haskell and switch over to F# when they’re ready
to try building the first real thing end to end.

~~~
thrower123
F# is really a very nice pragmatic language. C# keeps cannibalizing features
from it, which is both good and bad...

~~~
bob1029
As a die-hard .NET/C# developer, I would be curious what you perceive to be
the 'bad' side of that coin. I assume something like LINQ would be classified
as 'good'?

~~~
BeetleB
What he meant by bad is probably the fear that MS will abandon F# once C# has
borrowed enough features from it.

~~~
thrower123
The other unfortunate is that as C# accretes features, the old still hangs
around. Eventually you end up with too many valid ways of doing things, and
cruft that either can't be worked around or was never updated.

It's been over a decade since generics were introduced, but I still encounter
code using ArrayList today...

------
Tempest1981
Maybe I missed it, but what's the best way to learn basic Haskell? I was
expecting a tutorial. Or link to one.

~~~
colluphid
[http://learnyouahaskell.com/chapters](http://learnyouahaskell.com/chapters)

~~~
ahartmetz
NO. Not that one. It explains the easy parts at (boring, pseudo-funny) length
and expects you to understand the hard parts after a few sentences.

~~~
noisem4ker
It's good at explaining those easy parts, though. It also encourages
experimentation in the REPL. For a more complete understanding, I agree that
it must be accompanied by some more reference-style material.

------
macando
I always wondered whether imperative languages feel more intuitive to most
programmers because they are:

a) Inherently simpler and require no prior advanced knowledge of math.

b) They are the default in every curriculum and once your brain is wired that
way everything else seems counter-intuitive.

I remember in the first grade of my elementary school we were taught basic
algebra and how sets work (union, intersection etc). I understood both
concepts but I couldn't relate sets to the outside world. Like why do I even
need this. Maybe new programmers feel this way about functional languages and
Haskell.

~~~
ThrowawayR2
Try:

c) That's the way microprocessors actually work. Machine language is just
imperative commands and branch instructions.

------
vojta_letal
I am a skilled Scala developer with knowledge of FP sufficient enough to make
two contributions to the Typelevel cats/kittens ecosystem. Yet I was not even
able to start a hobby project in Haskell. I always start and fall back to
Python shortly after. Is it just me?

~~~
agumonkey
That's actually interesting. Was it the base prelude typeclasses that are too
different ? AFAIK scala uses monadic code too .. I expected not too much
difficulties using haskell. Maybe that's the syntax ?

~~~
vojta_letal
Scala has an awesome IDE support, familiar rich JVM ecosystem, familiar
syntax, ability to ignore the fact that logging is a side effect...

I had a hard time understanding the Haskell ecosystem, plus the syntax is just
way too different and restrictive.

For example the last tutorial I tried to follow recommend using nix package
manager to install Haskell. I failled missereably, it just did not work out of
the box.

~~~
agumonkey
I see, I had more luck using stack but I understand it was a matter of luck.

someone should make a haskell fiddle for newcomers

ps: I wouldn't think that syntax would matter that much, was Scala your first
FP language ?

------
agumonkey
I'd argue that it's not as simple. But there's a relativity factor here.

1) Haskell is much like math. You look at some concepts and ideas and fail to
see what it is about, until 20 years down the road you finally click that
"maaan" discrete mathematics was already encompassing 90% of computation it
just wrapped it in counting instead of concrete computer instructions.
Mathematicians have this culture of going too far, too concise, too fast for
most of the population.

2) Mainstream culture imposes a negative toll on this because when you're fed
Java or PHP (let's say you learned in the 2000s when they were peak fad)
you'll interpret Haskell through them, brain already set on a belief, and it
will make it twice harder. And it's really hard to disentangle the weird bliss
of being able to manipulate elements through an interface (here it would be
the syntax its idioms) from "objective reality". I too was enamored by PHP
associative array syntax (so fun compared to C or Java lack thereof) and F5 to
see a website change before my eyes. Haskell feels like a punishment compared
to this. Not even counting the social aspect of it .. wordpress made people
have colleagues and money.

Anyway, keep learning haskell (and FP, and logic, and math).

------
verttii
The real question is is it worth the time & effort.

~~~
bob1029
From my perspective, it isn't cut-and-dry. The quick response I give is:

If you are developing a business application and no one dies if something goes
wrong for a few hours, the answer is "hell no". Productivity takes a hit for
no strong upside to the biz.

If you are developing a safety-critical system, the answer is "maybe". This
one is more obvious.

The more complex reasoning is that ultimately, almost every software system
has to interface with the outside world in some way. Putting your functional
programming layer as your principal interface between your internal and
external domains is an extremely high-cost endeavor due to the complexity of
handling things you can't predict. If your system is safety-critical, and you
have extensive control over the external domain (e.g. dedicated, redundant
sensor networks), you might be able to justify this added complexity because
you can control many more variables than you would be able to otherwise.

An alternative approach that seems ideal to me at this time is to use
imperative techniques as the principal architecture, and then use functional
within that domain in the specific cases where it can be justified. Good
examples of this would be C#/LINQ, or even invocation of F# from C# (e.g.
rules engine). Imperative is extremely good at handling side-effects and
managing exceptions. Functional is deterministic if you can keep it on rails.
Using both where most suitable w/ interop between seems to be the most
productive approach.

A quick corollary could be: "If you are _exclusively_ using functional
techniques to build your application, you are probably making a mistake".

~~~
verttii
I'm writing most of my apps in Elixir which is also functional. I got no
problems wiring side effects with it despite it being less imperative than
some C#/Java/friends. In fact, I'd write high availability apps on Elixir any
day over C# or other OOP/imperative lang. I don't ever want to touch any
safety-critical systems though, but I do care about correctness of the
business logic. Somehow I have zero interest in Microsoft langs/runtimes in
general.

That said, Haskell just feels like a different beast. I also don't know how
interop would actually work with these different solutions, would feel like
unnecessary complexity if anything. Only to end up losing the benefits of
Haskell's strong typing.

I've been struggling to justify spending more time & effort on concepts mostly
exclusive to Haskell, only to be able to be productive on it. I keep thinking
I should brush up my Elixir skills instead.

------
pi-victor
i've learned rust in a month of coding sparsely. in fact, i'm as comfortable
today at writing rust as i am at writing go. i've been struggling to learn
haskell for over half a year. i think it's an amazing language, don't get me
wrong. but the fact that haskell is not harder to learn than any other
programming languages is false. after taking a few online course, tutorials
and so on, i still believe it's one of the most interesting (if not the most
interesting) programming language in existence and also the hardest.

~~~
tome
Did you click through to the article? The HN title is (currently) "Learning
Haskell is no harder than learning any other programming language". The
article's _actual_ title is "You are already smart enough to write Haskell".

You appear to be responding to what a zealous mod wrote not what anyone
actually believes.

(See also
[https://news.ycombinator.com/item?id=21171360](https://news.ycombinator.com/item?id=21171360))

------
ummonk
>What do you need to write real Haskell? The core of the language is extremely
simple. If you understand how to write and use

>pure functions and values >pattern matching >sum and product types >how to
glue together IO to make side effects

You can do pure functions, pattern matching, and sum and product languages in
plenty of other languages that have much more user-friendly syntax, community,
and documentation. Also doesn't hurt that they have impure IO so you don't
have to jury-rig impure IO using a monad.

~~~
tome
I don't think what you say contradicts anything in the article ...

~~~
ummonk
It does. Haskell is harder to learn than other languages because it has a
difficult syntax, navel-gazing community, and complex documentation.

~~~
tome
You're right! Turns out it's me that hasn't read the article. Anyway, remove
the sentence about it not being harder to learn than any other language (which
I think is unfortunate) and _then_ I don't think what you say contradicts it.
Haskell can be very hard to learn yet still within reach of most programmers.

------
spicyramen
I took a Haskell class couple of years back (Functional Programming) as
reference I worked for 12 years before as Software Engineer using Pascal, C,
C++, Java, Perl, Shell, Python, Visual Basic, and I felt like I was learning
Chinese, I really put extra effort, but Monads, Applicatives, etc were
complicated and way above my head. I really never found a reason to continue
that punishment, I admire the teacher and the community who work on it, maybe
not for me. But not easy

------
Mugwort
Haskell basics are easy to learn. Nobody learns Haskell to linger on the
basics. Haskell is a useful tool for express a deep ideas which aren't basic
and require time, effort, focus and guidance to learn properly. You can still
do quite a bit with the basics. I solved many Euler problems using Haskell and
prefer it over Python.

------
defanor
I mostly agree with the article, but not with the HN title (which doesn't
match the article's title). The article itself has a nice statement:

> If you’ve already learned another language, you can learn Haskell. And even
> if you haven’t, learning Haskell is no harder than learning any other
> programming language.

But most of the programmers are familiar with imperative languages, and can
quite easily switch between them (possibly writing non-idiomatic and awkward
code, but without having to really learn the language from scratch to do so).
While a purely functional language with unfamiliar syntax doesn't let one to
do it as easily. So indeed, if you haven't learned other languages, probably
it's not harder, and if you have, you still can learn it, but likely it would
be harder to learn than other imperative languages if you are already familiar
with a few imperative languages.

~~~
tome
> I mostly agree with the article, but not with the HN title (which doesn't
> match the article's title).

I think the HN title used to be correct. Perhaps the mods changed it. I can't
imagine why. It's a completely different claim from the article!

------
Elrac
As a Haskell n00b, I'd like to mention something I can do in about 20 other
languages but not in Haskell:

( UPDATE: I stand corrected, in a reply by tome. )

I'm writing and debugging some functional code - in Clojure. There's a
function I've smoke-tested on its own but that's failing me with "real" data.
Lacking a decent debugger for Clojure and being too lazy to isolate my problem
into a test setup, my tool of choice is the lowly "debug print."

In Clojure, the body of a function is essentially imperative, and I can insert
a `(println "label:" value)`. To do the same thing in Haskell, I'd have to
restructure my whole damn program.

I understand the rationale for purity in Haskell, but sometimes I see it as
badly standing in my way of accomplishing what I want to do.

~~~
tome
Have you heard of Debug.Trace? It gives you exactly what you are looking for.

[https://hackage.haskell.org/package/base-4.12.0.0/docs/Debug...](https://hackage.haskell.org/package/base-4.12.0.0/docs/Debug-
Trace.html)

~~~
Elrac
Wow, cool! Thanks. I hope to do more with Haskell once I retire, and this may
stand me in good stead.

I think my point is still supported to some extent by the fact that this is
knowledge from outside of the language that I'd need to know to accomplish.
It's something I need someone helpful like yourself to tell me about. Also
something that only works because this library deliberately breaks Haskell's
rules.

~~~
tome
> Wow, cool! Thanks. I hope to do more with Haskell once I retire, and this
> may stand me in good stead.

I'm glad it was helpful.

> It's something I need someone helpful like yourself to tell me about.

In general we're happy to help but it does annoy us when people make
assumptions about what it's like to program in Haskell without actually trying
it. If you'd like help I can suggest Haskell Reddit
[https://www.reddit.com/r/haskell/](https://www.reddit.com/r/haskell/) or
emailing me personally
[http://web.jaguarpaw.co.uk/~tom/contact](http://web.jaguarpaw.co.uk/~tom/contact)

> something that only works because this library deliberately breaks Haskell's
> rules.

Only if you have very punitive assumptions about what Haskell's rules are,
like those who have never used the language often do. People who actually
write Haskell programs have other ideas.

------
viburnum
When I tried to learn Haskell, I tried doing the kind of stuff I usually do in
Ruby: parsing log files, converting text formats, etc. It seemed hopeless. I'm
curious to hear about the experience of someone who uses Haskell for everyday
tasks. Does anyone do that?

------
nec4b
There are languages that attract people who want to get things done (mostly
multi paradigm languages these days) and there are languages that attract
people who want to feel special (languages oriented on one true way or
obsessed with a particular purity).

------
ConcernedCoder
Yeah, ok, let's say it's true that it's no more difficult to learn Haskell as
opposed to any other... with a mindshare of 0.29% ( according to something
like this: [http://pypl.github.io/PYPL.html](http://pypl.github.io/PYPL.html)
) isn't that like saying that it's no more difficult to learn "Upper Egyptian
Arabic" ( see:
[http://pypl.github.io/PYPL.html](http://pypl.github.io/PYPL.html) ) rather
than something a little more esoteric? ... i.e. WHY would you want to learn it
unless you have a very specific use-case, i.e. moving to Egypt

(edited for a word)

~~~
tome
Did you click through to the article? The HN title is (currently) "Learning
Haskell is no harder than learning any other programming language". The
article's actual title is "You are already smart enough to write Haskell".

You appear to be responding to what a zealous mod wrote not what anyone
actually believes.

(See also
[https://news.ycombinator.com/item?id=21171487](https://news.ycombinator.com/item?id=21171487))

~~~
ConcernedCoder

      My point was/is that even if it IS easy to learn, relatively speaking, WHY would you want to learn it when it's obviously a niche language... I mean a REALLY small niche at that...

------
foxes
Mirroring some of the comments here, just because you don't understand the
internals does not mean you can't pick it up and be productive with it. This
is what you do with any other language, but it just seems more natural to you
(even though they are really just as complicated).

Hence I feel like one of the big issues is that people learn to program in a
non declarative/imperative way. When you first pick up python / c / c++ etc,
there are plenty of details you don't necessarily understand (who here has
absorbed all of the c++ spec?).

At most Haskell is just different and I don't think it requires more mental
effort than anything else.

------
fooker
Everyone is smart enough to write Haskell. Almost no one is smart enough to
read Haskell.

There is a reason loops are easier to read and maintain compared to a
fold(map(filter(zip(...)))).

~~~
pwm
To give you a counter example: when i write code in an imperative language i
always first write the logic out as fold/map/filter and then translate that
into an imperative loop.

~~~
fooker
That's not a counter example. I stated map/fold/filter is difficult to read.
You said they are easier to write.

These are not opposite, and I happen to agree with you.

~~~
pwm
Fair comment. I do find reading it much easier as well, which I guess boils
down to familiarity, but when reading i don’t need to translate it hence my
comment re writing.

------
mac01021
Learning Chinese is no harder than learning any other language. Unless there's
a language you already know that is unlike Chinese and more like other
languages.

~~~
thrower123
Learning Chinese is objectively more difficult than learning alphabetic
languages. Although learning Chinese really would be more like learning APL.

~~~
AnimalMuppet
That's written Chinese. Learning _spoken_ Chinese is more difficult if you're
not used to a tonal language, though.

------
rmtech
Can anyone recommend an intro to Haskell for me? ~4 years of Python experience
and a math background. Ideally something online/interactive ...

~~~
tome
The canonical source for Haskell introductions is the following, I believe

[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

------
JanisL
Maybe things have changed since 2005 when I first used it but Haskell was
certainly harder for me and the people I knew to learn than other languages.
For languages of a _similar power_ I can see Haskell being similar difficulty
to learn. But compared with something like Python the amount of effort needed
to go from zero knowledge to being able to write some sort of program that
produces some useful real world results is much higher in Haskell.

I say this as someone who quite likes Haskell, when you have a problem that
fits well with Haskell it's really amazing.

~~~
yakshaving_jgt
Things have changed significantly in the last _four_ years, so they definitely
will have changed a huge amount in the last 14 years.

------
iLemming
I've struggled with Haskell for a long time. Surprisingly, learning Clojure
made many Haskell concepts clear and more approachable for me.

------
Dude2029
I would expect to get paid more though and that is not happening (except niche
places). Same story with F# and Scala. Not worth it.

~~~
atemerev
Scala software engineers are some of the best paid out there.

~~~
Dude2029
What are the examples? There is no requirement for specific domain experience?

~~~
Smaug123
Well, I was hired into dev at a quant finance shop (you may draw your own
inferences about pay), using F#, with no experience of quant finance.

~~~
Dude2029
Niche. Wouldn't be surprised if it's G-Research or Jane Street or one of those
very few places.

~~~
Smaug123
Could you give an example of something that's not niche? If quant finance is
niche, it's quite a big niche.

------
macawfish
It's not the language that's frustrating to learn, it's the tooling.

------
kunos
Honestly I think Haskellers should spend less time writing blogs and more time
writing code that does something interesting/useful. When the language you
claim being so superior comes with such bad tooling and usability your claim
instantly looses any substance.

~~~
yakshaving_jgt
Strange. I spend the vast majority of my time writing code that does something
interesting/useful. In fact, it puts food on the table and a roof over the
heads of several families.

The reason why I’ve given up my own time to write some blog posts (apart from
it just being an occasional pastime), is that everyone complains that Haskell
doesn’t have enough documentation or tutorials.

Damned if we do; damned if we don’t.

~~~
verttii
We absolutely need more hands-on Haskell tutorials and blogs. I've been
massively more productive with Haskell with the help of just a few well
written blogs that are full of tutorial posts.

We got a lot of books detailing various type theories, algorithmic nuances and
so on in Haskell, but very little resources to actually help anyone get off
the ground with practical web development.

~~~
tome
> I've been massively more productive with Haskell with the help of just a few
> well written blogs that are full of tutorial posts.

Could you share some examples? It's probably a good idea to promote useful
content!

~~~
verttii
The best resource for me has been Matt Parsons' blog:
[https://www.parsonsmatt.org/](https://www.parsonsmatt.org/)

------
sitzkrieg
haskell is easy to learn if you want to ignore a bunch of floofy high level
math concepts and just paste how to parse a json library.

lets be real, software engineering that brings results is i/o. i see the
appeal in pure functions and guarding that out but the shit that matters is
going to be the nasty mess of stuff that saves business logic that was hacked
together over 10 years of rnd, interns and crunches

~~~
UK-Al05
Algebaric data types and monadic types are perfect for business logic.

Read the book domain modelling made functional.

~~~
carapace
This too, eh? "Domain Modeling Made Functional" \- Scott Wlaschin

[https://www.youtube.com/watch?v=Up7LcbGZFuo](https://www.youtube.com/watch?v=Up7LcbGZFuo)

------
ben509
I'm not sure the idea of a "beginner" language should be a design goal, and I
don't think Haskell being a hard langauge to learn means it's a bad langauge.

Easy as a design goal has led to many languages like AppleScript that try to
ape natural language, or to visual languages, and those consistently seem to
be bad choices.

Haskell is probably not as hard as many people who haven't made the jump think
it is. But it is hard.

> What do you need to write real Haskell? The core of the language is
> extremely simple. If you understand how to write and use [four items broken
> out below] then you already have everything you need to write useful
> programs that solve real-world problems.

The core is admirably simple, but simple doesn't mean easy. Easy to learn is
when you have intuition and existing skill that readily map to the core
constructs used in a language.

> pattern matching

There are cases where pattern matching is obvious, but this is not how most
people have learned to structure a problem.

People aren't naturally good at breaking problems into parts, that's a skill
you have to develop over two or three years, which is my guess from observing
myself and peers.

> sum and product types

Explicit types are already hard; you're already excluding many people who have
trouble making the leap from Javascript to Java.

But Haskell's type system is _heavily_ generic. And its support for container
types is not so great. Making them easy was a major reason Perl, Python and
Ruby grew quickly, and landed us a ton of horrible code.

To understand how Haskell makes these container types hard, compare the API
for Data.Map to the API for java.util.Map[2]. You can ignore Java's rather
pathetic facilities for FP entirely because you don't need them.

The Haskell version has functions to do lookup, union, intersection and
various predicates. In Java, they're trivial to implement with a loop.

> pure functions and values

The intuitive way to change a thing is... well, to change a thing. I can
express it directly in plain language. To express the pure way, I have to
describe it as "construct a new value such that all properties are the same
except for the changed properties."

I've seen a meme that shows Common Core multiplication in a pedagogical
context, and contrasts it with the traditional long-form multiplication. It
completely misses what CC is trying to do, but it's useful in showing what
people are comfortable with: they grok procedures much better than
abstractions.

Functions are the part of math where most people who were okay with algebra
nevertheless started tuning out. First-class functions are weirder still.
Haskell also mandates currying, and being strongly typed every function gets a
confusing type signature.

All that said, keeping track of state changed by mutation is deceptively hard.
It's a case where your intuition routinely leads you to build things you can't
maintain. But sticking strictly to the claim in the OP, it's easy to _learn_
to mutate state but hard to _do_.

> how to glue together IO to make side effects

This shows that monads are core to the language, and they have all the
difficulties of generic types as well.

Everyone has jumped on how hard monads are already so I won't belabor the
point, just to say that except for concurrency / parallelism, I don't think
there are any core language features as hard to understand as monads.

(And I'm not sure exactly what the "core language" is, but I think anything in
the Prelude is fair game.)

Haskell does make them dramatically easier with "do" notation, but I think you
really do need to grok monads for your learning to progress beyond simple
examples.

[1]:
[https://hackage.haskell.org/package/containers-0.6.2.1/docs/...](https://hackage.haskell.org/package/containers-0.6.2.1/docs/Data-
Map-Lazy.html) [2]:
[https://docs.oracle.com/en/java/javase/12/docs/api/java.base...](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/Map.html)

~~~
tome
> To understand how Haskell makes these container types hard, compare the API
> for Data.Map to the API for java.util.Map[2]. You can ignore Java's rather
> pathetic facilities for FP entirely because you don't need them.

> The Haskell version has functions to do lookup, union, intersection and
> various predicates. In Java, they're trivial to implement with a loop.

I don't get it. I don't see how you do lookup with a loop at all. As for union
and intersection, are you sure you write them in Java with a loop? The way
that's obvious to me would be quadratic. Is there a better way?

------
vogre
...but have no reason to.

------
ngcc_hk
Not la. Clojure.

