[jerf]

The error here is confusing the language for the paradigm. He all but concedes that functional programming is a good idea and you can do it in current languages. True. When you do that, you have a functional program. The "functionalness" or "objectness" or "logicness" of a program is a characteristic of a program, not the implementation language. When you do object-oriented C, it isn't a "hack", it really is object-oriented C. You just don't have language support, you're doing objects by hand, with the corresponding disadvantages (syntactic pain) and advantages (no privileged concept of objects means you can do your own thing, which can be useful; want 'prototypes'? just do it! arguably easier in C than C++). When you do functional Javascript, it really is functional programming, you just don't have the same language support. When you refuse to mutate values and treat a language's values as immutable, even though the language permits you to mutate them, you have immutable values; the essense of immutable values is that you can depend on them not being mutated, not that the language makes it syntactically impossible to express mutation. This has obvious advantages if you want to use an immutable style, but is not strictly necessary.

Proof: It all ends up running on assembler anyhow, which isn't functional or OO or logical or any other paradigm. All of those things are categories of programs, not intrinsic attributes of the environment.

The author isn't being anywhere near as contrary as I think he'd like....

[cageface]

The title of his article is that functional languages are overrated and he specifically points out that functional techniques are available in other languages, so I don't think you can say he's confusing the two concepts.

[CodeMage]

Yet he has a bias and it shows in his comments on Scala:

And if you're working in a hybrid language, what assurances do you have, really, that your system is really thread safe? Indeed, the risk compentation effect might give you a false sense of security, giving you a system that actually had more concurrency problems that one written in a "dangerous" language.

The phrase "hybrid language" in the original text is a hyperlink to Scala. By author's own admission, the languages he has tried were Erlang and Haskell. He hasn't mentioned either trying or not trying Scala, but the article seems to imply the latter.

The problem with what he said is that he seems to be dismissing "hybrid" languages like Scala as equally overrated or worse than pure functional languages like Haskell. Just like Jerf pointed out, it's the paradigm that matters more than the language. A language like Scala is designed to make FP paradigm easy to do, without being a pure functional language. As far as I know, it's not designed to make your programs "thread safe". I believe that the author wouldn't have made his claim about "risk compensation" if he had actually studied Scala and tried it out.

[cageface]

The problem with what he said is that he seems to be dismissing "hybrid" languages like Scala as equally overrated or worse than pure functional languages like Haskell

His point is that concurrency is something you still have to consider carefully and design in from the ground up and that no language is a silver bullet for this essentially hard problem. I think he's also probably right to worry that people will think that because they're using Scala and actors, for example, that they have automatically created a correct, performant concurrent application.

That doesn't mean though that languages like Scala don't give you better tools to deal with these issues than Java.

[loup-vaillant]

> Just like Jerf pointed out, it's the paradigm that matters more than the language.

Note however, that languages are extremely good at making us use their prefered paradigm.

[CodeMage]

Which is why we have hybrid languages to help us combine paradigms.