PHP was actually on it before, but this just confirms what I already knew -- PHP is a badly-insecure language. As such, it does not belong in the web programming space. Security is a huge issue, and if you don't pay attention to it, it will come back and bite you. By ignoring this, PHP developers are placing all of their users at a disadvantage. Even if the language itself doesn't have holes, it is still notoriously easy to write insecure code in PHP. Contrast this with Perl, which has been around at least as long, and has had plenty of time to implement (and actually use effectively) security measures such as tainting. People say Perl is old, or ugly, or difficult to understand -- and they might be right. But Perl also has at least one kickass web framework that's nicer (and safer) to code with than PHP.
Python has been added to the list. I was wavering on it for a while, but I've finally decided it deserves a place. This was the straw that broke the camel's (well, the python's) back -- I believe that lambdas (anonymous functions, closures, whatever you want to call them) should have a place in every high-level language. Lambdas are extremely useful for quick, short functions that need to keep their context (e.g. GUI event handlers), and IMO are conceptually cleaner than generators (e.g. for complex iteration schemes). Named inner functions are a clumsy, but acceptable substitute. Or they would be, if it weren't for what I would consider to be Python's OO shortcomings.
It's been a while since I've used Python, so my memory's a bit fuzzy, but I have a very distinct recollection of feeling as though the OO features were bolted on as an afterthought. (Yes, I am aware this is not the case, however, I think my impression is more relevant here, because it has more influence on day-to-day usage than factual history.) WTF is up with
len(), for example? Why can't it just be a normal method? Do we really need a special
def __len__for what amounts to a normal method call?
I'm also a bit dubious on Python's handling of packages (though I hear that's been improved), globals (why do I need
globalkeywords everywhere?), statements vs. expressions, and indentation. IMO statements and expressions should be one and the same -- every statement should return a value (even if it's
None). Are there any good reasons for keeping them separate?
Also, I think indentation-based grouping is a neat concept in principle, but in practice it seems to have some shortcomings. First is the necessity for the
passstatement -- if there is a block that does nothing, then I don't think one should see anything there (not even a nop keyword). Second, it's not really possible to implement a syntax for
lambdathat allows multiple lines and still keeps consistency with the syntax of the rest of the language. Finally, splitting statements across multiple lines is clumsy (you need to use
\), and there's no way (that I know of) to put multiple statements on the same line. Yes, I am aware that doing so is supposedly Bad(tm), but they said that about
goto, too, and I know I've run across cases where using a goto made the most conceptual sense. I'd argue the same rule applies to splitting/joining statements on a line.
I'm also a little concerned about the rumblings I've been hearing from the Python community about new syntactic features each release. (Decorators one time, improved generators the next...) I don't have a problem with any specific feature, but I think it's telling that the Python devs feel it's necessary to keep adding new language features (and deprecating old ones). It suggests to me that maybe their overall language design/philosophy isn't as flexible as perhaps it should be. (But, obviously, that's a totally subjective judgement, and you should make your own.)
By contrast, Lisp syntax hasn't changed in a long, long time. C++ syntax has remained relatively stable since the introduction of templates (though there are rumors of more changes in C++0x, perhaps rightfully so).
So ... I'm still on a quest for the Perfect Language(tm). Maybe one of these days I'll get around to finishing Dryice, and then I'll have a first approximation thereof, or something. ;P I'm not silly enough to believe I'll find a perfect language, but I may as well try, yeah? ;)