Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: