
Why No One Uses Functional Languages (1998) [pdf] - tel
http://www.ugcs.caltech.edu/~lordkaos/why-no-one.pdf
======
hibikir
With most of those problems pretty much gone, functional programming is doing
quite a bit better than it did 15 years ago. Hybrids languages are gaining
popularity: You can find Scala in quite a few large companies out there.

Major adoption of non-hybrid languages doesn't seem like something that will
happen any time soon though, and it sure seems like the FP community actually
wants it that way. We just sent one of our people to attend Lambdajam, and in
his 5 minute version of what he learned, he was telling us how his impression
is that there were plenty of Haskell people there that seemed to barely
tolerate having any talk about Scala in the conference. Badmouthing of hybrid
languages is the order of the day by extremely prominent members of the FP
community, even if they end up using said languages in their presentations.

So I suspect that the future of FP is to be influential, for most of the best
bits to be copied by language makers that build communities that care about
marketing, and Haskell and the like will remain used only by people that just
think there's no way to write any useful program without first learning all
about category theory.

~~~
michaelochurch
_Badmouthing of hybrid languages is the order of the day by extremely
prominent members of the FP community, even if they end up using said
languages in their presentations._

Those hybrid languages (e.g. Python, F#, and Scala) are great for new
development but awful when you have to maintain low-quality legacy code. That
said... I think that observation applies far beyond functional programming.
(It's rare, but certainly possible, for bad Haskell code to exist.) A common
impetus behind language churn is the programmer's desire to justify green-
field development (which is fun, even in C++) instead of career-damning legacy
maintenance (which is unpleasant, even in good languages).

 _Haskell and the like will remain used only by people that just think there
's no way to write any useful program without first learning all about
category theory._

This is an exaggeration of that prejudice. I do think that the Haskell
community has failed (but is it a failure or a deliberate choice not-to?) to
package a not-that-hard language as something average programmers can
understand. Functor, monoid, and monad sound a lot scarier than they actually
are.

~~~
rtpg
pedantic, but I really wouldn't call Python a hybrid language on the same
level as F# and Scala. Python's functional programming capabilities are pretty
poor (not to mention that things like TCO are missing).

Not to say that Python is a bad language, but having continuously tried to
program in a functional style I've found that more iterative-seeming code ends
up being more idiomatic and maintainable.

> do think that the Haskell community has failed (but is it a failure or a
> deliberate choice not-to?) to package a not-that-hard language as something
> average programmers can understand.

That is extremely true. Even in widely-used packages, you'll rarely find good
official documentation (quickstarts or the like).

Sure, for a lot of packages , types are good enough (if you have a package to
read a CSV file, all you need to do is find the CSVConf -> Handle ->
[[String]] function), but with the bigger, more framework-y packages, there
are so many types internal to the system that you _have_ to read through
everything to do even simple things.

Too much time is spent trying to explain how the language (which ends up being
simple) works and not enough time on practical guides on how to actually do
things.

This has become a bit of a rant, but in Math (the kind most people go through
in middle school), you always learn specific cases before going into general
theory. Unfortunately, a lot of Haskellers end up being mathematicians of the
PhD style, where they're fine with just going into general theory. Examples
are useful!

------
galaxyLogic
I think the Haskell, OCaml, F# people are promoting their language of choice
the wrong way. The way to do it would be to show concrete examples of problems
which are difficult to solve in say Java, and then show how that is a non-
problem in Haskell etc.

Of course if you know your language very well, it is much easier for YOU to be
working with it. Just saying it has this or that feature is great, but does
not really tell us why it would be costly to do similar things in other
languages.

What does FP really mean? The term is used frequently as a synonym for
Haskell. Does it mean "type-inference"? But is that really a 'functional'
feature? Does it mean 'immutability'? In Java you can declare your data to be
immutable. Does it mean 'closures? Or being able to pass a function as an
argument or result. You can do those in JavaScript.

~~~
tel
"Functional" is really poorly defined. Instead, here are some reasons to feel
ML/Haskell are valuable

ML and Haskell: ubiquitous use of higher order functions through standard
library; concise syntax for lambdas; bi-directional type inference with
principle typing; named algebraic data types including sums, products,
exponentials, recursion, universal, and existential quantification; ubiquitous
purity, generalization at higher-kinded types, ubiquitous immutability; effect
typing.

ML alone: true modules; module functors; structural equality in typing
(polymorphic variants); great metaprogramming (camlp4)

Haskell alone: bounded polymorphism (typeclasses), completely ubiquitous
purity/completely ubiquitous effect typing; completely ubiquitous
immutability; lazy evaluation; a standard library including many high-level
higher-kinded type generalizations (functor, monad, applicative, traversable,
foldable, category, arrow, anything else you can think up); ok metaprogramming
(template haskell); programmer controlled rewrite rules, results in list
fusion/vector fusion

I list more under Haskell partly because I'm just more familiar with it, but
also because it takes more things further and thus derives greater
differentiation for it.

~~~
tieTYT
You're preaching to the choir. Your typical Java programmer doesn't even know
what these phrases mean.

~~~
tel
Sure, and it's a little sad that there isn't any good resource to explain
them... But I also am not going to try to do it in the space of a comment.

------
duncanawoods
Here is my take as someone who could but chooses not to use fp. When I look at
“good haskell” I see it dominated with comments written in procedural english
describing what the code does e.g.

[http://hackage.haskell.org/package/pretty-1.1.1.1/docs/src/T...](http://hackage.haskell.org/package/pretty-1.1.1.1/docs/src/Text-
PrettyPrint-HughesPJ.html)

Haskell requires this because, lets be frank, its really hard to understand. I
can hear the howls of anger but if you ask “man in the street”, will he do a
better job explaining the above haskell sans comments or a similar pretty
printer written in VB? I have CS background, studied FP and type theory, but I
am more like the man in the street.

What I want from a programming language is an executable description of what I
want to achieve. I want that description to have all the good qualities sought
in fp but more importantly I want it to flow into and out of my brain (and my
colleague’s brains) like butter not like a sudoku puzzle trapped in a type
theory proof and then Huffman encoded (because descriptive names are the
preserve of all those "terrible java programmers").

In the real world, I need to write code that makes fast incremental changes to
large interconnected data-structures e.g. graphs and trees with indexes and
all sorts. I cannot begin to imagine how to solve half my problems with
immutable data-structures. With what I know at the moment, it would be a
massive obstacle to the real problems I need to solve.

~~~
galaxyLogic
Yes, readability. It's only half the story if you can be more productive when
writing programs. Readability is probably more important because SW needs
maintenance. And readability is not only about how fast YOU can read and
understand Haskel. It's more about how fast other programmers can. Imagine all
scientific papers were written in Latin.

I think you make a valid point. Many comparisons of Programming Languages
productivity only try to measure how fast you can code a new application in
them, but not how fast you can modify an existing application to do something
else - ASSUMING you are not the author of the original version.

------
tieTYT
> Advocates of functional languages claim they produce an order of magnitude
> improvement in productivity. Experiments don't always verify that figure --
> sometimes they show an improvement of only a factor of four.

It's weird, the first time I read this I was excited to read the source of
this quote. When I finished reading I scrolled up to the top and was
disappointed to see a citation missing. Does anyone know what experiment he's
referring to?

~~~
Avshalom
I think probably
[http://haskell.cs.yale.edu/?post_type=publication&p=366](http://haskell.cs.yale.edu/?post_type=publication&p=366)

------
jaytaylor
It's interesting to see how 15+ years later, general attitudes among the
masses haven't changed much in this regard (according to the most popularly
used languages [0][1]).

Feels bad, man.

[0] [http://beust.com/weblog/2014/05/03/language-popularity-on-
gi...](http://beust.com/weblog/2014/05/03/language-popularity-on-github/)

[1]
[https://www.google.com/search?q=language+popularity](https://www.google.com/search?q=language+popularity)

~~~
clusterfoo
Would you say that the functional paradigm has started to gain more traction
lately though? -- I don't know because I haven't been programming long enough,
so maybe it just seems that way to me simply because now that I'm aware of its
existence I'm seeing it everywhere.

I read a quote once about The Velvet Underground that stuck with me. It said
that, while not many people bought their albums, everyone who did started a
band.

Sometimes it seems like Haskell is The Velvet Underground of programming
languages. While not many people are using it, everyone who is has started
their own language/functional library -- Influencing other languages is, in a
way, people using FP languages, just indirectly.

I've not written a single serious Haskell program -- I don't think I would
even know how to, tbh --, but I sure feel like just playing with it and
learning about its theoretical motivations has made me a much better
programmer in other languages.

~~~
mhogomchungu
>Would you say that the functional paradigm has started to gain more traction
lately though?

That is certainly true but I think more people will not shift to functional
programming languages to do functional programming style programming but will
stick with their favorite imperative language and do functional programming
there as more and more imperative languages add features and facilities that
allow functional programming style programming.

Case in point, i have this Qt/C++[1] library that evaluates lambdas in a lazy
fashion.

You can have,for example, a function that returns what is called "a future",ie
something that can be evaluated at a later time to produce a value "held" in
the future or the future can be cancelled if the function caller decides they
no longer need the result.

Introductions of lambdas in C++11 allows for this kind of programming to
happen in C++ and i suspect more and more C++ programmers will start coding to
this style as more and more APIs will start getting released that will take
lambdas as arguments or return them as results.

It is an interesting new way of doing C++ and these ideas are mostly borrowed
from functional programming world.

[1]
[https://github.com/mhogomchungu/tasks](https://github.com/mhogomchungu/tasks)

------
jkscm
Switching to FP is a bit like switching to Dvorak: the cost of switching are
still to high to justify the effort.

~~~
nbevans
The effort isn't very high at all? What are you talking about?

~~~
squidsoup
The effort required is dependant on a bunch of things - your existing
familiarity with FP concepts from using 'multi-paradigm' languages, the
language you're considering switching to (clojure is probably easier to learn
than haskell), your familiarity with tools commonly used in that language's
ecosystem (emacs, repls) etc.

------
RollAHardSix
It's not just popularity. I wouldn't trust anyone on my team (of 4) to 'get' a
Functional Language. Maybe one out of four (Not counting myself in this
scenario), and almost no-one that they would hire later on. That leads to a
pretty low chance of it ever being adopted where I work.

~~~
MichaelGG
What kind of work are you doing, and what kind of people are you hiring? I'd
be very nervous of working with someone that wasn't actually capable of
"getting" FP.

~~~
squidsoup
I suppose that depends on your definition of FP. If you're just talking about
HOF or 'programming with functions' fair enough, but some individuals
(erroneously imo) only consider languages with higher kinded types
'functional'. The term is really overloaded.

~~~
pjmlp
Which puts all Lisp inspired languages out of FP.

------
wyager
I think the "they don't get it" thing is actually quite a valid reason. I've
heard some really ignorant things said in opposition to functional
programming. I don't think it applies to the majority of potential users, but
certainly a non-negligible percentage.

Examples: "Immutability is stupid, because if your program is immutable it
can't do anything."

"You just end up writing everything in an IO Monad anyway."

"Functions are good for math, but not for coding."

~~~
swift
I agree that this is the case for a lot of people. It's not a judgement of
their abilities or anything like that; it's just that, as a practical matter,
to really understand some things you have to commit and actually solve some
real problems with them. The payoff isn't very apparent when you're starting
out, but for me at least the insights I've gained from functional programming
have been huge.

FP isn't the only thing in this category - like many people on HN I learned
OOP a long time ago, but I remember it being similarly earth shattering, and I
went through a period of over-enthusiasm and evangelism for Java and GoF
design patterns just like the one I went through when I first learned Haskell.
The code-is-data realization that you have when you learn a Lisp is similarly
powerful.

I hope I experience more revelations like these! These moments where you learn
a whole new way of thinking are the purest joy programming has given me.

------
ExpiredLink
> _For a given task, the imperative solution may leap immediately to mind or
> be found in a handy textbook, while a comparable functional solution may
> require considerable effort to find_

FP means additional levels of indirection which makes it less efficient than
imperative approaches. If FP really were more productive than imperative
languages it would have been adopted by the industry long ago.

------
michaelochurch
_Plus le change, plus le meme chose._

Functional programming has a couple of problems, when it comes to uptake. The
first is that you only get 40% of the benefit if you go 90% of the way.
(Static typing is the same way, which is why I prefer Clojure's typelessness
over the mediocre static typing of Java or C++ or Go.) In that case, the
"impure" 10% still causes, if not realized complexity, the _potential for_
complexity that infuriates maintainers.

If you go 90% of the way on FP and get 40% of the benefits, that still means
you're writing code faster and generally producing less of it, and those are
good things. However, there's a nasty duality in programming which is that
saving time on the fun stuff means more time is spent on the un-fun stuff. (If
you make writing of code 4 times faster and debugging of nasty interface
issues 2 times faster, you spend a larger proportion of your time on the
latter.) Unless you can eliminate whole classes of un-fun-ness (e.g.
categories of bugs) it's often not worth it. Eliminating 90% of the un-fun-
ness just means you're spending more time on that remaining 10%.

For example, Python can be used as a mostly functional language and thereby go
90% of the way (conceptually) to FP, but it isn't. The community has judged it
to be not worth it. Scala _should_ be used for FP, but there are plenty of
Java++ programmers who still use _null_ instead of Option[T]. Sadly, it
doesn't take much of this dysfunctional programming to emasculate FP and leave
an unbiased person asking, "Why bother?" It might not even be the right way to
go, for a maintenance project. Mixing two styles is going to make it more
illegible than using the existing (if suboptimal) style for new changes and
work.

The career issues noted are also huge. The average Clojure or Haskell
developer makes slightly than the average Java developer, but if you control
for skill and compare at-level, the Java or C++ developer wins. A 1.8 Java
developer (scale here:
[http://michaelochurch.wordpress.com/2013/04/22/gervais-
macle...](http://michaelochurch.wordpress.com/2013/04/22/gervais-
macleod-23-the-shodan-programmer/)) makes $175,000 and turns down invitations
into VP-level positions at major corporations on a regular basis, because 1.6+
Java developers are just so rare. A 1.8 C++ developer can make $500,000 per
year at a hedge fund. The 1.8 Haskell or Clojure developer makes about
$125,000 on average, which is not bad but hardly stratospheric. This tends
toward a self-perpetuating exaggeration of historical discrepancies in
language popularity. Even if the average Haskell job is better, Haskell jobs
(at all) are much harder to get, and Haskell jobs that pay as well as even an
upper-middle Java job are extremely rare. The market is just stronger for Java
people, so that keeps people wanting to use it, which keeps the majority of
companies preferring it over better languages because they fear maintenance
risk more than low productivity.

I'm less charitable than Wadler on the "they don't get it" angle. Certainly
there are smart people who "get" functional programming and have good reasons
not to use it. Still, I do think that a contributing factor to FP's lack of
uptake is the anti-intellectualism of the programming world.

It's not that anti-intellectuals have some natural inclination toward Java or
C++. The anti-intellectuals have the general attitude that _language doesn 't
matter_. And then they pick Java for some risk-averse, enterprisey shitfuck
reason like maintenance risk or lack of an available developer pool, both of
which are just business stinginess ("we don't want to train people"). What
makes them vile is not their tastes in languages (there is a lack of taste in
the Java community but, even still, there _are_ cases where Java is the
absolute right language to use) but the fact that they don't take programmers'
concerns (such as tooling choices) seriously at all, and prioritize manager-
type concerns over the needs of the people actually doing the fucking work.

~~~
yummyfajitas
_The anti-intellectuals have the general attitude that language doesn 't
matter._

This attitude should not be discounted. You'll find fewer proponents of strong
type systems than me.

I recently started working with a client who wanted to build a Haskell system
in order to do some complex financial modelling. I told them to forget Haskell
and build a Python/Django app that will handle 90% of their customers. The
only significant bug was comparing a backward discounted quantity to a forward
discounted quantity. Haskell wouldn't solve that.

The development effort saved due to _not rewriting built-in django apps_
vastly outweighed any productivity benefit we'd have gotten from using
Haskell.

~~~
collyw
A friend started a company a couple of years back. He was not a programmer,
but worked in a lab, so knew the bioinformaticians favored Python. He insisted
that the app was built in Python. I was thinking that the language didn't
really matter.

Anyway, a couple of years later he got a grant to continue with the project.
It was junior level wages. And he couldn't get a Python programmer to work for
that (he asked me) amongst others. PHP would have probably opened up more
options in that respect, even though it is considered a poorer choice of
language.

------
vajrabum
That's really old so I actually looked at it (again). Here are the criteria
that Wadler mentions that ho<eld back adoption.

Things that Haskell used to be weak on but now has good support for:

FFI - yes Libraries - Yes Portability - Yes Ease of installation - Yes
Packagability - Yes Tools - yes Training - available Performance - yes

(non)Reasons why it doesn't get adopted. Still apply.

Popularity - No still not popular They don’t get it - Yes they still don't get
it Killer App - none that I can see (darcs?)

~~~
dllthomas
_" Killer App - none that I can see (darcs?)"_

Maybe pandoc.

~~~
freyrs3
Historically I think Haskell will be very important as the substrate on which
a lot of the next generation of dependently-typed languages (Idris, Agda) are
bootstrapped on top of. It's a niche use admittedly, but it's hard to
understate how great Haskell is for writing modern functional compilers.

~~~
dllthomas
Certainly possible. There's some great stuff going on there.

