
"Study Functional Programming or Be Ignorant" - fogus
http://benhutchison.wordpress.com/2009/06/02/study-functional-programming-or-be-ignorant/
======
miguelpais
Is he also calling ignorant to the OO Scheme or Lisp programmers?

The best approach appears to me to be taking the best of both worlds.
Functional may solve lots of problems, but you can't deny the advantages of a
good OO design. Just devise your OO architecture for good reusability,
flexibility, low coupling and high cohesion and then just use the best that
functional programming has to offer.

~~~
jackfoxy
If Microsoft could pull it off, the ability to write both C# and F# inline in
the same class, or at least the same file, would really be the best of both
worlds. I'm not a languages guy, so I don't know if this idea is practical,
but like everything else, it probably is "possible".

~~~
RodgerTheGreat
Wouldn't that be a lot like C#'s LINQ? The ability to drop complex, lazily-
evaluated functional expressions into procedural C# is the closest example
I've seen to blending the two methodologies. (Perhaps 'ideologies' would be a
more accurate term?)

------
eplanit
"I still struggle to read most Haskell, and I certainly can’t use it to build
anything"....but it's great; and, if you don't know all this cool esoteric
stuff, you're ignorant.

Have heard/read similar posts from fans of other fringe languages: Lisp,
Scheme, Prolog, ... There are grand claims of superiority, but with little
practical evidence to bear out the claims.

I agree with other comments here -- the art of software design and programming
is _generally_ independent of language. Languages, bad ones, inhibit good
software engineering, and good ones enable if not encourage them (which is why
good ones are typically minimal).

------
bsaunder
Well, the title's a bit of a tautology, but it does seem that a bit of the
glow has worn off of Java (to those that were captivated by it in the first
place anyway). Functional programming seems to be trending upwards too.

I agree with the general assertion that hard core OO developers (Java and .Net
folks) will need to start learning some new mental models of programming to
keep adding relevance. I think we will start solving some harder problems that
are intractable with traditional OO mechanisms.

~~~
jefffoster
Can you give some examples of the "harder problems that are intractable with
traditional OO mechanisms"?

~~~
bsaunder
Yes, perhaps "are intractable" was too strong of an assertion.

I think as we migrate our data towards more flexible structures and look more
towards asynchronous parallel processing, we may find that splitting out data
and behavior serves us better than tightly binding them as OO methodology
does.

I think ultimately we will treat our code and data as the same thing, just
from different perspectives and levels of abstraction. I'm not sure most OO
programming environments today support this notion easily.

I do think we will be solving harder problems, but what exactly they are falls
into my unknown unknowns category.

------
pietrofmaggi
Knowing functional programming surely makes you a better programmer, as
knowing lisp do (even if you could never use in your projects).

But when I see post like this I always think to Fred Brooks' "There's no
silver bullet" paper (<http://en.wikipedia.org/wiki/No_Silver_Bullet>).

~~~
hello_moto
Knowing something new will make you a better person.

If an OO programmer never knew functional programming, yeah, sure, he'll be a
better programmer after learning LISP and I think the vice-versa is also true,
a functional programmer who never bother learning OO because he thinks his
paradigm is the silver bullet will benefit more knowledge if he decided to
learn OO.

------
hello_moto
Programming Language is like Software Development Methodology: it works well
in certain area but doesn't fit well in generalization.

There are evangelists and purists in both world.

Here's a challenge for all evangelists and purists: you keep telling people
that your thing is the right way to go, but when I ask you to learn my thing,
you refuse like a mad man.

IT is a very funny industry, people keep telling you that we change the world,
we have the power, we have the edge, we're the future or whatever. But at the
end of the day, don't tell us to change ourselves.

~~~
paulgb
Maybe I don't get out enough, but I've never met a Haskell programmer with
that mentality (LISPers, maybe). All the Haskellers I know are pragmatic
people who will use another language (usually Python, I guess because
iterators feel a lot like lazy lists) when it's the right tool for the job.

------
samstokes
The most important parts of this article, IMHO:

 _The bit that stirs me up is that this “stuff” isn’t, repeat is not, Haskell-
specific. Its rooted in the fabric of our reality, in our mathematics and our
problem domains, and bits poke up like the tips of icebergs into mainstream OO
languages, their true structure part-revealed. But rarely in the OO-world have
I found such carefully abstracted and subtle techniques of programming in
daily use.

Ideas from Haskell & Functional Programming will continue to flow into the
mainstream over the next couple of decades._

This is why it's important to read about things like immutable data structures
and higher-kinded polymorphism, even if your problem domain (or personal /
corporate style) is utterly unsuited to existing functional programming
languages. This stuff isn't just obscure tricks for maths nerds to obsess
over, it's fundamental to _how programming works_.

If you want to understand LINQ, you need to understand higher-kinded
polymorphism and monads. If you're writing a series of chained callbacks in
Javascript and feel like there's some repetition you'd like to extract but
can't quite put your finger on, you need to understand the continuation monad
(I'm only about halfway there...) If you want to reason sensibly about
concurrent updates to complex data structures, it helps a lot to know about
immutable structure-sharing data structures.

------
afhof
Its a pretty bold statement to say that programmers who don't use your
favorite language or style are ignorant of how a computer works.

~~~
Dunearhp
You can be a good bricklayer without knowing much about structural
engineering. What happens when you want to build something taller than ten
stories?

What happens when you want to program for more than ten CPU cores?

~~~
joegaudet
I find the assertion that the ONLY way to program for multiple cores or
concurrency is to use functional programming annoying. It seems to be the
default fall back of functional evangelists, as if there were no other way in
the world to solve concurrency.

I recently took a course on concurrent programming, and the from what I
learned, some problems are easier to deal with in erlang or something similar.
But then again some aren't. And a lot of the time, they run an order of
magnitude slower (though as my prof would say, correctness is sometimes more
valuable than speed).

And granted my Erlang program for matrix multiplication was very concise. My
MPI implementation ran WAY faster.

It seems to me, there are two schools of thought, and you can live in one, the
other, or both. Certainly there are things to be learned in either.

I think all one can take away from articles like this is that it's good to
keep learning.

~~~
chc
You seem to be confusing "Erlang" with "functional programming." They are not
equivalent. Erlang is not what makes functional style good for concurrency —
it takes advantage of some of the factors, but it is not the be-all-end-all.
Erlang's actor-based green-threaded messaging is only one concurrency style.

~~~
joegaudet
I was using Erlang as an example as I am familiar with it. My point was more
so that there are (as you say) many styles of concurrency, and that I hate it
when functional programers use "Try programming concurrently in an imperative
language" as their fall back argument for the merits of FP.

~~~
Dunearhp
It is one of the few arguments that doesn't first require the other person to
have a deep understanding of functional programming.

Try to convince someone of the value of immutability without mentioning
concurrency.

Imperative and functional programming relate in the same way that arithmetic
and algebra relate. It is hard to do deep reasoning in maths without algebra
and it is impossible to evaluate the value of most algebraic expressions
without arithmetic.

There is a reason that functional programming is at the forefront of
concurrency research. In the long run, imperative only approaches will be
unable to compete, and functional only approaches will remain on paper.

------
Aaronontheweb
If I said on this thread "oh yeah, I'm a pro at functional programming -I use
LINQ alllllll the time" how many heads would explode?

