Slashdot Mirror
Carrot, an Open Source C++ scripting module for Apache
Fons Rademakers writes: "ROOT-Apache (aka Carrot) is an open source scripting module for the Apache webserver. Based on the ROOT framework which is using C++ as scripting language, via the CINT interpreter, it has a number of powerful features, including the ability to embed C++ code into HTML pages, run interpreted and compiled C++ macros, dynamically extend the framework with external libraries, access and manipulate databases, and generate graphics on-the-fly, among many others."
With the cgicc library you can create CGI applications written in C++.
Supported features: client-side cookies, file-uploading, fast-cgi and environment debugging.
http://www.gnu.org/software/cgicc/
http://www.fastcgi.com (A language independent, open extension to CGI, that provides better performance due to process persistance.)
http://debianlinux.net/c++.html (C++ resources)
Once again, there is far more variance in programmer ability (judicious use of algorithms and patterns) than is inherently demonstrated by language choice.
...and the JVM is faster than the Python VM.
...and a regular expression engine? Sure. Do I like everything Sun has done? No. But then, I don't like everything the Perl, and C++ communities have done either.
Now with regard to Java, its standard library is much cleaner than that of Perl (for example). Perl objects were an afterthought and it shows. Its socket APIs are not intuitive. Couple this with the fact that you can't enforce by interface that a particular variable is an int vs. a string vs. anything else without extra runtime checks like regular expressions. This can add unecessarily to the runtime of a program. Large-scale Perl is a nightmare compared to language that doesn't just pay lip service to a component-based architecture. So right off the bat, this is what I get from servlets that I can't do with mod_perl.
Comparing VMs, Java's is noticeably faster than both Perl's and Python's for computationally intensive programs and is not quite so bad against C or C++ as you assert. Combine this with the fact that Java can be compiled natively with a variety of tools today (although modern JVMs do a more than adequate job). Speed approaches that of C and C++ code without core dumps, buffer-overflow exploits, etc. Add to this excellent i18n and l10n support, standard networking, threading, database, directory services, distributed programming, ABI, etc., I consider it a good trade.
A lot of development is going into Jython. Why? Because a lot of Python developers recognize the value of the Java platform.
Now let's examine the proprietary manuevers. Sun has not released Java to a standards body. ECMAScript *has* been released to a standards body and yet the programming models are not uniform on all platforms. Perl is the shining star apparently...but how many have tried to access CPAN modules directly from Perl on Windows? As it turns out, quite a few modules are programmed with C and a UNIX model in mind (or just Linux/BSD). Don't believe me, check out the graphics modules (dynamic creation of web images for example), RPC, mail handling, etc. So much for write once run anywhere with a "standard" language.
Are there issues like a logger that was put in even though there was an arguably better one out there?
Now let's examine the J2EE issue. If Sun tested JBoss for free, what does that say to IBM, BEA et all who paid a lot of money to get tested? You'll lose partners that way. But also notice that Sun has not tried to bully JBoss out of the market. When you look closely at the Lutris (Enhydra) J2EE stink, you'll note that they were worried because they used Sun J2EE libraries to produce a product. Couple this with the fact that Sun never issued a cease and desist; Lutris pulled back on their own.
As long as JBoss (and libre software in general) stays competitive, it is in Sun's best interest to leave it alone. Can you imagine what would happen if Sun suddenly decided to deny access to the Sun platform to anyone but licensed vendors? It would destroy the Solaris server market. The same holds true for Java. After all, it's just another platform, and there is far too much code out there to simply cut them off.
This is like saying that maybe tomorrow Microsoft may announce that all compilers except for Visual Studio are not allowed to be used on Windows OSes. Aside from the anti-trust issues, there is simply too much code out there that has been written with a Borland, GNU, Intel, Metrowerks, etc. compiler.
Someone's already pissed in the pool. You can't get it out now without draining all the water out first. Developers are in far more danger from DCMA, SSSCA, and other similar items than Java suddenly becoming unavailable.
- I don't need to go outside, my CRT tan'll do me just fine.