[Haskell-cafe] Investing in languages (Was: What is your favourite Haskell "aha" moment?)

[Joachim Durchholz]

Am 11.07.2018 um 16:36 schrieb Damian Nadales:
> 
> I speak only from my own narrow perspective. I'd say programming is 
> hard, but functional programming is harder.

Actually it's pretty much the opposite, I hear from teachers.

> Maybe that's why Java replaced Haskell in some universities
> curricula
The considerations are marketable skills.
A considerable fraction of students is looking at the curriculum and at 
job offers, and if they find that the lists don't match, they will go to 
another university.
Also, industry keeps lobbying for teaching skills that they can use. 
Industry can give money to universities so this gives them influence on 
the curriculum (and only if they get time to talk the topic over with 
the dean). This aspect can vary considerably between countries, 
depending on how much money the universities tend to acquire from industry.

> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason most 
> programmers I know are not scared of learning OO, but they fear 
> functional programming.

Programmers were *very* scared of OO in the nineties. It took roughly a 
decade or two (depending on where you put the starting point) to get 
comfortable with OO.

 >
   I think the reason might be that OO concepts
> like inheritance and passing messages between objects are a bit more 
> concrete and easier to grasp (when you present toy examples at least).

OO is about how to deal with having to pack everything into its own 
class (and how to arrange stuff into classes).
Functional is about how to deal with the inability to update. Here, the 
functional camp actually has the easier job, because you can just tell 
people to just write code that creates new data objects and get over 
with it. Performance concerns can be handwaved away by saying that the 
compiler is hyper-aggressive, and "you can look at the intermediate code 
if you suspect the compiler is the issue". (Functional is a bit similar 
to SQL here, but the SQL optimizers are much less competent than GHC at 
detecting optimization opportunities.)

> Then you have design patterns, which have intuitive names and give some 
> very general guidelines that one can try after reading them (and add 
> his/her own personal twist). I doubt people can read the Monad laws and 
> make any sense out of them at the first try.

That's true, but much of the misconceptions around monads from the first 
days have been cleared up.
But yes the monad laws are too hard to read. OTOH you won't be able to 
read the Tree code in the JDK without the explanations either.