mikrocontroller.net

Forum: PC-Programmierung Ist C# klimaschädlich?


Autor: Kalle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da wird doch ein Riesenhaufen Code durchlaufen, oder?
Nein im Ernst - was denkt ihr über diese These?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :=)

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATOMLOL Lieber C# als Javageraffel!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ne, umgekehrt... Java hat Stil und ne Existenzberechtigung im Netz, .NET 
ist einfach ne billige Abklatsche schmoll

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Java hat Stil und ne Existenzberechtigung

Quatsch mit Sauce...Java ist einfach nur grottenlahm!

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wen interessiert Portabilität?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, die sich einen riesen Markt erschließen wollen, zum Beispiel... 
aber da gehört auch "ausgereifter", "sicherer" und "verbreiteter" dazu..

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Java und ausgereift? Ich lach mir einen Ast...alle Ritt kommt da ein 
Sicherheitsupdate oder ein Bugfix rein...janeeisklar...

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: G. L. (glt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Ralf Schwarz (spacedog) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (mrrotzi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel F: zähl mal ein paar (deiner Meinung nach) Nachteile von .NET 
auf! Würd mich interessieren!

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jürgen C (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ..... :-) )

Autor: Jonny Obivan (-geo-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: yalu (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey yalu cooler beitrag. wenn das mal nicht ein versöhnlicher beitrag 
ist.

Autor: Andreas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
malbolge :) ok die setzt sich sicher nicht durch, aber wer darin ein 
programm schreibt der weiß wie man programmiert :)

Autor: André (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
             250MHz R10000       400MHz Pentium II       Quelltextzeilen
C             0,36 sek            0,30 sek                150
Java          4,9                 9,2                     105
C++/deque     2,6                 11,2                    70
C++/list      1,7                 1,5                     70
Awk           2,2                 2,1                     20
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)

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf Schwarz (spacedog) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bartli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas:

>- Java hat ein ungünstiges Verhältnis zwischen Ausführungs- und
>Entwicklungsaufwand

Wie meinst denn das? Einsparung bei Entwicklungszeit zu gering?

Autor: Sid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein objektiver Performancevergleich verschiedener 
Programmiersprachen:

http://shootout.alioth.debian.org/debian/benchmark...

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.