
Letter to a Young Haskell Enthusiast - psibi
http://comonad.com/reader/2014/letter-to-a-young-haskell-enthusiast/
======
joslin01
This is one of the best essays addressed to programmers I've ever read. It
speaks to you on a very personal level. Highlights:

> Haskell wasn’t built on great ideas, although it has those. It was built on
> a culture of how ideas are treated.

> In functional programming, our proofs are not by contradiction, but by
> construction. If you want to teach functional programming, or preach
> functional programming, or just to even have productive discussions as we
> all build libraries and projects together, it will serve you well to learn
> that ethic.

> Believe in everyone, attack nobody, even the trolliest.

> If you make even the most modest (to your mind) mistake, be it in social
> interaction or technical detail, be quick to apologize and retract, and do
> so freely. What is there to lose? Only your pride. Who keeps track? Only
> you. What is there to gain? Integrity

> Your self-esteem doesn’t need your help. You may feel you need to prove
> yourself, but you don't. Other people, in general, have better things to do
> with their time than judge you, even when you may sometimes feel otherwise.

> Be glad that others are charting other paths! Who knows what they will bring
> back from those explorations.

> Every time we learn something new and want to share it, we face these issues
> all over again -- the desire to proclaim, to overturn received wisdom all at
> once -- and the worse the received wisdom, the more vehemently we want to
> strike out. But if we are generous listeners and attentive teachers, we not
> only teach better and spread more knowledge, but also learn more, and enjoy
> ourselves more in the process.

~~~
bgilroy26
This is my favorite section of the essay as well. What a great approach to
disagreement, and how fruitful!

It's a mindset that shows tremendous respect for others, yet tremendous self-
assurance. It's the faith that the best ideas will win out in the long run.

------
VMG
It starts out from kind of weird premise

> Now, you’re a social person, and you want to go forth and share all the
> great things you’ve learned. And you have learned enough to distinguish some
> true statements from some false statements, and you want to go and slay all
> the false statements in the world.

I learned some Haskell recently and I'm somewhat enthusiastic about it. It's a
very difficult language, I took a lot of effort to learn Haskell compared to
most other languages. It's still difficult to understand other libraries and
code. But personally, For me, it was worth the effort to learn and understand
it.

I don't think it's worth the effort for everybody. I don't think it's fun for
everybody. I don't think it's the best tool for everything. I have no desire
to spread the good word.

If you start from the premise that it's the best language out there, everybody
should learn it and that it is easy, you'll get into trouble.

Edit: I don't get the downvotes -- maybe I did not express myself clearly?

~~~
munin
When you say "I don't think it's worth the effort for everybody", that's
exclusionary, and totally counter the tone of the article, so I don't think
your comment belongs in the thread about this article.

~~~
VMG
So the negation would be "Learning Haskell is worth the effort for everybody".
I think it is arrogant to say that when there are thousands of skills to learn
and a limited amount of time.

~~~
munin
And it's not arrogant to say "it's too hard"?

~~~
VMG
That is not what _" I don't think it's worth the effort for everybody"_ means.
Some people have a greater return on investment improving their skills for a
language they already know, learning a language that is not Haskell, or
learning a skill that is unrelated to programming.

------
roymurdock
Thanks for taking the time to formalize your thoughts in such a clear and
elegant manner.

Everyone needs a periodic reminder to keep their ego in check. On the one hand
it drives ambition, spurs achievement, and encourages personal development.
There is almost unlimited power in the concept of self.

 _Me_ against the world. _My_ achievements.

I think this attitude is very prevalent in programming and the tech world in
general. It is manifested and reinforced by the wild popularity of startups (
_My_ idea is good and _I_ can go it alone) and the tech visionaries (Gates,
Jobs, Musk) who seem to carry the weight of the world on their shoulders.

On the other, overfeeding your ego will make you narcissistic, selfish,
insecure, and hostile. You will lose your empathy for others, and ultimately,
your humanity, as you start to lose sight of the big picture: progress is a
process that started long before your time and that will continue unimpeded to
infinity, even after your infinitesimally tiny ego is wiped from existence.

As Isaac Newston put it best: "If I have seen further it is by standing on the
shoulders of giants."

~~~
kghose
"If I have seen further it is by standing on the shoulders of giants."

Ah, the original humblebrag.

~~~
marcosdumay
After you make the Scientific Revolution win, and start the Industrial
Revolution, changing the entire world forever, you're allowed to brag.

------
hibikir
I'll go against the grain and say that it's a pretty dangerous article.

What it wants you to do, slay false statements and spread what you know, is
exactly the kind of thing that goes terribly the minute you fail to figure out
what is true and what is false. Very few things in computing are really black
and white, but spending our time proselytizing just leads to more thinking in
a black and white world, and adoption of technologies that might leads us in
the completely wrong direction (Hello Spring!)

What we have to tell a young language enthusiast is that there is much insight
in ideas different than our own, and that there is much to learn in looking
outside of what you consider the best. Maybe there are tools that are better
suited for other kinds of problems. Maybe not everyone that disagrees with you
is very wrong about things and needs to be converted.

I mean, how can you even try to ask people to improve their communication
skills, when you say that people that do not think programming is math is
because they have the wrong notion of math?! I just don't see how you are
going to convince anyone of anything with that level of condescension.

Frankly, and being a bit meaner than I should, it seems to me that the reason
Haskell can't catch on is precisely that enough of its community thinks like
this.

~~~
the_af
(Disclaimer: Haskell fan who is also a complete newbie here).

I like what the article is trying to do, but I must admit there is something
off about it. Maybe it's me, but I read between the lines something like "you
and me both know Haskell is the best language, but try to be gentle with
unbelievers and admit that nobody, even Haskell programmers, is perfect. Other
languages have some good insights, too." which sounds a bit cultish to me, a
bit like teaching a Jedi knight to be humble. A truly open-minded position
would have to continually consider that maybe Haskell and its type system are
not the best options at all, instead of merely adopting a humble attitude and
avoiding aggressive confrontation.

Nothing wrong with believing a tool is better than others (I do!) but it makes
the article sound a bit condescending...

I'm ready to admit maybe I'm wrong and there is no implied presuposition that
Haskell is superior in the article :)

\----

Re-reading other comments, here is something related to what I've just said.
Someone quoted Newton: _" If I have seen further it is by standing on the
shoulders of giants."_

That statement sounds humble (a "humblebrag", some other commenter called it)
but carries the implication that you have, indeed, seen further. Maybe the
assumption that you as a Haskeller have "seen further" sounds immediately
condescending to others who think differently.

~~~
nbouscal
> A truly open-minded position would have to continually consider that maybe
> Haskell and its type system are not the best options at all

There are two ways that I can parse this comment. The first is that you mean
that there are other, newer options out there that will turn out to be better
than Haskell. This, almost all Haskellers would agree with: most of us have
more than a passing interest in e.g. Idris, Agda, Shen, etc.

The other reading is that you mean that other established paradigms are better
options (A third reading is that there is no such thing as better, but for
that I'll just point you to pg's classic Blub essay). This is a good thing to
consider once, but I strongly disagree with considering it continually. Once
you've made the comparison, if you come to the conclusion that one tool is
better than another, it doesn't make sense to continue that comparison
forever. It may make sense to revisit it from time to time as you grow in your
understanding of the task and the context, but at some point your posterior
probability of the other tool being better must grow so low as to no longer be
worth investigation. For many Haskellers, the comparison between a Haskell-
like type system and dynamic typing is this kind of comparison. My posterior
probability of dynamic typing being a better choice is less than one percent,
so it makes no sense for me to continue reevaluating that option.

If the latter is what you mean, I can't disagree that it is a truly open-
minded position, I can only point you to a quote by the inimitable Tim
Minchin: "If you open your mind too much, your brain will fall out."

~~~
marcosdumay
For a given problem, no doubt, some languages are better than others. I still
doubt one can say that in general, without qualifying what kind of problem
he's solving.

I'm just writting a device controller in a side project (at userland - I
already have enough problems to solve - the kernel sees it as a soundboard and
a USB TTY). At fist I tought "wait, great time to try some serious reactive
programming in Haskell", but I gave up, C++ looks much better fit to that
problem. When it's done, I'll probably write some Haskell wrapper, and use it
in a functional reactive program, but Haskell is just not the language for the
controller itself.

Also, another side project requires a CRUD web app, with some simple rules.
It's in Python. No way I'm going to write it in Haskell. Another component is
a TCP server with a complex behaviour and that I want to scale, it's in
Haskell, no way I'm going to write it in Python. Another component is in
VB.Net, go figure...

Maybe there is a young and mostly unkown language that is indeed best - no
strings attached. But it's certainly not Haskell and I still didn't find it.

~~~
nbouscal
There's definitely a tradeoff between library maturity and language quality.
There are also a few specific domains that are best-served by more domain-
targeted languages. That doesn't mean we can't say that, _aside from those
issues_ , one language is better than another. I can say that Haskell is a
better language than Python and then go ahead and use Python anyway because
NumPy/SciPy/pandas or whatever. We can separate the issues and render
judgments about language quality _independent from_ library maturity, etc.

The existence of specialized domains justifies an argument that you should use
specialized languages in those domains, but that is almost never what we're
discussing. Java, Python, Ruby, Haskell, Clojure... none of these are
languages specialized for a given domain. They're all general-purpose
languages, and if you compare them as such independent from their libraries,
Haskell is the best of them. That _does not mean_ that it's the best choice
for every project, but that's a completely different question.

~~~
marcosdumay
Sorry, but I still disagree.

It's the flexibility of Python that makes it great for writting CRUD
applications with diverse data types, at the same time that it's the rigidity
of Haskell that makes it great for writting a complex specialized server. It's
the unsafety of C++ that makes it great for directly interfacing devices, but
you really does not want that unsafety in any of the other examples.

None of that is a matter of maturity, it's the other way around, the available
libraries are good for different tasks because the languages allow them to be.
You can't just compare those languages without context.

~~~
nbouscal
I wasn't going to wade into the object-level CRUD app discussion because it
seems beside the point, but I can't possibly disagree more about Python
somehow being better suited for the domain because of "flexibility". Python is
not more flexible than Haskell in any meaningful way.

The only possible argument against static typing comes in the form of a
program that won't typecheck, but should. This is the only type of
"flexibility" that Python could win at, with regard to type systems. Please,
show me a practical example of such a program. I've asked a dozen people for
one, and nobody has ever followed through.

The only other argument against Haskell's "flexibility" I can think of would
be against purity, but that argument doesn't fly either. Any competent Haskell
programmer can work easily with state, IO, etc, and I've never run into an
effectful task in practice that takes meaningfully longer to do in Haskell
than in Python.

People are often quick to typecast languages into some role that seems to fit.
Haskell is rigid and mathematical, Python is flexible and readable, etc. These
impressions rarely come close to capturing the reality, and in this case end
up being downright misleading.

If I'm starting developing a web application from scratch, with zero libraries
available to me, I'm picking Haskell without a shadow of a doubt.

~~~
marcosdumay
Every single value in Python is weakly defined, and can change at runtime.
Functions can accept any set of parameters, objects do not need to conform to
a class, the entire namespace can be replaced during the execution of a
function. If you have a better name than "flexibility", please tell me,
because I can't think of any.

Haskell is in the oposite extreme of that dimension.

Anyway, that has no relation to readability. Python's flexibility leads too
easily to metaprogramming, for example, what's extremely powerfull, but a
nightmare to read. And classifying a language as "mathematical" is borderline
nonsensical - it only carries some slight meaning because people that say that
normaly want to say "algebrical", in oposition to, maybe, "logic-temporal".

~~~
nbouscal
Maybe reread my post - I wasn't saying that those typecasts of the languages
were accurate, I was doing exactly the opposite.

The characteristics of Python you just mentioned are only specific to it in
cases when they are erroneous. They basically all evaluate to "Python isn't
type-safe." So again, show me a program that is best represented in a non-
type-safe way, and I will concede the point. If you can't, then this
flexibility you're praising isn't a feature, it's a bug.

~~~
marcosdumay
> The characteristics of Python you just mentioned are only specific to it in
> cases when they are erroneous.

They are explicit at the official documentation, if they got there by error,
they are official features now.

> They basically all evaluate to "Python isn't type-safe."

Yes, they do. They are at the opposite extreme from type-safety. That's why I
used them to exemplify how it's the languages that apply better to some
problems.

> So again, show me a program that is best represented in a non-type-safe way,
> and I will concede the point.

Well, any Django[1] CRUD would do. They are quite trivial, in there's little
meaning in specifying exactly the manipulated data. Yes, Haskell has tools for
displaying data at the web, and querying a database; no they are simply not as
powerful when applied to that problem.

[1] In other frameworks they are about as simple, but you asked for one
example.

~~~
lomnakkus
I find this a strange and unconvincing example -- if I'm understanding you
correctly, that is. Is your complaint about strong typing here that you'd be
forced to define stuff like a record Customer with fields "lastName",
"firstName", etc. and you'd rather avoid that?

If you'd like something more "dynamic" (i.e. type-unsafe), you can instead
just define a "universal data type" for all your CRUD data. For example you
could define, say

    
    
       data Any = Number Int
                | Str String
                | Map String Any
                | Date ...
                | ...
    

and where you want "universal" data manipulation you just use Any.

EDIT: Thus you've confined all the "fuzziness" of your data definitions to a
"subsystem" of your system and you can still benefit from proper types and
type checking everywhere else.

------
tekacs
It's a shame this is titled to target Haskell developers - it feels like it
would be a good read for most young developers.

(though I can see how the endless feature-incorporating (typeclass-based)
refactor cycle is particularly relevant to Haskell - come to think of it, I
think many somewhat older Haskell developers could stand to take from this
too)

~~~
300bps
You're right - this letter fits perfectly with many languages.

 _Letter to a Young Visual Basic 6 Programmer_

[...]

 _So how do you help them want to learn it too? You do not tell them this is a
language for smart people. You do not tell them you are smart because you use
this language._

[...]

~~~
jimmaswell
I get the feeling you're trying to say something about VB6

------
dustingetz
" _You do not tell them this is a language for smart people. You do not tell
them you are smart because you use this language. You tell them that types are
for fallible people, like we all are. They help us reason and catch our
mistakes, because while software has grown more complex, we’re still stuck
with the same old brains. If they tell you they don’t need types to catch
errors, tell them that they must be much smarter than you, because you sure
do._ "

This tactic is used a lot in evangelism talks and it doesn't work. A lot of
the non-FP people listen to these talks and come away thinking, "this person
is _obviously_ really smart", and then it comes up in the discussion
afterwords, so not only is it unhelpful, but it distracts from the message and
perpetuates exactly the myth that we're trying to dispel. We have to calibrate
to the audience's understanding of relative words like "smart".

~~~
the_af
This.

I tried to say something like this in another comment. I am a Haskell fan, but
the article sounds like evangelism -- and like with evangelism, its tactics of
always-show-you're-humble will inevitably annoy a large number of people.

~~~
AnimalMuppet
Well, the "If you use anything else, it's because you're too stupid to
understand how wonderful Haskell is" attitude also annoys people.

(This is not a caricature. People on this board - though not necessarily this
thread - have come across that way to me.)

~~~
the_af
Yes, yes, being rude also annoys people. What I'm saying is that many people
detect the evangelist's "always humble" attitude for what it truly is: hidden
condescension.

~~~
AnimalMuppet
I didn't read the article that way at all. I read it as a plea for _real_
humility, not _fake_ humility. And I don't think real humility can be hidden
condescension.

------
a-nikolaev
The article addresses a real problem. Haskell is presented by its neophytes as
some uber-arcane thing that cannot be understood by a mere average programmer,
you have to learn algebra first!, and read all Martin-Lof, and whatever else.
And it hampers adoption of the language by many other people who might be
offended by such superiority attitudes.

However, it is much healthier to present Haskell as simply a tool for writing
better and safer code, which is frequently easier to reason about than your
conventional for-loops all the way down. So everyone should try it, and say
for themselves.

I may be wrong and over-generalizing here, but Haskell is a very convenient
vehicle for showing off and belittling others. And honestly, who does not want
to stick Haskell somewhere in their CV just to look better nowdays? Being
fancy has a cost for the language. This is not an intrinsic fault of Haskell.
People just need such a thing. If there were no Haskell, we would have APL,
Lisp, Erlang, C++, or something like this.

~~~
VMG
But isn't it also a mistake trying to portray Haskell as just-another-
langauge? It clearly is not, it is more difficult to learn. Like with most
things in life, the benefits appear after putting a lot of effort into it. I
don't get the impulse to portray Haskell as "easy". The perceived arrogance of
Haskellers may also come from that.

You don't defuse arrogance by saying "Look, I'm not smarter than you. This is
easy. Now let's talk about Monads, they're just like Tacos. I'm patient."

Better be honest and say "Look, I'm not smarter than you. This is hard. We
need to start with data types, and the benefits won't be obvious until long
down the road."

~~~
kmicklas
I think it is anything but clear that Haskell is harder. What may be clear is
that functional languages are harder to learn for people who have already
learned imperative programming. But then you're forgetting the massive time
investments they already made in that style.

Having TAed intro classes at a university, I can say from experience that new
students pick up functional style much quicker and are always confused by
mutation until they've had a fair amount of experience with it.

~~~
yawaramin
Haskell goes way beyond just functional programming. Most of the interesting
stuff is happening in the types: monads, applicatives, lenses, etc. And when
you're trying to understand something like:

    
    
        FooT w (BarF x) Baz y z a
    

... it can seem a tad difficult.

------
egeozcan
I'm not a Haskell developer but the main idea in this article is big enough
that it can be applied to any situation where you feel that you know better.

Years pass and I always feel that I got rid of this "proving that I know
better" motive but, every time I look back, I always see that I still acted
with it and it was usually me who could do better. At the very least, I always
feel that I could do better in the social area - like, communication.

------
jeffreyrogers
It looks like I'm one of the few people on here not excited about Haskell.
Functional programming is great. Static typing is nice, yes. Hindley-Milner
type-inference even moreso, but I often find the language getting in my way.
Now, I'm not a Haskell expert, but I have used OCaml for some fairly
sophisticated problems in the past (basic optimizing compilers). So I'm
curious for the people who have used Haskell for something substantial whether
they've found their experiences match with mine.

~~~
judk
Haskell is a research language. It is the most viable research language for
production applications. A few people will solve a major business or life
problem with Haskell. Many more people will take the ideas back to improve the
quality of their Java or C# code.

~~~
jeffreyrogers
That's a good point, and I've definitely used more functional language
techniques in my regular programming since learning Haskell/OCaml.

------
michaelfeathers
I like the Ruby version of this: "Matz is nice, so we are nice."

[http://blog.emmacodes.com/post/55841830917/minswan](http://blog.emmacodes.com/post/55841830917/minswan)

Interesting to note how two different language cultures manage to say this.

------
soperj
I actually learned some Haskell during my CSC degree, and it was actually a
language that I took to really easily and enjoyed. I actually went home and
made sure I could write haskell programs at home. It's been 8 years now though
and for the life of me I've never been able to think of something I'd use it
for.

~~~
the_af
If you enjoy Haskell and programming, why not start a hobby project with it?
It's a general purpose language after all.

(Using it at your day job is a different proposition, of course. I'm still
having arguments with my boss over the use of Scala instead of Java. Imagine
if I proposed moving outside the JVM!)

~~~
soperj
I have lots of hobby projects, I just can't see how Haskell itself would be
useful. I do back-end stuff at work, so most of the stuff I do at home tends
to be front end web apps. Based on what I learned of haskell at the time, it
doesn't really seem like the right language for that sort of thing.

------
pestaa
Nice attitude, that's for sure. However I feel like this is targeted at the
open source community. At work, it sucks to be better, because I'll get the
harder bugs, deeper work, more work, tough refactorings, architecture
planning, and everything that programmers who can't even write decent PHP
can't do.

~~~
egeozcan
There is something called "decent PHP"? Use Haskell! =) (This joke is so
relevant that I couldn't resist!)

Joking aside, my idea is that a job isn't good for one as long as you feel you
aren't learning anything but rather covering for other people. Monetary
compensation is not enough for these kind of situations because the
programmers I know generally are motivated not just by money but equally from
the sense of accomplishment as well. It's not about "confirming that you are
smarter and know more" as discussed in the article but rather the very basic
feeling of getting things done.

~~~
mattgreenrocks
This is something every young dev should know, Especially if you're a regular
full-time employee.

The job should do something for you! You may be paid well, but you must feel
like you're getting something out of it too; and if you have any sort of
intrinsic motivation you can't expect to be satisfied with just money. It may
be on you to find out what that is, there's no guarantee it will be technical
in nature.

There are times when this won't be the case, though, and you'll need to grind.

------
anmonteiro90
So.. wise. Thanks for this, I'll save it to read every few months.

This is something I always struggle against, but ends up coming to bite me
sometimes.

I also believe that there could be a more general version available for
either/both:

\- other programming languages / paradigms;

\- other fields of research

~~~
Dewie
... and other age-groups. Finding something that makes you feel "enlightened"
and makes you want to preach a bit can happen at any age.

------
ankurdhama
It happens with humans in general, probably one of the cognitive fallacies.
Whenever we gain new knowledge, we get infatuated with it and for the period
of infatuation we block out everything else. It could be any kind of knowledge
gain - "Hey I know the shortest path to office and I don't care what path you
take or suggest, mine is the best one".

My message would be this: "It is amazing what we know or learned, but what is
more amazing is the stuff we don't know yet - so be curious, not infatuated".

------
bilalhusain
May be the reason I want to learn Haskell but it never embraces me back is
that I enjoy snarky and condescending comments on HN.

~~~
titanomachy
We all have our vices.

------
amirmc
This is a great article and the ideas go _way_ beyond Haskell and programming.
We are _all_ still learning and our interactions with people can be much
better if we remember that.

In some sense, it also reminds me of the xkcd comic on learning new things
[http://xkcd.com/1053/](http://xkcd.com/1053/)

------
kelvin0
Wow, so many truths and core principles about life and social interaction in
such a concise post. I have started 'fiddling' with Haskell recently but after
reading this I realize I have some serious work to do with my interpersonal
skills and communication and being more considerate to others. Enlightening on
all fronts..

------
vorg
> Remember also that they were put off by your actions, not by your existence

Some people can be put off by your name, like when their primary interest is
their product is marketing its name rather than the technical merits of the
product.

------
Ono-Sendai
"It is not a language that is “more mathematical” or “for math” or “about
math”. "

I disagree, Haskell (and other functional languages) are a lot more similar to
traditional maths than other languages.

~~~
spopejoy
Hmm ... Pedagogically, I wonder if Haskell suffers from this emphasis on math.

For instance, I couldn't figure out State monad for the life of me, and in
general how monadic calls could maintain a context "in the background".
Explanations like "it's easy just follow the Kleisli arrows" weren't helping.

Finally I did the exercise of manually "inlining" every >>=, 'get' and
'modify' call in a trivial example of a StateT function calling another StateT
function. And then I got it. Truckloads of closures/continuations, constant
calls to re-create the monad with new information. Function calls with
functions as arguments that close over the previous calling function's state.

A lot of this was specific to how StateT + Identity unwrapped; I'm sure
inlining other monads would reveal different things, and unwrapping IO is
impossible in GHC :). My point is, math has been a great source of Haskell's
incredible expressivity, but the pedagogical focus on math threatens to mask
it's greatest triumph in Haskell: making all of that boilerplate code go away
with incredible precision and elegance. When you rip it open and see what >>=
or 'do ... get ... modify' is doing, you feel the power.

I feel like the article suggests this, too:

 _The only thing you need category theory for is to take great categorical and
mathematical concepts from the world and import them back to programming, and
translate them along the way so that others don’t need to make the same
journey you did._

At least for advanced programmers from other worlds, they need to see the guts
to appreciate how amazing this stuff is.

~~~
codygman
Seeing lots of those monads unwrapped and the lambdas that they get turned
into can be especially helpful for those of us (including me) that have an
imperative/OOP background.

------
Vektorweg
For me, it sounds like: go and study anthropology/ethics. Would be better for
everyone.

------
fasteo
tl;dr

"Nothing is worse than active ignorance." Johann Wolfgang von Goethe

------
innguest
Haskell just clicked for me not long ago after 4 years of revisiting it
periodically, writing one-liners and small programs, and reading tons of
material on it. All the tutorials in the world weren't helping it click for
me.

But then somehow I finally understood that Haskell is (trying its best to be)
Math. I had a deeply mistaken idea of what math is and I thought I "hated" it
and that any kind of advanced math is too hard for me. I have failed Calculus
before, though I've always done well in discrete math.

It was only when I realized that math begins (or does it?) with what you have
(objects, sheep, anything you want to count) and what you can do with them
(group, make a set, join two sets, etc). Then I went into a reading spree
about all ofthose very basic and foundational aspects of pure math (pure as in
"look around you, you can count things, you can group them based on some
trait, you can do operations based on groups, you can now think of those
groups as the entities to focus on, you can prove certain properties about
those groups, etc") and I found it amazing that so much can be known and
discovered from starting with just what you see around you.

When I understood that math starts with just looking around you then I finally
made peace with math, and I saw that it was good, that it was here to help me.
Then I looked at Haskell again, and suddenly Void, Unit, Either, Maybe, they
all made perfect sense. Maybe is a function that takes your set and gives you
a new set that looks the same, but has a special entity that means "the lack
of an entity in this set"; in other words, Maybe adds a zero to a type. It's
simple and easy for me when I choose to see it that way. Everything is a lot
more concrete and I have even drawn all these concepts and they map very well
to visual ideas. So many things in Haskell are recurring themes (like adding a
zero, starting things with a "one" entity, etc) that if you have a good
relationship with math, many things fall into place just nicely.

But I started Haskell hating math and that has held me back so much. So my
advice would be to never deny that Haskell is math, but to explain what's so
awesome about math, how it gives us so much certainty even if we only assume
very basic and seemingly obvious statements. I could have used some rough
advice like "listen, stop whining about math, you're wrong about what you
think math is, it's much more fundamental and it's a tool to help you organize
any set of ideas you have, so why would you not apply that to programming?"

~~~
pavlov
_It was only when I realized that math begins (or does it?) with what you have
(objects, sheep, anything you want to count) and what you can do with them
(group, make a set, join two sets, etc). Then I went into a reading spree
about all ofthose very basic and foundational aspects of pure math (pure as in
"look around you, you can count things, you can group them based on some
trait, you can do operations based on groups, you can now think of those
groups as the entities to focus on, you can prove certain properties about
those groups, etc") and I found it amazing that so much can be known and
discovered from starting with just what you see around you._

In the early '70s, there was a global movement in math pedagogy that took this
angle to elementary learning.

Instead of arithmetic, first graders were taught set theory. Elements and
unions became the first mathematical concepts introduced to 6-year-olds.

In the US, I think they called it "New Math". Here in Finland, set theory was
included in the national educational system's grand redesign. Regardless of
country, set theory as elementary math seems to have gone out of fashion as
quickly as it gained traction, and by the early '80s was out everywhere.

Maybe, if they had stuck with it, we would all be using Haskell now as a side
effect :)

(Here's a picture of a very '70s styled Finnish math teacher doing set theory:
[http://1.bp.blogspot.com/-vWW22FRIdfc/TobxIw3xF3I/AAAAAAAAHa...](http://1.bp.blogspot.com/-vWW22FRIdfc/TobxIw3xF3I/AAAAAAAAHaU/f5NMNHl5Z5Y/s1600/juou.jpg)
\-- "Now tell me children, what is the union of green swans and red bears?")

~~~
t-ob
I took a History of Mathematics module as an undergrad and remember our
lecturer telling us the main reason "New Math" never stuck was because parents
were no longer able to help their kids with their homework.

~~~
judk
This issue comes up every time new ideas enter education. This roadblock will
never be overcome, unless parents try to learn math as well.

------
jackmaney
> This is not a language for clever people, although there are clever things
> that can be done in this language. It is a language for simple things and
> clever things alike, and sometimes we want to be simple, and sometimes we
> want to be clever. But we don’t give bonus points for being clever.

I'm reminded of the adage about mathematics: think deeply of simple things.

------
michaelochurch
I think there's a lot of value in this article (which really isn't about
Haskell; but more generally about being in the top 5% of programming). I can't
disagree with the idea that we should show more open-mindedness toward
different approaches and civility to new entrants.

That said, I'm going to take a different tack, not because the OP is wrong,
but just to explore a second orthogonal component.

As programmers, we have both a weak and a submissive tribal identity. That's a
problem, and we should change it. I call it "weak" because we aren't good
judges of who belongs and who doesn't. The true bad guys (and, yes, they are
quite _bad_ and we must oppose them) have been commoditizing engineering work
for decades by flooding the market with low-skill, untrained, "software
engineers" (ScrumDrones, CommodityJavaDevelopers, etc.) in order to reduce top
talent's leverage in the market. It has created this mythology that talent and
skill don't matter, and while it's completely wrong, the failures are delayed
enough that the bad actors in the business can be promoted away from the
problem until shit breaks.

Our fatal flaw? Instead of striking the bad actors in the business world, we
attack those low-skill engineers, who might be infuriatingly incompetent, but
really didn't do anything wrong. ("You're just a PHP retard, so shut the fuck
up.") The true bad guys don't really care what happens to the
CommodityScrumDrones, and that's the point of having them is that they're
disposable. By attacking _them_ , the unskilled pawns, we gain nothing. Sure,
they're incompetent and may be anti-intellectual (or, more likely, they just
don't give a shit about programming and shouldn't be programmers, but aren't
stupid or bad people). But the anti-intellectualism we must fight is that of
the businessmen who are driving us in to the ground.

I say it is a submissive tribal identity because this divide-and-conquer game
_works_. Dysfunctional organizations and societies usually form three classes
that matter. (There are subclasses within each related to prestige factors
that don't matter.) The High must keep the Middle and Low at odds with each
other, lest they band together and overthrow the High.

In order to depress programmer wages and working conditions, the bad guys
prevent professionalization and collective bargaining, create startup
mythologies in order to make business bad actors look like real technologists,
and flood the market with commodity programmers (the Low). Amazingly, the more
skilled programmers (the Middle) will, driven by their disgust in sharing
working conditions with the Low, actually work unreasonably hard and clean up
their messes, just to out-compete them in a game that doesn't really matter
(the unskilled are never fired, and the overworked are rarely promoted). When
this works as designed, they turn into the Clueless layer of the MacLeod
model.

We _have_ to fight the anti-intellectualism. We've let ourselves be typecast
to _business subordinates_ rather than technologists and it's goddamn fucking
disgusting. When some businessman says "languages don't matter", we have to
humiliate him for his stupidity and anti-intellectualism, before he feels
empowered enough to start hiring commodity engineers. We do have to fight, and
we have to get nasty, and we have to crush our enemies. But we also have to
stop clawing _at each other_ over petty differences (e.g. tabs vs. spaces) and
focus on the battles that matter.

~~~
titanomachy
Interesting thesis. There's certainly a glut of minimally competent
developers, many of whom end up at companies for whom software is an
incidental concern and therefore lack sophisticated hiring practices.

But many of the top 5% are hired by software companies who depend on
innovation for survival and seem to recognize the distinction between the
CommodityJavaDeveloper and the PolyglotScientistEngineer (or whatever you want
to call the other end of the spectrum). Either these companies will resist the
pressure exerted by that ocean of lightly-trained 9-5 programmers or they will
lose their edge and fail. And aren't those companies where we want to work
anyway?

NOTE: I don't mean to disparage those who happen to work 9-5. Rather, I'm
suggesting that the best programmers don't cease to be such when they go home
at the end of the day.

------
kazinator
Techniques for implementing heterogeneous collections in Haskell:

[http://www.haskell.org/haskellwiki/Heterogenous_collections](http://www.haskell.org/haskellwiki/Heterogenous_collections)

Good grief!

Lisp:

    
    
       '(123 a "bc" #(d))
    

Python:

    
    
       [1, "abc", 4.0]

~~~
jlouis
There is no easy way around this if you really want a collection which is
heterogenous, but often, you would just cook up a struct/record-like object
for these things.

Trading off easy heterogenous lists buys you a better type checker, more
static knowledge, faster programs and so on. It also has the advantage that
mapping data into the system can be done safely. The price is that self-
describing data (JSON, Transit, Msgpack, ...) is more unwieldy to work with -
but a little combinator library, scrap-your-boilerplate-generics, or a
reflective code generator goes a long way to solve that problem:

\- OCaml: Yojson.Basic.Util \- Haskell: Generics, Rank2 polymorphism \- Go:
JSON unmarshalling

are all examples of how to handle that problem.

~~~
kazinator
You seem to be implying that the generic lists shown in Python or Lisp are
somehow unsafe. They must be since if we throw them away, or wrap them in some
clumsy structs/records, we can "buy" safety. Even if that is the case, we
cannot sell Haskell as some kind of semantically rich language for doing
cutting edge research, when coding up basic things like this is a struggle. If
I have to cook up things with structures, I might as well use C.

Here is another simple problem: divide two integers so that the result has
integer type when the numbers divide evenly, otherwise rational type.

~~~
edwardkmett
On the other hand, here's a problem.

Extend your numeric type tower to handle whatever new numeric types I come up
with in an internally consistent manner.

In haskell I have number types for things that automatically compute
derivatives. I have number types for functions that go to number types so all
vector spaces work like numbers as well. I have number types for arbitrary
precision floating point numbers, and I can build these things on top of each
other.

It is a trade-off. We give up a bit of one thing to get something else.

You can take either side of the deal. I'd argue that the weight of benefit is
on the side where we don't have a magic type tower to reason about, but it is
a perfectly reasonable stance to say that the thing you want is more important
to you.

On the other hand, I can turn around and argue that if what I really want is
an ad hoc tower of numeric types I can just make a type for that and work
inside it.

data Number = Int Int | Rational Rational | Double Double | Complex (Complex
Double) | ...

instance Num Number

Now I can opt into your model. Can you opt into mine?

~~~
GregBuchholz
>Can you opt into mine?

In Python, not only can you "opt in" to those features (in a completely
natural way) but those features already exist in the form of highly popular
libraries:

NumPy - [http://www.numpy.org/](http://www.numpy.org/)

SymPy -
[http://www.sympygamma.com/input/?i=diff%28x**2%29](http://www.sympygamma.com/input/?i=diff%28x**2%29)

mpmath - [http://mpmath.org/](http://mpmath.org/)

...and the story is similar with Common Lisp, whose generic functions dispatch
on function parameter type (just like Haskell allows with type classes),
allowing you to create libraries for vector arithmetic, symbolic algebra, and
arbitrary precision floating point math, again in a completely natural style.

The best forms of language advocacy probably involve showing the great things
you've done with a language and forgetting about comparisons to the
competition. Build it, and they will come.

~~~
dllthomas
_" The best forms of language advocacy probably involve showing the great
things you've done with a language and forgetting about comparisons to the
competition."_

Great things the parent has done with the language:

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

