Functional Programming Went Mainstream Years Ago | Hacker News Reader

Functional Programming Went Mainstream Years Ago

prog21.dadgum.com

21 pointsllimllib5 comments

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.

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.

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

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.

I'm still waiting on the type system.

Reply on news.ycombinator.com