Functional programming languages try to reduce side effects to a minimum, this usually involves immutable data structures and pure functions and then dropping down to something like Monads when side effects are needed.
- No way of enforcing functional purity
- No way of creating immutable objects
- You can't statically type variables
- You can't even put things into namespaces
First Class Functions
- Static typing is nothing to do with functional programming. It's an independent feature axis. You can't say that namespaces are a feature of functional programming; they're just naming features (as is your point on Scheme's
!suffix). Moreover, a great many languages that are functional actually support mutable state; it cannot be a feature that allows a decision to be made on whether a language is functional. The only thing that you might possibly have a point about is “functional purity” but you're beginning to sound to me like you're making a No True Scotsman argument, which is a logical fallacy. What I can agree though is that community practice with JS is not to program in a functional manner. –Donal Fellows 01:17, 1 January 2011 (UTC)
- To me, the key marks of a functional programming language are that it allows functions (or references to them) as values, that it allows recursion, and that it doesn't require the use of side-effects to produce the results of a function. That is admittedly a loose definition that permits lots of languages to claim that they support it, but so what? There's also a class of strict functional programming languages that are far more restrictive (e.g., by being side-effect free) but they're much less useful; even Haskell doesn't make it to that level of purity (due to the IO Monad, a requirement for participating in an outside world that has state). –Donal Fellows 01:28, 1 January 2011 (UTC)
- Lots and lots of programming languages support first class functions. If you put basically every language into the functional category it is going to become a basically meaningless word. So rather then making the word functional meaningless I set a bit of a higher standard. Functional languages should have immutable data structures and some good way to avoid side effects.
- Well, ultimately the functional paradigm's been pretty successful, though the strict functional less so (precisely because so many problems are very coupled to their state). That's an indication of a reasonable degree of success for the paradigm. (We probably ought to take this part of the discussion somewhere more general.) For my money, the fact that authorities outside of RC say that JS is functional is sufficient evidence for me to admit its description as such here. –Donal Fellows 10:56, 1 January 2011 (UTC)
- However, it is like when you said "just naming features." Functional programming is the name of a paradigm. Attach whatever meaning to it you want.
- It just so happens that declarative programming is probably the most important part of effective FP. By telling the computer what to do rather then how to do it, you free up the compiler to optimize and parallelize at will. –Jhuni 01:42, 2 Janurary 2010 (UTC)
- Unless a paradigm is fundamentally impossible in a programming language (perhaps it's made so by some feature of the VM), a programmer can employ that paradigm, regardless of how convoluted or tricky it might be. What all this tells me is that templates and language-page modifications are the wrong way on Rosetta Code to associate langauges with paradigms, and that a "show me the code" approach is really what's necessary. To that end, tasks would be needed in order to provoke demonstrations of aspects of a given paradigm. --Michael Mol 02:12, 2 January 2011 (UTC)