I believe functional programming is interesting, and fun. But it is not going to replace the world. My background has spanned from working on AAA games, to simulations for the DoE, to owning my own business developing embedded products, and graduate school (yes, I went back as a gray haired, and did that late). I fell in love with Lisp many years ago on a TI Explorer.
Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun).
There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding of the domain of problems that functional languages will benefit from, and the larger domain of problems that will not benefit from them.
As an employer, I don't hire people for their functional programming skills. If they have them, the better, but we have over 3 millions lines of code in C++, and close to a million in Java. We are not starting over, and new projects will leverage existing code.
> There are many types of applications where functional languages are perfect, but there are more that it would be a disaster.
Can you give an example or two of an application in a functional language would be a disaster?
> To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding
No, it's an opposing viewpoint to the popular "right tool for the job" and "take the best from functional, best from imperative, and smash them together".
See "The curse of the excluded middle by Erik Meijer".
> As an employer, I don't hire people for their functional programming skills.
I certainly choose my jobs with language and ecosystem in mind.
frag-1.1.2 failed during the building phase. The exception was:
ExitFailure 1
Go fix that for us.
``Can you give an example or two of an application in a functional language would be a disaster?``
Sure, code that tests its self. Not happening. Which means, most embedded applications where fault tolerance is a must. If you don't know what caused the error, well, lets here your ignorant response. Explain how you trap those problems in a functional language, and do it as simple as you can, say in C, or Pascal.
``opposing viewpoint to the popular "right tool for the job"``
So you advocate a hammer for screw. Got it. You're exactly the kinda of person I won't hire. You're so bent on proving you're right, you ignore the right tool for the right job.
>Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun).
Don't know about Haskell but it would be very fun to do it in Lisp.
Common lisp has a "pretty OK" story for calling C code whenever some speed is needed [0,1]. In my opinion, they suffer from some of the documentation/quick start problems that common lisp has, but they're otherwise usable.
Some of Naughty Dog's late 90's/early 2000's games (Jak and Daxter, Jak II) were written in a lisp called GOAL, Game Oriented Assembly Lisp [2]
Functional languages are inherently difficult to develop applications that require state to change in non-deterministic ways. In fact, I challenge you to develop a first-person shooter in Haskell (Have fun).
There are many types of applications where functional languages are perfect, but there are more that it would be a disaster. To make broad sweeping claims, such as this article, just encourages unnecessary discourse, and shows the ignorance of the author, and his limited understanding of the domain of problems that functional languages will benefit from, and the larger domain of problems that will not benefit from them.
As an employer, I don't hire people for their functional programming skills. If they have them, the better, but we have over 3 millions lines of code in C++, and close to a million in Java. We are not starting over, and new projects will leverage existing code.