Slashdot Mirror

--/ APOLOGIES /----
Please accept my apologies if I have spoken too harshly about Java. I have
not meant to insult you nor anyone who uses Java. I have not said Java
should not be used at all, nor that Java coders are morons. All I have
commented is that Java has worst starting times hence speed is not Java's
cup of tea, pardon the pun.

Before I make another error at offending you yet again: lets review the
discussion that has sparked this thread to maybe a conclusion in agreement:

--/ REVIEW /----
the original question: 'What does C/C++ do that Java does not??'. The
answer was 'Device Drivers'. to which you wrote quite properly that
\ Java can handle "soft" realtime just fine, and extensions are being
\ worked on for "hard" realtime support. And yes, some people actually
\ write device drivers in Java.

to which I have replied, to quote myself:
\ if java can not even simply start fast, how can it be speedy?

now, to get to crux of the problem, you eloquently have stated:
\ You are comparing a Virtual Machine platform designed to optimize large
\ and long running programs, against simple scripting languages? With a
\ Hello World program no less!

--/ THE RESPONSE - AKA : MEA CULPA , REALLY ? /----

Yes, Java Virtual Machine by itself is quite of a beast, but there are
reasons for that. JVM is large because it has many methods to optimize
the code as its running it. JIT (Just In Time) will reorder code based on
current code profiling to avoid branch misspredictions, wasted hardware
registers, etc. In some cases JVM/JIT can optimize the code its running
so well that it rivals unprofiled C/C++ code.

This is also where Java really shines, RAD world, not the actual program
execution time. Speed was never part of the Java's equasion, and you
yourself comment on that with:
\ tradeoffs programmers must make in order to make things fast, small, or
\ "abstract". Hint: It's a lot like Physics. You don't get something for nothing.
There are tradeoffs. Some need fast execution, while others will go after
clean code developed quickly that runs within required timeframe.

And although Java can do realtime device drivers its not really good at
it, kinda like PHP can bind to the GTK.

Some of the problems with JVM/JIT is that it can execute faster benchmarks
because it does not release used memory before benchmark finishes hence
it never incurs the Garbage Collector penalty.

This is quite evident in the Original Shootout comparison:

pure cpu report http://www.bagley.org/~doug/shootout/craps.shtml?x cpu=1&xmem=0
Java is at the top, considering real languages its third, behind the old
and venerable C/C++, not bad, right?

cpu+mem report http://www.bagley.org/~doug/shootout/craps.shtml?x cpu=1&xmem=1

Now we see a different picture, Java uses alot of the ram to avoid Garbage
penalty. C/C++ are still at the top, but now we also have lua (used alot
in games), Perl, Python and Ruby (out of the more well known languages)
that do better than Java.

As others said, doing comparisons between languages is bad, my bad.

now, I do admit to being guilty for delibratelly chosing a statistic that
is not in Java's favour at all, quite opposite to that, and for this
'manipulation' I am guilty. I am also guilty for overstating that Java is
the worst of them all, obviously Java is not as bad as I have made it
sound. However I stand by that Java is not as efficient as other Languages.
I stand by that Java slow JVM startup is an indication to not being best.

--

--/ APOLOGIES /----
Please accept my apologies if I have spoken too harshly about Java. I have
not meant to insult you nor anyone who uses Java. I have not said Java
should not be used at all, nor that Java coders are morons. All I have
commented is that Java has worst starting times hence speed is not Java's
cup of tea, pardon the pun.

Before I make another error at offending you yet again: lets review the
discussion that has sparked this thread to maybe a conclusion in agreement:

--/ REVIEW /----
the original question: 'What does C/C++ do that Java does not??'. The
answer was 'Device Drivers'. to which you wrote quite properly that
\ Java can handle "soft" realtime just fine, and extensions are being
\ worked on for "hard" realtime support. And yes, some people actually
\ write device drivers in Java.

to which I have replied, to quote myself:
\ if java can not even simply start fast, how can it be speedy?

now, to get to crux of the problem, you eloquently have stated:
\ You are comparing a Virtual Machine platform designed to optimize large
\ and long running programs, against simple scripting languages? With a
\ Hello World program no less!

--/ THE RESPONSE - AKA : MEA CULPA , REALLY ? /----

Yes, Java Virtual Machine by itself is quite of a beast, but there are
reasons for that. JVM is large because it has many methods to optimize
the code as its running it. JIT (Just In Time) will reorder code based on
current code profiling to avoid branch misspredictions, wasted hardware
registers, etc. In some cases JVM/JIT can optimize the code its running
so well that it rivals unprofiled C/C++ code.

This is also where Java really shines, RAD world, not the actual program
execution time. Speed was never part of the Java's equasion, and you
yourself comment on that with:
\ tradeoffs programmers must make in order to make things fast, small, or
\ "abstract". Hint: It's a lot like Physics. You don't get something for nothing.
There are tradeoffs. Some need fast execution, while others will go after
clean code developed quickly that runs within required timeframe.

And although Java can do realtime device drivers its not really good at
it, kinda like PHP can bind to the GTK.

Some of the problems with JVM/JIT is that it can execute faster benchmarks
because it does not release used memory before benchmark finishes hence
it never incurs the Garbage Collector penalty.

This is quite evident in the Original Shootout comparison:

pure cpu report http://www.bagley.org/~doug/shootout/craps.shtml?x cpu=1&xmem=0
Java is at the top, considering real languages its third, behind the old
and venerable C/C++, not bad, right?

cpu+mem report http://www.bagley.org/~doug/shootout/craps.shtml?x cpu=1&xmem=1

Now we see a different picture, Java uses alot of the ram to avoid Garbage
penalty. C/C++ are still at the top, but now we also have lua (used alot
in games), Perl, Python and Ruby (out of the more well known languages)
that do better than Java.

As others said, doing comparisons between languages is bad, my bad.

now, I do admit to being guilty for delibratelly chosing a statistic that
is not in Java's favour at all, quite opposite to that, and for this
'manipulation' I am guilty. I am also guilty for overstating that Java is
the worst of them all, obviously Java is not as bad as I have made it
sound. However I stand by that Java is not as efficient as other Languages.
I stand by that Java slow JVM startup is an indication to not being best.

--

I believe that it has been demonstrated that not all functional languages are slow.

I believe that it has been demonstrated that not all functional languages are slow.

From comments Doug Bagley made about the "Shootout" (where the benchmarks came from), no, I don't think it is an accurate comparison, or at least a conclusive comparison between C++ and Java. His comments from his conclusion:

I put it on the web because I thought it would interest others. Even though I put disclaimers on the page, and I try not to make any claims, I see some people say the shootout shows that "language X is faster than language Y".

That claim is probably premature and hence, bogus. I suppose you could make the claim that, in "Doug's word frequency test, on a PII-450 running Linux 2.4, given a certain input, language X is faster than language Y" Assuming, of course, that I haven't made any mistakes. Some of my tests are also arguably poorly designed and meaningless. (Hey, if you have some better ideas, please write to me).

Benchmarks are notoriously misleading, and perhaps mine aren't any better, although I do try. Benchmarks tell you about results in a very specific case. Drawing a general conclusion is problematic.

Working link: LINK

Correct link

The flip side is that before becoming productive one has to get used to a whole new way of thinking about problems: immutable data, everything is a function evaluation, no sequential statements, no side-effects, rely on recursion as much as possible, especially tail-recursion. But ocaml isn't religious about it: it has imperative features, including for and while loops, sequential statements (essentially successive function calls with side-effects and null output), and so on. After a while, though, you find you hardly need any of that. Maybe it's just me, but the sort of work I do is well suited to the functional approach. Also, it has a rich set of data structures and is pretty much agnostic about them: you can use linked lists, hashes, mutable arrays or records, sets, whatever suits your purposes.

The other drawback is the libraries (modules) aren't as complete as the Perl and Python equivalents (though far ahead of most other competition). I imagine that will get cured with time.

Well, what's your point? Yes, lisp is pretty fast, and as it seems like its optimization mechanisms are rather advanced, it is exactly lisp's dynamic nature that makes it not as fast as static compiled languages. But why lisp, python and lisp are too different beasts to even compare them, and I'm not a lisp guru to do this either.. If we talk about static/dymanic, this is not a boolean attribute of a language, it is an attribute of different things within execution enviroment. In this sense, python is more dynamic that lisp.. Plus, python doesn't seem to be designed with performance in mind.

Lisp is fast, when you add type annotations (optional) to variables and then compile, without it it is not that fast.

take a look at this language comparison, and of course the (flawed, but still not worthless) great shootout. or just google for "optimization" on comp.lang.lisp.

If you used ocaml instead of Guile, you could make your simulations finish in 1 minute...

(for people who don't know just how slow Guile is: take a look at e.g. the shootout

I'm sorry, but I think you're nuts.

Not to specifically knock the other choices you mention, but I think plenty of people feel that PHP has a far less annoying and convoluted syntax than say Perl or Lisp, which you seem to be advocating instead of PHP.

And you say you have a "superficial familiarity" with PHP, yet knock PHP for a lack of Speed... Try it, you might be surprised (especially if you use a compilation cache like Turck MMCache). Why do you think every other random interpreted language is going to be way faster than PHP?

The only point I won't argue strongly is the security aspect. I don't think PHP is as bad as everyone is claiming if it is set up properly, but it isn't perfect - in particular too many ease-of-use features have been added that can chuck any semblance of security right out the window...

The language shootout page gives an idea - it's up there with Java!

in a lot of higher-level languages, eg functional languages like lisp, haskell and ocaml. But not only debugging: in these languages you tend to write code that doesn't have bugs in the first place. No need for mallocs, no buffer overflows, no memory leaks. And if you're careful to write in a functional style, no "side-effect" bugs (variables that change value when you weren't expecting them to). For a language that started out in the 1950s, it's amazing how far ahead it was and still is as a development environment. This paper is a fascinating read, especially the section on Worse is better that describes why Unix/C won. And there are other languages like the ML family and Haskell. OCaml (Objective Caml, a descendant of ML) is as concise and elegant as python, but produces native-code binaries quite competitive in speed with C, and occasionally faster. I'm wondering why anyone uses C-like languages anymore.

Take a look at the great language shootout. It depends what you're doing of course but my general impression from the figures supplied here is - PERL is significantly faster than PHP for most algorithms. There are a myriad of entirely reasonable criticisms you can make of PERL, I don't think this is one of them though.

Thanks for the link. I always like to look at what other people have tried. However, I highly doubt those results. Besides, C++ still came out on top.. eh?

For one thing they don't really test anything useful as the tests are just tight loops of very basic math stuff. His C code doesn't even compile with the VC++ compiler because he's using C99 syntax (Microsoft's compiler is not C99 compliant). And even when I fixed those problems there where a lot of warnings due to questionable variable usage. The C++ version isn't even written in C++, I wonder why there are even two separate files. Not a good start and makes me seriously question this programmers abilities.

Just a quick glance at the code suggests at least the trig benchmarks are more a test of the standard math library rather than the language. C# is going to use the same version as C/C++.

His timing methods are also questionable. Using CPU time can be highly inaccurate. It's much better to use the high precision timing functions.

I will need to take a more detailed look and do some testing of my own to see if these results are valid. Off the top of my head I will say there seems to be something screwy going on because I've never seen properly written code run faster in C#. It's just not possible. C and C++ are so close to the hardware that when written properly it is near impossible to make it faster without going to assembly. The best C# can hope for is something close to C/C++, but never better.

I'll make another post if I get time to take a more detailed look but I'm not optimistic about these tests being worth anything. Try the Language Shootout (or the win32 version) benchmarks for broader benchmarks where a lot of them have actually been looked at by programmers that know what they are doing. If you know what you are doing then you might want to really try them, don't just go by the results on the pages because some of them are skewed because the run times are way too short to be meaningful.

Again, I ask you to design a vector class in C# that uses the same or less memory than C++ and performs the same or better. It's not even close to possible.

The OCaml variant of the very strongly typed languages of the ML family is not only extremely elegant, like Lisp and Scheme, but is extremely fast.

Just to bring you up to date:

Has reflection since they adopted the Eiffel Library Kernel Standard. This standard proposes the strictest and most comprehensive interface for reflection of any other OO language.

You're right, EiffelStudio is still far beyond SmartEiffel.

SmartEiffel did very well in the The Great Language Shootout back in 2001. I haven't seen any recent benchmarks but I do know that efficiency is a very high priority.

Eiffel is very much an open language. The ECMA committee is about to finish the written standard. Furthermore there has been NICE since about 1991. To say that it has been driven by Meyer's whims is to say that C++ has been driven by Stroustrup's whims. Sure they are instrumental in driving the standard, but they are not whims. Most people complain about Eiffel's lack of whims! The development of the Eiffel language has been the most structured of any I know.

I thought requirement for global type checking was a good thing.

Since when is covariance a serious problem! Covariance allows a lot of expressiveness and power. I think what you are referring to is CAT calls (Changed Availability and Type). Eiffel has an extremely tight type system, and this is a current hole in it. The hole is about half as wide as providing the ability to type cast.

Eiffel has method pointers and so much more. It has agents(chapter 25 from OOSC) which are functions treated as objects. Agents get all the benefits of objects including static typing, introspection, copying, comparison, etc. Furthermore agents support deferred parameters.

I do think C# is good, most likely because it has learned a lot from Eiffel. You won't see any direct mention of Eiffel in this article. However the style of generics and contracts are both Eiffel originals. Also Bertrand Meyer is part of the C# ECMA committee.

See JWZ's rant about Java.

Now, here's what Python has that Java doesn't:

• Local functions,
• lambdas,
• "everything is an object",
• automatic invoking of getter-setter methods,
• static methods are really class methods (and not merely global functions),
• two (byte, or otherwise) arrays compare equal if they have equal contents (and therefore they also work fine in hashtables),
• separate types but common interface for ascii and unicode strings,
• multiple inheritance (programmers are not dumb),
• weakly typed (solves 4-5 of his problems),
• methods don't really "belong" to classes (in his terminology),
• printf-like formatting is supported :-)

Actually, J2SE 1.5 already fixes a lot of these things in Java.

About static typing: Bruce Eckel very recently wrote about what he thinks about Python's typing, what he refers to as "latent typing". See my related blog entry.

We've started believing that static typing has a low benefit/hassle ratio.

See also: The Great Computer Language Shootout. (Python comes out way too bad in performance.)

Each time somone talk about moving from C to some others languages, we heard about C++, C# or Java. All are kind of OOL, but whatabout typed functionnal programming languages ?

I'm using OCaml every day, for many things (in the CDuce interpreter, see www.CDuce.org, but also in other coding projects.) And it is fast (nearly as C, just take a look at this language benchmark), it is in some way safe (the famous : "Well typed programs cannot go wrong"), it has a good interaction mechanism with C librairies, programs can be compiled in native or in bytecode, OCaml native code compiler is giving very good result on many arch/OS ...

And, speaking about gnome, there's also a "wrapper" for GTK and GTK2 (called lablgtk and lablgtk2.)

Thus, there's a MASSIVE performance loss when a functional programming language is executed on any of the existing processors. Because the compilers can't think and optimise the code to best fit the imperative model. Where as the human being s can. That's why we should stick to imperative programming languages.

• Count Lines/Words/Chars
• String Concatenation
• Word Frequency
• Hashes

• Count Lines/Words/Chars
• String Concatenation
• Word Frequency
• Hashes

• Count Lines/Words/Chars
• String Concatenation
• Word Frequency
• Hashes

• Count Lines/Words/Chars
• String Concatenation
• Word Frequency
• Hashes

• Count Lines/Words/Chars
• String Concatenation
• Word Frequency
• Hashes

• Count Lines/Words/Chars
• String Concatenation
• Word Frequency
• Hashes

The types of performance problems you're talking about are orders of magnitude away from the performance problems that users percieve when using Java applications though.

I disagree here.

Think of Moore's law, processor speeds, etc... Java is a fast enough language for doing just about anything a user needs to do. Even if java were only 25% as fast as native code, that would be 2 cycles of Moore's law, 36 months, 3 years ago. (And, java is much faster than 25% of C, check here)

3 years ago, users were all doing the same things they are doing today.

A couple of exceptions apply, of course: scientific computing, games, etc, tax the hardware pretty heavily.

But, the primary reason that Java is perceived as slow by users is the terrible speed of the GUI.

All the widgets are implemented in Java directly. This is almost like the same exception as game software, since all this rendering code involves moving around lots of memory, etc...

The GUI matters more than anything to user perception of slowness.

An old 14mhz 68000 amiga often "felt" faster than a 50mhz 386, because the amiga's os/gui were very responsive, while the 386 was running win3.1

Look at the recent developments with the linux kernel. Compare X responsiveness with a preemptible low-latency kernel, and how the whole machine "feels" better.

By going with preemption and low-latency, the overall throughput of the machine is actually slightly slower. But it feels loads better.

C# and the .NET framework use native code libraries for the GUI. It will never have the same perception of "slowness" that java has.

Go find out for yourself at The Great Computer Language Shootout. Although now a bit dated, it covers *way* more than this OSNews aritcle. They even have a page where you can wieght the various benchmarks here.

It's a real eye opener about supposedly "research" languages, and a great source of examples of how simple things are done in various languages. For me, in my work on Robotics/Vision/Graphics/Games, it told me what I already knew: C/C++ are the bomb (for what I do). If I ever start using a more featureful language, it will be OCaml (typcially, the feature sets of functional languages make the C/C++/Java and similar languages look like a joke. Only numerical speed saves C/C++, and only the vast libraries save Java.) The adjustable benchmark weights are great though, because they let you look at what *you* care about.

Go find out for yourself at The Great Computer Language Shootout. Although now a bit dated, it covers *way* more than this OSNews aritcle. They even have a page where you can wieght the various benchmarks here.

It's a real eye opener about supposedly "research" languages, and a great source of examples of how simple things are done in various languages. For me, in my work on Robotics/Vision/Graphics/Games, it told me what I already knew: C/C++ are the bomb (for what I do). If I ever start using a more featureful language, it will be OCaml (typcially, the feature sets of functional languages make the C/C++/Java and similar languages look like a joke. Only numerical speed saves C/C++, and only the vast libraries save Java.) The adjustable benchmark weights are great though, because they let you look at what *you* care about.

The Great Computer Language Shoot-Out compares many more languages in a variety of benchmarks, although it doesn't have C# yet. The key thing to note is that high-level compiled languages like ML or Scheme perform slower than C, but much much faster than interpreted scripting languages like Perl.

This benchmark strongly favours languages compiled to native code. A much better place to seek language comparisions is The Great Language Shootout, even if it hasn't been updated for 2 years or so. (There's a more up-to-date version, albeit Windows-oriented, at The Great Win32 Language Shootout.)

Dynamic web pages are slow in general, which is probably what the original post was referring to.

PHP is also fairly slow as a language; it was the second slowest language in Doug Bagley's computer language shootout, only winning over shell scripting.

Not that I think the shootout is a particularly good comparison in terms of methodology, but it seems fairly consistent with my own experience with the languages.

Of course raw performance isn't always the most important, Erlang isn't very fast, but has fairly impressive multithreading. Of course Oz and Concurrent ML have even faster multithreading, and the latter is also fast as a language.

Which is more productive ?(lines of code)

Which uses less resources ?

Which is faster ?

Here are some benchmarks for all the java zealots. Hurry before the evangelists censor this message!

Did you check out The Great Computer Language Shootout? O'Caml beat C++ in terms of speed, memory usage AND lines of codes (less == better), yet O'Caml does not allow the programmer to do explicit memory management.

Java is cheap (free), multipurpose, and difficult to learn to use well, but suitable for large applications.

Perl is cheap (free), multipurpose, and easy to learn to use, but difficult to create large, maintainable apps with (subject to change with Perl 6?)

First of all, your "easy to learn" comparison is asymmetric: you didn't include the term "well" in the Perl version. Secondly, I, personally, think that Java is easier to learn than Perl. I also don't think I'm the only one who thinks so.

As far as how a program performs, unless you're doing a lot of FP math, most small programs of similar function written by programmers of similar skill in a given language will be fairly even, performance-wise.

Though I'm not sure what you mean by "small programs", but the "Great Computer Language Shootout" suggests a high amount of variation between languages (language implementations, actually) for very small programs.

... can process Java code that's not a bit slower than native Java on Windows.

Orrr ... They can just stick with mod_perl or WebWare for Python or PHP or some other truly open source technology that isn't controlled by forty-thousand corporations all with an invested business interest in competing with Microsoft.

I swear to God, every time I hear a phrase like "suited to the Enterprise" it's accompanied by a Java, Microsoft, or IBM article, all of which have a huge interest in convincing you that in order to sell a widget on the Internet you've absolutely, no-question, gotta have nineteen layers of logical infrastructure completely independent of each other otherwise your site's gonna go down and boy are you going to pay. In the meantime, sites like Yahoo run their e-commerce off of Lisp, PHP is their standardizing implementation language, Amazon is hiring Perl programmers, and Slashdot, a site which regularly DOSes other sites by virtue of it's power to link, runs on Perl.

But if you really want to be successful YOU NEED JAVA FOR THE "ENTERPRISE". Only with Java can you take half the time to express what takes twice as much typing to code. Or maybe by "Enterprise" what everyone really means is the USS Enterprise? Maybe that's why it could max out to warp 7.

i think you're talking about the python/java programmer *you* know. all else being equal, a statically-compiled language is always going to beat a dynamic language.

take look at this and weep at python's inferior performance compared to perl, let alone to java.

Of course ppl troll python's use of whitespac-as-syntax -- it's python's use of whitespace that makes it slower than perl for every single task tested.

Let's see, these translation system require about one gigabyte of two-way translated text to train. They get them from gouvernemental diaries from bilingual countries and from online bilingual newspapers.

Where would you find one gigabyte woth of manually translated code to train with? The Great Programming Language Shootout and the 100 bottles of beers page together hardly add to one gigabyte.

Coding a compiler to translate between coding languages is much easier then manually translating one gigabyte worth of code. Plus the compiler will always give correct result (modulo bug), whereas the statistical approach is merely "likely" to be correct.

Sorry to burst your bubble.

• Ocaml: The syntax is butt-ugly, and it seems arbitrarily difficult to do things that should be easy. Any intuition gained from C-like languages will be useless here.
• Python: I hate looking at/typing indented languages.
• Ada: I haven't found easy documentation on how to install gcc 2.81 then patch gnat into it on a system with another gcc version. I haven't yet gained the 31337 ski11z to know what I might break during this process, and since Ada is an indented language with syntax I really don't like, I wasn't motivated to pursue it. I understand, however, that Ada has some superb features that make it better than C for applications that can't ever crash and comparable running times. I'll probably eventually get gnat installed and learn Ada.
• Java: It runs too slow. I know Java already, but I never use it for anything. Everytime I sit down to do something in Java, I feel like I'm throwing away my time. Also, the standard library is far, far too bloated, and digging through the ancestry of some classes is a royal pain in the ass.
• C++: It's a lot like C, but with more bullshit. If I need a low-level language, I can use C. If I need a high-level language, I can use Perl or Ruby. I've learned some C++ too, and that quote that C++ is "an octopus made by nailing extra legs onto a dog" seems very true.
• Lisp: Again, I dislike the syntax. Too many parenthesis. Also again, I understand that Lisp has some nice features that make it very useful.

Actually, in this test, OCaml ranked 2nd in speed between C and C++. (The test might not be the best, but still it may be significant)

Actually O'Caml is a functionnal AND imperative AND OO language. It's also very optimized (during byte-code interpretation and native code execution). See The Great Computer Language Shootout. I hope that those guys at Microsoft are working hard to reach this level of performance ...

I'm speaking from both experience and benchmarks. It's startup time is hideous, far worse than perl/python/bash/clisp, which are all interpretted languages (well, perl and python convert to bytecode internally, but they have to do it every time they run). It's overall performance is painful. The Great Computer Language Shootout places it between common lisp and python in overall performance (though dead last by a wide margin in startup cost). These are interpretted languages, so the bytecode excuse doesn't fly. One thing the shootout doesn't mention is GUIs. Java GUIs (whether AWT or SWING) are too slow for practical use (from my personal experience at least).

I suspect that Java's problem is that it uses itself too much. When I run a graphical app in python, the routines that actually paint individual widgets are written in C. When I use Java, they're written in Java. This gets it some improved portability, but at a serious performance cost. Considering that there are probably no more than a few dozen operating systems currently in significant use (and fewer than ten if all UNIXen are counted together), this was a bad move.

Truth be told, though, Java is a much greater memory hog than Haskell (LISP isn't even worth mentioning), probably due to Haskell's lazy evaluation.

PHP is designed more for database applications

No, PHP was designed (and I use that term loosely) to make dynamic web pages, and the database functions were - like most of PHP - thrown in as an afterthought, unlike perl's DBI, which was designed to be OO and have a consistent interface.

although it can be extended (like Perl) to do a lot more. The routines PHP uses for database management have been thoroughly refined and optimized to achieve maximum speed

That's content-free. All languages can be extended, even Visual Basic, and they all (except perhaps INTERCAL) claim that their libraries have been "thoroughly refined and optimized to achieve maximum speed." Of course, some do better than others (see Doug's shootout).

I believe it is generally accepted that for databasing, using PHP will result in faster, more streamlined, and smaller code.

And I believe the earth is flat, but it isn't. Or, BZZZT, WRONG (zero for three)! And databasing? PHP isn't neither particularly fast nor compact.

Sad but true: PHP sucks. It's a half-assed attempt by some lame twits to make a programming language for non-programmers, which is sort of like trying to make a car for non-drivers. Whether they succeeded or failed at that goal, we all still lose, because of the horrible proliferation of all the crap PHP scripts on the world.

Dijkstra would probably revise his famous quote for PHP's benefit to: It is practically impossible to teach good programming style to students that have had prior exposure to PHP; as potential programmers they are mentally mutilated beyond hope of regeneration.

czth

Haskell an implementation of Church's lambda calculus, a form of mathematical logic. There are compilers, which generate code comparable (within 20-50%) with c and a large number of mathematics packages. compare
Check it out!

I like Python more than I like Java. Still, in terms of speed (ignoring how much memory it takes), Java is faster.

It's not just the benchmarks that say it either. The creator of Python, Guido Van Rossum, says it as well.

"The best approach is often to write only the performance-critical parts of the application in C++ or Java, and use Python for all higher-level control and customization."

That quote is taken from here.

I was going to ask if there were any performance comparisons around showing how Watcom performed, but then I realised that anyone with half a brain ran something through Google before Slashdot.

Win32 compilers (not including Watcom - and with good reason, it's a bitch to set up on Win32)

as linked from the djgpp FAQ, some info on DOS compilers.

So, hooray! A lesson in using Google before Slashdot mixed with some blatant karma-whoring.

PS. this is good too.

Gotta copy and past that URL. If it sees a /. refer(r)er it goes to:

http://www.bagley.org/~doug/shootout/slashhole.sht ml