java anstelle von perl

[Monty Burns]

hi

hab gehöhrt das häufig java auf webservern zum einsatz kommt
was für vorteile bringt das? (abgesehen von geschwindigkeit?)

kennt jemand seiten die sich mit java im einstaz auf apache servern oder ähnlichem beschäftigen?

wär nett wenn jemand vieleicht ein paar infos hätte

gruss

Monty Burns

P.s.: ich weiss das es google gibt aber vieleicht kennt ja jemand ne seite mit der er slbst gute erfahrungen gemacht hat

[Sven]

Hallo Monty Burns,

hab gehöhrt das häufig java auf webservern zum einsatz kommt
was für vorteile bringt das? (abgesehen von geschwindigkeit?)

Ja, angeblich ist Java ins besondere bei Firmen auf dem aufsteigenden Ast.

Tatsache ist folgende: Stell dir vor, du machst was kleines mit nem PHP-Script. du hast dein script, packst es - wenn nötig - in dein cgi-bin, und fertig.

Mit Java musst du ggf. erst mal das "rundherum" schaffen. Dann dein Ding schreiben. Kompilieren. Du hast mehrere Dateien, und es wird umständlich.

Java eignet sich deswegen ggf. hervorragend für große und sehr große Projekte. Allgemein gesehen ist es im wirtschaftlichen bereich (afaik) die Konkrrenz zu M$'s .NET-Konzept.

Im "Mittelstand" wird es sich jedoch wohl kaum gegen sowas wie PHP oder Perl durchsetzten. Und das ist auch gut so.

Gruß,

Sven

[Monty Burns]

hm
ich kann fließend php (wie schwer) und perl kann ich auch recht gut

heisst das das ich am ende der fahnenstange angelangt bin?
gibt es für nen webprogramierer nichts mehr zu lernen?

ich wollt mich eigentlich ein bisschen weiterentwickeln

gibts da draussen nix was ich in angriff nehmen kann?

Monty Burns

Hallo,

jedes Programm das STDIN und STDOUT kann ist zur Webprogrammierung fähig, wenn du das willst, kannst du auch mit batch skripten cgi programmierung betreiben. son zeug wie ruby kannst du dir noch reinprügeln .net mist und so weiter, benutzt mal eine suchmaschine deiner wahl und such.

schüssi

[Slyh]

Hallo,

ich kann fließend php (wie schwer) und perl kann ich auch recht gut

heisst das das ich am ende der fahnenstange angelangt bin?

http://de.wikipedia.org/wiki/Programmiersprachen#Kurze_Zeittafel

Have fun! :-)

gibt es für nen webprogramierer nichts mehr zu lernen?

Was spricht gegen Java? Damit hättest du mal eine moderne objekt-orientierte
Sprache gelernt.

Gruß
Slyh

[Robert Bienert]

hi

Moin!

hab gehöhrt das häufig java auf webservern zum einsatz kommt
was für vorteile bringt das? (abgesehen von geschwindigkeit?)

Ge... was? Kennst du nicht den Spruch, das Java schneller langsamer wird, als Computer schneller? Ich muss schon sagen, dass Perl -- obwohl interpretiert -- schon richtig rockt.

Java wird AFAIK hauptsächlich als JavaServerPage JSP oder Servlets verwendet: JSP soll so etwas wie PHP/PerlEmbed, ... sein, Servlets sind richtige Programme.

kennt jemand seiten die sich mit java im einstaz auf apache servern oder ähnlichem beschäftigen?

http://jakarta.apache.org/, siehe dort u.a. Tomcat.

wär nett wenn jemand vieleicht ein paar infos hätte

Die bestimmt.

gruss

Monty Burns

Ausgezeichnet!

P.s.: ich weiss das es google gibt aber vieleicht kennt ja jemand ne seite mit der er slbst gute erfahrungen gemacht hat

Oh, damit ich noch gar keine Erfahrung gemacht, es soll aber trotzdem gut sein.

MfG, Robert

[Slyh]

Hallo,

hab gehöhrt das häufig java auf webservern zum einsatz kommt
was für vorteile bringt das? (abgesehen von geschwindigkeit?)

Ge... was? Kennst du nicht den Spruch, das Java schneller langsamer wird, als Computer schneller?

Kennst du die Benchmarks, die aufzeigen, daß in 50% der Fälle just-in-time
kompilierter Code schneller ist, als "richtig" kompilierter Code?
Je nachdem was man tut, trifft das bei Java zu.
Im Durchschnitt könnte man sagen, daß Java-Programme gleich schnell
sind wie nativ kompilierte Programme.

Ich muss schon sagen, dass Perl -- obwohl interpretiert -- schon richtig rockt.

Keine Ahnung wie schnell Perl ist. Sicherlich nicht so schnell wie
Java. Jedenfalls würde es mich wundern.
(Zweifellos würde ich von Perl jedoch nicht behaupten, daß es schlecht
ist.)

Java wird AFAIK hauptsächlich als JavaServerPage JSP oder Servlets verwendet: JSP soll so etwas wie PHP/PerlEmbed, ... sein, Servlets sind richtige Programme.

JSP-Dateien werden in Servlets übersetzt, bevor sie kompiliert werden.
Nach deiner Definition sind JSPs also auch "richtige Programme".
(Man kann damit alles tun, was man mit Servlets tun kann. Und mit
Servlets kann man alles tun, was man mit Java tun kann.)

Gruß
Slyh

[Robert Bienert]

Hallo,

Moin!

Kennst du die Benchmarks, die aufzeigen, daß in 50% der Fälle just-in-time
kompilierter Code schneller ist, als "richtig" kompilierter Code?

Welche 50% sollen das denn sein? Java vs. Objective-C auf Windows?

Je nachdem was man tut, trifft das bei Java zu.

Tut mir Leid, aber Java ist höchstens auf meinem Mac _hinreichend_ schnell, obwohl es ins System integriert ist. An (Objective)C kommt auch dort nichts vorbei.

Im Durchschnitt könnte man sagen, daß Java-Programme gleich schnell
sind wie nativ kompilierte Programme.

Komisch, dass das mein Java nicht weiß, vor allem unter Windows. GUI-Programme sind die reinste Katastrophe.

Ich muss schon sagen, dass Perl -- obwohl interpretiert -- schon richtig rockt.

Keine Ahnung wie schnell Perl ist. Sicherlich nicht so schnell wie
Java. Jedenfalls würde es mich wundern.

Dann wunder dich mal schön! Selbst Perl mit Tk (ein Widgetset) ist rein subjektiv schneller als Java.

(Zweifellos würde ich von Perl jedoch nicht behaupten, daß es schlecht
ist.)

In der Tat.

Java wird AFAIK hauptsächlich als JavaServerPage JSP oder Servlets verwendet: JSP soll so etwas wie PHP/PerlEmbed, ... sein, Servlets sind richtige Programme.

JSP-Dateien werden in Servlets übersetzt, bevor sie kompiliert werden.

Aha, ich wolle schon immer mal wissen, was das genau ist, evtl. kann man damit später mal Geld verdienen (deshalb kann ich auch C++, nicht aus Spaß an der Freude).

Nach deiner Definition sind JSPs also auch "richtige Programme".

Wie jetzt? Unter gewissen Umständen gibt es auch PHP-Programme.

Gruß
Slyh

Jo, Robert

[Slyh]

Hallo,

Kennst du die Benchmarks, die aufzeigen, daß in 50% der Fälle just-in-time
kompilierter Code schneller ist, als "richtig" kompilierter Code?

Welche 50% sollen das denn sein? Java vs. Objective-C auf Windows?

Ich redete nicht von einer Programmiersprache, sondern von just-in-time
kompiliertem Code.

Einstiegs-Lektüre:
http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
Des weiteren:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=rnripv04hr3v79bfmbnv3pfo0up2s0tjm8%404ax.com&rnum=1

Je nachdem was man tut, trifft das bei Java zu.

Tut mir Leid, aber Java ist höchstens auf meinem Mac _hinreichend_ schnell, obwohl es ins System integriert ist.

Auf dem Mac ist es auch nicht weiter integriert als in jedem anderen
Betriebssystem.

An (Objective)C kommt auch dort nichts vorbei.

S.o.

Im Durchschnitt könnte man sagen, daß Java-Programme gleich schnell
sind wie nativ kompilierte Programme.

Komisch, dass das mein Java nicht weiß, vor allem unter Windows. GUI-Programme sind die reinste Katastrophe.

Swing ist nicht wirklich schnell. Das ist bekannt.
Wir reden hier von Java, nicht von einer ausgewählten Komponente der JFC. Wenn du eine schnelle Java-Anwendung sehen möchtest, dann lade
dir Eclipse runter. Das verwendet ein natives Widget-Set, das aber
vollständig in Java programmiert wird.
Und wenn du dir dann noch den Eclipse-Code anschaust, und nachsiehst
welche Menge an Operationen dort intern schon bei den kleinsten
Aktionen abläuft, wirst du sehr schnell merken, daß Java überhaupt
nicht langsam sein kann!

In der c't wurde mal das Laufzeitverhalten von Java mit dem von Delphi,
C++ und C# verglichen. Du möchtest c't 19/03, Seite 204 und c't 21/03,
Seite 222 dazu konsultieren.

Zu den "Test-Methoden" gab es von verschiedenen Seiten heftige Kritik.
Nachzulesen u.a. unter:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=blpcjl%24f2r7t%241%40ID-3551.news.uni-berlin.de&rnum=1
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=bjd7i5.9s.1%40aljoscha-rittner.de&rnum=1
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=blpn91%24m7s%241%40newsreader2.netcologne.de&rnum=1
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=20031016080605.3aa08eb1.spam%40scott-net.de&rnum=1
http://www.heise.de/ct/foren/go.shtml?read=1&msg_id=4318247&forum_id=2

Da gab's noch mehr. Das finde ich auf die Schnelle aber nicht.

Keine Ahnung wie schnell Perl ist. Sicherlich nicht so schnell wie
Java. Jedenfalls würde es mich wundern.

Dann wunder dich mal schön! Selbst Perl mit Tk (ein Widgetset) ist rein subjektiv schneller als Java.

Das ist sicherlich zu bezweifeln. Vielleicht kannst du ja einen
glaubwürdigen Vergleich irgendwo auftreiben...

JSP-Dateien werden in Servlets übersetzt, bevor sie kompiliert werden.

Aha, ich wolle schon immer mal wissen, was das genau ist, evtl. kann man damit später mal Geld verdienen (deshalb kann ich auch C++, nicht aus Spaß an der Freude).

Was meinst du mit "das" genau?

Nach deiner Definition sind JSPs also auch "richtige Programme".

Wie jetzt? Unter gewissen Umständen gibt es auch PHP-Programme.

Was?
Du schriebst, daß Servlets richtige Programme seien. Natürlich sind
sie das. Genau wie JSP- oder PHP-Programme richtige Programme sind.
Daß sie nur innerhalb einer bestimmten Umgebung (sinnvoll) ausführbar
sind, ist eine völlig andere Geschichte.

Gruß
Slyh

[Robert Bienert]

Hallo,

Moin!

Kennst du die Benchmarks, die aufzeigen, daß in 50% der Fälle just-in-time
kompilierter Code schneller ist, als "richtig" kompilierter Code?

Fest verdrahteter Code ist noch schneller ;-)

Welche 50% sollen das denn sein? Java vs. Objective-C auf Windows?

Ich redete nicht von einer Programmiersprache, sondern von just-in-time
kompiliertem Code.

Ich merke schon, du kennst Objective-C nicht! Der OOP-Teil der Sprache ist SmallTalk, d.h. _zur Laufzeit_ werden Teile des Programmes durch einen SmallTalk-Interpreter gejagt.

Einstiegs-Lektüre:
http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
Des weiteren:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=rnripv04hr3v79bfmbnv3pfo0up2s0tjm8%404ax.com&rnum=1

OK, bin ich für diese Diskussion nicht wirklich schlau draus geworden, aber der Link wars wert.

Je nachdem was man tut, trifft das bei Java zu.

Tut mir Leid, aber Java ist höchstens auf meinem Mac _hinreichend_ schnell, obwohl es ins System integriert ist.

Auf dem Mac ist es auch nicht weiter integriert als in jedem anderen
Betriebssystem.

Stimmt, in Windows hat es M$ herausgenommen, an Stelle von Schrott Net (das beste ist immer noch J#).

[...] wirst du sehr schnell merken, daß Java überhaupt
nicht langsam sein kann!

Ich weiß, mein Rechner ist nur zu langsam.

In der c't wurde mal das Laufzeitverhalten von Java mit dem von Delphi,
C++ und C# verglichen. Du möchtest c't 19/03, Seite 204 und c't 21/03,
Seite 222 dazu konsultieren.

Gibt es die online? Bin eher der iX-Abonement.

Keine Ahnung wie schnell Perl ist. Sicherlich nicht so schnell wie
Java. Jedenfalls würde es mich wundern.

Dann wunder dich mal schön! Selbst Perl mit Tk (ein Widgetset) ist rein subjektiv schneller als Java.

Das ist sicherlich zu bezweifeln.

Probier es mal aus. Warum sonst wird Perl so häufig benutzt? Nicht nur wegen der ästhetischen Syntax. Ich weiß nicht, was Larry Wall für Optimierungen eingebaut hat, aber mein 1 GHz Rechner führt Perl _subjektiv_ schneller als Java aus.

Vielleicht kannst du ja einen
glaubwürdigen Vergleich irgendwo auftreiben...

Müsste ich mal messen.

JSP-Dateien werden in Servlets übersetzt, bevor sie kompiliert werden.

Aha, ich wolle schon immer mal wissen, was das genau ist, evtl. kann man damit später mal Geld verdienen (deshalb kann ich auch C++, nicht aus Spaß an der Freude).

Was meinst du mit "das" genau?

Naja, ich weiß jetzt endlich, was es mit Servlets, JSP und dieser Java-als-CGI-Geschichte auf sich hat. Könnte im Berufsleben mal relevant werden (der Kunde ist König).

Nach deiner Definition sind JSPs also auch "richtige Programme".

Wie jetzt? Unter gewissen Umständen gibt es auch PHP-Programme.

Was?
Du schriebst, daß Servlets richtige Programme seien.

Zitat aus der aktuellen iX, in der es eine Unterscheidung zwischen Servlets und JSP gibt, da ich davon aber keine Ahnung habe, kommentiere ich das nicht. Ich habe das halt nur so gelesen.

Natürlich sind sie das. Genau wie JSP- oder PHP-Programme richtige Programme sind.

Verzeih mir die kleine Spitze mit dem Wort "richtig". Viele "ernsthafte" Programmierer sehen PHP nicht als "richtige" sondern als "Kinder"-Programmiersprache an.

Gruß
Slyh

MfG, Robert

[Slyh]

Hallo,

kompilierter Code schneller ist, als "richtig" kompilierter Code?

Fest verdrahteter Code ist noch schneller ;-)

Was verstehst du unter "fest verdrahtetem" Code?

Ich redete nicht von einer Programmiersprache, sondern von just-in-time
kompiliertem Code.

Ich merke schon, du kennst Objective-C nicht!

Ich wiederhole nochmal, was ich schrieb:
"Ich redete nicht von einer Programmiersprache, sondern von just-in-time
kompiliertem Code."

Ich habe kein Wort über Objective-C verloren, da ich es -- und da hast
du unabhängig vom Rest der Aussage recht -- nicht kenne.

DU redest ständig von Objective-C, obwohl das gar nicht das Thema ist.

Der OOP-Teil der Sprache ist SmallTalk, d.h. _zur Laufzeit_ werden Teile des Programmes durch einen SmallTalk-Interpreter gejagt.

Das steht in http://en.wikipedia.org/wiki/Objective_C aber
zum Beispiel nicht. Bist du dir sicher? Habe auch bei Google nichts
in diese Richtung gefunden.

Was hat das jetzt eigentlich genau mit unserem Thema zu tun? :)

[...] wirst du sehr schnell merken, daß Java überhaupt
nicht langsam sein kann!

Ich weiß, mein Rechner ist nur zu langsam.

Nein. Du verwechselst einfach Java mit Swing und gute Programmierer
mit schlechten Programmierern.

In der c't wurde mal das Laufzeitverhalten von Java mit dem von Delphi,
C++ und C# verglichen. Du möchtest c't 19/03, Seite 204 und c't 21/03,
Seite 222 dazu konsultieren.

Gibt es die online? Bin eher der iX-Abonement.

Nein, nicht direkt online. Vielleicht zum Kaufen. Guck nach.

Dann wunder dich mal schön! Selbst Perl mit Tk (ein Widgetset) ist rein subjektiv schneller als Java.

Das ist sicherlich zu bezweifeln.

Probier es mal aus.

Glaub mir. Interpretierte Sprachen sind definitiv und immer langsamer
als kompilierte Sprachen. (Java wird im Speicher kompiliert).
Inwieweit es sowas wie einen JIT-Compiler in/für Perl gibt, weiß ich
nicht. Deshalb möchte ich da keine Aussage treffen.

Du kannst davon ausgehen, daß Java schneller ist.

Warum sonst wird Perl so häufig benutzt?

Das beantwortet dir wohl jedes Perl-Buch in der Einleitung.

Gegenfrage: Warum ist Java so verbreitet und wird immer beliebter?
Warum wird C#, das so ziemlich alles von Java geklaut hat, jetzt
relativ schnell beliebt?

Nicht nur wegen der ästhetischen Syntax.

Du wolltest sagen: >>Wohl kaum wegen der "ästetischen" Syntax.<<

Ich weiß nicht, was Larry Wall für Optimierungen eingebaut hat, aber mein 1 GHz Rechner führt Perl _subjektiv_ schneller als Java aus.

Du machst was falsch.

Vielleicht kannst du ja einen
glaubwürdigen Vergleich irgendwo auftreiben...

Müsste ich mal messen.

Tu das.

Natürlich sind sie das. Genau wie JSP- oder PHP-Programme richtige Programme sind.

Verzeih mir die kleine Spitze mit dem Wort "richtig". Viele "ernsthafte" Programmierer sehen PHP nicht als "richtige" sondern als "Kinder"-Programmiersprache an.

Ach, das wolltest du zum Ausdruck bringen...
Ja, ganz meine Meinung. :-)

Gruß
Slyh

[Robert Bienert]

Hallo,

Moin!

kompilierter Code schneller ist, als "richtig" kompilierter Code?

Fest verdrahteter Code ist noch schneller ;-)

Was verstehst du unter "fest verdrahtetem" Code?

Ein Programm, das direkt in das Silizium des Chips geätzt ist (oder mit diskreten Transistoren aufgebaut).

Der OOP-Teil der Sprache ist SmallTalk, d.h. _zur Laufzeit_ werden Teile des Programmes durch einen SmallTalk-Interpreter gejagt.

Das steht in http://en.wikipedia.org/wiki/Objective_C aber
zum Beispiel nicht. Bist du dir sicher? Habe auch bei Google nichts
in diese Richtung gefunden.

"Objective-C is a dynamically typed language, as is Smalltalk. This means that we can send a message to an object which is not specified in its interface. This may seem a bad idea, but in fact this allows for a great level of flexibility - in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behaviour is known as message forwarding or delegation. Alternatively, an error handler can be used instead, in case the message can not be forwarded. However if the object does not forward the message, handle the error, or respond to it, a runtime error occurs." http://en.wikipedia.org/wiki/Objective_C

Das bedingt, dass auch zur Laufzeit etwas geschehen muss, darauf basiert das Konzept.

[...] wirst du sehr schnell merken, daß Java überhaupt
nicht langsam sein kann!

Ich weiß, mein Rechner ist nur zu langsam.

Nein. Du verwechselst einfach Java mit Swing und gute Programmierer
mit schlechten Programmierern.

So, ich habe gestern abend ein _simples_ Hello-World in C (puts("Hello World!\n"), C++ (std::cout << "Hello World!\n"), Java (System.out.println("Hello World!"), Perl (print "Hello World!\n") und PHP (echo "Hello World!\n") geschrieben und mittels des Unix-Programmes time die Laufzeiten ermittelt: Java war mit einer halben Sekunde etwas 5mal langsamer als C, das ca. 0,1 s brauchte. Selbst ein Programm, dass über 10000 Schleifen durchläuft und den aktuellen Schleifenindex mit 2 XORed, ist in C 5mal schneller. Und das war nicht auf meiner alten DOSe mit 1GHz, sondern auf meinem neuem Mac mit GCC 3.3, Java 1.4.2, Perl 5.8.1 und PHP 4.3.2. Auf der DOSe verschiebt sich das ganze noch weiter zum Nachteil von Java.

Glaub mir. Interpretierte Sprachen sind definitiv und immer langsamer
als kompilierte Sprachen.

Ist das nicht meine Rede?

(Java wird im Speicher kompiliert).
Inwieweit es sowas wie einen JIT-Compiler in/für Perl gibt, weiß ich
nicht. Deshalb möchte ich da keine Aussage treffen.

Perl wird bei der Ausführung auf jeden Fall in einen Binärcode kompiliert, ich weiß allerdings nicht, ob das der der jeweiligen Architektur ist oder ein plattform-unabhängiger.

Du kannst davon ausgehen, daß Java schneller ist.

s.o.

Warum sonst wird Perl so häufig benutzt?

Das beantwortet dir wohl jedes Perl-Buch in der Einleitung.

Gegenfrage: Warum ist Java so verbreitet und wird immer beliebter?

Weil es irgendwie cooler ist dem Kunden irgendetwas binäres in die Hand zu drücken, bei Perl und Konsorten hat man ja zwangsläufig Opensource. Außerdem glaube ich, dass sich kommerzielle Sachen in einem kommerziellen Umfeld besser verbreiten als freie.

Warum wird C#, das so ziemlich alles von Java geklaut hat, jetzt
relativ schnell beliebt?

Weil z.B. M$ den Windows-Programmierern "droht", "Wer jetzt nicht auf Managed Code umsteigt, wird es später schwierig haben" (iX 05/2004 oder etwas später).

Ich weiß nicht, was Larry Wall für Optimierungen eingebaut hat, aber mein 1 GHz Rechner führt Perl _subjektiv_ schneller als Java aus.

Du machst was falsch.

Stimmt, Java-Programme ausführen und darüber diskutieren.

Natürlich sind sie das. Genau wie JSP- oder PHP-Programme richtige Programme sind.

Verzeih mir die kleine Spitze mit dem Wort "richtig". Viele "ernsthafte" Programmierer sehen PHP nicht als "richtige" sondern als "Kinder"-Programmiersprache an.

Ach, das wolltest du zum Ausdruck bringen...
Ja, ganz meine Meinung. :-)

Hätte mich gewundert, wenn wir uns nicht verstehen ;-)

Gruß
Slyh

MfG, Robert

[Slyh]

Hallo,

Was verstehst du unter "fest verdrahtetem" Code?

Ein Programm, das direkt in das Silizium des Chips geätzt ist (oder mit diskreten Transistoren aufgebaut).

Achso, du meinst Hardware...

Der OOP-Teil der Sprache ist SmallTalk, d.h. _zur Laufzeit_ werden Teile des Programmes durch einen SmallTalk-Interpreter gejagt.

"Objective-C is a dynamically typed language, as is Smalltalk. This means that we can send a message to an object which is not specified in its interface. This may seem a bad idea, but in fact this allows for a great level of flexibility - in Objective-C an object can "capture" this message, and depending on the object, can send the message off again to a different object (who can respond to the message correctly and appropriately, or likewise send the message on again). This behaviour is known as message forwarding or delegation. Alternatively, an error handler can be used instead, in case the message can not be forwarded. However if the object does not forward the message, handle the error, or respond to it, a runtime error occurs." http://en.wikipedia.org/wiki/Objective_C

Das bedingt, dass auch zur Laufzeit etwas geschehen muss, darauf basiert das Konzept.

Da steht nirgends, daß da irgendwo ein Smalltalk-Interpreter rumwerkelt.
Kommunikation über Messages bedingt außerdem in keinster Weise die
Ausführung des Codes in einem Interpreter.

Solange du keinen Text lieferst, der eindeutig (und glaubhaft) beschreibt,
daß Objective-C einen Smalltalk-Interpreter verwendet, glaube ich
deine Aussage nicht -- primär deshalb, weil die Aussage unglaubwürdig
ist.

Nein. Du verwechselst einfach Java mit Swing und gute Programmierer
mit schlechten Programmierern.

So, ich habe gestern abend ein _simples_ Hello-World in C (puts("Hello World!\n"), C++ (std::cout << "Hello World!\n"), Java (System.out.println("Hello World!"), Perl (print "Hello World!\n") und PHP (echo "Hello World!\n") geschrieben und mittels des Unix-Programmes time die Laufzeiten ermittelt: Java war mit einer halben Sekunde etwas 5mal langsamer als C, das ca. 0,1 s brauchte.

Wie oft hat er das "Hello World" ausgegeben? Einmal?
Wenn ja, hast du bedacht, daß bei Java zuerst eine komplette
Laufzeitumgebung geladen und initialisiert wird?
Wie lange haben denn Perl und PHP gebraucht, bei denen ja auch sowas
wie eine Laufzeitumgebung geladen wird?

Glückwunsch, übrigens.
Mit deinem "Benchmark" hast du jetzt nichts gemessen, außer genau die
Zeit, die ein Programm zum Starten braucht. (Im Falle von Java,
PHP und Perl inkl. der Laufzeitumgebung.) Allerdings dachte ich, daß
die Java-VM länger zum Starten braucht. 0,5s sind ja richtig schnell.

Von den (vermutlich) sehr geringen Auflösung von "time" will ich jetzt
gar nicht erst anfangen...

Selbst ein Programm, dass über 10000 Schleifen durchläuft und den aktuellen Schleifenindex mit 2 XORed, ist in C 5mal schneller. Und das war nicht auf meiner alten DOSe mit 1GHz, sondern auf meinem neuem Mac mit GCC 3.3, Java 1.4.2, Perl 5.8.1 und PHP 4.3.2. Auf der DOSe verschiebt sich das ganze noch weiter zum Nachteil von Java.

Ein XOR braucht seit spätestens einem 286 genau einen Prozessor-Takt
zur Ausführung. Macht also pessimistisch gerechnet inkl. loop
und jump 10 Takte pro Schleifendurchlauf, also 100.000 Takte. Ein
1GHz-Rechner macht das in 0,0001 Sekunden...
Du misst noch immer die Startzeit der Programme. (Außerdem optimiert
ein C-Compiler die Schleife eh praktisch weg -- zumindest die beiden
XORs. Vermutlich noch mehr.)

Wenn du noch eine Bedingung zwischen die beiden XORs packst, die die
Zählvariable abfragt, so daß die XORs nicht mehr wegoptimiert werden
können, und dann die Schleife 4Mrd. mal ausführen läßt, braucht die
Linux-Kiste hier mit Java ca. 23 Sekunden. Ein GCC-kompiliertes Programm
mit -O3 ca. 8 Sekunden.
(Im Falle von Java messe ich den Programmstart nicht mit.)

Bewiesen wäre damit jetzt, daß Java beim Zählen, Vergleichen, usw.
langsamer ist. Stimmt. Arithmetik ist bei Java bekanntermaßen
langsamer als bei kompilierten Programmen. :-)

Der Benchmark ist aber noch immer kein Benchmark. Ein Benchmark wäre es
dann, wenn hier systematisch die Geschwindigkeit von Methodenaufrufen,
Instanzierungen von Objekten uswusf. gemessen würde. Eben alles, was in
aktuellen Programmen wichtig ist. Und da ist Java nicht wirklich
unperformanter als kompilierte Programme.
(Lies die zitierte c't und die von mir verlinkten Diskussionen.)

Perl braucht übrigens ca. 50 Minuten für das ganze. (Hab die Schleife
nur bis 50.000.000 laufen lassen. Das hat schon 38 Sekunden gedauert.)

PHP habe ich nach 10 Minuten mal abgebrochen.

Übrigens beweist auch das noch praktisch gar nichts.
Einen gewissen Anhaltspunkt der allgemeinen Geschwindigkeit dürfte es
aber schon liefern. :-)

Glaub mir. Interpretierte Sprachen sind definitiv und immer langsamer
als kompilierte Sprachen.

Ist das nicht meine Rede?

Java ist nicht interpretiert.

(Java wird im Speicher kompiliert).

Siehst du.

Inwieweit es sowas wie einen JIT-Compiler in/für Perl gibt, weiß ich
nicht. Deshalb möchte ich da keine Aussage treffen.

Perl wird bei der Ausführung auf jeden Fall in einen Binärcode kompiliert, ich weiß allerdings nicht, ob das der der jeweiligen Architektur ist oder ein plattform-unabhängiger.

"Although Perl has most of the ease-of-use features of an interpreted
language, it does not strictly interpret and execute source code one
line at a time. Rather, perl (the program) first compiles an entire
program to an intermediate byte code (much like Java's byte code),
optimizing as it goes, and then executes that byte code. It is
possible to compile a Perl program to byte code to save the
compilation step on later executions, though the "interpreter" is
still needed to execute that code."

Du kannst davon ausgehen, daß Java schneller ist.

s.o.

Es kommt auf den Einsatz an.
(Ich sagte ja, daß es _im Durchschnitt_ gleich schnell ist.)

Warum sonst wird Perl so häufig benutzt?

Das beantwortet dir wohl jedes Perl-Buch in der Einleitung.

Gegenfrage: Warum ist Java so verbreitet und wird immer beliebter?

Weil es irgendwie cooler ist dem Kunden irgendetwas binäres in die Hand zu drücken, bei Perl und Konsorten hat man ja zwangsläufig Opensource.

Java-Bytecode ist beliebig dekompilierbar. (Der Code läßt sich praktisch
nur dadurch schützen, daß man Variablennamen entfernen läßt usw.)

Außerdem glaube ich, dass sich kommerzielle Sachen in einem kommerziellen Umfeld besser verbreiten als freie.

Java ist kommerziell? Aha.

Warum wird C#, das so ziemlich alles von Java geklaut hat, jetzt
relativ schnell beliebt?

Weil z.B. M$ den Windows-Programmierern "droht", "Wer jetzt nicht auf Managed Code umsteigt, wird es später schwierig haben" (iX 05/2004 oder etwas später).

Das ist vielleicht ein Grund, nicht aber "der Grund".
(Außerdem hat Microsoft in diesem Fall wohl recht.)

Gruß
Slyh