da wird doch ein Riesenhaufen Code durchlaufen, oder? Nein im Ernst - was denkt ihr über diese These?
Also wenn man ein C#-Programm auf einer 3GHz-Maschine mit einer Geschwindigkeit X ausführen kann, wohingegen ein Programm gleicher Funktionalität, jedoch nativ kompiliert, schon auf einer 1GHz-Maschine mindestens mit der Geschwindigkeit X ausführbar ist (da ja kein Interpreter mehr dazwischenhängt), dann ist deine These durchaus nachvollziehbar :=)
Ne, umgekehrt... Java hat Stil und ne Existenzberechtigung im Netz, .NET ist einfach ne billige Abklatsche schmoll
Das ist meiner Meinung eh ein Thema, welches im Moment noch unterschätzt wird. Mein Informatikprof. lacht immer laut, wenn ich während der Vorlesung einwende, dass eine bestimmte Art ein Problem zu lösen mehr Speicher und Rechenaufwand benötigt. Da sagt er immer, dass man sich heutzutage um Performanceverbesserung keine Gedanken mehr machen muss und die Zeit die man dafür investiert nur rausgeschmissenes Geld ist. Aber hey mal ehrlich... hat jemand schon einmal darüber nachgedacht um wie viel Prozent ein Windows Vista Rechner mehr Energie schluckt als ein Windows XP Rechner bei annähernd gleichem Bedienkomfort? Wie viel Energie schluckt ein Java Programm im Gegensatz zu einem C++ oder C Programm? Die Zahl der Javaprogramme nimmt immer weiter zu und damit auch die Verschwendung. Aber mal völlig unabhängig von der Klimadiskussion. Man sollte sich mal fragen wie lange diese Performancesteigerung von Rechensystemen noch in der derzeitigen Geschwindigkeit zunimmt. Zumindest was die Prozessorgeschwindigkeit angeht scheint man langsam an eine Grenze zu stoßen. Daher werden jetzt Geschwindigkeiten durch Dual oder Quad Cores gesteigert anstatt durch eine beträchtliche Taktsteigerung. Vielleicht erleben wir noch einmal eine zeit in der ressourcenschonende Programme wieder Konjunktur bekommen, einfach weil mit vernünftigen Aufwand und Kosten keine große Steigerung der Ressourcen mehr durchgeführt werden kann. Also ich bin davon überzeugt, dass man zumindest ab und an den Ressourcenverbrauch im Kopf haben sollte und daher vor allzu großzügiger Verschwendung lieber mal über eine vielleicht bessere Alternative nachdenken sollte.
Vollkommene Zustimmung meinerseits. Wobei sich das mit Java noch in Grenzen hält, sonderlich viele vollproduktive Anwendungen kenn ich net. Da sinds doch eher die Javaapplets. Bei .NET ist das ne ganze Ecke schärfer, weil M$ da wohl wesentlich mehr im Sinne hat.
>Java hat Stil und ne Existenzberechtigung
Quatsch mit Sauce...Java ist einfach nur grottenlahm!
Aber .NET ist natürlich schneller, ausgereifter, sicherer, verbreiteter und vorallem portabler, gelle? Würd ich auch auf der Stelle aktivieren, so als leistungsfähigen Active-X-Objekt-Ersatz im Internet-Explorer schmunzel
Leute, die sich einen riesen Markt erschließen wollen, zum Beispiel... aber da gehört auch "ausgereifter", "sicherer" und "verbreiteter" dazu..
Java und ausgereift? Ich lach mir einen Ast...alle Ritt kommt da ein Sicherheitsupdate oder ein Bugfix rein...janeeisklar...
Hi Wenn ich jetzt von Java und Konsorten höre, fühle ich mich in die tiefen 70-80er Jahre versetzt. Stichwort BASIC-Interpreter. Alle waren froh, als es Compiler gab, die richtige Programme ohne Laufzeitumgebung erzeugen konnten. Jetzt fängt der Sch... wieder an. MfG Spess
A. N. wrote: > Mein Informatikprof. lacht immer laut, wenn ich während der > Vorlesung einwende, dass eine bestimmte Art ein Problem zu lösen mehr > Speicher und Rechenaufwand benötigt. Da sagt er immer, dass man sich > heutzutage um Performanceverbesserung keine Gedanken mehr machen muss > und die Zeit die man dafür investiert nur rausgeschmissenes Geld ist. Und diejenigen, die ohne eigenes Denken und Meinungsbildung so nen Käse ungeprüft übernehmen, arbeiten aktiv daran, dass man alle 2 Jahre seine HW auf den Schrott bringen kann. Zu meiner Ausbildungszeit wurde einem noch empfohlen seinen Code auf ner lahmen Kiste zu testen und zu optimieren - so bemerkt am deutlichsten, welche Codevariante tatsächlich "optimaler" läuft. Java langsam? Vielleicht, aber wenns richtig gemacht wurde sicherlich nicht lahm - wie mir mal eindruchsvoll vorgeführt wurde.
Najo, wie gesagt -- lahm durch Java oder lahm durch .NET -- dann ist mir ersteres lieber. Da kann ich selbst Hand anlegen. Und ausgereifter: Wie gut, dass es für Windows keine Sicherheitsupdates braucht :-) Dann doch auch wieder lieber Java, da kann ich mir meine Lücken selber stopfen, wenn ich niemandem mehr vertrauen will.
wenigstens gibts für java bugfixes ;-) das einzige, das mir an .net nicht schlecht gefällt sind die partial classes. der rest ist m.M. ein java-plagiat mit allen nach- und vorteilen, wobei die nachteile des "nachbaus" überwiegen...
Bei uns in der Schweiz und wohl auch in vielen anderen Ländern kommt Java im grossen Stil im Finanzsektor zur Anwendung. Heutige Java-VMs analysieren den Code, den sie ausführen und kompilieren "heisse" Codebereiche, welche sehr oft ausgeführt werden, in Maschinencode. Dadurch können Java-Programme beinahe die gleiche Geschwindigkeit erreichen, wie in C++ oder ähnlich geschriebene Software. Davon bekommt man natürlich nicht viel mit, wenn man mal schnell irgendein Java-Progrämmchen für fünf Minuten auf seinem Rechner laufen lässt. Aber in einer Bank, wo ganze Serveranwendungen so entwickelt werden, spielt das schon eine Rolle. Somit wage ich mal zu behaupten, dass Java nicht klimaschädlich ist. Ich lasse dabei natürlich auch die ganzen GUI-Klassen ausser Acht. Die sind irgendwie auf jeder Plattform ein wenig ein Gebastel. C# kenne ich leider nicht, um zum Thema zurückzukommen. Aber das stirbt ja dann zum Glück irgendwann aus, wenn Apple an die Macht kommt und alle sorgenfrei in Objective C programmieren dürfen.
Ja leider ist Java in der tat groß im Kommen. Heutige Wirtschaftsinformatiker lernen gar keine andere Programmiersprache mehr als Java. Zumindest nicht die drei, die ich kenne und die an drei verschiedenen Hochschulen studieren. Ich persönlich mache um Javaprogramm, wenn es geht, einen großen Bogen. Für mich als Anwender steht vor allem die Benutzerfreundlichkeit und das Look and Feel einer Anwendung im Vordergrund (neben der Tatsache, dass sie natürlich auch funktionieren sollte) Leider habe ich da, selbst bei sehr teuren kommerziellen Javaanwendungen schlechte Erfahrungen gemacht. Zum Beispiel funktionieren nicht alle von mir gewohnten Tastenkombinationen, somit verhaue ich mir beim Copy/Paste oft irgendwelche Texte. Auch habe ich es schon oft erlebt, dass der Fensterinhalt nicht korrekt aktualisiert wird. Bei einigen Anwendungen ist auch ein deutlich träges Verhalten auf Benutzeraktionen zu bemerken. Zumindest was das Look and Feel angeht scheint da .net sich etwas passender in die Windowsoberfläche einzufügen. Doch grundsätzlich bin ich ein entschiedener Gegner von Interpretersprachen im Anwendungsbereich. Solange es nur um ein paar Scripts im Internet geht oder auf der Kommandozeile.. ok, aber nicht für komplette Anwendungen. Was spricht denn eigentlich dagegen eine Anwendung für jedes System extra zu compilieren? Statt einen identischen Code zu interpretieren könnte dieser ja problemlos auch compiliert werden (komplett) und man hat zumindest das Problem des Ressourcenverbrauchs damit erschlagen. Wie oft kommt es denn vor, das man im Vorfeld nicht weiß auf welchen System eine Software läuft? Gerade bei großen Anwendungen zum Beispiel im Finanzwesen doch eigentlich gar nicht oder? Die Anwendung läuft auf festen Servern und diese wechseln doch nicht alle paar Tage ihr Betriebssystem... also kann man eine solche Anwendung, gerade wenn sie rechtslastig ist, doch einfach einmal komplett compilieren und schon ist man alle Javasorgen los oder? Und auch die Terminals einer Firma wechseln nicht ständig das Betriebssystem... Ich sehe eigentlich kaum eine Daseinsberechtigung von Java, denn in den meisten Fällen kann man mit nur geringem Mehraufwand die Vorteile von Java auch bei komplett compilierten Programmen nutzen ohne sich die Nachteile von Java damit ins Boot zu holen. Und wenn eine Java VM eh die kritischen Teile inzwischen vorcompiliert, denn frage ich mich, warum sie das nicht gleich mit dem ganzen Programm macht? Natürlich ist einiges in Java für die Programmierer einfach bequemer, aber wenn ich mal in einer Firma die Entscheidung zwischen zwei großen teuren Softwarepakten hätte, würde ich wohl die nicht-Java Lösung bevorzugen. Ich befürchte nur, dass beim derzeitigen Trend es in ein paar Jahren für viele Anwendungen kaum mehr eine nicht-Java Lösung geben wird, zumindest wir die nächste Generation der Informatiker wohl kaum mehr eine andere Programmiersprache mehr beherrschen.
Die Sache ist die: Mac OS, Linux, Unix, SUN und wie sie alle heißen, verfügen über einen "gemeinsamen Nenner", beispielsweise POSIX. Da werden grundlegende Funktionen festgelegt, auf die man als Programmierer zurückgreifen kann und soll, weil sie auf allen Plattformen verfügbar sind. Einzig Windows schießt da quer: Keine Posix-Threads, abstruse Dateisystem-API und so weiter. Das schließt das Querkompilieren aus, zumindest für Windows. Schau doch mal nach: Viele Linux-Anwendungen sind ruck-zuck auch für Mac verfügbar. Um auf Windows zu kommen, schreiben sich viele ihre eigene portable Bibliothek (z.B. den "Apache Portable Runtime", APR). Die Daseinsberechtigung von Java sehe ich fast ausschließlich in Appletts -- da ist Java eindeutig vorne. Was Macromedia in sein Flash reinprogrammiert, kann niemand überblicken, bei Java geht das schon. Und das ist für mich ein Argument, wenn ich schon fremden Code blind ausführen möchte.
@Daniel F: zähl mal ein paar (deiner Meinung nach) Nachteile von .NET auf! Würd mich interessieren!
> Ich persönlich mache um Javaprogramm, wenn es geht, einen großen Bogen. > Für mich als Anwender steht vor allem die Benutzerfreundlichkeit und das > Look and Feel einer Anwendung im Vordergrund Java Bietet (Plattformabhäniges) Look and Feel wenn man es aktiviert > Zum Beispiel funktionieren nicht alle von mir gewohnten > Tastenkombinationen In der Tat ein Ärgernis da man dies erst aktivieren muß.. aber [STRG]+C/X/V funzt standardmäßig. Man kann aber auch beliebiges hinzufügen (man muß es halt aktivieren) > Doch grundsätzlich bin ich ein entschiedener Gegner von > Interpretersprachen im Anwendungsbereich. Solange es nur um ein paar > Scripts im Internet geht oder auf der Kommandozeile.. ok, aber nicht für > komplette Anwendungen. Java ist KEINE Skriptsprache! Da wird garnix interpretiert sondern der Code läuft (nachdem er vorcompiliert wurde) auf der VM, wer sich mal die VM Spezifikation durchließt, wird merken das da VIEL mehr passiert als das der compiler nur den Quellcode in ein paar bytes konvertiert! > Was spricht denn eigentlich dagegen eine Anwendung für jedes System > extra zu compilieren? z.B. Aufwand? Unwissenheit über das was der Benutzer hat. Es muß ja nichtmal nen Linux/Windows/Mac sein, alles was nen compatible JavaVM hat kann den Code ausführen >... also kann man eine solche Anwendung, gerade wenn sie > rechtslastig ist, doch einfach einmal komplett compilieren und schon ist > man alle Javasorgen los oder? a) Welche Sorgen? b) In der Firma wo ich zulezt mein Praktikum absolviert hab hab ichs live miterlebt das der Kunde im allerlezten Momment gesagt hat: Wir wollen doch lieber Windows statt Linux c) Rechenlastige Aufgaben kann man wenns einem echt sooo große Sorgen machet mittel JNI auslagern (ist dann natürlich nichtmehr Platformunabhängig) > Und wenn eine Java VM eh die kritischen Teile inzwischen vorcompiliert, > denn frage ich mich, warum sie das nicht gleich mit dem ganzen Programm > macht? Java geht nach dem Prinzip vor: Make the common case fast. Warum sollte der AUfwand betrieben werden alles in Maschinencode umzuwandeln? (Es wird nicht compiliert, sondern nur häufig durchlaufene Codeteile optimiert durch Maschinencode). Außerdem kann so die Java VM Prozessorpsezifische Optimierungen nutzen ohne das jedesmal für jeden Prozessor eine eigenes Programm übersezt werden muß! > Natürlich ist einiges in Java für die Programmierer einfach bequemer, Sehe ich nicht so, die richtige Einarbeitung erfordert ebenso arbeit wie bei jeder anderen Programmiersprache. Die Vorteile für mich sind: * Portabel (was ich einmal Programiert hab läuft auf (fast) jeder Java Plattform) * OO und strikt ... einem wird von vornherein "verboten" "dirty hacks" zu nutzen und man wird gezwungen OO zu programmieren. * Classloader: Damit kann man echt geniale Sachen machen * Viele (sehr viele) freie Bibliotheken die ich einfach so verwenden kann OHNE das ich erst stundenlang Anpassungen machen muß damit das ganze auf meinem System, mit meiner SDK, meinem Betriebssystem und meinem Compiler zusammenarbeitet * Kostenlos SDK und JRE... Programmieren ist Arbeit genug ich will nicht noch dafür zahlen mein Programm kompilieren zu dürfen ;) Java ist nicht so schlecht wie sein Ruf, und das ständige Gestänker gegen Java ohne stichhaltige Argumente nervt irgenwie.
Läubi Mail@laeubi.de wrote: > Java Bietet (Plattformabhäniges) Look and Feel wenn man es aktiviert Ja eben, aber das ist nicht das Look and Feel, welches ich gewohnt bin und in welchem ich mich wohlfühle. Wenn ich Geld für ne Software ausgeben muss, dann werde ich das selten für ein Produkt machen, welches eine für mich ungewohnte und damit unbequeme Bedienung und Umgebung schafft. > In der Tat ein Ärgernis da man dies erst aktivieren muß.. aber > [STRG]+C/X/V funzt standardmäßig. > Man kann aber auch beliebiges hinzufügen (man muß es halt aktivieren) Also ich als Nutzer hab noch in keinem Javaprogramm eine (vom Programm unabhängige) Einstellmöglichkeit von Tastenkombinationen gefunden. Wenn du mir veräst wo das ist, dann wäre mir bei dem einen oder anderen Programm schon geholfen. Das ein Programmierer soetwas beim Programmieren machen kann ist klar, aber bei vielen Programmen wird eben genau meine Liebingskombination CAPS+Einfg und CAPS+Entf nicht unterstützt. Dabei arbeite ich damit schon seit meinem Atari ST und die geht mir tausend mal schneller von der Hand als die Sache mit Strg X/C/V wo ich erst ständig überlegen muss welche Taste noch einmal für was stand. Ich als Anwender gebe nun einmal ungern Geld für Produkte aus bei denen ich mich nicht wohlfühle, denn wenn ich ein Produkt kaufe, dann weil ich mir davon Arbeitserleichterung für ein bestimmtes Vorhaben erhoffe. Wenn ich mich hier erst in eine völlig ungewohnte Umgebung eindenken muss, dann ist das für mich aber keine Arbeitserleichterung. > Java ist KEINE Skriptsprache! Da wird garnix interpretiert sondern der > Code läuft (nachdem er vorcompiliert wurde) auf der VM, wer sich mal die > VM Spezifikation durchließt, wird merken das da VIEL mehr passiert als > das der compiler nur den Quellcode in ein paar bytes konvertiert! Im prinzip ist es schon eine Scriptsprache, es wird eben eine Art Pseudomaschinencode für die VM erschaffen, der dann bei Laufzeit Interpretiert wird. Mehr als eine etwas bessere Scriptsprache ist das allerdings nicht. Und hinter jedem Befehl steht ein gewisses Offeset an Arbeit die die VM erledigen muss, Arbeit die Zeit kostet und zum Beispiel auf mobilen Geräten Akkuleistung. Eine Javaanwendung wird niemals so schnell und so ressourcenschonend auf einem system laufen wie eine dafür extra kompilierte Anwendung. Das ist leider nun einmal Prinzip bedingt. Für den einen ist das eventuell kein Argument, weil für ihn eben andere Dinge im Vordergrund stehen. Für mich ist das allerdings ein Argument, weil ich den Wahnsinn an Ressourcenverschwendung im IT Bereich ehrlich gesagt satt bin. >> Was spricht denn eigentlich dagegen eine Anwendung für jedes System >> extra zu compilieren? > z.B. Aufwand? Unwissenheit über das was der Benutzer hat. Es muß ja > nichtmal nen Linux/Windows/Mac sein, alles was nen compatible JavaVM hat > kann den Code ausführen Was macht eine Java VM? Es Interpretiert den Zwischencode und setzt die Befehle dann Systemspezifisch um. Also zumindest muss irgendwann einmal eine Java VM für dieses System geschaffen worden sein, damit es läuft. Anstatt also bei jeder Programmausführung den Zwischencode systemspezifisch auszuführen, wäre es doch wesentlich Sinnvoller den Zwischencode einmalig für das System zu compilieren und dann direkt vom System als Maschinencode ausführen zu lassen. Der einzige Grund so etwas zu tun ist, wenn man wirklich nicht weiß wo das Programm als nächstes ausgeführt wird. Zum Beispiel bei einem Internetapplet. Bei einer Anwendungssoftware die dauerhaft auf einem System angewendet wird kann man hingegen sicher problemlos ein Programm für das entsprechende System einmalig compilieren und es dann nativ ausführen lassen. > a) Welche Sorgen? Performance > b) In der Firma wo ich zulezt mein Praktikum absolviert hab hab ichs > live miterlebt das der Kunde im allerlezten Momment gesagt hat: Wir > wollen doch lieber Windows statt Linux Na und, dann wird der Code halt durch einen windowscompiler gejagt anstatt durch einen Linuxcompiler und schon ist der Kunde zu frieden. Das ist noch lange kein Grund ein Programm während der Laufzeit bei jeder Ausführung erneut systemspezifisch umzusetzen, wie es Java macht. > c) Rechenlastige Aufgaben kann man wenns einem echt sooo große Sorgen > machet mittel JNI auslagern (ist dann natürlich nichtmehr > Platformunabhängig) Dann kann man gleich das ganze Programm durch einen plattformspezifischen Compiler jagen, dann spart man sich auch gleich den ganzen VM Kram und schont damit die Ressourcen der Anwendungsrechner. > Java geht nach dem Prinzip vor: Make the common case fast. Warum sollte > der AUfwand betrieben werden alles in Maschinencode umzuwandeln? (Es > wird nicht compiliert, sondern nur häufig durchlaufene Codeteile > optimiert durch Maschinencode). Außerdem kann so die Java VM > Prozessorpsezifische Optimierungen nutzen ohne das jedesmal für jeden > Prozessor eine eigenes Programm übersezt werden muß! Wie gesagt, wenn man bei jeder Anwendung eines Programmes ein anderes System hat, dann ist das ja ok. Aber das hat man bei Anwendungssoftware halt normalerweise nicht. Und wenn der Anwender dann doch einmal auf Linux umsteigt installiert er eben einfach die Version des Programmes, welche für Linux compiliert wurde. >> Natürlich ist einiges in Java für die Programmierer einfach bequemer, > Sehe ich nicht so, die richtige Einarbeitung erfordert ebenso arbeit wie > bei jeder anderen Programmiersprache. Logisch > Die Vorteile für mich sind: > * Portabel (was ich einmal Programiert hab läuft auf (fast) jeder Java > Plattform) > * OO und strikt ... einem wird von vornherein "verboten" "dirty hacks" > zu nutzen und man wird gezwungen OO zu programmieren. Was ja auch Ansichtssache ist, ob man diesen Zwang jetzt gut finden soll oder nicht. Aber unabhängig davon gibt es genug echte Programmierspreche die ausschließlich OO Programmierung zulassen. > * Classloader: Damit kann man echt geniale Sachen machen > * Viele (sehr viele) freie Bibliotheken die ich einfach so verwenden > kann OHNE das ich erst stundenlang Anpassungen machen muß damit das > ganze auf meinem System, mit meiner SDK, meinem Betriebssystem und > meinem Compiler zusammenarbeitet Mit den entsprechenden Bibliotheken und einer sorgfältigen Programmierung ist soetwas auch in C++ zu realisieren. Viele Open Source Projekte machen es ja vor, wie man Code erzeugt, den man auf jedem System für das es einen C++ Compiler gibt compilieren kann... > * Kostenlos SDK und JRE... Programmieren ist Arbeit genug ich will nicht > noch dafür zahlen mein Programm kompilieren zu dürfen ;) Also es gibt absolut kostenlose Compiler für alle möglichen Sprachen und Systeme, das ist also nichts besonderen von Java. > Java ist nicht so schlecht wie sein Ruf, und das ständige Gestänker > gegen Java ohne stichhaltige Argumente nervt irgenwie. Im Allgemeinen hast du eben ne ganze Menge Vorteile aufgelistet, die Java für Dich als Programmierer bietet, das ist ok und teilweise kann ich das ja auch nachvollziehen. Ich mag auch Programmiersprachen, die mir das leben als Programmierer nicht zusätzlich schwer machen ich mag auch tolle IDEs und schöne Programmierkonzepte, bei denen man nicht um 3 Ecken denken muss. Doch all dies bieten viele andere Programmiersprachen auch, da sticht Java nicht unbedingt hervor. Für mich als Anwender steht jedoch nicht im Mittelpunkt ob der Programmierer es besonders bequem hatte, sondern ob das Programm meinen Anforderungen genügt. Wie schon oben erwähnt lege ich viel Wert auf effiziente Anwendungen, wo Konzepte wie .net und Java nun einmal ganz prinzipiell sich nciht besonders mit Ruhm bekleckern. Darüber hinaus bin ich wie schon oben erwähnt oft genug im Konflikt mit dem javatypischen Look and Feel, welches ich nicht als angenehm empfinde. Dies ist bei .net natürlich nicht der Fall, wäre ja auch schön blöd von MS, wenn die ihr eigenes Look and Feel untergraben. Aber bei .net ist es dennoch die Performance die mich abschreckt. Das was man am heimischen Rechner an Mehrarbeit bei solchen Konzepten nicht mitbekommt, merkt man spätestens wenn man für ein Windows Mobile Handy .net Anwendungen benutzt. Bei starker Nutzung solcher Anwendungen sinkt die Akkulaufzeit schon drastisch, hier haben vollständig compilierte Programme nun einmal einen Vorteil. Bei Firmen mit tausenden Terminals und großen Servern, denke ich auch, dass es sich bei der Stromrechnung und den Anschaffungskosten bemerkbar macht, ob man ein C++ Programm oder ein Java/.net Programm laufen lässt. Nur achten im Moment noch zu wenig Leute darauf... Ich bin davon überzeugt, dass sich dies irgendwann ändern wird.
A. N. wrote: > Läubi Mail@laeubi.de wrote: >> Java Bietet (Plattformabhäniges) Look and Feel wenn man es aktiviert > Ja eben, aber das ist nicht das Look and Feel, welches ich gewohnt bin > und in welchem ich mich wohlfühle. (...) Was willst du denn? Mit Java kannst du z.B. SWAT benutzen und hast ein plattformübergreifendes, gleiches Benutzerinterface, oder aber du aktivierst die jeweils plattformabhängige Variante. Beides geht. >> In der Tat ein Ärgernis da man dies erst aktivieren muß.. aber >> [STRG]+C/X/V funzt standardmäßig. >> Man kann aber auch beliebiges hinzufügen (man muß es halt aktivieren) > Also ich als Nutzer hab noch in keinem Javaprogramm eine (vom Programm > unabhängige) Einstellmöglichkeit von Tastenkombinationen gefunden. (...) Hat nix mit Java zu tun, sondern mit dem Programmierer und seinen Vorstellungen. > Das ein Programmierer soetwas beim Programmieren machen kann ist klar, > aber bei vielen Programmen wird eben genau meine Liebingskombination > CAPS+Einfg und CAPS+Entf nicht unterstützt. (...) Dann schieb das doch bitte dem Programmierer in die Schuhe, und nicht Java. > Ich als Anwender gebe nun einmal ungern Geld für Produkte aus bei denen > ich mich nicht wohlfühle, (...) Hat immer noch nix mit Java zu tun. >> Java ist KEINE Skriptsprache! Da wird garnix interpretiert sondern der >> Code läuft (nachdem er vorcompiliert wurde) auf der VM, wer sich mal die >> VM Spezifikation durchließt, wird merken das da VIEL mehr passiert als >> das der compiler nur den Quellcode in ein paar bytes konvertiert! > Im prinzip ist es schon eine Scriptsprache, es wird eben eine Art > Pseudomaschinencode für die VM erschaffen, der dann bei Laufzeit > Interpretiert wird. (...) Richtig. Gleiches gilt auch für dotNET. > Für den einen ist das eventuell kein Argument, weil für ihn eben andere > Dinge im Vordergrund stehen. Für mich ist das allerdings ein Argument, > weil ich den Wahnsinn an Ressourcenverschwendung im IT Bereich ehrlich > gesagt satt bin. Da ist auch was Wahres dran... :-) >>> Was spricht denn eigentlich dagegen eine Anwendung für jedes System >>> extra zu compilieren? >> z.B. Aufwand? Unwissenheit über das was der Benutzer hat. Es muß ja >> nichtmal nen Linux/Windows/Mac sein, alles was nen compatible JavaVM hat >> kann den Code ausführen > Was macht eine Java VM? (...) > > Der einzige Grund so etwas zu tun ist, wenn man wirklich nicht weiß wo > das Programm als nächstes ausgeführt wird. Zum Beispiel bei einem > Internetapplet. Bei einer Anwendungssoftware die dauerhaft auf einem > System angewendet wird kann man hingegen sicher problemlos ein Programm > für das entsprechende System einmalig compilieren und es dann nativ > ausführen lassen. Nein, kann man nicht. Wenn man ein Programm für Linux mit Funktionsaufrufen wie stinknormales POSIX-Threading, QT, X11 oder so schreibt, wird das unter Windows nicht laufen, basta. Umgekehrt wird Linux keine "SendMessage" bereitstellen... >> a) Welche Sorgen? > Performance > >> b) In der Firma wo ich zulezt mein Praktikum absolviert hab hab ichs >> live miterlebt das der Kunde im allerlezten Momment gesagt hat: Wir >> wollen doch lieber Windows statt Linux > Na und, dann wird der Code halt durch einen windowscompiler gejagt > anstatt durch einen Linuxcompiler und schon ist der Kunde zu frieden. > Das ist noch lange kein Grund ein Programm während der Laufzeit bei > jeder Ausführung erneut systemspezifisch umzusetzen, wie es Java macht. Siehe oben, das funktioniert so schlicht und einfach nicht. Man kann das umstricken, indem man, wie es der Apache-Webserver macht, alle betriebssystemspezifischen Funktionen in Bibliotheken auslagert. Aber auch diese müssen dann für jedes OS neu geschrieben werden und bringen Overhead mit. >> c) Rechenlastige Aufgaben kann man wenns einem echt sooo große Sorgen >> machet mittel JNI auslagern (ist dann natürlich nichtmehr >> Platformunabhängig) > Dann kann man gleich das ganze Programm durch einen > plattformspezifischen Compiler jagen, (...) Siehe oben. >> Java geht nach dem Prinzip vor: Make the common case fast. (...) > Wie gesagt, (...) Siehe oben. > >> Natürlich ist einiges in Java für die Programmierer einfach > bequemer,(...) > Mit den entsprechenden Bibliotheken und einer sorgfältigen > Programmierung ist soetwas auch in C++ zu realisieren. Viele Open Source > Projekte machen es ja vor, wie man Code erzeugt, den man auf jedem > System für das es einen C++ Compiler gibt compilieren kann... Siehe oben. Hier sind es halt die spärlichen C++-Standardheader. Aber vollständig plattformunabhängig wird das so nicht, da die C-/C++-Standards z.B. keine Userinterfaces enthalten. >> * Kostenlos SDK und JRE... Programmieren ist Arbeit genug ich will nicht >> noch dafür zahlen mein Programm kompilieren zu dürfen ;) > Also es gibt absolut kostenlose Compiler für alle möglichen Sprachen und > Systeme, das ist also nichts besonderen von Java. Jo. >(...) > Für mich als Anwender steht jedoch nicht im Mittelpunkt ob der > Programmierer es besonders bequem hatte, sondern ob das Programm meinen > Anforderungen genügt. Siehe oben, dafür kann Java nix. > Wie schon oben erwähnt lege ich viel Wert auf > effiziente Anwendungen, wo Konzepte wie .net und Java nun einmal ganz > prinzipiell sich nciht besonders mit Ruhm bekleckern. Darüber hinaus bin > ich wie schon oben erwähnt oft genug im Konflikt mit dem javatypischen > Look and Feel, welches ich nicht als angenehm empfinde. Siehe oben. Man kann auch mit Java das Look-and-Feel von Windows nutzen. Tjo... entschuldigt die vielen Kürzungen...
Hallo, bei uns in der Bank wird jetzt eine Klimaanlage installiert weil durch die Wärmeentwicklung u.a. der Terminals die Raumtemperatur zu hoch wird. Gruß Jürgen
Ob nun Java oder .Net besser ist, ist doch eigendlich völlig egal !!! Letztenendes wird damit das gleiche gemacht wie schon in den letzten Jahrzehnten des Computerzeitalters. Der einziger Unterschied liegt doch nur darin, dass die Menschen dumm genug sind dem Werbegebaren der Industrie zu glauben. Mir persönlich ist es noch nicht passiert, dass das mir ein Bug in einer meiner .Net Anwendungen mehr Spass gemacht hat als einer in purem C/C++ bzw. Assembler (Für Java etc. gilt bestimmt das gleiche!). Besonders schlimm ist es doch, dass wir heute im Vergleich zu 1985 bestimmt 10.000 fache (oder mehr) and Rechenleistung haben und unsere Systeme zu 95% mit Dingen beschäftigen bei denen ein Rechner von 1985 ausreichen würde. Hierbei denke ich immer an einen Peak in der Prozessorlastanzeige mit einem 3Ghz DUAL-Core Prozessor unter WinXp. Dabei habe ich nur die rechte Maustaste betätigt und der Rechner muste schwitzen. Ich möchte nicht wissen, was nun passiert wenn ich diesen Beitrag losschicke. (Komm Luder arbeite für mich ..... :-) )
Das die Terminals in einer Bank soviel Wärme produzieren ist eigentlich schon ein Armutszeugnis - Ein C64 müsste mit den primitiven Aufgaben die so ein Terminal leisten muss schon klarkommen. Kopfschüttel
Sven Pauli wrote: > Was willst du denn? Mit Java kannst du z.B. SWAT benutzen und hast ein > plattformübergreifendes, gleiches Benutzerinterface, oder aber du > aktivierst die jeweils plattformabhängige Variante. Beides geht. >[...] > Hat nix mit Java zu tun, sondern mit dem Programmierer und seinen > Vorstellungen. >[...] > Dann schieb das doch bitte dem Programmierer in die Schuhe, und nicht > Java. >[...] > Hat immer noch nix mit Java zu tun. Natürlich ist das kein direktes Javaproblem, Doch interessanter weise weisen dennoch ein Großteil der Javaprogramme dieses Problem auf. Wenn du als Javaprogrammierer dafür sorgst, dass dein Programm sich nahtlos in das gewohnte Look und Feel deiner Kunden einfügt, dann finde ich das sehr gut aber anschneiend unterstützt Java die Programmierer nicht gerade dabei. Im Gegensatz zu VC++, welches ja die windowseigene Oberflächte benutzt oder aber auch wxWidget wo der Programmierer ebenfalls nicht in die Verlegenheit kommt solch eingebürgerten Tastenkombinationen zu vergessen. Aber in der tat, hier besteht ja Hoffnung darauf, dass soetwas bald standardmäßig bei allen Javaprogrammen funktioniert. Dennoch bleibt dann das Problem, das zum Beispiel Fensterinhalte nicht immer korrekt aktualisiert werden. In einigen Javaanwendungen blieben zum Beispiel in einer Liste Textartefakte an den Rändern, wenn man die Liste sehr schnell scrollte. Sicher keine Katastrophe, es gibt den Benutzer jedoch ein ungutes Gefühl. Auch hier sehe ich kein Problem darin, dass soetwas in späteren Javaversionen nicht mehr vorkommt, aber bisher stört es mich. >> Im prinzip ist es schon eine Scriptsprache, es wird eben eine Art >> Pseudomaschinencode für die VM erschaffen, der dann bei Laufzeit >> Interpretiert wird. (...) > Richtig. Gleiches gilt auch für dotNET. Stimmt und deswegen mache ich auch einen großen Bogen darum, wann immer es nur geht :-) > Nein, kann man nicht. Wenn man ein Programm für Linux mit > Funktionsaufrufen wie stinknormales POSIX-Threading, QT, X11 oder so > schreibt, wird das unter Windows nicht laufen, basta. Umgekehrt wird > Linux keine "SendMessage" bereitstellen... > [...] > Siehe oben, das funktioniert so schlicht und einfach nicht. > Man kann das umstricken, indem man, wie es der Apache-Webserver macht, > alle betriebssystemspezifischen Funktionen in Bibliotheken auslagert. > Aber auch diese müssen dann für jedes OS neu geschrieben werden und > bringen Overhead mit. > [...] > Siehe oben. > [...] > Siehe oben. Hier sind es halt die spärlichen C++-Standardheader. Aber > vollständig plattformunabhängig wird das so nicht, da die > C-/C++-Standards z.B. keine Userinterfaces enthalten. Nun, ich habe selbst noch nie Plattform unabhängig programmiert. Aber ich weiß, das dies durchaus unter C++/C ein Problem darstellen kann. Daher sehe ich durchaus eine Daseinsberechtigung für eine Hochsprache, bei der der Code plattformunabhängig ist und nur noch vom entsprechenden Compiler übersetzt werden muss.. also eine art Java nur halt mit einem richtigen Compiler. Das wäre doch eine feine Lösung. Allerdings scheint es nicht unmöglich zu sein mit C++/C plattformunabhängig zu programmieren. Guck dir doch mal das openttd Projekt an oder freeciv oder Code:Blocks. Die Liste kann man Fortsetzen... ein Code, der je nach Plattform von einem entsprechenden Compiler übersetzt wird. Falls dann doch einmal gravierende Unterschiede existieren muss man sich eben einmalig plattformabhängige Bibliotheken schaffen, auf die man bei jedem Folgeprojekt wieder zugreifen kann. Es ist sicher etwas aufwendiger, aber es ist ganz offensichtlich möglich.
C# ist nicht klimaschädlich. Es sei denn du ersetzt einen µC im funkfühler mit einen Windowssystem um .net drauf laufen zu lassen. und zu allen die irgendeine programmiersprache verteidigen oder hochloben. Ihr seid keine guten Programmierer. Was für eine Sprache ist doch schließlich egal. Die Ideen oder Konzepte hinter einer Sprache hat sich jemand ausgedacht, um damit sicher irgendwas zu erreichen. Solange es nicht darum geht sein eigenes Gebiet abzustecken (was man bei M$ ja erwarten könnte) hat es einen Sinn. Selbst eine Sprache wie Brainfu ck hat ihren Sinn. Scriptsprachen haben ein paar Vorteile gegenüber Compilierte Sprachen, genauso wie umgekehrt. Es ist nicht immer nötig auf den letzten bischen Performence oder Speicher zu achten. Wenn ich zwei Byte mehr Ram brauche wenn ich noch 1kB frei habe, aber dadurch das Codeschnipsel portabel halte, dann sprache ich dadurch mehr CO2 ein weil ich es nochmal verwenden kann als es zu optimieren. Wer sich zu lange an kleinigkeiten aufhält der kommt nie weiter. Nur da optimieren wo nötig und den Rest auf Sicherheit und Stabilität legen.
A. N.: Klar ist Portabilität kein Problem. Wie ich schon sagte: Programme, die sich z.B. an POSIX halten, kann man nahezu problemlos zwischen Linux, Mac, Sun, Unix austauschen. Nur Windows passt aber auch überhaupt net da hinein. Viele Linux-Programme gibts mittlerweile schon für Windows, und zwar nativ (GIMP...), aber umgekehrt...? Manchmal bin ich mir ziemlich sicher: Microsoft will überhaupt nicht, dass Win-Programme portiert werden, weil es dann ja eigentlich keine Argumente mehr gibt, die den Einsatz von Windows unterstützen.
A. N. wrote: > Läubi Mail@laeubi.de wrote: >> Java Bietet (Plattformabhäniges) Look and Feel wenn man es aktiviert > Ja eben, aber das ist nicht das Look and Feel, welches ich gewohnt bin > und in welchem ich mich wohlfühle. Wenn ich Geld für ne Software > ausgeben muss, dann werde ich das selten für ein Produkt machen, welches > eine für mich ungewohnte und damit unbequeme Bedienung und Umgebung > schafft. Ich weiß nicht was du hast. Schonmal Eclipse benutzt? Sieht exakt wie ein natives Windowsprogramm aus und hat auch ähnliche Tastaturkombinationen. Aber du hast trotzdem Recht: Man kann Plattformübergreifende Programme auch mit C++ erstellen. Dafür gibt es diverse Toolkits (Hast ja auch schon wxWidgets genannt). Problematisch ist nur, wenn das wxWidgets Toolkit eine Funktion nicht bereitstellt, die du aber dringend benötigst. Aber das Problem hast du bei Java ja prinzipiell auch.
Andreas W. wrote: > C# ist nicht klimaschädlich. Es sei denn du ersetzt einen µC im > funkfühler mit einen Windowssystem um .net drauf laufen zu lassen. Aber genau dahin geht doch der Trend. Es gibt ja schon µC die darauf ausgelegt werden, dass darauf eine Java VM läuft... > und zu allen die irgendeine programmiersprache verteidigen oder > hochloben. Ihr seid keine guten Programmierer. Was für eine Sprache ist > doch schließlich egal. Die Ideen oder Konzepte hinter einer Sprache hat > sich jemand ausgedacht, um damit sicher irgendwas zu erreichen. Solange > es nicht darum geht sein eigenes Gebiet abzustecken (was man bei M$ ja > erwarten könnte) hat es einen Sinn. > Selbst eine Sprache wie Brainfu ck hat ihren Sinn. Stimmt durchaus, jede Sprache hat ihren speziellen Anwendungsbereich. Problematisch wird es halt wenn eine Sprache oder ein Sprachkonzept als Universallösung eingesetzt wird. Ein Internet Applet mit C++ wäre sicher etwas eigenartig, da Punktet halt soetwas wie Java, Flash etc. Aber eine lokale Anwendung, wie zum Beispiel ein Textverarbeitungsprogramm in Java oder Flash finde ich halt etwas daneben. Dahin geht aber eben der Trend... > Scriptsprachen haben ein paar Vorteile gegenüber Compilierte Sprachen, > genauso wie umgekehrt. > Es ist nicht immer nötig auf den letzten bischen Performence oder > Speicher zu achten. Wenn ich zwei Byte mehr Ram brauche wenn ich noch > 1kB frei habe, aber dadurch das Codeschnipsel portabel halte, dann > sprache ich dadurch mehr CO2 ein weil ich es nochmal verwenden kann als > es zu optimieren. > Wer sich zu lange an kleinigkeiten aufhält der kommt nie weiter. Nur da > optimieren wo nötig und den Rest auf Sicherheit und Stabilität legen. Es geht ja nicht um die Frage ob nur ein Byte oder zwei Byte. Sondern um die Frage ob es gerechtfertigt ist, dass es für Ressourcenverschwendung gar keine Grenzen mehr gibt. Wenn bei jeder Anwendung im Hintergrund ein Interpreter mitläuft der selbst noch speicher und Rechenleistung Nutzt und zudem die Ausführgeschwindigkeit abbremst, dann ist das halt nicht mehr feierlich. Mein Informatikprof. proklamiert halt, das man sich um Ressourcen gar keine Gedanken mehr machen muss und dann werden 300 Ziffern von 0 bis 9 halt mal geschwind in einem Array aus 300 32bit Integer gespeichert... Diese Fehlentwicklung ist eben nicht mehr ok.
Simon K. wrote: > Ich weiß nicht was du hast. Schonmal Eclipse benutzt? Sieht exakt wie > ein natives Windowsprogramm aus und hat auch ähnliche > Tastaturkombinationen. Ja, allerdings mal vor 3 Jahren unter Linux. Das überlebte ganze 30min. auf meiner festplatte, danach war es weg, da beim schnellen scrollen, wie oben beschrieben, Artefakte im Textfenster hängen blieben und danamls zumindest meine Lieblingstestenkombination CPAS-Entf/Einfg nicht ging. Das kann sich ja inzwischen durchaus geändert haben ;)
@A. N. das beispiel mit den Array wird ich auch machen, weil es im Prozessor Strom spart :) und wenn das ganze nur im zeitraum von ms gemacht durchsucht wird spielt es keine rolle. Wichtig ist da optimieren wo nötig, vieleicht ist es bei allen euren Programmen nicht nötig. Das ist genau so sache, erstmal muss man lernen das performence wirklich nicht das wichtigste ist (jedenfals nicht überall) es kommt auf den Anwendungsfall an. Und bei einen Schreibprogramm ist mir wichtig das es in unter 100 ms startet, es ist mir egal ob es in 5 ms oder in 90 ms startet. zugegeben davon sind die großen schreibprogramme weit weg :( keine frage die Performceverschwendung ist bei vielen dingen schon nichtmehr angenehm. Bedienoberflächen und Benutzerinteraktionen gehen wirklich Richtung Scriptsprache, dies hat den Vorteil das sich der programmierer nicht so den kopf über den DAU machen muss, dies erhöht die Sicherheit und die Stabilität, größere Programme werden aber kombiniert, also ein teil als scriptsprache und ein teil compiliert. Ich selbst schreibe gerne in Python :-) da ist es leicht C/C++ einzubinden.
Angehängte Dateien:
-
sprachen.png
21 KB
Programmiersprachen können langsam oder schnell sein - in der Ausführung - bei der Softwareentwicklung Sprachen, die in beiden Kategorien sehr langsam sind, setzen sich nicht durch. Sprachen, die in beiden Kategorien sehr schnell sind, wurden (leider) noch nicht erfunden. Es wird also bei der Spezifikation von Programmiersprachen versucht, entweder die Ausführungs- oder die Entwicklungsgeschwindigkeit zu optimieren oder einen Kompromiss zwischen beiden zu finden. Im obigen Diagramm¹, in dem für unterschiedliche Sprachen die Ausführungs- über der Entwicklungsgeschwindigkeit aufgetragen ist, liegen deswegen alle Sprachen mehr oder weniger auf einer Geraden. Von links oben nach rechts unten nimmt die Dynamik der Sprachen tendenziell zu. Dies erleichtert zwar die Programmierung enorm, erschwert aber die Ausführung auf den heutigen Computern, die ein sehr statisches Ausführungsmodell realisieren. Um das Klima zu schonen, sollten Anwendungen, über lange Zeit viel CPU-Zeit brauchen (bspw. numerische Berechnungen, aber auch aufwendige iund häufig genutzte Web-Anwendungen) in einer der Sprachen im oberen Bereich programmiert werden. Bei Anwendungen, die nur selten verwendet werden oder die meiste Zeit auf externe Ereignisse warten (bspw. Anwendungen mit viel Benutzerinteraktion und selten genutzte Web-Anwendungen), dürfen die Entwicklungskosten optimiert und Sprachen im rechten unteren Bereich ausgewählt werden, ohne dass sich das auf das Klima nennenswert auswirkt. Wenn man sowieso nur eine einzige Programmiersprache lernt (wie bspw. ein Großteil der o.g. Wirtschaftsinformatiker ;-)), ist es schon sinnvoll, eine aus dem Mittelbereich (z.B. Java oder C#) zu wählen. Leistet man sich den Luxus, zwei Sprachen zu lernen², nimmt man besser zwei, die weit auseinander liegen, also z.B. C und Python. man liegt damit für jeden Anwendungstyp nahe am Optimum. —————————— ¹) Die Werte sind qualitativ, die Achsen nichtlinear und das Ganze natürlich stark vom Typ der entwickelten Anwendung abhängig. Also bitte weder hauen noch verlangen, dass einer Punkte 3 Pixel weiter nach oben und 2 nach links soll :) ²) Diesen Luxus sollte sich eigentlich jeder hauptberufliche Softwareentwickler leisten.
hey yalu cooler beitrag. wenn das mal nicht ein versöhnlicher beitrag ist.
malbolge :) ok die setzt sich sicher nicht durch, aber wer darin ein programm schreibt der weiß wie man programmiert :)
>Ja, allerdings mal vor 3 Jahren unter Linux. Das überlebte ganze 30min. >auf meiner festplatte, danach war es weg, da beim schnellen scrollen, >wie oben beschrieben, Artefakte im Textfenster hängen blieben und >danamls zumindest meine Lieblingstestenkombination CPAS-Entf/Einfg nicht >ging. LOL ich vor vier Wochen...ich dachte einen Moment lang, ich hätte einen 486er 66MHz auf dem Tisch stehen so grottenlahm war die Oberfläche. Danke nein...das muss heute definitiv nicht mehr sein. Gleiches mit Open Office...Performance ist eine einzige Katastrophe, völlig indiskutabel. Da bringt mir ach so tolle Portabilität und was weis ich noch alles genau gar nichts.
Laut diversen Benchmarks kann Java-Code wirklich die Performance von C- oder C++-Code erreichen. Dass man davon gerade bei Desktopprogrammen nichts merkt liegt an der hohen Startzeit und dem exorbitant hohen Speicherbedarf von Java im Allgemeinen, und der Aufgeblasenheit von vielen Programmen, GUI-Toolkits und Bibliotheken im Speziellen. Beispiel: Eclipse startet für das Anzeigen der Hilfe einen lokalen Webserver.
Wenn sich hier wirklich alle für die Klimaschädlichkeit von Programmiersprachen interessieren würden, hätten wir alle den Computer ausgeschaltet lassen sollen und einen Tag in der Natur verbringen sollen! :-) Ohne Java - ohne DotNet ...
Da hatte ich doch mal...wart mal...ahhh da isses ja: 1. Da war mal ein Unternehmen, das hat einen Prozessor mit dem Hardware-Debugger untersucht und festgestellt, dass etwa die halbe Zeit lang nur dieselbe Folgen von einigen Instruktionen ausgeführt wurde. Also hat man dem Prozessor eine neue Instruktion eingebaut, die den gleichen Zweck erfüllt, aber eben nur einen Instruktionstakt braucht. Resultat: Man hatte die "Idle-Schleife" des Kerns optimiert. 2. Auf einer MIPS R10000 braucht eine Integerdivision länger als eine Fließkommadivision. 3. Ein Programm wurde in C, Java, C++, für AWK und in Perl geschrieben und ausgeführt. In C++ wurde einmal eine deque, ein andres Mal eine list benutzt. Resultat:
1 | 250MHz R10000 400MHz Pentium II Quelltextzeilen |
2 | C 0,36 sek 0,30 sek 150 |
3 | Java 4,9 9,2 105 |
4 | C++/deque 2,6 11,2 70 |
5 | C++/list 1,7 1,5 70 |
6 | Awk 2,2 2,1 20 |
7 | Perl 1,8 1,0 18 |
Ist doch mal interessant, oder? Vorallem sieht man schön, wie furchtbar ineffektiv der Pentium II ist. Awk und Perl sind übrigens Skriptsprachen. (Entnommen aus: The Practice of Programming; Kernighan, Pike)
@Sven Von wann ist dieser Performance vergleich? Wohl eher aus dem Mittelalter. Andreas hat schon recht. Aktuelle Java Programme erreichen die Performance von C++ Programmen. Da hat sich in letzter Zeit sehr viel getan in sachen Performance und Java.
Performancevergleiche zwischen Java und C* im Sekundenbereich sind sowieso sinnlos, weil man da nur die Startzeit misst, nicht die für die eigentliche Programmausführung. Ob zufällig oder nicht, eine grobe Tendenz die m.e. heute immer noch gilt kann man in diesen Ergebnissen trotzdem feststellen: - eine relativ unbedeutende Performancesteigerung (Perl vs. C) erkauft man sich oft mit einem vielfach höheren Entwicklungsaufwand - Java hat ein ungünstiges Verhältnis zwischen Ausführungs- und Entwicklungsaufwand
Das Hauptproblem von C# ist, dass da immer noch FCKW als Treiber verwendet werden. Die zerfressen ja bekannticherweise die Ozonschicht. Java wurde seit Version 5 auf HFA-134a umgerüstet und Java 7 wird dann sogar nur noch mit Druckluft laufen. Das ist viel umweltfreundlicher. Dass das ganze dann natürlich nicht mehr so schnell läuft wie C# ist natürlich klar, weil ja etwas nicht umweltfreundlich und gleichzeitig auch leistungsfähig sein kann. Was mich allerdings ein wenig traurig stimmt und was viele Leute auch gar nicht wissen: Microsoft ist ja im grossen Stil an den drei grössten Sonnencréme-Herstellern der Welt beteiligt: Frisco, Findus und Dr. Oetker. Darum nehmen sie es natürlich gerne in Kauf, dass die Ozonschicht durch ihre Programmiersprache zerfressen wird und dann besonders die hungernden Kinder in den äquatornahen Gebieten auf überteuerte Sonnenschutzmittel angewiesen sind. Das sind doch echt alles dreckige Mistkerle; jetzt ist's mir richtig schlecht.
Dieser Vergleich entstammt dem genannten Buch von 1999 (Auflage von 2005). Ok... :-) Der Vergleich ist an sich schon i.O.; die Daten beziehen sich auf die Laufzeit (d.h. für Java, die Ladezeit ist nicht dabei).
Ich habe letztens mal das Programm JOSM von Openstreepmap getestet. Dies ist wirklich ein Negativ-Beispiel für eine Java-Anwendung: http://wiki.openstreetmap.org/index.php/JOSM Extrem träge wenn man einen etwas größeren Kartenausschnitt hat, und das Look&Feel ist alles, auf jeden Fall nicht Windows. Ein Vorteil mag sein, dass die Anwendung auf anderen Systemen läuft. Allerdings ist diese lahme Software ein Grund dafür dass ich an dem (eigentlich interessanten) Projekt nicht teilnehme.
Java und C# sind für die Tonne. Wobei Java immernoch eine gewisse Berechtigung hat (für die Fließbandprogrammierer, die irgendwelche Programme zusammenschreiben müssen in denen nix, aber auch garnix neues steckt). Und was die Performance angeht: Jede Programmiersprache ist langsam, wenn der Programmierer keinen Plan vom Programmeschreiben hat. C und C++ bieten das beste Potenzial für schnelle Programme, aber wenn man damit net umgehen kann, kommt nix schnelles raus. Ich find solche Tests wie "wir nehmen das und das aus der jeweiligen Standardlib und machen was ganz einfaches damit" eh sinnbefreit. Ein guter C++ Compiler optimiert irgendwelche Codefolgen die sich über 10 Klassen erstrecken so, dass sie in der am häufigsten auftretenden Reihenfolge am schnellsten ausgeführt werden. Außerdem testet man so die jeweiligen Standardlibs, und nicht die eigentlichen Sprachen (btw. die von java ist nicht in java geschrieben, und die von c# warscheinlich nicht in c#... ratet mal wieso). Aber wie gesagt - die meisten Programme sind zu langsam weil die Programmierer zu unfähig waren. Heute geht das ja schon soweit, das bestimmte Sprachen in bestimmten Kreisen ungern gesehen werden, weil sie bestimmte Sachen können die andere Sprachen nicht können... so wie Mehrfachvererbung zB. Dabei geben die Leute damit nur ihre eigene Unfähigkeit zu, mit sowas klarzukommen und es notfalls nicht zu benutzen. Zu dem JOSM Zeugs: Ich kenn das Ding nicht, aber wenn das look&feel nicht windows-like ist, ist das eigentlich ein Vorteil. Andere Umgebungen benötigen viel weniger Aufwand für gleiche Ergebnisse. Vielleicht sollten die windowser mal von ihrem Ross runterkommen, die windows gui ist für PC-Neulinge ganz ok, das war's aber schon. Mit richtigen Bedienoberflächen sind Windowser doch total überfordert. Wenn das Ding klebt wie Kaugummi ist das natürlich 'ne andere Sache.
> malbolge :) ok die setzt sich sicher nicht durch, aber wer darin ein > programm schreibt der weiß wie man programmiert :) Würd ich jetzt mal so abändern: [...]aber wer darin ein programm schreibt der weiß wie man malbolge programmiert. Ist ja auch etwas, oder? Für BF gibts übrigens einen .NET Compiler. Das ist sehr praktisch, denn dann kann man die Programmteile, bei welchen es weder auf schnelle Entwicklungszeit noch auf hohe Performance ankommt in BF schreiben, und den Rest des Codes in einer anderen Sprache, meinetwegen IronPython.
Standardlibs von C#/Java > (btw. die von java ist nicht in java geschrieben, > und die von c# warscheinlich nicht in c#... ratet mal wieso). Die sind zu einem grossen Teil in C#/Java selber geschrieben. Die Klassen aus System.Collections z.B. sind IL-Code. Die Hashtable z.B. benutzt als unterliegenden Speicher ein .NET-Array. Einen grossen Teil der .NET-Bibiliotheken kannst du mit Reflector (http://www.aisto.com/roeder/dotnet/) in ziemlich lesbaren C# Code dekompilieren. Wäre das Zeug nativer Code, ginge das ziemlich sicher nicht.
Dann erklärt das wieso c# so grottenlahm ist. Bei Java sind glaub die meisten Container nicht in Java geschrieben, das sind auch die einzigen Sachen die mit C/C++ halbwegs mithalten können.
Andreas: >- Java hat ein ungünstiges Verhältnis zwischen Ausführungs- und >Entwicklungsaufwand Wie meinst denn das? Einsparung bei Entwicklungszeit zu gering?
Hier mal ein objektiver Performancevergleich verschiedener Programmiersprachen: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gpp Und trotzdem ist Performance nicht alles. Meisten lohnt es sich auch mal über den eignen Tellerrand zu schauen. yalu hats eigentlich schon auf den Punkt gebracht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.