I have to agree with the other guys here: The article doesn't seem to take recent functional languages (and their rise in usage) into account.
To write as little BS as possible I mostly keep myself limited to F#, a language I know:
- You don't need to use formal proves to design your software, the "purity" of your code is up to you
- Stacktraces? Hell, yeah.
- IO: Use what the .Net framework gives you - it's not that different from other .Net languages and you can isolate these side effects nicely in a simple method or go down the monad path..
In short: I disagree with the article, because I have made quite different experiences in the past. The morale of the story: Don't be too general (functional programming) if you have trouble with specific things (like Haskell's academic background).
To write as little BS as possible I mostly keep myself limited to F#, a language I know:
- You don't need to use formal proves to design your software, the "purity" of your code is up to you
- Stacktraces? Hell, yeah.
- IO: Use what the .Net framework gives you - it's not that different from other .Net languages and you can isolate these side effects nicely in a simple method or go down the monad path..
In short: I disagree with the article, because I have made quite different experiences in the past. The morale of the story: Don't be too general (functional programming) if you have trouble with specific things (like Haskell's academic background).