Open Source Languages Rumble At OSCON

blackbearnh writes "Everybody knows what the best programming language is, it's whatever one you like the most. But is there a best language overall? Or even a best language for a given purpose? This question has been debated since the first time there were two languages to choose from. The argument is still going on, of course, but maybe a little light will be shed on the issue this week at OSCON. On Wednesday night at 7PM Pacific, representatives of the 5 major open source languages (perl, PHP, Python, Java and Ruby), as arbitrarily decided by O'Reilly, will meet to debate the merits of their various languages. If you're not going to be at OSCON, you can watch it live on a webcast and pose questions or comments to the participants. The representatives are: Python: Alex Martelli, Google; Ruby: Brian Ford, Engine Yard; PHP: Laura Thomson, Mozilla; Perl: Jim Brandt, Perl Foundation; Java: Rod Johnson, SpringSource."

Comments

Re:No C or C++

[EsbenMoseHansen]

I really should write it down. I will forget some points. For each feature, I will list a language that actually implements this feature

• Static typing, both duck and declared (Much like proposed in C++0x)
• closures (like ruby, or C++0x). I'll even settle for just anonymous inline functions, but the C++0x standard shows how *easy* closures would be.
• No "native types", everything an object, including nil, constants and whatever (much like ruby and lots of others)
• Full range of memory techniques supported, including RAII, scoped, shared, weak, garbage collected. (Lots of examples for each point, but really none for them all)
• Easy to parse grammar, so that the language is parsable with off-the-shelf parser (Java, ruby and many others). *Admittedly*, the parsers of today seems to be solving this problem even for perl and C++, so maybe it is not so important as it once was.
• No dependency on a virtual machine, should be able to run on bare iron or not (c++)
• No unneccessary overhead. Overhead introduced by features must only apply if the features are actually used (C++)
• Full metaprogramming, including static reflection (e.g., the ability to enumerate over all members of a class. Sorry, I don't have an example for this one, but it does seem so *easy* to extend say C++ to do this.)
• Sensible error messages (like NOT C++ currently and especially g++. "Expected primary-expression before ;" is just not very helpful, and the template errors are much much worse. Much tied to the aforementioned grammar)
• C interfaces must be easily callable (e.g., NOT like Java) and for preference, easy export of interfaces to at least C)
• Full dynamic reflection, perhaps optionally (mostly for test)

I probably forgot a lot, but it's a start, no?