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

Comments

Yes...

[Anonymous Coward]

Because C++ is designed to be a quick and dirty web scripting language...

This is quite sweet!

[NWT]

Yes, this is a good mod_,it's a lot more flexible than mod_php4 and gives you more possibilities to do stuff. But what about security matters? Does it have anything to prevent people, using it on your webserver, to access files etc.?

Re:This is quite sweet!

[adamy]

My God, Scripted STL

Shudder. I want one.

Great idea

[__past__]

Finally, a web-server scripting environment giving you all the features you always missed, like coredumps, buffer overflows and format string errors...

Re:Great idea

[m_ilya]

Mod parent up. It is amazing what language can invent C/C++ programmers who never seen other languages. I just don't get what are they thinking about. What the reason to create *scripting* language which is as hard as C/C++ to program in? As scripting language it cannot be as fast as C/C++ language. And as C/C++ like language it cannot be as high level as other lanugages like Perl, Python, Ruby, etc.

Re:Great idea

[Fweeky]

> Finally, a web-server scripting environment giving you all the features you always missed, like
> coredumps, buffer overflows and format string errors

Yup, open source web software finally catches up with Microsoft. Should go nicely with the FreeBSD .NET port :)

Re:Great idea

[cperciva]

I'll agree that buffer overflows and format string errors are a problem... but core dumps?

If you don't want core dumps, disable them. Personally, I find core dumps to be rather useful things... if something goes wrong, you can track down what happened, unlike with interpreted languages where you'll be lucky to get an uninformative "Abnormal program termination" message back.

Re:Great idea

[Snowfox]

What the reason to create *scripting* language which is as hard as C/C++ to program in? As scripting language it cannot be as fast as C/C++ language. And as C/C++ like language it cannot be as high level as other lanugages like Perl, Python, Ruby, etc.

C/C++ are only hard to program in if you do everything from scratch. You wouldn't use any of the above languages without anyone else's toolkits and libraries. Why would you do differently with C/C++?

There are string, memory, file, html, etc libraries which make C/C++ every bit as easy (some would say easier) to work with as any language you care to name. And there are more libraries available for free use than there are for all of the languages you can name combined.

On top of that, you get a huge suite of debugging tools and superior performance. Do a little research. A C/C++ environment is about the most flexible thing out there. You can turn it into anything you like.

Re:Great idea

[m_ilya]

First of all don't take my words as offence. I don't want to say that C/C++ is bad. Still I think that most good scripting languages are much more easier to program in (with libraries or without them programs in scripting language are shorter anyway). After all good scripting languages are *designed* to be easier. You can have even garbage collection in C/C++ but still it fills very alien in it. However I know that some tasks are better to do in C/C++ (but definetly web development is wrong application for it).

Anyway my point was that *scripting* languages which resemble C/C++ are crap. There is no huge suite of debugging tools and superior performance for them and there is no string, memory, file, html, etc libraries which make C/C++ every bit as easy for them. I've been there. I've been forced to write in one such language. It is very annoying when you have to deal with memory managment in *scripting* language.

Re:Great idea

[Wojtek]

Format string errors? That's C. No, C++ in the webserver will bring you the joys of doing template code instantiation on every single page lookup! Fun for the whole family!

Re:Great idea

[Webmonger]

Perhaps you should read a little more carefully. *this* C/C++ scripting language supports libraries that aren't specifically written for it.

Re:Great idea

[angel'o'sphere]

Format string errors? That's C. No, C++ in the webserver will bring you the joys of doing template code instantiation on every single page lookup! Fun for the whole family!

The template is instanciated by the compiler not by the web server.
If you use an interpreter a template class is just a meta class.
Nothing to instanciated neither.
Probably you should get a degree ....
Or at least inform your self a bit better how languages work. No wonder that all people(like you) think that C is ALLWAYS faster than Java.

Regards,
angel'o'sphere

Re:Great idea

[nzkoz]

What scripting language do you use? Python's errors are nice, simple exceptions. If they make it all the way to __main__ you get a full stack trace and an explanation of the error. Much nicer than chasing around errors in gdb or ddd.

Also, if you use std::string you don't get buffer overflows. gets rid of format string errors. Most of the problem with current c++ usage is that people treat it like c with classes, while it has *so* much more to offer!

no....

[Gambit-x7x]

C++ is not a web scripting langueage, yea it can be used as cgi but that is different

Not in C++

[ttfkam]

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.

Re:Not in C++

[__past__]

All of the power of a scripting language with the ease of use and simplicity of C++.

Perhaps they want to learn from Java's success, which elegantly combined the disadvantages of interpreted and compiled languages...

Re:Not in C++

[ttfkam]

With the exception of Python (I think...I'm not sure) I know of no commonly used scripting languages that allow for simple and consistent object serialization/deserialization. I know of no scripting languages that have the equivalent functionality to EJBs. Combine those with the fact that strong typing (it's a int, it's a String) can be an invaluable asset in interface-based programs -- especially when talking to other languages or over a distributed model such as CORBA.

While there is definite overlap, Java has a different problem space from most scripting languages (and from C or C++). Use the right tool for the job.

Re:Not in C++

[einhverfr]

With the exception of Python (I think...I'm not sure) I know of no commonly used scripting languages that allow for simple and consistent object serialization/deserialization.

iirc, REBOL has these features. Unfortunately, the licensing model for that language for commercial purposes sort of prices it out of the market even though it is a killer language.

Debugging

[Anonymous Coward]

Now we need a gdb plugin for netscape.

A better idea ....

[geirt]

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.

Re:A better idea ....

[Anonymous Coward]

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)

Re:A better idea ....

[geirt]

Yes but you are still stuck with code like:

printf("<tr>\n");
printf("<td colspan = \"2\">\n");
printf("<img src=\"/img/myimage.png\" alt=\"comment\" border=\"0\" height=\"100\" width=\"150\">");

Not very readable. We need a preprocessor which embeds the HTML code in C for readability.

Re:A better idea ....

[m_ilya]

If you want readability separate data and code. Put HTML into templates.

Still I don't understand why people insist on wasting their time writting web applications in C.

Re:A better idea ....

[ahde]

Doesn't this also do it your way (a la JSP)

example:

<H1> Say it ten times </H1>
<OL>
<CARROT>
for (int i = 0; i < 10;i++)
cout << "<LI> this whole thing will be compiled" << endl;
</CARROT>
</OL>

is converted to:

cout << "<H1> Say it ten times </H1> "" << endl;
cout << "<OL>" << endl;
cout << "<!-- begin embedded carrot section -->" << endl;
for (int i = 0; i < 10;i++)
cout << "<LI> this whole thing will be compiled" << endl;
cout << "<!-- end embedded carrot section -->" << endl;
cout << "</OL>" << endl;

Re:A better idea ....

[Anonymous Coward]

The same reason they waste time writing all other kinds of applications in C.

Java

[alan_d_post]

Right . . . Java is for those cases when runtime performance is unimportant, *and* programmer convenience in unimportant. I truly believe it is a fraud by Sun, with the goal of pushing more hardware. "Oh, your Java program is slow? Just buy this $2 million Sun box, and it will be just fine." And I'm sure everyone here knows what a fraud the whole "Java Community Process" thing is. Java is a shitty language with a proprietary, poorly implemented runtime environment.

Re:Java

[ttfkam]

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.

Re:Java

[alan_d_post]

Again -- if it needs to be fast, use C or C++. If you need to write it quickly, use Perl or Python or TCL or some higher-level language. I am *off topic* here, just bashing Java -- nothing about scriptable C (which also seems moronic to me). What do you get from servlets that you couldn't do more easily with mod_snake or mod_perl?

Besides, like I said, Java is all about proprietary maneuvers and bad vibes. Why bother with all that, when people are cooperating on better stuff?

Re:Java

[angel'o'sphere]

I programmed 3 or 4 years in PERL and gave it up.

I programmed about 10 years in C++ and gave it up.

Still to today there is no standard portable thread library in C++. Still to today there is no standard portable GUI library in C++. Still to today there is no standard web services, XML, directory services or ANY other standard library available in C++.

C++ is the best language I ever worked with(look at Spirit parser library, or at Open C++), but no vendor gives you a wide set of standard libraries. The only standard is the standard C++ library (where STL is a part off) and the standard C lib.
STL exists since 6 years now. And? It still is not supported on all platforms.

I now programe since 4 years JAVA.

EVERYTHING IN JAVA IS A STANDARD. And works on all machines the same.

Before you have not worked in a > 100 members development team on a > 300 man years project, just shut up to trash a language.

Most arguements against Java are either wrong(other languages are easyer, lol) or outdated(its to slow, Sun makes fraud, LOL even louder).

BTW: ROOT and CINT are nice projects and they work pretty well. I played with both.

If C++ would compile to JAVA bytecode I would stick to C++. But JBC has so many advantages ....

E.g. you can link with other languages compiling to JBC(C, PERL, Python, RUBY, Prolog, LISP, SCHEME, ML ... well, there are more languages compiling to java byte code than I can program in)

C++ has no reflection, Perl has no reflection either ... well, you hate Java, I asume you have no clue what reflection si and why it is usefull.
Well, as you hate Java you will never know. Keep sitting in your little hole, but don't cry when the time for old outdated languages is over. (Like it is for COBOL, Simula, Smaltalk ... yeah they still exist, but how was it for/with them ten years ago?)

Regarding your rant against servlets: Easyer than a servlet? Even more easyer than a servlet? I don't know about mod_snake but about mod_perl I know pretty well.
They ara FAR away from a servlet. FAR.
What do you think why there are PERL servlet APIs implemented right now? Because of the ideas behind the servlet environment and the frameworks. Look for "libservlet" on freshmeat.

Regards,
angel'o'sphere

Re:Java

[alan_d_post]

> Still to today there is no standard portable thread library in C++.

There is no portable concept of threads in various operating systems, either.

> Still to today there is no standard portable GUI library in C++.

There are a number of GUI libraries; why the obsession with a "standard" library? GUIs written in Java tend to be ugly and monstrously bloated programs. As of a year ago, Swing still had pretty serious memory leaks, and AWT still looked like donkey turds. Do you remember the original marketing spin from Sun about Java? All GUI programs were going to be written in Java, so they would run everywhere! Sun would write a Java web browser, that would be super-fantastic, and run everywhere! Microsoft would crumble as all user apps were written to Java APIs! Only of course HotJava sucked, as did pretty much all GUI Java programs, and now Sun wants to talk to you about server-side Java. Strange, given all that talk about portability. They basically retreated from GUI land, and are pushing slow server software.

> Still to today there is no standard web services

meaningless market-speak

> XML

overhyped (and brain-damaged) serialization syntax

> directory services

a weak version of a database

> or ANY other standard library available in C++.

That's odd, on my planet there is an incredible wealth of libraries in C and C++ implementing all kinds of wonderful things. For a start, you could look into the GNU project (including GNOME) or KDE.

> C++ is the best language I ever worked with(look at Spirit parser library, or at Open C++), but no vendor gives you a wide set of standard libraries. The only standard is the standard C++ library (where STL is a part off) and the standard C lib.

> STL exists since 6 years now. And? It still is not supported on all platforms.

C++ is horrifically complicated, so every compiler implements it a bit differently. STL pushes those horrifically complicated features pretty hard,

> I now programe since 4 years JAVA.

I guess you really like all those really long type names you have to use to cast objects that come out of containers. You must also really like FOR loops, and be bothered by complicated concepts like map, filter, etc..

> EVERYTHING IN JAVA IS A STANDARD. And works on all machines the same.

Meaning you have what Sun gives you. You are under the control of a vendor whose interests don't particularly line up with yours. Sounds a lot like other proprietary software situations, doesn't it?

> Before you have not worked in a > 100 members development team on a > 300 man years project, just shut up to trash a language.

There are lots of projects to be done (I would venture, even, most of them) that don't require 100 active developers. As for man-years, I would imagine that using Java increases the time required by quite a bit.

> Most arguements against Java are either wrong(other languages are easyer, lol)

For many tasks, other language are much easier to use. Want to do massive string manipulation-type stuff? Way easier to write in Perl. Want to use higher-order functions? Functional languages (e.g. ML, haskell) are a much better fit. Want to implement your program quickly? Java programs tend to be very lengthy, compared to implementations in less verbose languages.

> or outdated(its to slow, Sun makes fraud, LOL even louder).

Sun has been promising for many years that the next version of Java would be the one that solved all the performance problems. I haven't seen it happen yet. The RAM requirements are particularly egregious. The performance of JIT programs is incredibly erratic, to the point where it is difficult to measure the troughput, because the response time varies to wildly from request to request.

> BTW: ROOT and CINT are nice projects and they work pretty well. I played with both.

That's nice. It's always good to have more free software!

> If C++ would compile to JAVA bytecode I would stick to C++.

This is a really strange statement. C++ is incredibly complicated, largely because of the keep-it-close-to-the-metal spirit interacting poorly with all the features Bjarne crammed in. A C++ compiler targeting Java bytecode would get you a horrendously complicated language, and a slow program. The worst of both worlds!

> But JBC has so many advantages ....

Aside from burning all your RAM and CPU.

> E.g. you can link with other languages compiling to JBC(C, PERL, Python, RUBY, Prolog, LISP, SCHEME, ML ... well, there are more languages compiling to java byte code than I can program in)

Definitely a neat feature. It's too bad that the bytecode language was aimed at embedded devices, and so is way too simple to convey at a high level what your program is doing. This makes implementing a fast JVM extremely difficult!

> C++ has no reflection, Perl has no reflection either ... well, you hate Java, I asume you have no clue what reflection si and why it is usefull.

Perl lets you do all kinds of wacky things at runtime, including inspecting namespaces, inspecting the runtime stack, creating new classes -- with eval, you can basically do anything! Not to say that Perl is wonderful in every way (I will not defend the rampant cruftiness), but it *is* very flexible.

> Well, as you hate Java you will never know. Keep sitting in your little hole, but don't cry when the time for old outdated languages is over. (Like it is for COBOL, Simula, Smaltalk ... yeah they still exist, but how was it for/with them ten years ago?)

And you will keep writing FOR loops, casting pointers you get from container objects (all that effort to declare the types of things, and then you have to throw the info away when they're in a list!), and reading up on the last "hot new trend" being pushed by the marketeers at Sun. Is it B2B-enabled Web Vortals? Or is it P2P Web Services with XML? I lose track.

> Regarding your rant against servlets: Easyer than a servlet? Even more easyer than a servlet? I don't know about mod_snake but about mod_perl I know pretty well.

As I mentioned above, for string manipulation, Perl is very convenient. When building a web page, it happens sometimes that one does . . . string manipulation! In those cases, I'll always take the four lines of Perl over ten to twenty lines of Java, even if I can't claim I'm using an Enterprise Java Bean.

> They ara FAR away from a servlet. FAR. What do you think why there are PERL servlet APIs implemented right now? Because of the ideas behind the servlet environment and the frameworks. Look for "libservlet" on freshmeat.

(incidentally, writing apache modules in C is also really easy)

Because it is *really easy* to code in Perl. People code all kinds of stuff in Perl -- surely you have seen CPAN. People write all this stuff because Perl makes it easy. If someone likes Sun's content handler API better than Apache's, they can implement it, no big deal.

If you want one vendor controlling everthing, why not use the Microsoft stuff? At least they don't pretend to have a Community Process, etc..

If you want strong typing, try ML, haskell, O'Caml, etc.

If you want a short program, Perl wins almost every time.

I just don't see where the tradeoffs make sense for Java.

Re:Java

[lkaos]

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++).

Re:Java

[ChannelX]

> EVERYTHING IN JAVA IS A STANDARD. And works on all machines the same.

Meaning you have what Sun gives you. You are under the control of a vendor whose interests don't particularly line up with yours. Sounds a lot like other proprietary software situations, doesn't it?

I dont remember being forced to use most of what Sun provides. What they do provide though is a huge API that covers pretty much all the bases. You seem to forget that not everyone cares if something is proprietary or not. And Java certainly is not proprietary in the sense that you mean.

As for man-years, I would imagine that using Java increases the time required by quite a bit.

Why would you imagine that other than never having done a project in Java?

As I mentioned above, for string manipulation, Perl is very convenient. When building a web page, it happens sometimes that one does . . . string manipulation! In those cases, I'll always take the four lines of Perl over ten to twenty lines of Java, even if I can't claim I'm using an Enterprise Java Bean.

Java is pretty convenient for doing web projects also. Your comments carry even less weight with the implicit connection of web and EJB. EJB has nothing to do with the web. Can it be used for web projects? Yes. Is it necessary. No. Servlets work great.

I find it amusing all your railing against Java when Apache is a huge Java supporter in the web space.

Re:Java

[ChannelX]

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.

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.

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.

Can I have some of what you're smoking please? Memory handling definitely could be improved but the comment that very little useful things can be done with Java is absolutely ridiculous.

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

Java doesn't pass by reference. It passes reference by value. Your mistake is a common one. As to "well-written" C++ that is the key. Define robust please. Java is very robust.

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++).

Java does have input from people other than the engineers at Sun. JavaBeans being a prime example. I also dont get the buzz phrase comment. The APIs being created are there because people are asking for them. JVM bytecode *is* robust enough to be useful for other languages. The thing I wonder about though is why does that even make a difference?

Re:Java

[lkaos]

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.

Re:Java

[alan_d_post]

> I dont remember being forced to use most of what Sun provides. What they do provide though is a huge API that covers pretty much all the bases. You seem to forget that not everyone cares if something is proprietary or not. And Java certainly is not proprietary in the sense that you mean.

What bothers me is that Sun pretends to be all friendly and open, while actually using a restrictive license / undocumented native functions to make it difficult for people to implement their own JVMs. If you write your app using the Sun-provided libraries, you won't be able to run it with gcj, for instance.

>> As for man-years, I would imagine that using Java increases the time required by quite a bit.
> Why would you imagine that other than never having done a project in Java?

When I did a project in Java, I found it much more convenient than C -- in particular, that it handled null pointer derefs and array out-of-bounds cases nicely, giving a stack trace that showed where the problem was. Also, garbage collection is nice, though it doesn't free you completely from memory management.

When I subsequently learned Perl really well, I found I was several times faster in Perl than in Java or in C. Not "line noise" code -- nicely written code, broken up into little classes, etc.. Java is so *verbose* that it just takes way more effort to get anything done, and once you've written it, tearing it down and rewriting seems pretty unappealing. Not to say that I love everything about Perl -- I think it is too complicated and poorly defined. But boy is it handy!

More recently, I've been doing C++ coding, which feels to me kind of like Java but without the memory bloat, and with nice generic containers (fewer verbose casts!). But boy do I miss map() and grep(). The STL equivalents just aren't the same at all. I can't say I miss anything about Java, but that may be because I haven't had to do any difficult memory management.

This is why I don't see why Java is useful -- it's more bloated than perl, comparable (but more variable) performance to perl, but even more verbose than C++. It combines the worst of both worlds! The Sun-is-evil slant is just the icing on the cake.

> Servlets work great.

Some people I'm working with are doing a big servlet application. They say it is very convenient, but we're having serious performance problems, and the memory usage is simply horrendous.

> I find it amusing all your railing against Java when Apache is a huge Java supporter in the web space.

I guess you haven't been following the latest stuff in the Apache section. Sun uses the Apache brand to gain credibility, Apache projects get Sun full-time developers: should be great, right? It would be, if Sun weren't so nasty.

Re:Java

[ChannelX]

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.

How exactly are interfaces misued in Java? If you wanted a default interface in Java you'd be better off using a language that supports MI. The whole point of an interface is that you get a guaranteed set of methods that someone has to implement thereby providing a contract between objects. This idea is used very well throught the various Java APIs (especially Swing). If you want MI then use a language that includes MI. Its pretty simple. I dont see lack of MI being a hindrance to the use of Smalltalk in many mission-critical applications. This sounds like the attempt at an argument that static typing somehow means more robust applications.

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?

Java passes reference by value. Thats what you get when you use Java. Primitives are passed by value and objects are passed by reference by value. Seems to work just fine. If you need something else *use another language*.

There is no reason why drawString should be able to modify the String object that is passed in.

drawString won't modify the String object that is passed in. You have read the language spec right?

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?

Last time I checked the JCP wasnt a bunch of suits at Sun determining what is in the language.

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 JVM is apparently robust enough for a Smalltalk implementation and Smalltalk certainly isnt identical in functionality to Java.

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.

The success of Java in the enterprise marketplace pretty much invalidates your statement.

Re:Java

[ChannelX]

Aha! Better arguements! Thank you! Will reply below:

What bothers me is that Sun pretends to be all friendly and open, while actually using a restrictive license / undocumented native functions to make it difficult for people to implement their own JVMs. If you write your app using the Sun-provided libraries, you won't be able to run it with gcj, for instance.

Yes...I tend to agree that they pretend to be more open than they really are. I do take issue with that much more than the proprietary nature of Java itself. I'm not sure what you're referring to about undoced native functions and gcj.

When I did a project in Java, I found it much more convenient than C -- in particular, that it handled null pointer derefs and array out-of-bounds cases nicely, giving a stack trace that showed where the problem was. Also, garbage collection is nice, though it doesn't free you completely from memory management.

Agreed. Features I really like that take time off of projects because you have less to worry about. And youre right that GC doesnt solve all the memory management issues. wish all people thought that ;)

When I subsequently learned Perl really well, I found I was several times faster in Perl than in Java or in C. Not "line noise" code -- nicely written code, broken up into little classes, etc.. Java is so *verbose* that it just takes way more effort to get anything done, and once you've written it, tearing it down and rewriting seems pretty unappealing. Not to say that I love everything about Perl -- I think it is too complicated and poorly defined. But boy is it handy!

Yes. You are right. Java is pretty verbose but I don't think that is necessarily a problem. Certain projects will call for Perl and its style and others for Java. This is just the nature of things. Right tool for the job and all that. Perl is very handy but there are many projects I wouldn't want to touch with it. I also think it is too complicated. At times that is worse than the verbosity of Java. Its the 'lets hack this and that onto it' feel of Perl that really bothers me. That being said I wouldnt use anything else for lots of my scripting and admin tasks. Very useful there and lots of people know Perl.

More recently, I've been doing C++ coding, which feels to me kind of like Java but without the memory bloat, and with nice generic containers (fewer verbose casts!). But boy do I miss map() and grep(). The STL equivalents just aren't the same at all. I can't say I miss anything about Java, but that may be because I haven't had to do any difficult memory management.

I just can't deal with C++ anymore. Its too "dirty" and there are far to many things it leaves you to deal with. Yes casting in Java can be a real PITA but so far, in the types of applications I write, it hasn't been an issue. Are generic containers less verbose? You still have to define the template no? Is that any less verbose than a cast when retrieving something from a container? IMHO the best containers I've ever dealt with are the ones in Smalltalk. Smalltalk just rules but it isnt for everyone or every project.

This is why I don't see why Java is useful -- it's more bloated than perl, comparable (but more variable) performance to perl, but even more verbose than C++. It combines the worst of both worlds! The Sun-is-evil slant is just the icing on the cake.

You would not use Perl on the same types of applications you'd use Java on (or for that matter C++). I think Java's best space is in enterprise-level applications. I dont see Perl being all that useful there nor C++ and with Java its much easier to have stuff co-exist on different platforms. You definitely get trade-offs for that.

Some people I'm working with are doing a big servlet application. They say it is very convenient, but we're having serious performance problems, and the memory usage is simply horrendous.

I'd be curious to know what app server or servlet container youre using. Several are notorious for what you're reporting.

I guess you haven't been following the latest stuff in the Apache section. Sun uses the Apache brand to gain credibility, Apache projects get Sun full-time developers: should be great, right? It would be, if Sun weren't so nasty.

I've been following it. But the Apache projects are still important to Java and I don't see them going away regardless of what Sun does. And anyhow Apache said things are getting better and they have support from others (like IBM). There is lots of important work being done under the Jakarta project. Sun wont change that.

Re:Java

[alan_d_post]

> Yes...I tend to agree that they pretend to be more open than they really are. I do take issue with that much more than the proprietary nature of Java itself. I'm not sure what you're referring to about undoced native functions and gcj.

I strongly suggest you read the relevant gcj FAQ entry -- I think you may be underestimating how proprietary it is.

> And youre right that GC doesnt solve all the memory management issues. wish all people thought that ;)

Yep. In fact, when we used Swing last year, we had lots of trouble with memory leaks in the libraries. Aargh!

> Perl is very handy but there are many projects I wouldn't want to touch with it.

What sorts of projects? As long as your programmers are skilled, I think performance is the only real problem.

> That being said I wouldnt use anything else for lots of my scripting and admin tasks.

I find that using map(), grep(), sub{} expressions, and the class system makes manipulating complex data structures very easy. And most performance-sensitive things are done off in C libraries.

> I just can't deal with C++ anymore.... Are generic containers less verbose?

I think so.

using namespace std;
...
map<int,int> foo;
foo[1] = 2;
cout << foo[1];

The main place where I encounter verbosity is in using STL iterators, but even there I don't see that its any less verbose that Java, where you are either using iterators or for loops.

> Its too "dirty" and there are far to many things it leaves you to deal with.

I think C++ is way too complicated, but if you stick to unix, the overall experience isn't too yucky. What irritates me about STL is the compiler-compatibility problems, particularly on MS Windows.

> I think Java's best space is in enterprise-level applications. I dont see Perl being all that useful there nor C++....

I'm not sure what you mean by "enterprise-level applications" -- do you mean things like the EToys ecommerce system? If you mean, "we have to sell this thing to a PHB who will only buy it if it is written in Java," then, okay, I guess that's the only option.

> I'd be curious to know what app server or servlet container youre using. Several are notorious for what you're reporting.

They are using Tomcat. Tomcat 4 doesn't seem to be any faster than 3; both have about 10 times the latency of Apache for "hello world."

We tried out Resin last year, and it was much better than Tomcat, but building your app on a hidden-source-code foundation is just asking for trouble down the line. Not to mention having to deal with licensing issues.

> And anyhow Apache said things are getting better and they have support from others (like IBM).

Then IBM should release an LGPL implementation of the JVM and class libraries, and everyone should use that. As things stand now, Sun has control, and they have demonstrated that they cannot be trusted.

Seriously, read the GCJ FAQ entry and think about it for a minute or two. What Sun is doing is pretty insidious.

Re:Java

[Anonymous Coward]

Sun's support and marketing of Java sucks and some of the libraries are way too complex.

But Sun's Java implementation really has excellent performance. If your code in Java doesn't run pretty much as fast as in C/C++, it's your fault, not Java's. The Java language itself is pretty decent as well--nothing ground-breaking, but a straightforward, proven design.

Re:Java

[ChannelX]

I'm not sure what you mean by "enterprise-level applications" -- do you mean things like the EToys ecommerce system [perl.com]? If you mean, "we have to sell this thing to a PHB who will only buy it if it is written in Java," then, okay, I guess that's the only option.

That would be something I'd consider part of an enterprise-level application. And I'm happy they were able to use Perl but I dont any significant advantage of Perl over Java Servlets in a situation like that and more negatives. They mentioned using Perl's OO features. Yuck.

They are using Tomcat. Tomcat 4 doesn't seem to be any faster than 3; both have about 10 times the latency of Apache for "hello world."

We tried out Resin last year, and it was much better than Tomcat, but building your app on a hidden-source-code foundation is just asking for trouble down the line. Not to mention having to deal with licensing issues.

Tomcat is a reference and not something that should be put into production. As to Resin I'm not quite sure I get what you're talking about. There is nothing hidden about the Resin source. It is downloadable and modifiable. I quote from the website "Modification for your own use is, of course, permitted and encouraged. Distribution of Resin or of works derived from Resin is governed by the license. In most cases, you will need to contact us for the right to distribute." I also dont get the bit about having to deal with licensing issues. They have 3 clearly defined options. The servlet runner is $500 per server regardless of number of CPUs. I dont see this as something that is hard to deal with.Then IBM should release an LGPL implementation of the JVM and class libraries, and everyone should use that. As things stand now, Sun has control, and they have demonstrated that they cannot be trusted.

IBM can't release an LGPL implementation. They dont own Java.

I just read the section of the FAQ that you mentioned and I see accusations with no proof to back them up. The person who wrote that needs to provide a list (or at least a subset of a list) of what exactly requires native calls. Mind you I'm not saying that the situation doesnt exist but hes hardly being credible by stating it and not providing examples. Its obvious that Java is more than just the VM. You have to have native code in order to get at the file system and things like that.

Re:Java

[alan_d_post]

> They mentioned using Perl's OO features. Yuck.

Have you actually written Perl programs with lots of classes? It's a bit ugly, but not that bad. I actually kind of *like* how exposed the mechanics are. It is a pain to have to write the extra line of code in the constructor to bless the reference, but that's all it is: one line of code. Not the end of the world.

> Tomcat is a reference and not something that should be put into production

It certainly seems that way. I find that very disappointing.

> There is nothing hidden about the Resin source. It is downloadable and modifiable.

Wow, you are right about this! I will start agitating for further consideration of Resin. Thanks for pointing that out.

> IBM can't release an LGPL implementation. They dont own Java.

Do you mean there are patent issues, or trademark issues, or what? Even if they had to call it JNJ (JNJ's Not Java), what's to stop them from writing the program? Clearly, copyright law bars them from using Sun's code, but that's not what I'm proposing.

> I just read the section of the FAQ that you mentioned and I see accusations with no proof to back them up.

(warning: sarcasm)
Sure, those people are reimplementing all of Sun's libraries simply for the pleasure of doing so.
(end of sarcasm)

There were actually two projects working on that (GNU Classpath and the GCJ people at Cygnus) but they have merged efforts now.

Re:Java

[ChannelX]

>They mentioned using Perl's OO features. Yuck.

>Have you actually written Perl programs with lots of classes? It's a bit ugly, but not that bad. I actually kind of *like* how exposed the mechanics are. It is a pain to have to write the extra line of code in the constructor to bless the reference, but that's all it is: one line of code. Not the end of the world.

Honestly I've hardly done a thing with Perl's OO stuff. Seems pretty pointless when there are other languages available with OO features that aren't just grafted on. If I were gonna have to do something that required objects that required a scripting language I'd probably use Ruby.

> Tomcat is a reference and not something that should be put into production

It certainly seems that way. I find that very disappointing.

I don't. They have never intended it to be a production-level piece of software. It certainly is getting better but I'd rather pay a modest fee for something like Resin or Orion. Then again there is always JBoss with Jetty.

> I just read the section of the FAQ that you mentioned and I see accusations with no proof to back them up.

(warning: sarcasm)
Sure, those people are reimplementing all of Sun's libraries simply for the pleasure of doing so.
(end of sarcasm)

There were actually two projects working on that (GNU Classpath and the GCJ people at Cygnus) but they have merged efforts now.

Maybe I wasn't clear. I'm not saying those issues don't exist. What I'm saying is that its goofy in an article to mention something like that without at least giving some examples of what you're referring to. When people read that sort of thing they tend to want proof. A few links or something would go a long way.

Re:Java

[Beliskner]

You would not use Perl on the same types of applications you'd use Java on (or for that matter C++). I think Java's best space is in enterprise-level applications. I dont see Perl being all that useful there nor C++ and with Java its much easier to have stuff co-exist on different platforms. You definitely get trade-offs for that.

Correct. Persistant objects (no process fork()) make scalability under Java much better as you can use one shared object as for example a cache. This has been covered by an excellent article before here

Download

[DutchSchultz]

Has anyone been able to download the Carrot tarball? The FTP server gives me "Login incorrect" when I try to login as anonymous user.

Re:Download

[cyborch]

I have mirrored the tarball here.

No no no...

[ttfkam]

Once again, there is far more variance in programmer ability (judicious use of algorithms and patterns) than is inherently demonstrated by language choice.

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. ...and the JVM is faster than the Python VM.

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

Yea, Um, couldnt you feel the sarcasm dripping ??

[rudy079]

nt

cgi is not allways faster

[tokiko]

on some simple pages, an interpreter will be faster than fork&exec needed by a cgi program

Java is compiled in JSPs anyway

[Anonymous Coward]

So why not C++?
The speed is simply too attractive to pass up.
You can host more HTTP sessions per server due to the reduced memory and CPU of C++.

Welcome to the recession

[Beliskner]

There is a far greater variance in programmer ability than the inherent speed traits of a particular language.

Welcome to the recession, expert programmers in every language are on the sidewalks now :-( So with proper hiring, there is no variance any more.