>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

>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". 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". 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. At this point, I think I'm beating a dead horse (or maybe Nothing).