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."
Because C++ is designed to be a quick and dirty web scripting language...
Finally, a web-server scripting environment giving you all the features you always missed, like coredumps, buffer overflows and format string errors...
Programming can be fun again. Film at 11.
As long as you write standard C++ (std::string instead of char*, cin/cout instead of scanf/printf, etc.) buffer overflows and format string errors go away. Core dumps are still a danger though...
I agree though... All of the power of a scripting language with the ease of use and simplicity of C++. Makes me pine for the days where assembly was the dominant language.
- I don't need to go outside, my CRT tan'll do me just fine.
I like C, but I think they got this the wrong way around...
Instead of creating a scripting language out of C, they should have created a good way to embed html codes in the C source (eg. a pre-processor and a custom library), and compile the pages to a cgi program.
This way you will get the best out of both worlds. You can code in C, and get real compile time checking instead of an interpreter failure because of a misspelled variable name or keyword. You get the speed of a compiled program and the C code can contain real html with no escape characters.
With a good library (no libc by default, that is too risky ...) you can
get access to apache internals, code in C (that is the whole idea,
isn't it ?) and get super fast performance. The library needs a large
collection of string handling functions.
RFC1925
Algorithms are fast or slow -- not so much the languages in which they are written. A for-loop in Java is just as fast as a for-loop in C. An O(log n) operation in BASIC will probably run faster than a O(n^2) operation in assembly. In most cases, if your standard library is complete and reasonably efficient, most programmer errors are avoided simply by helping them avoid reinvention of the wheel.
That being said, as compared to C or C++, Java is a faster language in which to code -- standard library that includes networking, i/o, threading, enterprise components, directory services, database access, etc.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
That being said, for numerics, low-memory usage GUIs, kernels, and those applications that need the absolute last squeeze of performance (0.01% of all programs), use some language other than Java. Hell, use whatever works best for you. But a properly written program (badly written programs and inefficient algorithms can occur in any language) are speed-wise quite similar to one another despite the choice of language. There is a far greater variance in programmer ability than the inherent speed traits of a particular language.
For the record, I don't own any Sun hardware, don't have $2 million to spare, and my servlets and EJBs run just fine thank you.
My only point of skepticism with a scriptable C and C++ is that the languages weren't designed to be scriptable -- they were designed with compile-time inefficiency so that runtime efficiency could be maximized. This is in direct contrast to scripting languages that are meant to be loaded and run in a single pass with no linking steps, best guess, general optimizations, and ease of coding. If it works for Carrot, good for them. If it helps primarily C and C++ coders get their jobs done, good for them. Will it give the same type of benefits that languages such as Python can give, probably not.
Use the right tool for the job and use that tool correctly. Everything else (including language-bashing) is waste of energy.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
That being said, Java is a more complete language for handling networking, i/o, threading, enterprise components, directory services, database access, etc. than any scripting language I know.
My biggest problem with Java is how horribly ugly it is. Interfaces are a joke and the lack of MI is incredibly painful. It's collections are utterly uselessly and adapter classes are almost as painful as functors in C++ although the lack of any binder functions make them much less useful.
Java is, at best, an academic language. Very little useful things can be done with it other then a 20 line hello world program. It has some good ideas (Inner Classes) but they are poorly implemented and the memory model absolutely sucks.
Passing by reference encourages sloppy programming as the use of final is not encouraged as it should. A well written C++ framework is a thousand times more robust then Java. Well written C++ classes can literally be safe even with monkeys smacking the keyboard in Emacs.
Java would be better if 1) it was an open language and allowed input from people other than Sun engineers 2) it was organized by a company looking to create a good platform and not by a company looking to exploit every buzz phrase in the world 3) the JVM bytecode was robust enough to be useful for other languages (and not bastardized versions of languages such as Mangled C++).
int func(int a);
func((b += 3, b));
Please. Interfaces couldnt be any simpler or easier to use. Lack of MI might be incredible painful to the .01% of people who need it. The other 100% dont care because interfaces provide what you need. Is it perfect? No but its hardly what you make it out to be.
Interfaces are a poor excuse for MI and are misused in Java. The fact that interfaces can't have a default implementation (or that certain aspects of an interface can't be option) is why interfaces stink. GCC has an extension to C++ called signatures which are much more useful than Java interfaces especially since they can be applied to a class post-compilation.
Java doesn't pass by reference. It passes reference by value. Your mistake is a common one.
If Java does indeed pass value by reference, then surely I can pass reference by reference then perhaps? Or maybe dereference the reference and pass by value directly?
No, you can't. Java doesn't give you the option. It does not have a 'robust' passing mechanism. Encouraging objects to be passed around by reference (making them writable) is very bad programming practice. Strict use of const (or final in Java) makes programming much safer. There is no reason why drawString should be able to modify the String object that is passed in.
Java does have input from people other than the engineers at Sun.
Is there a non-partial committee that oversees the development of the Java language? or do a bunch of suits at Sun determine what is in the language?
They may be open to suggestions, but I would equate that more to stealing ideas.
JVM bytecode *is* robust enough to be useful for other languages.
So then it supports MI? Or referencing objects? Or passing objects by value? It supports operating overloading? Come on now. JVM bytecode is only useful to languages which only contain identical functionality to Java.
The thing I wonder about though is why does that even make a difference?
Because then Java could be used (practically) with other languages. The C-to-Java wrappers are a joke. If a language cannot be mixed with other languages, then it is useless in the real world and useless for most production programs where legacy libraries are a reality.
int func(int a);
func((b += 3, b));