
Functional Programming Went Mainstream Years Ago - llimllib
http://prog21.dadgum.com/31.html
======
iigs
_Fold and map are beautiful, but they work just as well in the guise of a
foreach loop._

It's hard to argue with the foundation of the article -- namely that for any
novel programming paradigm we've seen implementation of key features in a lot
of modern languages, but if this statement holds you could easily say "foreach
loops are beautiful, but they work just as well in the guise of an array and
an iterative loop in assembly." It's true they produce equivalent results, but
the nice thing about (perhaps the whole point of?) higher level languages is
that they provide the compiler/interpreter with more clues about the intent of
the code, and the compiler can do smarter things because of it.

With map, and i assume fold, you could (in theory) replace the uniprocessor
foreach style implementation with a multicore friendly version or even a
hadoop/google mapreduce style cluster-aware implementation. If the code was
initially in foreach style it would seemingly only be possible if the compiler
was smart enough to ensure that there was no access outside of the foreach
code block.

I suspect that the premise is right -- that the functional languages of today
are probably not going to ever win out over the popular languages of today --
but I think the popular languages of today are going to have to evolve a lot
to become the popular languages of the multi-core tomorrow, and a lot of that
evolution will come from these functional languages.

~~~
gaius
Exactly. And not only does map() imply that you can extract as much
parallelism as possible, it also means you can access the memory in the most
efficient way possible rather than implicitly sorting into the order of the
loop counter.

------
systems
I have some issues with the term Functional Programming, the term is supposed
to mean a set of programming languages features and how to program with them.

The set of features (first order functions, automatic memory managment,
elaborate data types) have been as the article suggest available in many
programming languages that are not advertised as functional programming
languages, such as Perl, Javascript and Groovy

The how-to part is well, to me, a lot less obvious, the most common thing you
hear, is you create code or functions with no side effect, why is this good,
is not always explained, again the obvious benefit will be is you get a
clearer API, but still this is highly subjective and debate-able.

In conclusion, I think the term functional programming is not representative
of a clear set of benefits, and that moving the discussion to more concrete
terms such as closures, first class functions, object primitives is better

~~~
rkts
I agree. As with "OOP," the term "functional programming" is too broad to be
the subject of a meaningful discussion about language design. It's better to
break the term down into its sub-concepts, which are often independent of each
other.

I question whether the notion of "programming paradigms" should exist. The
more powerful a language is, the less I seem to notice paradigms in my code. I
can't point to a piece of Lisp code and say, "this code is functional," or
"this code is imperative," or whatever. I just use the tools that are most
appropriate for what I'm trying to do.

Paradigms are like design patterns in this respect; they only seem to arise in
languages whose weaknesses force you to write code a certain way. I think
"multi-paradigm" languages like Lisp and OCaml would be better described as
"no paradigm," and this is how languages ought to be.

------
rtf
I'm still waiting on the type system.

