Objekte und String

Zitat von hal

was bei C++ nicht möglich ist.

Ich kann genausogut Java Bytecode aus sauberem C++ erzeugen und den JIT-Compiler optimieren lassen, wie ich Java auf Maschinencode runterkompilieren kann. Wie ich ein Programm letztlich ausfuehre (VM, Interpreter, Compiler etc.), und wie effizient die gewaehlte Strategie ist, ist doch keine Eigenschaft der Sprache.

Garbage collection ist eine Selbstverstaendlichkeit fuer jede high-level Sprache seit den 60ern. Sie als "sehr wichtige Neuerung" zu bezeichnen ist entweder an Ignoranz oder Humor schwer zu ueberbieten.

Zitat

Generizität hätte auch vom Anfang an drin sein sollen.
Leider ist es unsauber und typunsicher implementiert,
damit man die JVM nicht updaten musste.

Full ack.
War ziemlich entäuscht davon, aber trotzdem besser als gar keine Generizität

Zitat

Schade, dass (trotz allen Gegenbekundungen) Java immer noch für Programme mit User Interfaces saulangsam ist und Swing so eine Krücke
(in jeder Hinsicht) ist.

Swing:
Ja, auch full ack.
Eine Zumutung für User und Programmierer.
Aber SWT/RCP find' ich beispiesweise gut/besser.
Und es gibt da noch genug andere - gute - Ansätze ...
Die Existenz eines langsamen/eher schlechten GUI Frameworks heisst IMHO nicht, daß Java generell ungeignet für GUI Anwendungen ist.

Zitat von Spockman

Garbage collection ist eine Selbstverstaendlichkeit fuer jede high-level Sprache seit den 60ern. Sie als "sehr wichtige Neuerung" zu bezeichnen ist entweder an Ignoranz oder Humor schwer zu ueberbieten.

Wenn du schon von Ignoranz sprichst, das "gegenüber C++" hast du überlesen, stimmts?

Zitat von Lord Binary

Die Existenz eines langsamen/eher schlechten GUI Frameworks heisst IMHO nicht, daß Java generell ungeignet für GUI Anwendungen ist.

Zustimmung von mir.

Übrigens: Wenn ich sage, "Java ist langsamer als C++", dann meine ich: "Die gebräuchlichen Java-Development-Systeme sind langsamer als die gebräuchlichen C++-Development-Systeme" (wo du DS durch Kombinationen von Compiler/Interpreter ersetzen kannst). Und das stimmt zweifellos immer noch (icc, msvc, g++, ...).

Zitat von Lord Binary

Die höchste Ebene dieser Schwachsinnigkeit kommt aber erst: Es ist völlig irrelevant

Aber z.b. nicht bei GUI-Anwendungen. Jedem graphischen Java-Programm, das ich bisher in die Finger bekommen habe, hat man sofort angesehen, dass es ein Java-Programm ist. Schon einfachste Aktionen laggen wie Sau.

Zitat von sauzachn

Wenn du schon von Ignoranz sprichst, das "gegenüber C++" hast du überlesen, stimmts?

Ja, und zwar bewusst und zu Deinen Gunsten. Mit dem Zusatz ist die Behauptung ja sogar faktisch falsch, da Garbage Collection nicht mal mehr noch Jahre vor der Entstehung von C++ eine "Neuerung" darstellte. Wie koennte sie es dann spaeter sein? Falls Du den Zeitverlauf in den Begriff der Neuerung nicht einbeziehst und nur Features vergleichst, halte ich in diesem Sinn Lisp-Makros fuer eine sehr wichtige Neuerung "gegenueber Java".

Zitat von sauzachn

Aber z.b. nicht bei GUI-Anwendungen. Jedem graphischen Java-Programm, das ich bisher in die Finger bekommen habe, hat man sofort angesehen, dass es ein Java-Programm ist. Schon einfachste Aktionen laggen wie Sau.

Ich hab schon welche benutzt, wo ich erst nachträglich gemerkt hab, in welcher Sprache sie verfasst wurden. Cocoa/Java machts möglich.

Zitat von hal

Ich hab schon welche benutzt, wo ich erst nachträglich gemerkt hab, in welcher Sprache sie verfasst wurden. Cocoa/Java machts möglich.

aslo ich finde die beste java Frontend hat Matlab 7x. Das ist sogar einigermassen zu bedienen (wenn man in den options den speicher erhoeht hat - sonst sind bei mir immer Out of Mem. errors gekommen). Andere gute bsp fuer eine brauchbare java Anwendungen sind Alice (http://www.alice.org) und Netlogo. Aber besonders moegen tu ich Java auch nicht (allerdings is das mehr Gefuehlssache)

Zitat von sauzachn

Java ist sogar ein sehr gutes Beispiel für eine OO Sprache.

Ich will Java nicht schlecht reden, aber auch wenn die Sprache
objektorientierte Programmierung prinzipiell unterstützt, macht es
sie auch durch die unzähligen Ausnahmen unnötig kompliziert.

Nicht nur primitive Datentypen, sondern auch Packages, Klassen,
Operatoren, null, loops, Blöcke oder Methoden haben in Java eine
Sonder rolle bekommen, so dass sie entweder nicht wie gewöhnliche
Objekte behandelt, oder zumindest von der Syntax speziell
berücksichtigt werden müssen.

Ein Folge dieser Ausnahmen ist zum Beispiel, dass Metaprogrammierung
und Reflection in Java viel komplizierter sind als in "reinen" OOP
Sprachen wie Smalltalk, Ruby oder Io.

Eine weitere Folge sind die unkonventionellen APIs, die aus der
uneinheitlichen Syntax entstehen. Dinge Math.abs(-5) oder
Collections.sort(list) zeugen nicht gerade von gutem Design.

Instanzvariablen können öffentlich sein, und wenn man ordentliche
Kapselung implementieren will, muss man einen Haufen Get- und
Setmethoden schreiben, auch wenn man sie zunächst überhaupt nicht
benötigen würde.

Siehe hierzu auch das letzte drittel von diesem Artikel auf meinem blog.

Ich schätze die Plattform Java, weil sie mir eine riesige
Bibliothekensammlung und einheitliche Schnittstellen zur Verfügung
stellt. Die Sprache an sich ist, das sehe ich wie Paul Graham, ein
langfristig gesehen toter Ast im Evolutionsbaum der
Programmiersprachen.

Zitat von Spockman

Mit dem Zusatz ist die Behauptung ja sogar faktisch falsch, da Garbage Collection nicht mal mehr noch Jahre vor der Entstehung von C++ eine "Neuerung" darstellte.

C/C++: hat keine Garbage Collection.
Java: hat Garbage Collection.

Java ist eine Nachfolgesprache von C/C++ -> Garbage Collection ist eine wichtige Neuerung in Java _gegenüber_ C++.

Ich verstehe deinen Einwand einfach nicht.

Natürlich gibt es GC schon sehr lange, aber eben nicht in C++, und nur auf diese Sprache habe ich mich in meiner Aussage bezogen.

> Nicht nur primitive Datentypen, sondern auch Packages,
> Klassen, Operatoren, null, loops, Blöcke oder Methoden
> haben in Java eine Sonder rolle bekommen, so dass sie
> entweder nicht wie gewöhnliche Objekte behandelt, oder
> zumindest von der Syntax speziell berücksichtigt werden
> müssen.

Ah, ok, darauf möchtest du hinaus.

Da musst du aber schon sehen, dass es zwei große Familien von OO Sprachen gibt: Die dynamischen (Smalltalk-ähnlichen) und die statischen (C++/Java/C#/Eiffel/...). Man kann jetzt ewig drüber diskutieren, welche davon besser ist. Aber eine Sprache ist nicht weniger OO, nur weil sie statisch ist und abseits von Objekten und Nachrichten auch andere Konzepte bietet.

> Eine weitere Folge sind die unkonventionellen APIs, die
> aus der uneinheitlichen Syntax entstehen. Dinge
> Math.abs(-5) oder Collections.sort(list) zeugen nicht
> gerade von gutem Design.

Das hat aber nur mit API-Design zu tun und nicht mit grundlegenden Eigenschaften von Java. Es spricht ja nichts dagegen, list.sort(); zu ermöglichen. Schwieriger wird es bei Konstanten, etwa wie in (-5).abs(); das in Java so ohne weiteres nicht möglich ist. Sollte aber zumindest über new Integer(-5).abs(); o.ä. erreichbar sein.

> Instanzvariablen können öffentlich sein, und wenn man
> ordentliche Kapselung implementieren will, muss man
> einen Haufen Get- und Setmethoden schreiben, auch wenn
> man sie zunächst überhaupt nicht benötigen würde.

Es gibt auch statische Sprachen, wo es so ist, dass man auf öffentliche Variablen nur lesend zugreifen kann. Eiffel z.b.

@Blog:
1. Die Anzahl der Keywords ist nicht wirklich ein geeignetes Mittel zur Bestimmung der Komplexität einer Sprache.
2. Dein Schleifenbeispiel kann man auch in nicht-dynamischen Sprachen durch spezielle Syntax ermöglichen (die Nachricht in Ruby muss auch irgendwie speziell implementiert sein, damit man damit eine Schleife darstellen kann), die Zeile "number += 25.percent_of number" schaut mit "number += 0.25*number;" auch nicht viel anders aus.
3. Variablen-Mitglieder einer Klasse sollten sowieso niemals öffentlich sein, da dadurch die Invarianten der Klasse von einem Client nicht beachtet werden müssen (z.b. dass x keine negativen Werte annehmen darf oder so was). Ich stimme aber zu, dass Setter/Getter-Methoden eine Krücke sind.
btw: Der physikalische Overhead im Vergleich zum restlichen Programm dürfte eher vernachlässigbar sein.
4. "Point = Struct.new(:x,:y,:color)" Zumindest in C++ kann man so etwas mit einem Präprozessor-Macro erreichen - wenn man wirklich will.

Zitat von so mancher

java..gui...langsam...aber

Ich glaube ein Grund, warum solche Diskussionen immer und immer
weitergeführt werden, ist, dass sich die Beteiligten fast immer auf
die Bereiche konzentrieren, in denen eine Sprache nicht so erfolgreich
ist.

Ich denke doch wir sind uns alle einig, dass keine Programmiersprache
und schon gar nicht die darunterliegende Plattform, alle
Anwendungsgebiete optimal abdecken kann, und dass man als
Programmierer sinnvollerweise eine Vielzahl von Sprachen lernt und
verwendet.

Warum sich also z.b. bei Kritiken immer nur auf die Bereiche stürzen, in
denen die Sprache eh nicht so erfolgreich ist (bei Java die
Standard-Desktopsoftware), anstatt sich auf tatsächlichen
Anwendungsgebiete zu konzentrieren?

Java wird heute in großflächigen Serverapplikationen, verteilten
Systemen, customized Desktopsoftware und mobilen Geräten
verwendet. Die übliche GUI für eine Javaapplikation ist HTTP&HTML,
und diese Applikationen laufen meist schneller als die meisten
Alternativen in diesen Sektor. Auch unter großer Last (siehe
z.B. http://ebay.com ).

Unternehmen, die eine Desktopapplikation in Auftrag geben, kümmern
sich meiner Erfahrung nach einen Sch... um Look&Feel, und wenn die GUI
etwas träge ist, dann kauft man eben nochmal ein GB RAM und die Sache
ist gegessen. wichtig ist hier, dass die Wartung so wenig Kohle wie
möglich kostet.

Zitat

Ich hab schon welche benutzt, wo ich erst nachträglich gemerkt hab, in welcher Sprache sie verfasst wurden. Cocoa/Java machts möglich.

Azureus find' ich ein gutes Beispiel für ein sehr gelungens Java-basierendes GUI.

Zitat von sauzachn

>Nicht nur primitive Datentypen, sondern auch Packages,
> Klassen, Operatoren, null, loops, Blöcke oder Methoden
> haben in Java eine Sonder rolle bekommen, so dass sie
> entweder nicht wie gewöhnliche Objekte behandelt, oder
> zumindest von der Syntax speziell berücksichtigt werden
> müssen.

Ah, ok, darauf möchtest du hinaus.

Da musst du aber schon sehen, dass es zwei große Familien von OO Sprachen gibt: Die dynamischen (Smalltalk-ähnlichen) und die statischen (C++/Java/C#/Eiffel/...). Man kann jetzt ewig drüber diskutieren, welche davon besser ist. Aber eine Sprache ist nicht weniger OO, nur weil sie statisch ist und abseits von Objekten und Nachrichten auch andere Konzepte bietet.

Da geb ich dir vollkommen recht. Aber ich habe ja vor allem die Ausnahmen in Javas OO Design kritisiert, und die meisten davon sind nicht abhaengig von statischer oder dynamischer Typisierung. Auch in einer statischen Sprache koennen Packages, Klassen, Operatoren, null, loops, Blöcke oder Methoden Objekte sein, die auch wie andere Objekte behandelt werden.

Zitat von sauzachn

> Eine weitere Folge sind die unkonventionellen APIs, die
> aus der uneinheitlichen Syntax entstehen. Dinge
> Math.abs(-5) oder Collections.sort(list) zeugen nicht
> gerade von gutem Design.

Das hat aber nur mit API-Design zu tun und nicht mit grundlegenden Eigenschaften von Java. Es spricht ja nichts dagegen, list.sort(); zu ermöglichen. Schwieriger wird es bei Konstanten, etwa wie in (-5).abs(); das in Java so ohne weiteres nicht möglich ist. Sollte aber zumindest über new Integer(-5).abs(); o.ä. erreichbar sein.

Du hast natuerlich recht was list.sort() betrifft. Da war es vermutlich nur zu muehsam, das Interface zu aendern. Die Math Klassen sind aber eindeutig eine Folge der Ausnahme "primitve datentypen", denn Integer(-5).abs() ist ja eher nicht so der Traum, nicht nur weil da insgesamt 3 Instanzen benoetigt werden, um den Wert zu ermitteln *g*.

Zitat von sauzachn

> Instanzvariablen können öffentlich sein, und wenn man
> ordentliche Kapselung implementieren will, muss man
> einen Haufen Get- und Setmethoden schreiben, auch wenn
> man sie zunächst überhaupt nicht benötigen würde.

Es gibt auch statische Sprachen, wo es so ist, dass man auf öffentliche Variablen nur lesend zugreifen kann. Eiffel z.b.

Ja, C# kennt auch etwas in der Art. Aber ich habe ja wie schon bemerkt nichts gegen statisch getypte Programmiersprachen.

Zitat von Lord Binary

Azureus find' ich ein gutes Beispiel für ein sehr gelungens Java-basierendes GUI.

Stimmt, Azureus hat eine sehr feine GUI. JEdit ist auch ein gutes Beispiel. Das ist Swing und das sieht man auch, der Editor lauft aber sehr effizient.

Zitat von sauzachn

> Siehe hierzu auch das letzte drittel von diesem Artikel auf meinem blog.
@Blog:
1. Die Anzahl der Keywords ist nicht wirklich ein geeignetes Mittel zur Bestimmung der Komplexität einer Sprache.

Zumindest bedingt schon, denn umso mehr eine Sprache durch ihre
natürliche Struktur ausdrücken kann, um so weniger keywords werden
benötigt. Aber der Vergleich mit Java war vielleicht nicht ganz
gerecht, da eine statisch getypte Sprache selbstverständlich mehr
keywords benötigt. Von daher geb ich dir Recht, und auch das das
Argument ziemlich wackelig ist. Ich hatte das geschrieben, kurz nachdem ich
mir Io angeschaut habe, das sich ruehmt, mit sehr wenig keywords
auszukommen.

Zitat von sauzachn

2. Dein Schleifenbeispiel kann man auch in nicht-dynamischen Sprachen durch spezielle Syntax ermöglichen (die Nachricht in Ruby muss auch irgendwie speziell implementiert sein, damit man damit eine Schleife darstellen kann), die Zeile "number += 25.percent_of number" schaut mit "number += 0.25*number;" auch nicht viel anders aus.

Ich hab ja Dich schon vorhin aufgeklärt, dass es mir gar nicht um
statisches typing geht. eine Syntax wie

100_000_000.times do 
   ...
end

ist in Ruby möglich, weil die Sprache Closures unterstützt und primitive
Datentypen Objekte sind. Und 25.percent_of number beschreibt
tatsaechlich, was da berechnet wird, 0.25 * number tut das nicht.

Zitat von sauzachn

3. Variablen-Mitglieder einer Klasse sollten sowieso niemals öffentlich sein, da dadurch die Invarianten der Klasse von einem Client nicht beachtet werden müssen (z.b. dass x keine negativen Werte annehmen darf oder so was).

Eine oeffentliche Variable ist an sich ja kein Problem, solange man
das Interface nicht ändern muss, wenn man auf Zugriffsmethoden
umsteigen muss. In Ruby kann man auf Objekte ohnehin nur ueber
Nachrichten/Methoden zugreifen, aber z.B in C# kannst du eine
Instanzvariable public machen, und wenn du später merkst, dass du noch
Überprüfungen machen musst, kannst Du auf GET/SET Methoden umsteigen,
ohne das sich das Interface nach außen ändert.

Zitat von sauzachn

4. "Point = Struct.new(:x,:y,:color)" Zumindest in C++ kann man so etwas mit einem Präprozessor-Macro erreichen - wenn man wirklich will.

In Ruby wird hier dynamisch eine Klasse erstellt, die aequivalent zu
der im blog vorgestellten Javaklasse ist. diese Klasse kann hinterher beliebig
erweitert und veraendert werden:

Point = Struct.new(:x,:y,:color)


class Point
  def foo
    "bar"
  end
end


p = Point.new(50,50)
p.foo

Btw.: 10 Things Every Java Programmer Should Know About Ruby

Auf jeden Fall vielen Dank fuer das Feedback!

Zitat von Swoncen

Was heißt es kann mehr? Es macht die Arbeit für den Programmierer leichter, aber wo sind bitte die Pointer?

igitt pointer! da bin ich wirklich froh, dass ich die in java los bin.

rein von der sprachen syntax & sematik bin ich eher der java-fan, da doch einiges klarer rüberkommt und der dualismus call by reference/value von C beseitigt ist.

Zitat von a9bejo

Eine oeffentliche Variable ist an sich ja kein Problem, solange man das Interface nicht ändern muss, wenn man auf Zugriffsmethoden umsteigen muss. In Ruby kann man auf Objekte ohnehin nur ueber Nachrichten/Methoden zugreifen, aber z.B in C# kannst du eine Instanzvariable public machen, und wenn du später merkst, dass du noch Überprüfungen machen musst, kannst Du auf GET/SET Methoden umsteigen, ohne das sich das Interface nach außen ändert.

Apple hat das übrigens in Java auch implementiert (weil das für Cocoa/Java notwendig ist), ist nur eine Frage der API bei dynamischen Programmiersprachen.

Zitat von klausi

igitt pointer! da bin ich wirklich froh, dass ich die in java los bin.

naja, eigentlich nicht los, sondern nur "versteckt".

und apropos performanz von gui anwendungen in java: kann mir keiner sagen, dass die nicht zach sind, weil die sind zach (und nein hal, eine combo von cocoa/java zählt nicht, und auch kein JNI, wenn dann 100% java).

Zitat von phudy

und nein hal, eine combo von cocoa/java zählt nicht, und auch kein JNI, wenn dann 100% java

Es gibt kein Java-GUI ohne JNI, das kann gar nicht funktionieren.

Und zum Thema GUI zeichnen in Java: Das wird in modernen GUIs ja nichtmal mehr in C/C++ gemacht, weil das zu langsam ist (wird auf die Grafikkarte ausgelagert). Wie soll Java da dann was ordentliches produzieren? Zaubern kanns auch net.