11. Sarcastic lists from smug developers that make me out to be an idiot are off putting.<p>If you are ever thinking of marketing something where you genuinely want people to buy it and not just make yourself (or others who have already bought it) feel superior; do not use this technique as an example, even if you genuinely mean it in good humour.
>I don't know why the functional people couldn't stick with things I already know -- obvious symbols like ++ and != and easy concepts such as "inheritance" and "polymorphism".<p>This is the most poignant line, in my opinion. I think many people underestimate just how much power familiarity has in the industry. "Don't fix what ain't broke" is so ingrained that people try to follow it even when process is clearly broken: they simply can't comprehend how a system that "works" can be "broken".<p>It's also near impossible to convince someone to switch to a tool they don't understand, especially when empirical evidence is near impossible to get. You can say to your manager, "I rewrote/can write most of our app in 200 hours, cutting the lines of code to 40%, and implicitly eliminating many bugs without even trying". But you can't predict how many hours of maintenance you save in the future, even if you know beyond a shadow of a doubt that it will be orders of magnitudes more than the time it took for to rewrite, teach your team, or find good programmers who know your favorite static functional language.<p>At this point, I think I'm beating a dead horse (or maybe Nothing).
Noticed the article was a few years old. Wondering if it still holds up.<p>Haven't the most useful features of functional programming languages already been ported over to the practical languages?
> To me, functional programming just hasn't been around long enough to convince me that it is here to stay.<p>... is 1958 not long enough ago?*<p>* I'm guessing he means "statically typed FP"