
Why don't we use functional programming languages more? (2004) - AndrewDucker
http://tratt.net/laurie/tech_articles/articles/why_dont_we_use_functional_programming_languages_more
======
darklajid
I have to agree with the other guys here: The article doesn't seem to take
recent functional languages (and their rise in usage) into account.

To write as little BS as possible I mostly keep myself limited to F#, a
language I know:

\- You don't need to use formal proves to design your software, the "purity"
of your code is up to you

\- Stacktraces? Hell, yeah.

\- IO: Use what the .Net framework gives you - it's not that different from
other .Net languages and you can isolate these side effects nicely in a simple
method or go down the monad path..

In short: I disagree with the article, because I have made quite different
experiences in the past. The morale of the story: Don't be too general
(functional programming) if you have trouble with specific things (like
Haskell's academic background).

~~~
gaius
Check the date on the article.

~~~
borisk
F# was first released in 2002.

~~~
gaius
What?!? Try 2007!

~~~
borisk
"Started as Caml.NET, with a ﬁrst preview release of F# compiler in
2002/2003."

[http://www.inf.ed.ac.uk/teaching/courses/apl/2009-2010/slide...](http://www.inf.ed.ac.uk/teaching/courses/apl/2009-2010/slides/apl19.pdf)

------
pjscott
Because nobody has mentioned Erlang yet, I should point out that CouchDB,
Riak, and RabbitMQ are all written in it. They seem to be holding their own
when it comes to practicality.

Erlang is a functional programming language without so much as a single
iteration construct; if you want a loop, you have to use recursion. Variables
are immutable, and it communicates via asynchronous messages between
lightweight processes.

~~~
tsuraan
Just some clarifications so that newbies don't get scared away from erlang :)

 _Erlang is a functional programming language without so much as a single
iteration construct; if you want a loop, you have to use recursion._

To keep it from sounding too terrible, Erlang has all the standard
map/foreach/fold functions that every other functional language has; it's all
recursion at the bottom, but it's nicely encapsulated. Most data structures
follow the conventions of the iteration functions found in the lists module:
<http://erlang.org/doc/man/lists.html>

_Variables are immutable, and it communicates via asynchronous messages
between lightweight processes._

I don't know if couch, riak, or rabbit use them, but erlang does have the
process dictionary, which is a per-"thread" mutable datastore
(<http://www.erlang.org/course/advanced.html#dict>). I know that wings3d uses
the process dictionary a lot, supposedly for performance reasons. The use of
the process dictionary isn't recomended, but it is there when needed.

EDIT: corrected an instance of rabbit where I meant erlang

~~~
philwelch
Erlang also has convenient features like list comprehensions and partial
definitions of functions to make this stuff easier. And while the process
communication stuff is supposedly a distribution/concurrency system, you can
treat processes as objects and do message-passing style OOP with a little
cleverness.

------
twymer
I don't feel that this post is fair. You can't say "we can't do solve real
world tasks with functional programming because Haskell isn't practical."

I'm sure this isn't a fair analysis either, but I think it's an accepted
belief that pure functional languages don't fit with how the world works. That
doesn't mean that functional languages with side effects (multi-paradigm is
probably the correct term) like Lisp, given the recent rise of Clojure, or F#
can't be used in the real world.

~~~
sid0
> That doesn't mean that functional languages with side effects

Haskell has side-effects too, you know. The point of Haskell is not to
eliminate side-effects entirely, but to have a _static_ separation between
functions with side-effects and functions without _through the type system_.

------
rwmj
We solved a lot of real world (advertising) problems with OCaml at my last
company. Stack traces worked too ...

------
steveklabnik
Add on another "this seems overly simplistic" vote here. I've actually been
playing around with writing a Roguelike in Haskell over the last few weeks. My
code is super-noobish, but it's working fairly well.

Just because it's different doesn't mean that it can't be done.

------
kenjackson
There are some things that are easier to do efficiently with imperative
languages. And one can generally easily write functional code in a modern
imperative language (C# for example has many, if not most, of the tools
available in popular functional languages). But less easy to do imperative in
a functional language.

Multiparadigm languages are here now and feel like the future.

~~~
j_baker
"There are some things that are easier to do efficiently with imperative
languages. And one can generally easily write functional code in a modern
imperative language (C# for example has many, if not most, of the tools
available in popular functional languages)."

Really? When did they add pattern matching, algebraic data types, and reliable
tail call elimination?

Reality is that imperative languages provide about as much support for
functional programming as functional languages have for imperative
programming: just enough to get by. And I would even say this is a good thing
(perhaps excluding lisp: it can do everything due to sheer elegance rather
than due to bloat).

~~~
kenjackson
"Really? When did they add pattern matching, algebraic data types, and
reliable tail call elimination?"

I didn't say all features. In fact I said "has many, if not most". I was
trying to be explicit that not all features that exist in every functional
language exist.

Now with that said, the specific features you list, while popular, weren't
widely considered "necessary" features to be classified as a functional
language. For example, Scheme has neither pattern matching nor ADTs. Although
I'll grant you that for modern functional languages its near a prerequisite.
And AFAIK tail call elimination is less a function of the language, and more
of the implementation (and I'd argue to the extent that you write in a
functional style, many/most production quality compilers of imperative
languages will do this optimization). Of course I could be wrong and maybe
some functional languages define in their spec exactly when tail call
elimination must invoked.

If you look at what is commonly the crux of functional languages you'll see
things like:

* Recursion -- yes, there was a time imperative languages didn't support recursion. So when they were arguing Lisp vs Fortran this was relevant. Now this seems like such a passe feature of all languages, but I think its worth point out.

* First class functions.

* Lambdas and closures

* Immutable data

* Pure functions

* ADTs or other interesting type systems

And there are some second order features like list comprehensions.

Again, I think if you go through this list, you'll see that modern imperative
languages capture a lot of these features. Not necessarily all of them, but I
have discovered that I've been able to do some relatively straightforward
ports of functional algorithms, keeping all of the functionalism intact.

~~~
philwelch
_Of course I could be wrong and maybe some functional languages define in
their spec exactly when tail call elimination must invoked._

Scheme does. I believe it was widely considered an innovation in the field of
programming language specification that they specified that.

------
meterplech
I think this post doesn't recognize that you should match the problem you are
solving to the paradigm you are using. Functional programming is extremely
useful for many types of financial analysis, and other big data problems like
pattern matching and data verification. Sure- you might not want to write a
mvp for a lean webapp in Ocaml, but saying people don't use functional
programming anymore is just not true.

~~~
gaius
You could easily do that - check out Ocsigen.

------
evilthinker
Prelude> head [] __* Exception: Prelude.head: empty list

Damn I think might need to trace this one.

~~~
nickik
I thought that this was implemented.

I Clojure its like this: (first []) --> nil

What is in that list? Answer nothing.

I think thats a way to go too.

~~~
frio
I haven't used Clojure, so excuse me if there's something I'm missing here,
but doesn't that mean that the following is true?

    
    
        first [nil] == first []
    

In which case, I prefer the Haskell way, as it's more specific.

~~~
pufuwozu

        user=> (= (first [nil]) (first []))
        true

------
nickik
"I love such languages... Of course, I use Java for everything these days,
because it's much easier".

\--> MMhh, Java and easy. Yes that makes sence. The rest of the blogpost
speaks for it self too.

Did he write that when he waited for eclipse to start up?

------
InclinedPlane
Python, Javascript, Ruby, C#.

Functional programming languages, you're soaking in them.

