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."

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?

Re:what does open mean?

[derGoldstein]

I guess "deprecated" is the wrong term, technically. What I meant was, that "in practice", you'd move past many of the lower-level elements of C++ and use STL instead. There's no reason to write your own String class when there's std::string, nor write your own Array class when there's std::vector (and other containers for array-like structures). Because of this, manual memory allocation is rare -- you'd only use 'new' and 'delete' in very special cases. The rest of the time you'd probably depend on RAII and scoping. You'd also avoid pointers and raw arrays, unless, again, you're *creating* a container, or if there's some extreme performance issue.

Then there's the C-compatibility stuff, that you'd never use in a pure-C++ program. They're just there to stay compatible with C (which is very important, but if you're writing something from scratch, you're not likely to malloc in C++).

These things aren't deprecated, but they are in the "lower level" bracket of C++, and in most situations are there to write the higher-level classes/templates. And since almost any container you're likely to need already exists in the STL, you're not likely to find them in a program that leans on the STL.

That's kind of the philosophy of Accelerated C++ [acceleratedcpp.com], in which the higher-level elements are covered first, and only then does it delve into the lower levels (which is the reverse way of how C++ is learned in academia).
I suppose that the main problem C++ has is its breadth (which I guess is what you meant when you said "complex beast").
(this comment didn't really go anywhere, but I'll post it anyway...)