Which one?
It is a dynamic language with closures, higher order functions (lambda), map, join, the option to work in an expression-oriented manner, and the ability to modify the language to suit the task.
It's worth noting that a couple of the languages in the other list (the not "inferior" languages) lack one or more of those capabilities. What's trendy is not always the whole picture.
Language Snobs stress the superiority of one programming language over others. Some languages are extremely guilty of this (Lisp, SmallTalk, Python, Ruby, Scala, Haskell, etc) while others aren’t (Java, C#, VB, BASIC, PHP, Perl, C, etc). The snob languages talk about why they’re so great, and the other languages just point to what has been written in them as proof that they’re great (or at least good enough). </quote>
I'm saying the classifications don't make sense:
If the point is "people who use the languages get things done", then Ruby and Python clearly belong in the first list, as there's plenty of code in those languages doing work in all sorts of fields.
If the point of the second list is the superiority of the languages due to purity (Smalltalk, Scala and Haskell, I guess, but not Lisp) then Python and Ruby don't belong in the second list. If the point is capability (where "dynamic" is a capability along with all of the other goodies, shared by almost all of the second list languages), then Perl belongs in the second list and Scala probably doesn't, since Scala is the language that has the least in common with the others in the list (which is not to say it has significantly more in common with the first list).
The point of the article is probably valid, but the lists are flawed. No matter how you classify the languages, at least a couple of the languages are out of place in the lists they've been put in. Leaving Perl, Python, and Ruby out of the picture altogether would have left a gaping hole in the argument (as they are quite good and powerful tools, with which lots of people have written useful code), but cramming them into the wrong slots also makes the argument weaker. So, I guess what I'm saying is that the argument turns out to somewhat weak...huh! It seemed so compelling to start with.
2. But life, business, and software are full of trade-offs. If you can accept a little imperfection here, some cruft there, and sloppy duplication there, they you can hire from a bigger pool of employees, deploy to a wider range of platforms, hit more markets more frequently. The key point that the penny pinchers miss is that while using inferior tools has a cost associated with it, so does not using those tools. The important thing is to Always Be Shipping. </quote> (press C-f, type inferior tools)
The article does not reflect my opinion (EDIT: but accidentally I agree with the above fragment). I was trying to make a short version (summary) of the article and as Joel (joelonsoftware.com) said:
the trouble is if you put something up without writing a long enough post to actually make your full case, uhmm, you just get misunderstood, was sort of what I concluded. </quote>