nicht angemeldet
Hi Christian,
ich klinke mich jetzt einfach mal hier ein (im Parallelzweig wäre es genauso angebracht gewesen).
Weiterhin erlaube ich mir, die Struktur des Postings ein klein wenig zu verändern.
<moved>
Ich sags mal ganz klar und deutlich: ich mag Java nicht.
Das ist Dein subjektives Problem und kein objektives Argument.
<moved>
Ich halte Java fuer
umstaendlich, wenig kompfortabel, langsam und inkonsistent. Daran wirst du so
einfach nicht ruetteln koennen, denn ich habe es oft genug selber miterlebt
und erlebe es noch mit (ich muss fuer Lotus Domino 6 entwickeln).
Und Lust auf eine weitere Diskussion habe ich auch nicht. Martin hat mich nach
Gruenden gefragt, warum wir (bzw. Wilhelm) Java ablehnen. Ich habe sie
genannt.
Nein. Ich las keinen Grund/Beispiel für Umständlichkeit, geringe Komfortabilität und generelle Langsamkeit.
StringBuffer war nicht das einzige Beispiel. Derartige Schnitzer sind schlicht
und ergreifend ein Indiz fuer ein fehlerhaftes Konzept.
Eine suboptimale Umsetzung ist kein Beleg für Mängel des Konzepts.
Was hast du eigentlich für ein Problem mit einer Veränderung der API?
Um was für "Schnitzer" handelt es sich denn bei StringBuffer und Konsorten.
Dü würdest eine neu entwickelte API nie mehr verändern, auch wenn die praktische Erfahrung vieler Entwickler dies eigentlich nahelegt?
Programme, die mit einem alten API laufen, laufen generell auch weiterhin mit dieser API.
In den Bereichen, in welchen Java massivst eingesetzt wird (verteilte Businessapplikationen) sind die (äußerst selten vorkommenden!) Api-Anpassungen das _geringste_ Problem und die _einfachste_ Herausforderung.
Bei Java muss man viel auswendig lernen.
Generell setzt Erkenntnis Wissen voraus. Was aber, bitte schön, muss man auswendig lernen? Meinst Du die Java-Datentypen?
Nein. In machen Fällen vielleicht langsamer als C/C++. Aber ganz bestimmt
nicht _langsam_!
Doch.
Sehr überzeugend.
Java mag für "JPhotoshop" nicht geeignet sein, weil _dafür_ zu langsam.
Immer wider dieses dämliche "Java ist viel langsamer als C/C++ und was weiß ich nicht alles". Es sind nur wenige Programme ausgesprochen rechenintensiv. Die meiste Zeit "warten sie" auf Benutzereingaben, langsame Datenbank- oder Festplattenzugriffe. In den überwiegenden Fällen haben langsame Java-Applikationen ihre Ursache einfach in schlechtem Design und/oder schlechter Implementation* (manchmal ist auch durchaus die Entscheidung zu Java für die Problemlösung bereits der Fehler).
Wer eine potentiell performanzkritische Anwendung "mal so schnell" in Java schreiben will und wahl- und wissenslos die abstrakten Designmöglichkeiten von Java verwendet (Stichworte: Strings, Reader/Writer, Collection-Framework), ist selbst schuld.
Man könnte sogar augenzwinkernd sagen: JAVA zwingt den Entwickler wieder, über seine Arbeit nachzudenken ;-)
* Dies kann übrigens auch Folge der Kombination aus "jungem Alter" und gleichzeitigem Erfolg von Java sein (woran letzteres wohl liegt?).
Ein beliebiger Java-Editor. Nimm JBuilder, nimm JEdit, egal.
Eine repräsentative und umfangreiche Auswahl.
Ich finds schon krank, dass eine Firma mal eben so mir nichts, dir
nichts die APIs aendern kann.
Was ist daran krank - das nennt man Fortschritt, Weiterentwicklung. Übrigens passiert das bei SUN nicht "mir nichts, dir nichts". Vielleicht passiert es ohne Deine Zustimmung, aber solche Fragen können und werden vorher in Java Community diskutiert.
Eine API legt man einmal fest und schreibt dann hoechstens Erweiterungen.
Aha. Wo steht das?
Ich hab nicht unbedingt die groesste Lust, alles neu schreiben zu muessen.
Du plädierst für nichts anderes als Stillstand.
Java ist plattformunabhängig.
Perl auch.
Ist kein Gegenargument.
Java ist mächtig.
Das wage ich zu bezweifeln
Warum? Beispiele? Gründe (wo sind diese, ich warte immer noch)
aber Perl auch.
Java ist einfach.
Perl auch.
Die Java-Syntax ist für Programmiereinsteiger mit Sicherheit leichter zu erlernen. Ich halte Java sogar für elegant.
Wer ernsthaft damit arbeiten will, muss sich aber selbstverständlich ernsthaft und ausdauernd damit beschäftigen (OO!).
Java ist sicher.
Wie soll eine Sprache sicher sein?
Weil die (jdk)-VM bereits ein gewisses Maß an Sicherheit garantiert (z.B. Stack-Overflow Attacken, zumindest ist mir bisher noch keine bekannt). Das "Sandbox"-Modell ermöglicht die eine frei konfigurierbare Zugriffskontrolle auf Systemresouren, sei es aus lokalem oder "remote" Code. Weil auf Pointer und Pointerarithmetik verzichtet wird.
Letzteres ermöglicht prinzipiell auch die effizientere Entwicklung von robustem Code.
Fürderhin bietet Java:
- Unterstützung für Multithreading
- Unterstützung für verteilte Anwendungen
- Reflektions-Mechanismus
- strukturiertes Exception-Handling
- Unterstützung für Internationalisierung durch Unicode (alle Strings/Chars werden intern als Unicode-Zeichen behandelt)
- Java ist Binärcode-kompatibel
Viele Grüße,
Martin