Steve Yegge transcribed an excellent talk he gave on dynamic languages. It's incredibly thought-provoking and worth reading all the way through. And for the pseudo-obligatory Perl content, here is one of his comments on marketing:
I mean, like, Perl was a marketing success, right? But it didn't have Sun or Microsoft or somebody hyping it. It had, you know, the guy in the cube next to you saying "Hey, check out this Perl. I know you're using Awk, but Perl's, like, weirder!"
And for the Big Bucket of Fail, a someone named "dibblego" had this to say about Yegge's pre-emptive apology regarding some of his colorful comments:
Some of these people are more likely to be offended by your compulsion to pass severely under-qualified comment on the topic; something you have done more than once before. The offense comes about because it is almost deliberately misleading to others who might have the desire to learn and are not in a position to know any better and may mistake your pseudo-scientific nonsense with warranted factual claims.
I say "almost deliberate" because I am more inclined to believe your desire to continue doing this is a result of your ignorance rather than malice.
Here's a tip for you kids: "dibblego" might be right, but we'll never know since he never bothers to back up his assertions. Hell, if you're going to be rude, at least be rude with some meat on, will ya?
On another note, Yegge commented that many issues with Java generics require relatively newer programmers to have at least an implicit understanding of covariance and contravariance. These deal with the substitutability of return types and parameters in OO systems and, and, and
Here's a tip for language designers: if an oft-used feature of your language requires a deep understanding of comp-sci/math, programmers are going to get it wrong. Here be dragons. It's OK to allow things to require advanced concepts, but not for common code that you hope to spread to the masses.
For extra credit, try to find a clear, concise explanation of covariance and contravariance (and invariance, while you're at it) that your typical Jack in the Box programmer is going to be willing to read, much less understand.
On a side note, I still think it would be good to have a "Just Enough Theory" book for programmers that explains the basics they need to know to prevent the "beat them to death with Knuth" fantasies. I don't expect a new programmer to understand why restricting first order predicate logic to horn clauses is considered (by some) to be a weakness, but they had better know about loose coupling and cohesive functions.