One thing I noticed when I was in college was that the basics of FP is not hard, in fact it seems way easier (from my data annecdote).
In my university CS course, we start with FP (using Haskell), and in a course with one of the biggest number of dropouts un the first year, FP wasn’t really a reason for it, in fact, from the ten 1st year classes FP was in the top half in success.
BUT what I actually took from that experience was that the students having more trouble with FP (excluding dropouts that failed everything) were actually people that had programing experience before college. For the rest of the world pure functions are easy and “x = x + 1” is confusing as hell.
To note that even though we used haskell, monads were just a light touch at the end mostly to use IO. Haskell has an intrepeter, so you could have a language that mimics how you wrote functions before. It also helped that we learned recursion paralel with induction on a math class, so we where recursing over a Natural Int type on FP while difining naturals through induction on a math intro class (and proofs over inductive definitions are usually do e with recursion).
FP suffers from
* unfamiliarity from the general programing community
* bad tooling due to smaller community
* people very vocal about a language like haskell which has research and teaching before production in its goals
* no decent bridge from the academia ivory to industry.
Some languages like elm most issues but suffer from smaller community and weird dictator.
Erlang was industry first but had a very small community (thus tooling), until elixir came aling decades later. And its focus get “solved” at a different layer/abstraction level by k8s.
Ocaml has shit tooling
F# is Microsoft ocaml, but suffers from most things you want to use with it are tailored for C#.
Lisp derivatives seem to live in a world of their own. Closure seems popular, and i guess emacs will never be irrelevant. And in lisps you have to learn all the vocabulary as each project is almost its own language.
So we need an FP language doing what GoLang did to C++.
Few features, very good tooling and libraries (as in golang has a formatter, builder, dependency manager, etc all on its “compiler”, and strong std lib), easy to read. Basically focusing on Developer productivity from hour 1. An “ML for the masses”, just like go was intended for devs straight out of college to be productive on day one.
True story: when I started programming at age 11, in the book I saw a pair of assignments like:
x = x + y
y = y + 1
(or whatever). I was thinking, what, that has no solutions!
It's just due to notations; abusing the sacrosanct equal sign for something different. People otherwise have no problem with the idea of a datum being updated in place; it's part of everyday experience.
You got me thinking and I think part of what it comes down to for typed FP languages is that you can either generally
1) Go for a simple design, but having poor interop with existing ecosystems because the language lacks equivalent features. I see Elm in this camp, and it's hard to live in because the FP community has fewer people than other communities to build up another ecosystem
2) Go for a more fully featured design, integrating with some ecosystem (like F#, Scala), but you end up with multiple overlapping concepts and inconsistency in the native language's ecosystem
It seems like dynamic FP languages are the only ones to get away with a simple core and wide ecosystem by avoiding the need for features that are important for writing modular code in typed MLs. OCaml is probably closest to the sweet spot as a language+ecosystem, but the language tools are a bit weak coming from other platforms
> So we need an FP language doing what GoLang did to C++.
What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one.
This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.
We have a few of those, they just aren't popular. Ocaml and F# both fit, as well as ocamlish langs like rescript, which is really underrated imo.
There's also racket, which I think people give too much credit to as a teaching language, but is genuinely good and lets you easily separate FP from immutability semantics which tend to get conflated in this conversation. Janet, same, but with a different approach to that. Clojure, which is very practical and enforces the kind of constraints that make you think in a functional way.
If I was teaching programming from scratch to a beginner without a specific end goal I'd likely use one of these. I have taught total beginners and have observed a moderately functional style is intuitive to them. Rarely see a totally new programmer bust out the for loop once you show them map, etc.
Unfortunately when I've taught programming before it was with the specific goal of web development so JS was the only real choice.
> What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one.
yes, anything focusing on devs being actually productive has to be pragmatic. So, yeah, real world exists, IO needs to be "easy/simple", just like compiling should be fast, good error messages, etc. Lots of constraints, Go is nice because it is "good enough" at everything. So it's productive general programming language.
> This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.
Disagree here. Fully agree those and pretty much all popular languages are better than haskell for the very mast majority of devs including beginner on actually delivering something aka work.
I disagree that haskell is worse for somebody that never actually programmed to learn programming (which is fundamentally different than creating an working application or modifying one), specially at a CS college/university course, than any of the languages you listed.
"basic" Haskell is extremely simple. And it's syntax mirrors what you would typically use when are doing something with functions during your high school. Recursion is not harder than loops, the hard part is going from lots of familiarity with one to the other. I've seen people learning imperative first and functional first at different places, and I can tell you that the confusion first timers face getting to understand a loop is not smaller than recursion(again "x = x +1" hits hard against everything you see in school until programming, re-assigning is evil for teaching).
With recursion, haskell's enums/unions equivalent, and haskell's interface equivalent, you can get really far!
So you won't hit haskell issues while teaching because:
* problems/assignments can be self contained, you don't need to reach for libraries to make simple compiler for example, so you don't have the ivory tower of type category, all conversations about monads, someone else code using unfamiliar lingo/code
* due to good interpreter, IO can be teached last, and can always be and should be only a layer over the rest of the code, and once familiar with the rest, writing some outer functions using do notation to pass to your core isn't troublesome to understand.
F# and Ocaml are not as nice for that purpose, as polymorphism/generics is better teached with haskell, and the language is more consistent without objects.
Racket and some lisps are nice, but i would say that Type checking is important for teaching, due to the whole concept of change data from one thing to another, gets easier to explain, the compiler gives some help as well.
Teaching 1st timers (assuming college) with Haskell Drawbacks IMO are only:
* reaching for out of the class stuff, online discussions and public haskell libraries are hell due to academic mismatch.
with too much
* while type checking and compiler messages are a nice help teaching, they can also have the opposite effect with cryptic messages if for some reason there was some heavy polymorphic/generic code.
For a more general teaching, I'll add the drawback of not being able to do what the general crowd thinks of a "app" or "web app" etc, easily. JS just working on a browser is great, swift playgrounds are great, ruby has rails, etc.
In general it's a mess. Very big language, so C++ issues.
Different communities liking different subsets.
Plenty of people "having to" use it, causing annoyance/hate.
It's not great for teaching due to not only being big, but tooling for first time usage is also not great, and it doesn't hit the nice things about FP for first time programers:
* functional syntax very similar to the way you defined functions in high school math class, or intros in college.
```
f : Z -> Z
f(x) = x + 1
```
is
```
f :: Int -> Int
f x = x + 1
```
in haskell (you can also omit domains/types/sets/signature in both). Familiarity is very important, which is why most programers do not like functional, and most people that haven't learned to program yet can start with it arguably more easily
just not having statements, and everything being immutable is really nice (x=x+1 is cancer).
Scala then has a whole lot of "class" stuff on top.
In my university CS course, we start with FP (using Haskell), and in a course with one of the biggest number of dropouts un the first year, FP wasn’t really a reason for it, in fact, from the ten 1st year classes FP was in the top half in success.
BUT what I actually took from that experience was that the students having more trouble with FP (excluding dropouts that failed everything) were actually people that had programing experience before college. For the rest of the world pure functions are easy and “x = x + 1” is confusing as hell.
To note that even though we used haskell, monads were just a light touch at the end mostly to use IO. Haskell has an intrepeter, so you could have a language that mimics how you wrote functions before. It also helped that we learned recursion paralel with induction on a math class, so we where recursing over a Natural Int type on FP while difining naturals through induction on a math intro class (and proofs over inductive definitions are usually do e with recursion).
FP suffers from * unfamiliarity from the general programing community * bad tooling due to smaller community * people very vocal about a language like haskell which has research and teaching before production in its goals * no decent bridge from the academia ivory to industry.
Some languages like elm most issues but suffer from smaller community and weird dictator. Erlang was industry first but had a very small community (thus tooling), until elixir came aling decades later. And its focus get “solved” at a different layer/abstraction level by k8s. Ocaml has shit tooling F# is Microsoft ocaml, but suffers from most things you want to use with it are tailored for C#. Lisp derivatives seem to live in a world of their own. Closure seems popular, and i guess emacs will never be irrelevant. And in lisps you have to learn all the vocabulary as each project is almost its own language.
So we need an FP language doing what GoLang did to C++. Few features, very good tooling and libraries (as in golang has a formatter, builder, dependency manager, etc all on its “compiler”, and strong std lib), easy to read. Basically focusing on Developer productivity from hour 1. An “ML for the masses”, just like go was intended for devs straight out of college to be productive on day one.