Discussion:
Microsoft vergleicht Java und C#
(zu alt für eine Antwort)
Stefan Matthias Aust
2004-06-09 06:52:04 UTC
Permalink
Schon gesehen? ->
http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/

Ein IMHO sehr interessanter Vergleich von Java und C#. Verglichen
werden Java 1.4 und C# 1.0. Hier meine Anmerkungen:

Es wird erwähnt, dass C# mehrere public toplevel classes in einer Datei
haben kann. Finde ich irrelevant, ich denke in und entwickle mit
Klassen, nicht Dateien. Dateien sind ein notwendiges Übel. Die starke
Bindung zwischen Klassenname und Dateinamen macht es IMHO einfacher,
ohne IDE die richtige Datei zu finden - wenigstens für public toplevel
classes.

Alias bei import ist nett, aber bis auf den unsäglichen Konflikt bei
awt/util.List und Date hatte ich bislang noch keine Probleme, auch wenn
es in der Theorie nett wäre, Namenskonflikte durch Umbenennen während
des Imports zu lösen.

Einen Präprozessor als Teil der Sprachdefinition halte ich für unnötig.
Diesen kann man, wenn man es benötigt, durch externe Werkzeuge nachrüsten.

Einen Finalizer mit Destruktor-Syntax zu notieren so wie C# es macht
halte ich für irreführend.

Bei den Datentypen hat C# in für Geschäftsanwendungen wichtigen Datentyp
"decimal". Diesen könnte man duch BigInteger bzw. BigDecimal bei Java
realisieren, aber wegen des fehlenden operator overloadings ist es
anstrengend, mit diesen Objekten zu arbeiten. C# hat operator
overloading. Warum es daher ein eigener primitiver Datentyp sein musste
erschließt sich mir nicht.

Automatisches Boxing und Unboxing - und damit eine Vereinheitlichung der
Typhierarchie von primitiven und Objekttypen bietet Java leider erst mit
1.5. Bis dahin ist das ein Plus-Punkt für C#. Zudem ist die CLR laut
einem kleinen inoffiziellen Benchmark von mir wesentlich schneller als
die 1.5 beta1...

Enums kommen ebenfalls erst mit 1.5. Noch ein Plus-Punkt für C#.

Strings können in C# mit == verglichen werden, was dafür übergeschrieben
wurde. Vermeidet sicherlich viele Anfängerfehler, macht es aber lästig,
wenn man tatsächlich die Referenzen vergleichen will

((object) "a") == ((object) "b")

was zumindest ich in Java häufig brauche, weil ich gerne (aus
Effizienzgründen - ich kann nicht anders) mit intern'ten String arbeite.
Ob es derartige Strings in C# gibt, wird nicht erwähnt und ich weiss
es gerade nicht.

Strings, in denen \ kein Escape ist mögen für Windows-Dateinamen und
Reguläre Ausdrücke eine Erleichterung bieten, sind aber IMHO nicht
wirklich wichtig.

C# hat "unsigned" Datentypen. Macht das Rechnen einfacher. Ich finde
aber inkonsequent, dass es sonst immer T und uT gibt nur bei byte ist es
anders herum und dort ist byte unsigned unt sbyte ist die
vorzeichenbehaftere Variante.

Die Unterscheidung zwischen Werttypen und Referenztypen bei C# (bzw. der
CLR) ist eine wichtige, insbesondere da man mit "struct" eigene
Werttypen definieren kann. Noch ein Pluspunkt für C#.

Ebenfalls hilfreich ist, dass wahlweise integer Berechnung nicht einfach
klamheimlich überlaufen und das Vorzeichen wechseln. Ich verstehe
nicht, warum das nicht standardmäßig einen Fehler gibt. Wahrscheinlich
weil sonst zu viele unwissende oder schlampige Programmierer merken
würden, dass sie fehlerhaften Code schreiben.

Der Sinn von typeof und sizeof von C# erschließt sich mir nicht. Was
unterscheidet ersteres von .getType() und beim zweiten Operator kann ich
doch einfach in der Spec nachgucken...

Switch ist IMHO besser gelöst als in Java und man hat sich von
C-Kompatibiliät gelöst, was an sich schon mal gut ist :) Noch ein
Pluspunkt.

foreach-Schleifen aus C# gibt es in Java ab 1.5.

Den Zugriffsmodifikator "internal" finde ich gelungener als Javas
"package" Sichtbarkeit, die, da auf ein Package beschränkt,
normalerweise zu klein ist und unnötig oft zu "public" zwingt. Auch die
Entscheidung, private als default zu nehmen finde ich besser. Noch ein
Plus-Punkt.

Das in C# (und der CLR) alle Methoden mit einem Großbuchstaben anfangen
finde ich jedenfalls sehr verwirend. Ich bin das seit Jahren anders
gewöhnt und finde es schwer, auf diese Weise zwischen Klassen,
Namensräumen und Methoden zu unterscheiden. Daher ist das für mich ein
dicker Minuspunkt.

Mehr Freiheit bei der Signatur der Main-Methoden bei C# finde ich auch
nicht erstrebenswert.

Call-by-reference für Variablen ist nett... noch besser hätte ich aber
gefunden, wenn die Sprachen Tupel-Typen hätten und demzufolge mehrfache
Rückgabewerte zulassen würde. Bietet dummerweise weder Java noch C#.

Variable Argumente direkt statt extra ein Object[] zu benutzen finde ich
da wesentlich wichtiger und brauche ich häufiger. Schön, dass C# das
kann. Java wird's ab 1.5 können.

Properties machen IMHO den Code lesbarer - allerdings zu dem Preis von
mehr Syntax und der ewigen Entscheidung - nehme ich eine parameterlose
Funktion oder doch ein Property...

C# hat echte mehrdimensionale Array - ein Vorteil gegenüber Java. Punkt.

Der Artikel erwähnt, dass ein C#-Array eine Sort-Methode hat. Schön.
In Java gibt es aber wenigstens java.util.Arrays mit derartigen
statischen Hilfsfunktionen. Das unterschlägt der Artikel...

Das man in C# überschriebene Methoden mit "override" kennzeichnen muss
finde ich gut. Das man "virtual" 'dranschreiben muss finde ich
schlecht. Das man dadurch auch Methoden mit gleichen Namen in
Unterklassen definieren kann, ebenfalls, da nur verwirrend. Covariante
Rückgabetypen, die in Java erst ab 1.5 und nur mit generischen Typen
gehen, hat C# jetzt schon.

Wie ich schon sagte, ich finde Operator-Overloading gut und finde
schade, dass Java das nicht bietet. Dumm ist aber, dass es Operatoren
überhaupt gibt. Schöner und eleganter wäre, wenn das einfach
syntaktischer Zucker für normale Methoden wäre. Das hat keine Sprache
begriffen und implementiert. Man muss da zu Lisp, Smalltalk, Python,
Ruby gucken.

Und wenn schon nicht Operator-Overloading generell, dann wäre ich
glücklich wenn nur der Index-Operator [] überschreibbar wäre. Ein

map["Hallo"] = map["Welt"]

finde ich so viel besser und einheitlicher als

integerArray[0]
string.charAt(0)
list.get(0)
map.get(0)

was in Java nötig ist. Warum hat man eigentlich bei List und Map den
selben Namen gewählt? Ist das nicht inkonsequent in der Inkonsequenz?

Exceptions in C# sind niemals checked. Ich könnte damit leben. Ob es
ein Vorteil oder doch Nachteil ist, kann ich nicht sagen - tendiere aber
zu einem Vorteil, weil ich doch zu häufig in Java schon "normale"
Exceptions in Runtime-Exceptions verpacken musste, nur um sie durch
vordefinierte Interfaces zu schleusen.

Den kleinen Bruder von Attributen (Metadaten) bekommt Java mit 1.5.

Delegates sind IMHO elegant. Dafür hat Java anonyme innere Klassen, die
bei C# fehlen. Brauchbar wird C# 2.0, das closures haben soll... Das
lässt Java 1.5 vermissen.

In C# kann man Regionen als Unsafe erklären und dann mit Pointer
spielen, sodass jeder C-Entwickler neidisch werden kann. Das mag für
bestimmte Fälle hilfreich sein, ist aber natürlich tödlich für
plattformübergreifende Entwicklungen. Auch kann man sich damit u.U. die
allerseits beliebten Buffer-Overrun-Exploits einhandeln. Zumindest kann
man per Security-Einstellungen festlegen, ob Programme mit
unsafe-Einschlüssen gestartet werden dürfen oder nicht.

Was der Artikel nicht erwähnt ist PInvoke, eine Funktion, um einfach
DLLs aufzurufen. Auch nicht wirklich plattformübergreifend, aber doch
bei Mono z.B. der Grund, warum es schnell sehr viele existierende
Linux-Bibliotheken angebunden wurden konnten und deutlich bequemer als
der Krampf bei Java, jedes Mal den C-Compiler hervorzuholen und soll
blöde Glue-DLLs selbst zu schreiben. Etwas wie PInvoke kann man
natürlich auch in Java realisieren und es gibt IMHO Anbieter von
vergleichbaren Lösungen für Java.

Fazit: Die Sprache C# ist deutlich größer und komplexer und bietet
dafür einige interessante Zusatzfeatures. Diese alleine halte ich
alleridngs nicht für produktivitätssteigend. Die Produktivität mache
ich eher an der IDE fest und da kann ich jetzt keinen Vergleich von z.B.
Eclipse zu VS.NET anstellen. Ich würde allerdings unterstellen, dass
die fehlenden Refactorings bei VS.NET produktivitätshemmend sind. Eine
IDE wie SharpDevelop hat in meinen Augen keine Chance gegen etwas wie
Eclipse oder IDEA. Wer auf mehrdimensionale Array und Werttypen
angewiesen ist - etwa für komplexe mathematische Berechnungen - der ist
mit C# besser 'dran als mit Java. Ansonsten sind die einzelnen Features
nicht so wichtig. Einzig das erweiterte switch und die gotos habe ich
einmal zu schätzen gelernt. Es ist damit sehr einfach, Parser mittels
Generator zu bauen während man bei Java echt schleußlichen Code mit
benannten Schleifen erzeugen muss und zudem noch mit der 64K-Grenze der
VM kämpfen muss.

Die Klassenbibliotheken vergleicht der Artikel gar nicht - gerade hier
liegt aber IMHO die Mächtigkeit der Sprachen. Tatsächlich haben mir
eigentlich beide Sprachen viel zu viel Syntax und mindestens die hälfte
aller Features sollte lieber in der Klassenbibliothek liegen (etwa alle
Datentypen) und dafür sollte die Sprache lieber erweiterbar und
generischer sein. Das entspricht aber wohl nicht dem C-Erbe und ist
vielleicht auch laut Ansicht der Sprachentwickler zu
modern/exotisch/unheimlich, keine Ahnung...

Java 1.5 gleicht die meisten Sprachdefizite von Java gegenüber C# aus.

Allerdings wird auch hier aufgerüstet und C# 2.0 soll einige
interessante Neuerungen bieten - und die Sprache noch komplexer machen.

Dank closures wird C# erstmalig in die Austsche "languages which does
not suck immediately"-Kategorie aufgenommen werden können. Polymophe
Typen (aka generics) wird es auch geben - zusammen mit dem Versprechen,
dass diese im Gegensatz zu Java auch für primitive aka Wert-Datentypen
funktionieren. Iteratoren sind deutlich besser als in Java und es wird
"nullable"-Typen geben, also ein int, das auch keinen Wert haben kann -
Kompatibilität zu Datenbank, yeah. Hätte man ganz ohne primitive Typen
natürlich automatisch, aber das sieht wohl man wieder keiner... so ganz
habe ich aber vielleicht die doch recht lange Spec noch nicht verstanden.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Jan Sauerwein
2004-06-09 08:28:59 UTC
Permalink
Post by Stefan Matthias Aust
Schon gesehen? ->
http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/
Ein IMHO sehr interessanter Vergleich von Java und C#. Verglichen werden
Es wird erwähnt, dass C# mehrere public toplevel classes in einer Datei
haben kann. Finde ich irrelevant, ich denke in und entwickle mit
Klassen, nicht Dateien. Dateien sind ein notwendiges Übel. Die starke
Bindung zwischen Klassenname und Dateinamen macht es IMHO einfacher, ohne
IDE die richtige Datei zu finden - wenigstens für public toplevel
classes.
Eine Homage an die C-Entwickler, die auch in C# quasi-prozedural
entwickeln.
Post by Stefan Matthias Aust
Alias bei import ist nett, aber bis auf den unsäglichen Konflikt bei
awt/util.List und Date hatte ich bislang noch keine Probleme, auch wenn
es in der Theorie nett wäre, Namenskonflikte durch Umbenennen während des
Imports zu lösen.
Variable Namespaces wären generell etwas sehr schönes. Wobei man dies mit
Post by Stefan Matthias Aust
Einen Präprozessor als Teil der Sprachdefinition halte ich für unnötig.
Diesen kann man, wenn man es benötigt, durch externe Werkzeuge nachrüsten.
Was dabei vorteilhaft ist, ist die Tatsache, dass der Präprozessor immer
mit einer ähnlichen Syntax arbeitet. Zumindest der Aufruf dürfte identisch
sein. Bei Java habe ich da ziemliche Unterschiede (ich kenne allerdings
auch nur 2).
Post by Stefan Matthias Aust
Automatisches Boxing und Unboxing - und damit eine Vereinheitlichung der
Typhierarchie von primitiven und Objekttypen bietet Java leider erst mit
1.5. Bis dahin ist das ein Plus-Punkt für C#. Zudem ist die CLR laut
einem kleinen inoffiziellen Benchmark von mir wesentlich schneller als
die 1.5 beta1...
Was mich nicht überrascht, da CLR sehr gut auf ein OS abgestimmt wird. Sun
macht dies für eine ganze Reihe von Systemen, was zur Folge hat, dass man
nicht so viel Zeit in die Optimierung steckt wie es wünschenswert wäre.
(Wenigstens sollen sich mit 1.5 Programme die gleiche VM teilen können. Da
ich mich mit 1.5 noch nicht beschäftigt habe, bin ich da leider noch im
Hoff-Status.)
Post by Stefan Matthias Aust
Enums kommen ebenfalls erst mit 1.5. Noch ein Plus-Punkt für C#.
Einfache Enums kann man mit Java auch vor 1.5 realisieren:

int k = 5;
int PREDEF_VAR_1 = k++;
int PREDEF_VAR_2 = k++;
int PREDEF_VAR_3 = k++;

Aber natürlich sind Enums schöner.
Post by Stefan Matthias Aust
Strings können in C# mit == verglichen werden, was dafür übergeschrieben
wurde. Vermeidet sicherlich viele Anfängerfehler, macht es aber lästig,
wenn man tatsächlich die Referenzen vergleichen will
((object) "a") == ((object) "b")
Vor allem finde ich es nicht so berauschend eine Sonderregel einzuführen
nur um einen Anfängerfehler zu beheben. Denn einen Anfängerfehler macht man
nur am Anfang, dafür muss man mit dem umständlichen Verhalten auch später
leben.
Post by Stefan Matthias Aust
C# hat "unsigned" Datentypen. Macht das Rechnen einfacher. Ich finde
aber inkonsequent, dass es sonst immer T und uT gibt nur bei byte ist es
anders herum und dort ist byte unsigned unt sbyte ist die
vorzeichenbehaftere Variante.
Vorzeichenbehaftete und vorzeichenlose Datentypen unterscheiden sich nur
darin, wie auf das V-Flag reagiert wird. Am Liebsten hätte ich einfach ein
Objekt, dass den Datentyp repräsentiert (mit Länge - im Gegensatz zu
Smalltalk) und dann zwei Subklassen, die das Verhalten auf Vorzeichen
implementieren.
Post by Stefan Matthias Aust
Die Unterscheidung zwischen Werttypen und Referenztypen bei C# (bzw. der
CLR) ist eine wichtige, insbesondere da man mit "struct" eigene Werttypen
definieren kann. Noch ein Pluspunkt für C#.
Ich kenne C# leider nicht zu gut. Aber struct in C++ ist ein Horror, da es
als Klassen-Ersatz von vielen "Prozeduralen" verwendet wird. Selbst in
recht großen kommerziellen Bibliotheken. (Stichwort: Methoden für structs).
Post by Stefan Matthias Aust
Ebenfalls hilfreich ist, dass wahlweise integer Berechnung nicht einfach
klamheimlich überlaufen und das Vorzeichen wechseln. Ich verstehe nicht,
warum das nicht standardmäßig einen Fehler gibt. Wahrscheinlich weil
sonst zu viele unwissende oder schlampige Programmierer merken würden,
dass sie fehlerhaften Code schreiben.
Geht in die selbe Richtung wie signed-unsigned. Ich hätte generell gerne
Zugriff auf alle vier Assembler-Flags - zumindest als Exception. Als Error
würde ich es jedoch nicht implementieren, da es kein Fehler sein muss.
Post by Stefan Matthias Aust
foreach-Schleifen aus C# gibt es in Java ab 1.5.
Hier existiert meiner Meinung nach der größte Vorteil von C#. Schachtelbare
foreach-Schleifen über den gleichen Index. (Auch wenn dies schmerzfrei
eingesetzt zu ziemlich kryptischem Code führen kann.)
Post by Stefan Matthias Aust
Den Zugriffsmodifikator "internal" finde ich gelungener als Javas
"package" Sichtbarkeit, die, da auf ein Package beschränkt, normalerweise
zu klein ist und unnötig oft zu "public" zwingt. Auch die Entscheidung,
private als default zu nehmen finde ich besser. Noch ein Plus-Punkt.
Ich hätte lieber in Java protected kleiner. Also nur erbende Klassen und
nicht gleich das ganze Package.
Post by Stefan Matthias Aust
Das in C# (und der CLR) alle Methoden mit einem Großbuchstaben anfangen
finde ich jedenfalls sehr verwirend. Ich bin das seit Jahren anders
gewöhnt und finde es schwer, auf diese Weise zwischen Klassen,
Namensräumen und Methoden zu unterscheiden. Daher ist das für mich ein
dicker Minuspunkt.
Scheint mir eine Gefühlsaltlast aus C-Zeiten zu sein. Allerdings sind wir
hier in Deutschland durch "Subjekt prädikat Objekt" schon durch unsere
Muttersprache an das Java-Conventions-Modell gewöhnt. Angelsachsen kennen
diese strikte Unterscheidung von Groß-/Klein-Schreibung nicht schon mit der
Muttermilch.
Post by Stefan Matthias Aust
Mehr Freiheit bei der Signatur der Main-Methoden bei C# finde ich auch
nicht erstrebenswert.
Besonders bei großen Projekten ein echter Nachteil.
Post by Stefan Matthias Aust
Call-by-reference für Variablen ist nett... noch besser hätte ich aber
gefunden, wenn die Sprachen Tupel-Typen hätten und demzufolge mehrfache
Rückgabewerte zulassen würde. Bietet dummerweise weder Java noch C#.
Warum dann nicht auch Tripel? Ich habe mir so etwas auch mal gewünscht.
Doch finde ich es inzwischen nicht mehr so erstrebenswert. Man müsste den
Rückgabewerten Namen geben, oder aber die Reihenfolge ist der Selektor,
dies jedoch ist meiner Meinung nach nicht mehr sehr produktiv, da besonders
bei Fremdklassen sicher einige Fehler passieren. Und eine Unterscheidung
durch den Typ ist ja auch nicht möglich, da ja auch gleiche Typen
zurückgegeben werden können. Multiple Rückgabewerte vermisse ich gar nicht
mehr. Lieber wäre es mir, wenn wie in Smalltalk void verschwinden würde und
zumindest immer das gefragte Objekt zurückgegeben würde.
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde ich
da wesentlich wichtiger und brauche ich häufiger. Schön, dass C# das
kann. Java wird's ab 1.5 können.
Definitiv ein Vorteil von C#. Aber das Warten hat ja bald ein Ende.
Post by Stefan Matthias Aust
C# hat echte mehrdimensionale Array - ein Vorteil gegenüber Java. Punkt.
Nein. Ich kann mit Java meine Arrays wie mehrdimensionale Arrays verwalten.
Arrays fransen im Gegensatz zu C und C++ nicht aus, was für die
Mathematiker wichtig ist.
Post by Stefan Matthias Aust
Der Artikel erwähnt, dass ein C#-Array eine Sort-Methode hat. Schön. In
Java gibt es aber wenigstens java.util.Arrays mit derartigen statischen
Hilfsfunktionen. Das unterschlägt der Artikel...
Zumal eine Sort-Methode im Array selber recht Fehl am Platze ist. Array ist
ein Datenty. ADTs haben für gewöhnlich keine Methoden um sich selbst zu
verändern. Ich finde den Java-Ansatz daher sogar weit besser.
Post by Stefan Matthias Aust
Wie ich schon sagte, ich finde Operator-Overloading gut und finde schade,
dass Java das nicht bietet. Dumm ist aber, dass es Operatoren überhaupt
gibt. Schöner und eleganter wäre, wenn das einfach syntaktischer Zucker
für normale Methoden wäre. Das hat keine Sprache begriffen und
implementiert. Man muss da zu Lisp, Smalltalk, Python, Ruby gucken.
Solange es Operatoren gibt bin ich gegen deren Überladung, da damit viel zu
viel Probleme eingekauft werden, die ich mit Methoden nicht hätte. Das
Überladen von Operatoren müsste besonders dokumentiert werden, die Realität
zeigt jedoch, dass Operator-Überladungen meist gar nicht oder miserabel
dokumentiert werden. Das behindert meist sehr und ist höchst unproduktiv.
Bestes Beispiel ist dafür die Matrizenmultiplikation. Dafür den *-Operator
zu verwenden ist gefährlich, da die Matrizenmultiplikation nicht kommutativ
ist. Aber es gibt noch sehr viele andere Beispiele: -, [] für Zeichenketten
(eigentlich auch +).

Es ist zwar schön etwas wie:

s = "Anna liebt Otto."
s["Otto"] = "Franz"

zu haben. Dies ist jedoch manchmal recht verwirrend, da nicht intuitiv ist
wie der Operator funktioniert. Werden alle Ottos ersetzt? Können nur von
Leerzeichen getrennte Teile ersetzt werden order beliebige Zeichen Ketten?
Ersetzt der Operator überhaupt?
Post by Stefan Matthias Aust
Und wenn schon nicht Operator-Overloading generell, dann wäre ich
glücklich wenn nur der Index-Operator [] überschreibbar wäre. Ein
map["Hallo"] = map["Welt"]
finde ich so viel besser und einheitlicher als
integerArray[0]
string.charAt(0)
list.get(0)
map.get(0)
Was gibt zeichenkette[0] in Pascal aus?
Was gibt zeichenkette[0] in C aus?

Alleine diese Unterschiede machen eigentlich deutlich, dass die doch recht
aussagenlosen Operatoren einige Stolpersteine mit sich bringen.
Post by Stefan Matthias Aust
was in Java nötig ist. Warum hat man eigentlich bei List und Map den
selben Namen gewählt? Ist das nicht inkonsequent in der Inkonsequenz?
Jepp, da gebe ich dir Recht. Die Methodennamen der Klassenbibliothek hätten
wenigstens gleich sein sollen. Aber das passiert bei wachsenden Systemen
(die eine Abwärstkompatibilität behalten wollen) leider viel zu oft.
Post by Stefan Matthias Aust
Delegates sind IMHO elegant. Dafür hat Java anonyme innere Klassen, die
bei C# fehlen. Brauchbar wird C# 2.0, das closures haben soll... Das
lässt Java 1.5 vermissen.
Was ist für dich ein Delegate? Ist es nicht einfach ein Objekt, das von
einer Klasse als Funktionalitätslieferant benutzt wird? Sorry kenne C# wohl
zu wenig, aber wie kann man das eleganter lösen?
Post by Stefan Matthias Aust
In C# kann man Regionen als Unsafe erklären und dann mit Pointer spielen,
sodass jeder C-Entwickler neidisch werden kann. Das mag für bestimmte
Fälle hilfreich sein, ist aber natürlich tödlich für
plattformübergreifende Entwicklungen. Auch kann man sich damit u.U. die
allerseits beliebten Buffer-Overrun-Exploits einhandeln. Zumindest kann
man per Security-Einstellungen festlegen, ob Programme mit unsafe-
Einschlüssen gestartet werden dürfen oder nicht.
Definitiv ein Nachteil. Zumal man damit nicht nur den Buffer-Overrun
erzeugen kann. Man kann auch eine Menge anderer Dinge kaputt machen. Oder
hat man (im Gegensatz zu C) nur noch eine Sandbox, in der man spielen kann?
Post by Stefan Matthias Aust
Einzig das erweiterte switch und die gotos habe ich einmal zu schätzen
gelernt.
Wie gesagt, ich habe mich nur ca. ein halbes Jahr mit C# beschäftigt. Und
auch nur um es zu verstehen nicht selber zu schreiben. Aber GOTOs sind mir
persönlich verhasst, da es schwer ist sich durch Code mit Sprungmarken
durchzukämpfen. Was ich jedoch als extrem nützlich empfunden habe waren die
foreach-Schleifen. Und da besonders die Möglichkeit, zwei Schleifen mit dem
gleichen Index zu schachteln.
Post by Stefan Matthias Aust
Die Klassenbibliotheken vergleicht der Artikel gar nicht - gerade hier
liegt aber IMHO die Mächtigkeit der Sprachen. Tatsächlich haben mir
eigentlich beide Sprachen viel zu viel Syntax und mindestens die hälfte
aller Features sollte lieber in der Klassenbibliothek liegen (etwa alle
Datentypen) und dafür sollte die Sprache lieber erweiterbar und
generischer sein. Das entspricht aber wohl nicht dem C-Erbe und ist
vielleicht auch laut Ansicht der Sprachentwickler zu
modern/exotisch/unheimlich, keine Ahnung...
Nichts hinzuzufügen.

Jan


PS: zeichenkette[0] in Pascal die Länge der Zeichenkette, in C den ersten
Buchstaben.
Stefan Matthias Aust
2004-06-09 08:50:04 UTC
Permalink
Post by Jan Sauerwein
Post by Stefan Matthias Aust
Automatisches Boxing und Unboxing - und damit eine Vereinheitlichung
der Typhierarchie von primitiven und Objekttypen bietet Java leider
erst mit 1.5. Bis dahin ist das ein Plus-Punkt für C#. Zudem ist die
CLR laut einem kleinen inoffiziellen Benchmark von mir wesentlich
schneller als die 1.5 beta1...
Was mich nicht überrascht, da CLR sehr gut auf ein OS abgestimmt wird.
Oh, ich muss das klarstellen, damit ich nicht ab so fort falsch zitiert
werde: Das *autoboxing* alleine ist schneller, nicht etwa der Code an
sich. Da hat Java bei meinem Beispiel (JScheme vs. NScheme) klar die
Nase vorne.
Post by Jan Sauerwein
int k = 5;
int PREDEF_VAR_1 = k++;
int PREDEF_VAR_2 = k++;
int PREDEF_VAR_3 = k++;
Nicht wirklich.. Wie verhinderst du das Zuweisen von 2? Klar, du
kannst Objekte nehmen, aber wie serialisiert man die richtig? Das ist
echte Arbeit, die ein Compiler besser erledigen kann.
Post by Jan Sauerwein
Geht in die selbe Richtung wie signed-unsigned. Ich hätte generell gerne
Zugriff auf alle vier Assembler-Flags - zumindest als Exception. Als
Error würde ich es jedoch nicht implementieren, da es kein Fehler sein
muss.
Ich finde, dass Ganzzahlen niemals "überlaufen" sollten sondern dann
eben natlos in Bignum aka BigInters aka LargeIntegers überführt werden
sollten. Wer einen wraparound haben will, soll Modulo benutzen. Dazu
ist das ja da. Das kann dann die VM immer noch effizient implementieren.
Post by Jan Sauerwein
Ich hätte lieber in Java protected kleiner. Also nur erbende Klassen und
nicht gleich das ganze Package.
In Java 1.0 gab es mal kurzfristig "private protected" - das war IIRC
genau das.
Post by Jan Sauerwein
Post by Stefan Matthias Aust
Call-by-reference für Variablen ist nett... noch besser hätte ich aber
gefunden, wenn die Sprachen Tupel-Typen hätten und demzufolge
mehrfache Rückgabewerte zulassen würde. Bietet dummerweise weder Java
noch C#.
Warum dann nicht auch Tripel?
Tupel bzw. Tuple meint in allen mir bekannten Sprachen N-Tupel, also
Kombinationen beliebiger Stelligkeit. Das schließt Tripel mit ein.
Post by Jan Sauerwein
Man müsste
den Rückgabewerten Namen geben, oder aber die Reihenfolge ist der
Selektor, dies jedoch ist meiner Meinung nach nicht mehr sehr produktiv,
Das macht man doch automatisch durch Zuweisung, also

a, b = returnSomething()

Dies beißt sich natürlich mit Javas krankhaftem Zwang, überall einen Typ
annotieren zu müssen. Natürlich sollte das System die Typen von a und b
aus dem Kontext inferrieren können.

Desweiteren bietet sich als allgemeines Konzept pattern matching an.
Post by Jan Sauerwein
Lieber wäre es mir, wenn wie in Smalltalk
void verschwinden würde und zumindest immer das gefragte Objekt
zurückgegeben würde.
Ach, mir würde ja schon der ;-Operator zum Kaskadieren von Aufrufen
reichen. Mit der impliziten Rückgabe ist das so eine Sache. Wenn man
sich etwa darauf verlässt, dass ein setter den receiver zurückgibt - was
IMHO guter Stil wäre - und dann jemand treudoof

foo
^foo

foo: bar
^foo := bar

implementiert, ist das ein schwer zu findender Fehler. Explizit zu
sagen, dass nix zurückgegeben wird ist schon nett. Aber bitte nicht bei
"if" o.ä. So weit irgendwie möglich, solle alles einen funktionalen
Charakter haben. IMHO...
Post by Jan Sauerwein
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde
ich da wesentlich wichtiger und brauche ich häufiger. Schön, dass C#
das kann. Java wird's ab 1.5 können.
Definitiv ein Vorteil von C#. Aber das Warten hat ja bald ein Ende.
Beiden Sprachen fehlt aber ein "splice" oder wie das heißt, also diese
Möglichkeit:

int m1(int... params) {
m2(@params);
}

int m2(int a, int b, int c) {
...
}

Ja, ich weiss, dass das zu einem Laufzeitfehler wegen unpassender
Argumentanzahl kommen kann - na und? Jetzt muss man mühsamst
reflections benutzen und das gibt auch den selben potentiellen Fehler.
Post by Jan Sauerwein
Zumal eine Sort-Methode im Array selber recht Fehl am Platze ist. Array
ist ein Datenty.
Ja, aber das ist der Grundfehler. Es hat keine primitiven Datentypen zu
geben! Punkt. Da ist es schon gut, dass Array in C# wenigstens wie ein
Objekt (genauer eine Collection) wirkt.
Post by Jan Sauerwein
Solange es Operatoren gibt bin ich gegen deren Überladung, da damit viel
zu viel Probleme eingekauft werden, die ich mit Methoden nicht hätte.
Das Überladen von Operatoren müsste besonders dokumentiert werden
Wo du Smalltalk ein paar mal erwähnst. Dort hatte ich noch niemals
Probleme damit, dass es dort Methoden mit Operatornamen gibt, die man
selbstverständlich überladen kann...
Post by Jan Sauerwein
s = "Anna liebt Otto."
s["Otto"] = "Franz"
zu haben. Dies ist jedoch manchmal recht verwirrend, da nicht intuitiv
ist wie der Operator funktioniert.
Das würde ich überhaupt nicht zulassen.... Das hat doch nichts mit der
Möglichkeit des Operator-Overloadings zu tun. EIn

s.atput("Otto", "Franz")

wäre exakt genauso mehrdeutig.
Post by Jan Sauerwein
Jepp, da gebe ich dir Recht. Die Methodennamen der Klassenbibliothek
hätten wenigstens gleich sein sollen. Aber das passiert bei wachsenden
Systemen (die eine Abwärstkompatibilität behalten wollen) leider viel zu
oft.
Und noch ein paar Alias-Namen mehr wären nicht gegangen? Hat man jemand
GridBagLayout gesehen, wo einige Namen GROSS geschrieben wurden und wo
man jetzt die selben Methodennamen nochmal mit Kleinbuchstabe
hinzugefügt hat? Oder bei Color, wo man die Farbkonstanten jetzt GROSS
schreibt? Warum hätte man nicht auch size() parallel zu length()
implementieren können - oder anders herum?
Post by Jan Sauerwein
Was ist für dich ein Delegate? Ist es nicht einfach ein Objekt, das von
einer Klasse als Funktionalitätslieferant benutzt wird? Sorry kenne C#
wohl zu wenig, aber wie kann man das eleganter lösen?
Das ist quasi der Implementierer eines Microinterface, welches nur eine
Signatur vorgibt und wo der Name egal ist, etwa

interface ActionListener {
public *(ActionEvent e);
}

Deklariert man jetzt eine Variable mit diesem Typ, kann man jedes
Objekt, was eine passende Methode hat zuweisen. Das macht den Umgang
mit Events IMHO einfacher. Auch ist es angenehm (stelle ich mir vor,
hab's noch nie gemacht) wenn man nicht laufend den Standardcode für
EventQuellen, die Listener-Listen verwalten implementieren muss. In C#
addiert man einfach mit += (ja, man kann streiten, ob hier ein +=
wirklich eine gute Idee war) ein delegate und fertig.
Post by Jan Sauerwein
Post by Stefan Matthias Aust
In C# kann man Regionen als Unsafe erklären
Definitiv ein Nachteil. Zumal man damit nicht nur den Buffer-Overrun
erzeugen kann. Man kann auch eine Menge anderer Dinge kaputt machen.
Oder hat man (im Gegensatz zu C) nur noch eine Sandbox, in der man
spielen kann?
Jein. So absolut würde ich es nicht sehen. Es erlaubt definitiv eine
sanftere Migration von existierem C und C++ Code (gerade auch durch die
Existenz von Managed C und Managed C++) - in den Händen eines
verantwortungsvollen Entwicklers (sind wir doch alle, oder? :).
Weiterhin muss man halt für ein bisschen native-Code nicht sofort die
Sprache verlassen.
Post by Jan Sauerwein
Wie gesagt, ich habe mich nur ca. ein halbes Jahr mit C# beschäftigt.
Und auch nur um es zu verstehen nicht selber zu schreiben. Aber GOTOs
sind mir persönlich verhasst, da es schwer ist sich durch Code mit
Sprungmarken durchzukämpfen.
Du brauchst sie aber für State-Engines... und das goto zu cases-Marken
finde ich hinreichend eingeschränkt und 1000 mal besser als das von C
geerbte "fall through".


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Jan Sauerwein
2004-06-09 12:58:47 UTC
Permalink
Post by Jan Sauerwein
Geht in die selbe Richtung wie signed-unsigned. Ich hätte generell gerne
Zugriff auf alle vier Assembler-Flags - zumindest als Exception. Als
Error würde ich es jedoch nicht implementieren, da es kein Fehler sein
muss.
Ich finde, dass Ganzzahlen niemals "überlaufen" sollten sondern dann eben
natlos in Bignum aka BigInters aka LargeIntegers überführt werden
sollten. Wer einen wraparound haben will, soll Modulo benutzen. Dazu
ist das ja da. Das kann dann die VM immer noch effizient implementieren.
Wenn ich N, Z und Q als Zahlenräume abbilden will, dann ist das sicher
richtig. Aber signed kann man eben nicht durch Modulo verarzten.
Mathematisch gesehen müsste -7 % 5 gleich 3 sein und nicht -2. In Java (und
vielen anderen Sprachen) ist Modulo als Betragsfunktion mit aufgesetztem
Vorzeichen implementiert. Ich muss also immer selber mit dem Verschieben um
n Stellen dafür sorgen, dass mein Z/nZ erhalten bleibt. Die Unendlichkeit
von Q wird schon durch die mangelnde Genauigkeit ein Problem. Und wir sind
immer noch bei den abzählbar unendlichen Körpern. Darüber ist dann
endgültig der Ofen aus. Trotzdem tun fast alle System (auch Smalltalk) so
als gebe es diese "natürlichen" Grenzen nicht.

Aber wenn man das Ganze nicht mathematisch betrachtet, sind die Flags V, N,
Z und C des x86 und vieler anderer Architekturen als Überlauf gar nicht so
falsch. Sicher eine Hochsprache hat (oder besser sollte) die Aufgabe haben
mich die Probleme und Wehwehchen der darunter verborgenen Maschine
möglichst wenig spüren zu lassen. Und begrenzte Datentypen sind so ein
Wehwehchen. Ich habe also einen Kompromiss:

Wie wäre es mit einer "unendlichen" Wrapperklasse für Zahlen (im folgenden
als Beispiel für Ganzzahlen, Fließkomma ginge aber nach IEEE754 auch), die
mir Methoden liefert um zu erkennen ob an gewissen Grenzen Überläufe
entstehen würden und mir auch die Ergebnisse bei Beschränkung als neue Zahl
liefern könnten. (Auch wenn ich persönlich dennoch lieber einzelne Klassen
dafür hätte.)
Einig darüber, dass Typen an sich schon ein Fehler sind, sind wir uns ja.
Post by Jan Sauerwein
Ich hätte lieber in Java protected kleiner. Also nur erbende Klassen und
nicht gleich das ganze Package.
In Java 1.0 gab es mal kurzfristig "private protected" - das war IIRC
genau das.
Hat es das in die 1.0.0 final geschaft gehabt? Hab hier leider nur noch
eine 1.0.2 und da ist es nicht mehr drin.
Post by Jan Sauerwein
Man müsste
den Rückgabewerten Namen geben, oder aber die Reihenfolge ist der
Selektor, dies jedoch ist meiner Meinung nach nicht mehr sehr produktiv,
Das macht man doch automatisch durch Zuweisung, also
a, b = returnSomething()
Aber wie machst du es dann, wenn du nur Wert b brauchst?
Dies beißt sich natürlich mit Javas krankhaftem Zwang, überall einen Typ
annotieren zu müssen. Natürlich sollte das System die Typen von a und b
aus dem Kontext inferrieren können.
Diesen Zwang emfinde ich als äußerst wohltuend. Um beim Vergleich mit
Smalltalk zu bleiben. Ich habe schon - ich weiß nicht mehr wie häufig -
Kostrukte gebaut um sicherzustellen, dass mein Übergabe-Parameter oder
Rückgabewert auch wirklich Subklasse einer bestimmten Klasse ist, dass ich
die sehr strenge Typisierung von Java lieben gelernt habe. Niemand hindert
mich daran in Smalltalk eine Klasse falsch anzusprechen. Dies finde ich
meistens durch den hervoragenden Debugger heraus, aber es gleich zu
unterbinden finde ich besser.
Desweiteren bietet sich als allgemeines Konzept pattern matching an.
Post by Jan Sauerwein
Lieber wäre es mir, wenn wie in Smalltalk
void verschwinden würde und zumindest immer das gefragte Objekt
zurückgegeben würde.
Ach, mir würde ja schon der ;-Operator zum Kaskadieren von Aufrufen
reichen. Mit der impliziten Rückgabe ist das so eine Sache. Wenn man
sich etwa darauf verlässt, dass ein setter den receiver zurückgibt - was
IMHO guter Stil wäre - und dann jemand treudoof
foo
^foo
foo: bar
^foo := bar
Sicher ein gefährlicher Fallstrick. Aber mit dem ;-Operator ist die
Rückgabe noch nicht gelöst. Ich habe es häufig, dass eine Methode ein
Objekt nur kurz etwas tun lässt bevor es zurückgegeben wird:

Object doIt(Object o) {
return o.makeSomething();
}

Und wenn bei "void" makeSomething() das Objekt selbst zurückgegeben würde
sähe das schon viel schöner aus.
implementiert, ist das ein schwer zu findender Fehler. Explizit zu
sagen, dass nix zurückgegeben wird ist schon nett. Aber bitte nicht bei
"if" o.ä. So weit irgendwie möglich, solle alles einen funktionalen
Charakter haben. IMHO...
Ich finde Kontrollstrukturen wie switch, if, for, while, ... sollten
generell aus der Klassenbibliothek kommen und nicht Schlüsselwörter und
Kontrollstrukturen der Klassenspezifikation.
Post by Jan Sauerwein
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde
ich da wesentlich wichtiger und brauche ich häufiger. Schön, dass C#
das kann. Java wird's ab 1.5 können.
Definitiv ein Vorteil von C#. Aber das Warten hat ja bald ein Ende.
Beiden Sprachen fehlt aber ein "splice" oder wie das heißt, also diese
int m1(int... params) {
}
int m2(int a, int b, int c) {
...
}
Damit hab ich mich nie richtig anfreunden können. Die meisten Sprachen
nehmen zwar bei @params > Parameter von m2 die ersten der Parameter, aber
das halte ich für ziemlich fehleranfällig. Wäre die Frage, wenn man mit
Variablen Parameterübergaben und variablen Parametertypen generisch
arbeitet, ob dies wirklich ein Entwicklungsvorteil ist.
Post by Jan Sauerwein
Zumal eine Sort-Methode im Array selber recht Fehl am Platze ist. Array
ist ein Datentyp.
Ja, aber das ist der Grundfehler. Es hat keine primitiven Datentypen zu
geben! Punkt. Da ist es schon gut, dass Array in C# wenigstens wie ein
Objekt (genauer eine Collection) wirkt.
Jaja. Aber sort hat auch nichts in dem Objekt Array nichts zu suchen. Ein
ADT muss das Einfügen, Löschen und den Zugriff (vielleicht auch noch das
Suchen) regeln, für den Rest ist er nicht zuständig. Das Ablaufen regelt
ein Iterator. Das Sortieren ist ja schon nicht einmal für jeden ADT
sinnvoll. Wie soll ich einen Heap sortieren? Wie soll ich einen binären
Suchbaum sortieren? Wie soll ich einen Graphen sortieren? Ich finde die
Lösung, die Sortierlogik in eine statische Methode einer Sammelklasse zu
packen, von Java recht gut. Zumal das Sortieren zusammen mit dem Mischen
und anderen (übrigens auch Suchen) Funktionen recht gut aufgehoben ist. Für
eine Klasse von ADTs brauch so auch der Algorithmus nur einmal verwendet
werden. Man könnte sich höchstens wünschen Array von List erben zu lassen.
Dann müsste man allerdings entweder int[] aus der Sprache verbannen oder
aber die primitiven Datentypen. (Mir wäre letzteres sehr recht - sprich
wenn wie in ST 3245 ein Objekt wäre, mit all den Mehtoden und Funktionen,
die ich bei Ganzzahlen erwarten würde plus obige Verwaltungsmethoden.
Post by Jan Sauerwein
Solange es Operatoren gibt bin ich gegen deren Überladung, da damit viel
zu viel Probleme eingekauft werden, die ich mit Methoden nicht hätte.
Das Überladen von Operatoren müsste besonders dokumentiert werden
Wo du Smalltalk ein paar mal erwähnst. Dort hatte ich noch niemals
Probleme damit, dass es dort Methoden mit Operatornamen gibt, die man
selbstverständlich überladen kann...
Bei Smalltalk gibt es nur sehr wenige Operatoren. Ad hoc fällt mir sogar
nur der Zuweisungsoperator ein und den kann ich nicht überladen (oder
doch?). Alle anderen "Operatoren" sind als Methoden, die zu einem Objekt
gehören implementiert. Richtig ein Operator ist eigentlich nichts anderes.
Es sei denn man nimmt Operatoren wie []. Diese gibt es in Smalltalk nicht.
Da hat Array zum Beispiel die Methode put:at:, was ist übrigens auch
schöner finde als [].
Post by Jan Sauerwein
s = "Anna liebt Otto."
s["Otto"] = "Franz"
zu haben. Dies ist jedoch manchmal recht verwirrend, da nicht intuitiv
ist wie der Operator funktioniert.
Das würde ich überhaupt nicht zulassen.... Das hat doch nichts mit der
Möglichkeit des Operator-Overloadings zu tun. EIn
s.atput("Otto", "Franz")
wäre exakt genauso mehrdeutig.
Was würde mich in Smalltalk daran hindern für Strings folgende Methode zu
implementieren:

string at:'Otto' put:'Franz'

Natürlich wäre die genauso mehrdeutig, aber während ich bei [] durch
Vorkenntnisse an ein Verhalten gewöhnt bin, bin ich dies bei einer
benannten Methode nicht - oder zumindest nicht so stark.
Post by Jan Sauerwein
Jepp, da gebe ich dir Recht. Die Methodennamen der Klassenbibliothek
hätten wenigstens gleich sein sollen. Aber das passiert bei wachsenden
Systemen (die eine Abwärstkompatibilität behalten wollen) leider viel zu
oft.
Und noch ein paar Alias-Namen mehr wären nicht gegangen? Hat man jemand
GridBagLayout gesehen, wo einige Namen GROSS geschrieben wurden und wo
man jetzt die selben Methodennamen nochmal mit Kleinbuchstabe hinzugefügt
hat? Oder bei Color, wo man die Farbkonstanten jetzt GROSS schreibt?
Warum hätte man nicht auch size() parallel zu length() implementieren
können - oder anders herum?
Du sagst selber, dass es (vor allem durch java.util.List) Beispiele gibt,
bei denen Aliase eingefügt wurden, dass es dir nicht schnell genug geht
verstehe ich.
Post by Jan Sauerwein
Was ist für dich ein Delegate? Ist es nicht einfach ein Objekt, das von
einer Klasse als Funktionalitätslieferant benutzt wird? Sorry kenne C#
wohl zu wenig, aber wie kann man das eleganter lösen?
Das ist quasi der Implementierer eines Microinterface, welches nur eine
Signatur vorgibt und wo der Name egal ist, etwa
interface ActionListener {
public *(ActionEvent e);
}
Deklariert man jetzt eine Variable mit diesem Typ, kann man jedes Objekt,
was eine passende Methode hat zuweisen. Das macht den Umgang mit Events
IMHO einfacher. Auch ist es angenehm (stelle ich mir vor, hab's noch nie
gemacht) wenn man nicht laufend den Standardcode für EventQuellen, die
Listener-Listen verwalten implementieren muss. In C# addiert man einfach
mit += (ja, man kann streiten, ob hier ein += wirklich eine gute Idee
war) ein delegate und fertig.
Was passiert wenn mein zugewiesenes Delegate Funktionalität besitzt, die
ich nicht weiterreichen will? Oder habe ich das falsch verstanden und ich
erstelle selbst dieses Interface? Dann wäre es wirklich eine recht schöne
Sache. Eine Frage noch, wenn ich die Funktionalität des Delegate noch etwas
modifizieren muss, wie mache ich das?
Post by Jan Sauerwein
Post by Stefan Matthias Aust
In C# kann man Regionen als Unsafe erklären
Definitiv ein Nachteil. Zumal man damit nicht nur den Buffer-Overrun
erzeugen kann. Man kann auch eine Menge anderer Dinge kaputt machen.
Oder hat man (im Gegensatz zu C) nur noch eine Sandbox, in der man
spielen kann?
Jein. So absolut würde ich es nicht sehen. Es erlaubt definitiv eine
sanftere Migration von existierem C und C++ Code (gerade auch durch die
Existenz von Managed C und Managed C++) - in den Händen eines
verantwortungsvollen Entwicklers (sind wir doch alle, oder? :). Weiterhin
muss man halt für ein bisschen native-Code nicht sofort die Sprache
verlassen.
Sicher Migration ist vor allem bei einer jungen Sprache wichtig. Leider
wird dies sicher nicht nur zur Migration bestehender Programme sondern auch
der eingefahrenen Verhalten der alten C-Entwickler führen, so dass dieses
Feature (oder doch Bug?) dazu führt, dass es auch in zukünftigen Programmen
wohl etwas zu häufig als Wurschtellösung benutzt wird.
Post by Jan Sauerwein
Wie gesagt, ich habe mich nur ca. ein halbes Jahr mit C# beschäftigt.
Und auch nur um es zu verstehen nicht selber zu schreiben. Aber GOTOs
sind mir persönlich verhasst, da es schwer ist sich durch Code mit
Sprungmarken durchzukämpfen.
Du brauchst sie aber für State-Engines... und das goto zu cases-Marken
finde ich hinreichend eingeschränkt und 1000 mal besser als das von C
geerbte "fall through".
Vielen Dank für die Erklärung. Aber wie viele Fälle gibt es in denen der
"fall through" nicht ausreicht?

Jan
Stefan Matthias Aust
2004-06-09 14:11:43 UTC
Permalink
Post by Jan Sauerwein
Einig darüber, dass Typen an sich schon ein Fehler sind, sind wir uns ja.
Nein. Typen an sich sind etwas feines. Wir sind uns einig darüber,
dass primitiven Datentypen parallel zu Objekttypen ein Fehler sind :)
Post by Jan Sauerwein
Hat es das in die 1.0.0 final geschaft gehabt? Hab hier leider nur noch
eine 1.0.2 und da ist es nicht mehr drin.
Google sagt ->
http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html
Post by Jan Sauerwein
Post by Stefan Matthias Aust
a, b = returnSomething()
Aber wie machst du es dann, wenn du nur Wert b brauchst?
_, b = returnSomething()

oder - angeleht an ML (glaube ich)

b = returnSomething()#2

Die erste Variante gefällt mir besser.
Post by Jan Sauerwein
Post by Stefan Matthias Aust
Dies beißt sich natürlich mit Javas krankhaftem Zwang, überall einen
Typ annotieren zu müssen. Natürlich sollte das System die Typen von a
und b aus dem Kontext inferrieren können.
Diesen Zwang emfinde ich als äußerst wohltuend.
Ich finde den Zwang nicht wohltuend. Ich habe beim Typsystem von Java
immer fast körperliche Schmerzen :) Dieser dümmliche Compiler kann doch
bitte nun wirklich wissen, dass bei

Person p = new Person();

"p" eine Person ist. Warum muss ich den Typ 2x hinschreiben? Oder auch

String s = "Hi";

Also ich weiss, dass etwas in " ein String ist. Der Compiler etwa
nicht? Wie blöd ist das?

Ich hatte neulich ein bisschen mit Scala gespielt - die Sprache macht es
IMHO richtig. Dort werden derartige Typen selbstredend inferriert. Man
muss eigentlich nur bei Methoden ab und zu einen Parameter oder
Rückgabetyp angeben - den Rest erledigt der Compiler. Und typsicher ist
es trotzdem.
Post by Jan Sauerwein
Smalltalk zu bleiben. Ich habe schon - ich weiß nicht mehr wie häufig -
Kostrukte gebaut um sicherzustellen, dass mein Übergabe-Parameter oder
Rückgabewert auch wirklich Subklasse einer bestimmten Klasse ist
Dieses Problem hatte ich fast nie. Einmal hatte ich ein Programm, wo
wild durcheinander String und Symbol benutzt wurde und wechselweise =
und ==. Da hätte ich mir eine klarere Unterscheidung gewünscht - aber
das war dann mit

Object>>assureSymbol
self error: 'I''m not a symbol'
Symbol>>assureSymbol
self

nach einem Testlauf erledigt. Ich gebe aber gerne zu, dass ich das auch
gerne statisch auseinander devidiert hätte. Doch das gelingt mit mit
normalen und internten Strings in Java noch weniger als in Smalltalk, wo
das wenigstens zwei Klassen sind.
Post by Jan Sauerwein
Rückgabe noch nicht gelöst. Ich habe es häufig, dass eine Methode ein
Object doIt(Object o) {
return o.makeSomething();
}
Und wenn bei "void" makeSomething() das Objekt selbst zurückgegeben
würde sähe das schon viel schöner aus.
KLar, in Java ist das jetzt der typische prozedurale Mehrzeiler:

o.makeSomething();
return o;

Aber niemand hindert dich daran, zumindest alle eigenen Methoden so zu
bauen, dass der Empfänger zurückgeliefert wird. Allerdings will man
generische Typen haben, damit das nicht in eine Cast-Orgie ausartet.
Also hindert einen Java-1.4 und früher schon effektiv daran. Zudem sind
die vielen "return this" im Code lästig. Und die extra-Typdeklaration,
die der Compiler mal wieder auch prima selbst herausbekommen kann. Er
wird ja wohl den Typ von "this" kennen...
Post by Jan Sauerwein
Ich finde Kontrollstrukturen wie switch, if, for, while, ... sollten
generell aus der Klassenbibliothek kommen und nicht Schlüsselwörter und
Kontrollstrukturen der Klassenspezifikation.
Dazu braucht es aber erstmal eine Sprache, die mächtig genug ist. In
Java bräuchtest du mindestens ein if. Oder du musst auf true und false
verzichten, und es so wie in Smalltalk machen. Aber dann kann man sich
nicht mehr vor anonymen inneren Klassen retten...
Post by Jan Sauerwein
Damit hab ich mich nie richtig anfreunden können. Die meisten Sprachen
aber das halte ich für ziemlich fehleranfällig.
Ich schrieb doch, das ist nicht fehleranfälliger als die nun notwendige
Reflection. ALso ist das schon mal kein Grund, es nicht zu haben.
Post by Jan Sauerwein
Jaja. Aber sort hat auch nichts in dem Objekt Array nichts zu suchen.
Ein ADT muss das Einfügen, Löschen und den Zugriff (vielleicht auch noch
das Suchen) regeln, für den Rest ist er nicht zuständig.
ADT ist ein Konzept, von dem ich mir nicht sicher bin, dass es zur OOP
gehört. Daher würde ich nicht derart argumentierne. Ein Array ist ein
Objekt mit einem bestimmten verhalten. UNd wenn man meint, dass
sortieren dazu gehört, dann ist das gut so. Da kannst du IMHO nicht mit
ADT argumentieren.
Post by Jan Sauerwein
Wie soll ich einen Heap sortieren? Wie soll ich einen
binären Suchbaum sortieren? Wie soll ich einen Graphen sortieren?
Keine Ahnung. Das sind aber auch alles keine Arrays und verhindern
nicht, dass man diese trotzdem sortieren kann.
Post by Jan Sauerwein
Ich
finde die Lösung, die Sortierlogik in eine statische Methode einer
Sammelklasse zu packen, von Java recht gut.
Statische Methoden in Helferklassen sucken bigtime. Meine Meinung.
Entweder meine ganze Sprache ist operational und trennt sauber Klassen
und die Operationen auf den Klassen - siehe etwa CLOS. Oder aber es
sollte nur Methoden geben. Nicht aber noch statische Funktionen, die
man notgedungen in irgendwelchen Extraklassen (eigentlich nur
Namensräumen) sammelt, weil die Objekte, wo das eignetlich hingehört,
nicht mehr um diese Methoden erweitert werden können.
Post by Jan Sauerwein
Man könnte sich höchstens wünschen Array
von List erben zu lassen.
Natürlich müsste das so sein.
Post by Jan Sauerwein
Dann müsste man allerdings entweder int[] aus
der Sprache verbannen oder aber die primitiven Datentypen.
Beides :)
Post by Jan Sauerwein
(Mir wäre
letzteres sehr recht - sprich wenn wie in ST 3245 ein Objekt wäre, mit
all den Mehtoden und Funktionen, die ich bei Ganzzahlen erwarten würde
plus obige Verwaltungsmethoden.
Wenigstens auf Java-Ebene sollte es so aussehen. Wie es die VM macht,
ist egal. Da darf es gerne aus Effizienzgründen Bitfolgen geben, die
direkt als Werte interpretiert werden.
Post by Jan Sauerwein
Bei Smalltalk gibt es nur sehr wenige Operatoren.
Reine Definitionsfrage. Ich schrieb ja Methoden mit Operatornamen.
Typischerweise nennt man "+" einen Operator. In Smalltalk (oder Ruby)
ist das eine Methode. In C++ ist das nicht so eindeutig, denn da gibt
es nicht nur Methoden, sondern auch Funktionen. In C# sind alle
überladenen Operatoren durch statische Funktionen realisiert (meine
ich). Dort sind es also keine Methoden.
Post by Jan Sauerwein
Ad hoc fällt mir sogar
nur der Zuweisungsoperator ein und den kann ich nicht überladen (oder
doch?)
Nein. Aber man könnte den Compiler ändern :) Es gibt noch den
Return-Operator "^". Zusammen mit ";" haben haben wir sie dann alle.
Ich würde das aber streng genommen nicht als Operatoren bezeichnen
sondern als Syntax. Genau wie ( ) oder [ ].
Post by Jan Sauerwein
Es sei denn man nimmt Operatoren wie []
Warum ist dieser Index-Operator den anders als z.B. +? Das verstehe ich
nicht. In Ruby kann man etwa einfach

def []=(index)

schreiben und so diesen "Operator" definieren. In Smalltalk wäre das
ein at:put:.
Post by Jan Sauerwein
Smalltalk nicht. Da hat Array zum Beispiel die Methode put:at:, was ist
übrigens auch schöner finde als [].
Geht so. Ein

a[1+2] = hallo[..-2]

ist kürzer als ein

a at: 1 + 2 put: (hallo at: (0 to: -2))

aber dafür geht dann andererseits at:ifAbsent: at:ifPresent:
at:ifAbsentPut: usw. und das ist wieder schön übersichtlich.
Post by Jan Sauerwein
Was würde mich in Smalltalk daran hindern für Strings folgende Methode
string at:'Otto' put:'Franz'
Das fehlende Überladen von Methoden :) String kennt schon at:put: und
erwartet an erster Stelle ein Integer und an zweiter Stelle ein
Character. Du müsstest die Systemmethode ändern, was eine andere
Qualität hat und was ich nicht empfehlen würde. Du könntest aber
myAt:put: implementieren, dann mittels double-dispatch die neue Variante
und die alte existierende MEthode unterscheiden und dann deine neue
Variante implementieren. Klingt zu umständlich.
Post by Jan Sauerwein
Natürlich wäre die genauso mehrdeutig, aber während ich bei [] durch
Vorkenntnisse an ein Verhalten gewöhnt bin, bin ich dies bei einer
benannten Methode nicht - oder zumindest nicht so stark.
Ich höre dieses Argument immer wieder und kann es einfach nicht
nachvollziehen. Ob [] oder at:, das sind beides Zeichenfolgen ohne
qualitativen Unterschied. Das [] hat den Vorteil, dass es das Argument
gleich klammert, während das at: evtl. noch Klammern benötigt, wenn es
in größerem Zusammenhang benutzt wird (siehe beispiel oben). Daher wäre
erstmal die erste Variante einen Tick einfacher. Dafür ist, wie schon
erwähnt, die zweite Variante vielfältiger Erweiterbar. Das spricht denn
dafür. Unendschieden.

Smalltalk-76 hat übrigens einen Punkt (hier mal als @ geschrieben) statt
at: und ein @ und ein <- für at:put: benutzt. Das war dann die subscript
message. Etwa so

array @ 1 <- array @ 2

Finde ich eigentlich ganz schick, ist aber jetzt ein Sonderfall im
Parser, der @ ... <- zu @<- zusammenziehen muss. Statt ifTrue:ifFalse:
gab es eine cond-artige Syntax

a = 1 => ['eins'];
= 2 => ['zwei'];
= 3 => ['drei']

da kommt wohl der ";" her. Schließlich waren Schleifen noch keine
Methoden, sondern eben sondere Syntax...
Post by Jan Sauerwein
Was passiert wenn mein zugewiesenes Delegate Funktionalität besitzt, die
ich nicht weiterreichen will?
Das hat doch nur genau eine Methode, die erreichbar ist.
Post by Jan Sauerwein
Oder habe ich das falsch verstanden und
ich erstelle selbst dieses Interface?
Ja.

delegate void D(String s);

Jetzt z.B.

class A {
public void show(String s) { ... }
}

und dann kannst du

A a = new A();
D d = new D(a.show);
d("Hallo");

benutzen.

In Java wäre das

interface D {
void show(String s); // man beachte, ich MUSS einen Namen definieren
}
class A implements D {
// ich MUSS jetzt schon definieren dass das D erfüllt
public void show(String s) { ... }
}
A a = new A();
a.show();

In C# kann ich auch

class B {
void m1(String s) ...
void m2(String s) ...
}
B b = new B();
D d1 = new D(b.m1);
D d2 = new D(b.m2);

benutzen. Ja ich kann sogar dies machen:

D dd = d1 + d2;
dd("Hallo");

was dann beide Methoden aufruft. Das ist alles ein bisschen einfacher,
als mit EventListenern, EventListenerLists und EventSources herumzuwirbeln.
Post by Jan Sauerwein
Sicher Migration ist vor allem bei einer jungen Sprache wichtig. Leider
wird dies sicher nicht nur zur Migration bestehender Programme sondern
auch der eingefahrenen Verhalten der alten C-Entwickler führen, so dass
dieses Feature (oder doch Bug?) dazu führt, dass es auch in zukünftigen
Programmen wohl etwas zu häufig als Wurschtellösung benutzt wird.
Sehe ich nicht als so große Gefahr. Dazu gibt es dann tausende von
Artikeln, Tutorials und Büchern, die gute Entwicklung beibringen.
Zudem, ich bin darüber hinaus, dass ich mich von einer
Programmiersprache gängeln lassen will.
Post by Jan Sauerwein
Vielen Dank für die Erklärung. Aber wie viele Fälle gibt es in denen der
"fall through" nicht ausreicht?
Mein Fall war so einer. Quantifizieren kann ich das nicht.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Ram
2004-06-09 14:33:30 UTC
Permalink
Post by Stefan Matthias Aust
Person p = new Person();
"p" eine Person ist. Warum muss ich den Typ 2x hinschreiben? Oder auch
String s = "Hi";
Also ich weiss, dass etwas in " ein String ist. Der Compiler etwa
nicht? Wie blöd ist das?
Es kann ja sinnvoll sein, als Typ eine Oberklasse oder Schnittstelle
anzugeben. z.B.:

Map m = new HashMap()

Mich stört das "new" mehr, ich hätte gerne:

Map m = HashMap()

Warum wird das "new" in Java verlangt?

[Kontrollstrukturen mit der Sprache implementieren]
Post by Stefan Matthias Aust
Dazu braucht es aber erstmal eine Sprache, die mächtig genug ist.
Eben eine objektorientierte Sprache.
Post by Stefan Matthias Aust
Statische Methoden in Helferklassen sucken bigtime. Meine Meinung.
Entweder meine ganze Sprache ist operational und trennt sauber Klassen
und die Operationen auf den Klassen - siehe etwa CLOS. Oder aber es
sollte nur Methoden geben. Nicht aber noch statische Funktionen, die
man notgedungen in irgendwelchen Extraklassen (eigentlich nur
Namensräumen) sammelt, weil die Objekte, wo das eignetlich hingehört,
nicht mehr um diese Methoden erweitert werden können.
Das finde ich nicht so schlimm. Vielleicht nur eine
Fehlbezeichnung. Aber man kann es so sehen, daß man selber
"Klassen für Objekte" (alles ohne "static") schreibt und
"statische Klassen" (d.h. Klassen mit nur statischen
Einträgen) als Behälter für benannte Algorithmen. (Die sollte
möglichst generisch sein, also Schnittstellen oder möglichst
allgemeine Oberklassen als Parametertypen haben). Dann ist es
nur schade, daß solche Behälter auch "Klassen" genannt werden,
aber damit kann ich leben.
Stefan Matthias Aust
2004-06-09 18:46:21 UTC
Permalink
Post by Stefan Ram
Es kann ja sinnvoll sein, als Typ eine Oberklasse oder Schnittstelle
Map m = new HashMap()
Kann es das? Wie auch immer, Können oder Müssen ist ein Unterschied.
Ich will Typen angeben können und nicht müssen.
Post by Stefan Ram
Map m = HashMap()
Warum wird das "new" in Java verlangt?
Frag Gosling.
Post by Stefan Ram
[Kontrollstrukturen mit der Sprache implementieren]
Post by Stefan Matthias Aust
Dazu braucht es aber erstmal eine Sprache, die mächtig genug ist.
Eben eine objektorientierte Sprache.
Das hat weniger mit OO als mit Erweiterbarkeit zu tun. Reines Lisp oder
z.B. FORTH nicht nicht OO und trotzdem erweiterbar.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Ram
2004-06-09 19:08:34 UTC
Permalink
Post by Stefan Matthias Aust
Post by Stefan Ram
[Kontrollstrukturen mit der Sprache implementieren]
Post by Stefan Matthias Aust
Dazu braucht es aber erstmal eine Sprache, die mächtig genug ist.
Eben eine objektorientierte Sprache.
Das hat weniger mit OO als mit Erweiterbarkeit zu tun. Reines Lisp oder
z.B. FORTH nicht nicht OO und trotzdem erweiterbar.
In einer objektorientierten Sprache muß es IMO möglich sein,
alles, was sinnvollerweise als Objekt aufgefaßt werden kann,
auch als Objekt zu verwenden. (Im Zweifel: Mindestens alles,
was in Smalltalk als Objekt verwendet werden kann.) Daraus
folgt, daß dort Blöcke Objekte sind, woraus die
Erweiterbarkeit folgt. Wobei natürlich Blockliterale bequem
sind. In Java kann man so etwas teilweise mit anonymen inneren
Klassen nachbilden. In Java gibt es natürlich Blockliterale
(Quelltextnotation eines Blocks), aber ihr Wert ist kein
Objekt.

Allerdings gibt es auch Alternativen, um Kontrollstrukturen
einführen zu können, wenn Blöcke nicht Objekte sind: Sie
können teilweise auch mit Hilfe von trägen Parametern (wie in
der funktionalen Programmierung) implementiert werden. Oder
durch eine andere Möglichkeit, Blöcke als Daten zu behandeln
(LISP), auch wenn nicht als Objekte.

Vielleicht kann man Kontrollstrukturen mit einem guten
Makro-Assembler sogar noch besser implementieren als mit Java?
Jochen Theodorou
2004-06-09 19:43:34 UTC
Permalink
Post by Stefan Matthias Aust
Post by Stefan Ram
Es kann ja sinnvoll sein, als Typ eine Oberklasse oder Schnittstelle
Map m = new HashMap()
Kann es das? Wie auch immer, Können oder Müssen ist ein Unterschied.
Ich will Typen angeben können und nicht müssen.
ein Tribut an die statische Typisierung.
Post by Stefan Matthias Aust
Post by Stefan Ram
Map m = HashMap()
Warum wird das "new" in Java verlangt?
Frag Gosling.
Ich spekuliere mal, dass diese Form einem Methodenaufruf zu ähnlich ist.
Und wenn schon mit Methodenaufruf, dann doch die Variante

Map m = HashMap.new();

da hätte man doch kein extra Schlüsselwort gebraucht und diese dumme
Sonderform mit den Konstruktoren wäre auch nicht notwendig gewesen...
aber ach dann wäre new eine Art statische Methode und das Erzeugen eines
Objektes wird wieder unklar... ich meine wo wird hier das Objekt erzeugt?

public new() {
//do something
}


Aber eigentlich besteht dieses Problem bei einem Konstrultor doch auch,
oder?
Post by Stefan Matthias Aust
Post by Stefan Ram
[Kontrollstrukturen mit der Sprache implementieren]
Post by Stefan Matthias Aust
Dazu braucht es aber erstmal eine Sprache, die mächtig genug ist.
Eben eine objektorientierte Sprache.
Das hat weniger mit OO als mit Erweiterbarkeit zu tun. Reines Lisp oder
z.B. FORTH nicht nicht OO und trotzdem erweiterbar.
Tja... wie modellierrt man ein if ohne ?: und ohne select... irgendwo
muss man da doch was machen... Man kann das objekt natürlich vorgeben
und mit einer Art virtuellen Implementierung versehen ähnlich dem
JNI-Ansatz.

Gruss theo
Christian Wederhake
2004-06-10 02:11:51 UTC
Permalink
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Post by Stefan Ram
Map m = HashMap()
Warum wird das "new" in Java verlangt?
Frag Gosling.
Ich spekuliere mal, dass diese Form einem Methodenaufruf zu ähnlich ist.
Und wenn schon mit Methodenaufruf, dann doch die Variante
Map m = HashMap.new();
da hätte man doch kein extra Schlüsselwort gebraucht und diese dumme
Sonderform mit den Konstruktoren wäre auch nicht notwendig gewesen...
aber ach dann wäre new eine Art statische Methode und das Erzeugen eines
Objektes wird wieder unklar... ich meine wo wird hier das Objekt erzeugt?
public new() {
//do something
}
Aber eigentlich besteht dieses Problem bei einem Konstrultor doch auch,
oder?
Und man haette es genau wie dort loesen koennen, wenn man sich mal
anschaut, wie es schlussendlich kompiliert wird:

Der Konstruktor in

# class MyClass {
# MyClass($params) {
# }
# }

wird zu (ungefaehr):

# static MyClass <clinit>($params) {
# native_new();
# }

mit *IIRC* der Zusatzbedingung, nicht per invokestatic sondern per
invokespecial aufgrufen zu werden...
Gegen ein MyClass#new() als Constructor haette demnach nicht wirklich
etwas gesprochen, einzig die Reflection-API haette man vielleicht etwas
anders modelliert...

Ciao
Chris
--
Die Freiheit der Meinung setzt voraus, daß man eine hat.(Heinrich Heine)
Paul Ebermann
2004-06-10 07:32:24 UTC
Permalink
Post by Christian Wederhake
Und man haette es genau wie dort loesen koennen, wenn man sich mal
Der Konstruktor in
# class MyClass {
# MyClass($params) {
# }
# }
# static MyClass <clinit>($params) {
# native_new();
# }
Nicht <clinit>, sondern <init>.

Und ohne "native_new" - da ist stattdessen ein
super-Konstruktor-Aufruf.
Post by Christian Wederhake
mit *IIRC* der Zusatzbedingung, nicht per invokestatic sondern per
invokespecial aufgrufen zu werden...
Das native_new geschieht auf der Aufrufseite:


# MyClass mc = new MyClass();

# MyClass mc = native_new(MyClass)
# invoke_special(mc, <init>);



Paul
Christian Wederhake
2004-06-10 19:52:31 UTC
Permalink
Post by Paul Ebermann
Post by Christian Wederhake
Und man haette es genau wie dort loesen koennen, wenn man sich mal
Der Konstruktor in
# class MyClass {
# MyClass($params) {
# }
# }
# static MyClass <clinit>($params) {
# native_new();
# }
Nicht <clinit>, sondern <init>.
Selbstverstaendlich... Sorry... Ich scheine in letzter Zeit zuviele
static-initializer gesehen zu haebn... :-/
Post by Paul Ebermann
Und ohne "native_new" - da ist stattdessen ein
super-Konstruktor-Aufruf.
Den hatte ich jetzt ja voellig vergessen, aber das macht ja zum Glueck
fuer die Veranschaulichung nichts... :-)

Aber dann gerne nachgereicht:
# static MyClass <linit>($params) {
# MySuperClass.<init>($params);
# }
Post by Paul Ebermann
Post by Christian Wederhake
mit *IIRC* der Zusatzbedingung, nicht per invokestatic sondern per
invokespecial aufgrufen zu werden...
*gruebel*
*jetztdochnachschlag*
*autsch*
Recht hast Du... Ich sollte mir dringends mal wieder einen Tag zum
generellen Doku-Lesen und -Auffrischen freinehmen, damit ich nicht
wieder unqualifizierten Bloedsinn ins Usenet blase... Ich hatte wirklich
schon bessere Zeiten... Was einem zuviel PHP nicht alles antun kann...
*schnueff*
Aber die Menge an fuer mich wirklich interessanten Java-Problemen
hat hier ja leider auch etwas abgenommen... IDEs, XML, Datenbanken
und J2EE so weit das Auge schaut... *nochmalschnueff* :-)
Post by Paul Ebermann
# MyClass mc = new MyClass();
# MyClass mc = native_new(MyClass)
# invoke_special(mc, <init>);
Bedankt fuer die Korrektur...

Ciao
Chris
--
"Jeder Mann wünscht sich eine Frau, klug genug, um ihn zu verstehen,
und dumm genug, um ihn zu bewundern." (Israel Zangwill)
Stefan Matthias Aust
2004-06-10 09:57:47 UTC
Permalink
Post by Jochen Theodorou
ein Tribut an die statische Typisierung.
Bestenfalls ein Gedenken an eine fehlende automatische Typinferrenz.
Post by Jochen Theodorou
Tja... wie modellierrt man ein if ohne ?: und ohne select... irgendwo
muss man da doch was machen...
In Smalltalk wird Polymorphismus genutzt. Die Konstanten true und false
sind jeweils die einzigen Exemplare der Klassen True und False. Ein

if (a > 3) { print("Hallo"); }

sieht in Smalltalk so aus

a > 3 ifTrue: ['Hallo' print]

und das wäre in Java wiederum ein

a.greater(3).ifTrue(new Block() {
public value() {
print("hallo");
}
});

wobei greater jetzt entweder True.INSTANCE oder False.INSTANCE zurück gibt.

abstract class Boolean {
abstract void ifTrue(Block b);
}
class True extends Boolean {
public static final INSTANCE = new True();
void ifTrue(Block b) { b.value(); }
}
class False extends Boolean {
public static final INSTANCE = new False();
void ifTrue(Block b) {}
}

Das selbe macht man jetzt für ifFalse und alle weiteren
Kontrollstrukturen. Ich habe jetzt unterschlagen, dass eigentlich alle
Methoden etwas zurückgeben, aber das Prinzip sollte klar sein.

Funktionale Sprachen nutzen meist pattern matching über Typen. Das ist
sehr ähnlich. Eine Sprache wie FORTH manipuliert einfach ihren eigenen
internen Zustand und sagt sich so quasi selbst, wo es weiter geht. Es
geht also ohne eingebautes "if" und ohne "JNI".


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Ram
2004-06-10 10:20:20 UTC
Permalink
Post by Stefan Matthias Aust
a > 3 ifTrue: ['Hallo' print]
und das wäre in Java wiederum ein
a.greater(3).ifTrue(new Block() {
public value() {
print("hallo");
}
});
WIMRE kann man aus "value" nun nicht auf den "Block" umgebende
Variablen zugreifen (wenn diese nicht "final" sind). Also ist
es eben leider kein Block.
Stefan Matthias Aust
2004-06-10 11:22:53 UTC
Permalink
Post by Stefan Ram
WIMRE kann man aus "value" nun nicht auf den "Block" umgebende
Variablen zugreifen (wenn diese nicht "final" sind). Also ist
es eben leider kein Block.
Mein Beispiel war mit bedacht so einfach gewählt, dass es auch in Java
funktioniert :) Und natürlich kann man, es ist nur umständlicher. Man
muss hat statt

int i;

ein

final int[] iref = new int[1];

benutzen und dann statt

i

ein

i[0]

Das hätte natürlich auch der Sun-Compiler bei seinen bemühungen, innere
Klassen zu implementieren ebenfalls noch ersetzen können... man wollte
das offenbar aber nicht.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Jan Sauerwein
2004-06-10 11:45:08 UTC
Permalink
Post by Stefan Ram
Post by Stefan Matthias Aust
a > 3 ifTrue: ['Hallo' print]
und das wäre in Java wiederum ein
a.greater(3).ifTrue(new Block() {
public value() {
print("hallo");
}
});
WIMRE kann man aus "value" nun nicht auf den "Block" umgebende
Variablen zugreifen (wenn diese nicht "final" sind). Also ist
es eben leider kein Block.
Letzten Samstag/Sonntag gab es zur Implementierung eines Schalters eine
recht ähnliche Diskussion:

http://groups.google.de/groups?q=%22%5Blang%5D%5BOOP%5DSwitch,+on,+off,+true,+false%22+Jan+Sauerwein&hl=de&lr=&ie=UTF-
8&scoring=d&selm=opr849lasiqn70hu%40news.individual.de&rnum=6&filter=0

Hier hatte ich eine Block-Klasse entworfen mit der dann als innere Klasse
das ganze zu realisieren gewesen wäre. Aber Java ist einfach nicht in der
Lage so schön zu arbeiten wie es Smalltalk an dieser Stelle tut.

Jan
Wanja Gayk
2004-06-10 22:52:18 UTC
Permalink
Jochen Theodorou said...
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Post by Stefan Ram
Map m = HashMap()
Warum wird das "new" in Java verlangt?
Frag Gosling.
Ich spekuliere mal, dass diese Form einem Methodenaufruf zu ähnlich ist.
Und wenn schon mit Methodenaufruf, dann doch die Variante
Map m = HashMap.new();
da hätte man doch kein extra Schlüsselwort gebraucht und diese dumme
Sonderform mit den Konstruktoren wäre auch nicht notwendig gewesen...
Guter Punkt.
Man müsste die new-methode lediglich reservieren und immer static
machen.

Gruß,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Wanja Gayk
2004-06-10 22:49:57 UTC
Permalink
Stefan Ram said...
Post by Stefan Ram
Map m = HashMap()
Warum wird das "new" in Java verlangt?
Weil man das, was du schreibst, schnell mal mit ner Methode verwechselt.

Gruß,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Stefan Matthias Aust
2004-06-11 07:33:36 UTC
Permalink
Post by Wanja Gayk
Post by Stefan Ram
Warum wird das "new" in Java verlangt?
Weil man das, was du schreibst, schnell mal mit ner Methode verwechselt.
Na und? Ein Konstruktor ist doch auch nur eine Methode (wenn auch mit
einem unaussprechlichen Namen <init>)? Überzeugt mich nicht als
Argument. Eigentlich sollte es gar keinen Unterschied geben zwischen
"normalen" Methoden und Objekt-konstruierenden Methoden. Was ist denn mit

String m() { return "a" + "b"; }

Ist das auch ein Konstruktor? Liefert doch ein neues String-Element.
Müsste ich jetzt also

new m()

schreiben?


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Wanja Gayk
2004-06-11 17:08:07 UTC
Permalink
Stefan Matthias Aust said...
Post by Stefan Matthias Aust
Post by Wanja Gayk
Post by Stefan Ram
Warum wird das "new" in Java verlangt?
Weil man das, was du schreibst, schnell mal mit ner Methode verwechselt.
Na und? Ein Konstruktor ist doch auch nur eine Methode (wenn auch mit
einem unaussprechlichen Namen <init>)? Überzeugt mich nicht als
Argument. Eigentlich sollte es gar keinen Unterschied geben zwischen
"normalen" Methoden und Objekt-konstruierenden Methoden.
Richtig. Die Frage ist: wie willst du explizit angeben, dass du ein
Objekt erzeugen willst? Vponausen kein Problem, man würde z.B.
Foo myFoo = Foo.new();
schreiben, aber wenn wir nun die Konstruktor-Methode selbst anschauen,
wie schreiben wir die, so dass sie zur restlichen Syntax stimmig ist?
Weil man ja noch kein Objekt der Klasse hat, muss man die Methode im
zweifel statisch machen, also an die Klasse hängen. Das gibt wiederum
ein Problem mit dem Ausdruck, z.B.:

class Foo{
final int someValue;
public static Foo new(){
someValue = 10;
return this; <- passt nicht zur statik.
}
}

oder:

class Foo{
final int someValue;
public static Foo new(){
Foo object = super.new(); <- passt nicht wirklich zu "super".
object.someValue = 10;
return object;
}
}

oder:

class Foo{
final int someValue;
public static Foo new(){
Foo object = class.new(); <- sieht endlos aus.
object.someValue = 10;
return object;
}
}

Wobei mir die erste Variante noch am besten gefiele. Sieht aber nicht
minder nach einer weiteren Syntaxausnahme aus.

Vielleicht könnte ich mich damit anfreunden, dass es eine zentrale
Instanz gibt, an die man die Erzeugung delegiert, um die Methode nicht
statisch machen zu müssen:

class Foo{
final int someValue;
public Foo new(){
someValue = 10;
return this;
}

public static void main(String[] args){
Foo object = Runtime.new(Foo.class);
}
}

Aber wer verhindert hier, den Aufruf von "new" von ausserhalb der
runtime-Klasse?

Gruß,
-Wanja-



Gruß,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Christoph Jerolimov
2004-06-11 18:24:51 UTC
Permalink
Post by Wanja Gayk
Post by Stefan Ram
Warum wird das "new" in Java verlangt?
Richtig. Die Frage ist: wie willst du explizit angeben, dass du ein
Objekt erzeugen willst?
Ich wäre für die alte klassische Art der definition:

class Foo {
public Foo() {
}
}

Und verwenden ist doch noch viel einfacher, verstehe nicht warum dort
ein Schlüßelwort nötig sein sollte, bin also gegen:

new Foo()

und erst Recht gegen:


Foo.new()

Meine Idee wäre:

Foo()

:)


Und der Compiler sollte doch etwas wie folgt verstehen:

// Ohne! vorheriges Map m;
m = HashMap();
m.put("key", "value");


Gruß Christoph
Stefan Matthias Aust
2004-06-12 08:09:39 UTC
Permalink
Post by Christoph Jerolimov
// Ohne! vorheriges Map m;
m = HashMap();
m.put("key", "value");
Das wäre Typinferrenz. Allerdings würde ich mir schon wünschen, dass
man die Variable definieren muss. Sonst hast du Python oder Basic, was
implizit Variablen durch Zuweisung definiert.

Also so

var m = HashMap();

oder

let m = HashMap();


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Matthias Aust
2004-06-12 08:07:04 UTC
Permalink
Post by Wanja Gayk
Foo myFoo = Foo.new();
Dies wäre eine konsequnte Syntax, aber funktioniert nicht mit statischen
"Methoden". Dazu braucht man Metaklassen. Siehe auch Smalltalk oder
Ruby, wie das richtig geht.

Implizite Konstruktoren (also ganz ohne new) würde zu Java oder
allgemein Sprachen ohne Metaklassen besser passen. Python macht es auch
so - ich meine obwohl es da Metaklassen gibt?!


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Wanja Gayk
2004-06-10 22:48:47 UTC
Permalink
Stefan Matthias Aust said...
Post by Stefan Matthias Aust
Ich finde den Zwang nicht wohltuend. Ich habe beim Typsystem von Java
immer fast körperliche Schmerzen :) Dieser dümmliche Compiler kann doch
bitte nun wirklich wissen, dass bei
Person p = new Person();
"p" eine Person ist. Warum muss ich den Typ 2x hinschreiben? Oder auch
Es kann allerdings durchaus Sinn machen, um in einem Programm
Implementationen schnell zu tauschen. Wenn man sowas hat, wie:

Person p = new Woman("Lisa");

Kommt man im Programm nicht in Gefahr, etwas zu benutzen, wie:

p.doBirth();

Und kann daher notfalls die Implementation tauschen, indem man einfach
Person p = new Man("Lars");

Okay, blödes Beispiel, aber im Umgang mit Collections z.B. ist es gar
nicht so dümmlich.

Gruß,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Paul Ebermann
2004-06-09 19:24:18 UTC
Permalink
[...]
Post by Stefan Matthias Aust
Post by Jan Sauerwein
Man müsste
den Rückgabewerten Namen geben, oder aber die Reihenfolge ist der
Selektor, dies jedoch ist meiner Meinung nach nicht mehr sehr produktiv,
Das macht man doch automatisch durch Zuweisung, also
a, b = returnSomething()
Dies beißt sich natürlich mit Javas krankhaftem Zwang, überall einen Typ
annotieren zu müssen. Natürlich sollte das System die Typen von a und b
aus dem Kontext inferrieren können.
Das geht notfalls auch ohne, wenn man eine Syntax
für Tupeltypen (eventuell nur bei Methodenrückgabewerten)
hat. Zum Beispiel so:
---
public String, int returnSomething()
{
return "Hallo", 42;
}


String a;
int b;
a,b = returnSomething();
---

Oder mit Klammern:

---
public (String, int)returnSomething()
{
return "Hallo", 42;
}


String a;
int b;
(a,b) = returnSomething();
---

Das wird auch eindeutiger, wenn man Zuweisungen
wie

a = b, c = d, e = f;

machen will:

a = ((b,c) = (d, (e = f)));



Paul
Ortwin Glück
2004-06-09 08:54:17 UTC
Permalink
Post by Stefan Matthias Aust
Switch ist IMHO besser gelöst als in Java und man hat sich von
C-Kompatibiliät gelöst, was an sich schon mal gut ist :) Noch ein
Pluspunkt.
Das Beispiel mit der Switch-Kaskade ist aber schlecht, weil nicht OO.
Für sowas gibt's Hashmaps.
Post by Stefan Matthias Aust
Die Unterscheidung zwischen Werttypen und Referenztypen bei C# (bzw. der
CLR) ist eine wichtige, insbesondere da man mit "struct" eigene
Werttypen definieren kann. Noch ein Pluspunkt für C#.
Die gibts doch bei Java auch. Hier heissen sie halt primitive Typen und
alles andere sind Klassen.
Post by Stefan Matthias Aust
Call-by-reference für Variablen ist nett... noch besser hätte ich aber
gefunden, wenn die Sprachen Tupel-Typen hätten und demzufolge mehrfache
Rückgabewerte zulassen würde. Bietet dummerweise weder Java noch C#.
Kannst du mit einem Array / Klasse leicht lösen.
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde ich
da wesentlich wichtiger und brauche ich häufiger. Schön, dass C# das
kann. Java wird's ab 1.5 können.
Dafür gibt es die Polymorphie.
Post by Stefan Matthias Aust
Properties machen IMHO den Code lesbarer - allerdings zu dem Preis von
mehr Syntax und der ewigen Entscheidung - nehme ich eine parameterlose
Funktion oder doch ein Property...
Ich finde Properties machen den Code unlesbarer. Ich weiss bei einem
Variablenzugriff dann nie ob es ein Property ist, der Code ausführt!
Post by Stefan Matthias Aust
Der Artikel erwähnt, dass ein C#-Array eine Sort-Methode hat. Schön. In
Java gibt es aber wenigstens java.util.Arrays mit derartigen statischen
Hilfsfunktionen. Das unterschlägt der Artikel...
Die implementieren die Sortieralgorithmen dann wahrscheinlich auf den
Listenklassen nochmal .-)
Post by Stefan Matthias Aust
Exceptions in C# sind niemals checked.
Eine Katastrophe. Genau dieses Feature macht Java stark im
Exceptionhandling!
Post by Stefan Matthias Aust
Delegates sind IMHO elegant. Dafür hat Java anonyme innere Klassen, die
bei C# fehlen. Brauchbar wird C# 2.0, das closures haben soll... Das
lässt Java 1.5 vermissen.
Definitiv, Closures vermisse ich auch.
Post by Stefan Matthias Aust
In C# kann man Regionen als Unsafe erklären und dann mit Pointer
spielen, sodass jeder C-Entwickler neidisch werden kann.
Wüsste nicht wozu das gut sein soll.
Post by Stefan Matthias Aust
Was der Artikel nicht erwähnt ist PInvoke, eine Funktion, um einfach
DLLs aufzurufen.
Das einzig wahre Komponentenmodell ist doch CORBA, wie man an Gnome
sieht :-)
Post by Stefan Matthias Aust
Es ist damit sehr einfach, Parser mittels
Generator zu bauen während man bei Java echt schleußlichen Code mit
benannten Schleifen erzeugen muss und zudem noch mit der 64K-Grenze der
VM kämpfen muss.
Gut, bei Java enstehen einfach sehr viele freingranulare Klassen. Habe
ich irgendwie doch lieber als eine >64KB Klasse.

Ortwin Glück
Jan Sauerwein
2004-06-09 09:18:53 UTC
Permalink
Post by Ortwin Glück
Post by Stefan Matthias Aust
Die Unterscheidung zwischen Werttypen und Referenztypen bei C# (bzw. der
CLR) ist eine wichtige, insbesondere da man mit "struct" eigene
Werttypen definieren kann. Noch ein Pluspunkt für C#.
Die gibts doch bei Java auch. Hier heissen sie halt primitive Typen und
alles andere sind Klassen.
Java kennt keine Referenztypen. Genauer: Java kennt kein callByReference
und callByValue. Tiefenkopien müssen explizit angelegt werden, ansonsten
sind alle Verweise Zeiger auf ein Objekt im Speicher. Also wenn man so will
sind alle Klassen als Referenztypen implementiert und ein callByValue ist
nicht möglich. Primitive Datentypen können nicht als Referenz übergeben
werden und müssen als callByValue übergeben werden. Manchmal eine unschöne
Einschränkung.
Post by Ortwin Glück
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde ich
da wesentlich wichtiger und brauche ich häufiger. Schön, dass C# das
kann. Java wird's ab 1.5 können.
Dafür gibt es die Polymorphie.
Die aber nicht immer greift, bzw. manchmal recht umständlich ist.
Post by Ortwin Glück
Post by Stefan Matthias Aust
Exceptions in C# sind niemals checked.
Eine Katastrophe. Genau dieses Feature macht Java stark im
Exceptionhandling!
Das verstehe ich nicht? Die Tatsache, dass es Exceptions gibt, um die nicht
ich, sondern die VM sich kümmert finde ich nicht so prikelnd. (Error ist
etwas anderes.)
Post by Ortwin Glück
Post by Stefan Matthias Aust
Es ist damit sehr einfach, Parser mittels Generator zu bauen während man
bei Java echt schleußlichen Code mit benannten Schleifen erzeugen muss
und zudem noch mit der 64K-Grenze der VM kämpfen muss.
Gut, bei Java enstehen einfach sehr viele freingranulare Klassen. Habe
ich irgendwie doch lieber als eine >64KB Klasse.
Was dann auch lesbarer wird. (Zumal Klassen >64k auch schon fast reine
prozedurale Lösungen sind.)

Jan
Ralf Beutler
2004-06-09 09:37:46 UTC
Permalink
Post by Jan Sauerwein
Java kennt keine Referenztypen. Genauer: Java kennt kein callByReference
und callByValue.
[1] sind callByReference und callByValue Referenztypen?
Post by Jan Sauerwein
Tiefenkopien müssen explizit angelegt werden, ansonsten
sind alle Verweise Zeiger auf ein Objekt im Speicher.
[2] OK.
Post by Jan Sauerwein
Also wenn man so will sind alle Klassen als Referenztypen implementiert
Wenn [1] wahr ist, wie können dann Klassen Referenztypen sein?
Post by Jan Sauerwein
und ein callByValue ist nicht möglich.
Konkrete Objekte sind Zeiger auf ein Objekt im Speicher [2], diese
Zeiger werden bei einem Methodenaufrufen kopiert und dann übergeben (auf
den Stack gelegt). Damit macht Java doch immer ein callByValue.
(Ich kann das Objekt selber nicht verändern, aber dessen Eigenschaften.)
Post by Jan Sauerwein
Primitive Datentypen können nicht als Referenz übergeben
werden und müssen als callByValue übergeben werden.
Du hast sowieso keine andere Chance. Das Verhalten ist deckungsgleich
mit dem Verhalten von Objekten als Parameter. Nur haben primitive
Datentypen keine Eigenschaften, die man ändern könnte.
Post by Jan Sauerwein
Manchmal eine unschöne Einschränkung.
ACK.

Habe ich was übersehen?

br | rb
--
Sie freuten sich riesig, wenn eine Maschine nach sechs Stunden etwas
fertig brachte, wozu jeder Mensch auf der Straße für 2 Cent fähig
gewesen wäre. Anschließend ließen sie sich Bananen- und Sushi-Pizza
kommen und schliefen vor der Tastatur ein. [aus T.P., Heiße Hüpfer]
Jochen Theodorou
2004-06-09 13:50:45 UTC
Permalink
Post by Ralf Beutler
Post by Jan Sauerwein
Java kennt keine Referenztypen. Genauer: Java kennt kein callByReference
und callByValue.
[1] sind callByReference und callByValue Referenztypen?
Nö... Java kennt kein callByReference. Auch bei Objekten nicht, denn man
kann keinen Konstruktor mit einer Methode nachbauen und void als
Rückgabetype haben.

Eine Einschränkung mit der ich meistens ganz gut leben kann.

callByValue kennt Java, nur wird dazu nur die Variable selbst kopiert.

Object a = new Object(); Object b=a;

a und b haben den selben Inhalt, aber die Variablen a und b sind nicht
die gleichen. freilich kann man das in Java nicht so ohne weiteres
feststellen, in C wäre die Adresse der Variablen a nicht gleich der
Adresse der Variablen b. Würden a und b tatsächlich die selbe Variable
sein, dann könnte ich

a=new Object();

machen und a und b müssten auch weiterhin den selben Inhalt haben. In C
hätte sich die Addresse der Varibale a nicht geändert, der
Speicherbereich, den die Variable bezeichnet aber sehr wohl.

Für die Parameterübergabe bedeutet das, dass die Varible kopiert wird,
also eine neue Variable erzeugt wird, deren Addresse ungleich der des
originals ist, aber den selben Speicherbereich (für das Objekt)
bezeichnet wie das original.

Bei einem callByReferenz würde man die Addresse der Variablen kopieren.

Nun ist es so, dass es in C zum Beispiel sowas wie structs gibt, die
dann direkt in der Variable gespeichert sind (ok, ok, ist nicht ganz
einwandfrei formuliert, ich weiss). Eine Kopie der Varible bedeutet,
dass ich dieses struct ebenfalls kopiere. Ich vermute diese Möglichkeit
wollte Jan ansprechen

[...]
Post by Ralf Beutler
Post by Jan Sauerwein
Primitive Datentypen können nicht als Referenz übergeben
werden und müssen als callByValue übergeben werden.
Du hast sowieso keine andere Chance. Das Verhalten ist deckungsgleich
mit dem Verhalten von Objekten als Parameter. Nur haben primitive
Datentypen keine Eigenschaften, die man ändern könnte.
Wollte man den Wert ändern müsste man die Variable selbst ändern. Nur
das ist IMHO mit callByReferenz gemint


Gruss theo
Daniel Urban
2004-06-09 22:55:47 UTC
Permalink
Post by Jochen Theodorou
Post by Ralf Beutler
Post by Jan Sauerwein
Java kennt keine Referenztypen. Genauer: Java kennt kein callByReference
und callByValue.
[1] sind callByReference und callByValue Referenztypen?
Nö... Java kennt kein callByReference. Auch bei Objekten nicht, denn man
kann keinen Konstruktor mit einer Methode nachbauen und void als
Rückgabetype haben.
Wird das jetzt ein Wettbewerb in wie kann ich eine einfache Sache am
unverständlichsten (inkorrektesten) erklären? ;-)

Gruß,

Daniel
Stefan Matthias Aust
2004-06-09 09:15:33 UTC
Permalink
Post by Ortwin Glück
Das Beispiel mit der Switch-Kaskade ist aber schlecht, weil nicht OO.
Für sowas gibt's Hashmaps.
Ich kenne leider keinen Parsergenerator (für Java oder C#) seine
State-Engine derart implementiert. Ich würde's ehrlich gesagt auch
nicht per HashMap machen, sondern im continuation-style durch das
weiterreichen des nächsten Programmabschnitts. Das wäre bei Java aber
hochgradig rekursiv und ich würde wohl einen Stackoverflow riskieren.
Ergo -> geht nicht, ich brauche switch.
Post by Ortwin Glück
Post by Stefan Matthias Aust
Die Unterscheidung zwischen Werttypen und Referenztypen bei C# (bzw.
der CLR) ist eine wichtige, insbesondere da man mit "struct" eigene
Werttypen definieren kann. Noch ein Pluspunkt für C#.
Die gibts doch bei Java auch. Hier heissen sie halt primitive Typen und
alles andere sind Klassen.
Einen Point (mit x und y Komponenten) als Wertobjekt definieren zu
können, hat einen Vorteil. Sowohl von der Performance als auch der
Semantik. Das geht in Java eben nicht.
Post by Ortwin Glück
Kannst du mit einem Array / Klasse leicht lösen.
Du hast eine andere Definition von leicht als ich :) Etwas wie

Object[] m() {
return new Object[]{ new Double(42.11), "Hallo", new Intger(23) }
}
Object[] a = m();
double d = ((Double) a[0]).doubleValue();
STring s = (String) a[1];
int i = ((Integer) a[2]).integerValue();

halte ich nicht für einfach.
Post by Ortwin Glück
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde
ich da wesentlich wichtiger und brauche ich häufiger. Schön, dass C#
das kann. Java wird's ab 1.5 können.
Dafür gibt es die Polymorphie.
Dann bitte baue mir per Methodenüberladung mal bitte ein printf mit bis
zu 6 Parameter, die alle beliebigen primitiven Typen sein können.
Post by Ortwin Glück
Ich finde Properties machen den Code unlesbarer. Ich weiss bei einem
Variablenzugriff dann nie ob es ein Property ist, der Code ausführt!
Hey, genau das ist der Vorteil. Kapselung. Information hiding. Von
außen soll man nicht erkennen können, ob es ein Variablenzugriff ist.
Nach außen sollten Objekte so etwas überhaupt nicht haben. Du musst
davon ausgehen, dass etwas wie

a.b

IMMER ein Methodenaufruf (bzw. das Senden der Nachricht "b" an den
Empfänger "a" gemäß message passing paradigm) ist. Ich würde den
Zugriff auf die Variable selbst durch eine besondere Syntax ächten, etwa
wie in Ruby, wo man @b benutzen muss, wenn man innerhalb der Klasse von
a auf eine Variable b zugreifen will.
Post by Ortwin Glück
Gut, bei Java enstehen einfach sehr viele freingranulare Klassen. Habe
ich irgendwie doch lieber als eine >64KB Klasse.
Wenn ein Parsergenerator eine ungültige, zwar kompilierbare aber nicht
ausführbare Klasse erzeugt, ist das lästig. Siehe auch die Anfrage
gestern nach dem VM-Limit bei JSP. Erstmal soll es laufen. Dann kann
man es immer noch schön machen. C# ist da etwas pragmatischer, wenn es
darum geht, alten Code etwa von C zu portieren.

Bei meinem Versuch, das Spiel Rogue von C nach Java zu portieren, hatte
ich einiges an Arbeit, weil die Sprachen eben doch recht unterschiedlich
waren und C etwa passiv call-by-reference benutzt hat. Es gab viele
printfs mit variablen Parametern, usw. Ich würde jetzt schätzen
(entgegen meiner ursprünglichen Annahme), dass ich einen Port nach C# in
einem kürzerer Zeit geschafft hätte. Das Umschreiben des Codes war gar
nicht so das Problem - doch ich hatte doch ziemlich viele Fehler dabei
eingefügt, die zu finden nicht einfach war... irgendwann gab ich dann
auf. Und die Speichern-Funktion von Rogue war so ein Teil, der massiv
pointer benutzt hat, um Speicherbereiche von Variablen und Arrays
abzuspeichern. Das hätte man in C# vielleicht erstmal als unsafe
deklarieren können und so zunächst etwas gehabt, das estmal läuft. In
Java hatte ich das nie realisiert...


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Timothy Truckle
2004-06-09 21:45:24 UTC
Permalink
Stefan Matthias Aust schrieb am Mittwoch, 9. Juni 2004 11:15 in
Post by Stefan Matthias Aust
Post by Ortwin Glück
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu
benutzen finde
ich da wesentlich wichtiger und brauche ich häufiger. Schön, dass C#
das kann. Java wird's ab 1.5 können.
Dafür gibt es die Polymorphie.
Dann bitte baue mir per Methodenüberladung mal bitte ein printf
mit bis zu 6 Parameter, die alle beliebigen primitiven Typen
sein können.
Was spricht hier gegen das normale 'System.out.println()'?
Da kannst Du deine Primitiven Typen direkt per '+' Operator mit
den Statischen Text verknüpfen.
Ich denke, das ist nicht weniger komfortabel als ein
"C"-like printf().
Post by Stefan Matthias Aust
Post by Ortwin Glück
Ich finde Properties machen den Code unlesbarer. Ich weiss bei
einem Variablenzugriff dann nie ob es ein Property ist, der
Code ausführt!
Hey, genau das ist der Vorteil. Kapselung. Information
hiding. Von außen soll man nicht erkennen können, ob es ein
Variablenzugriff ist.
Nach außen sollten Objekte so etwas überhaupt nicht haben. Du
musst davon ausgehen, dass etwas wie
a.b
IMMER ein Methodenaufruf (bzw. das Senden der Nachricht "b" an
den
Empfänger "a" gemäß message passing paradigm) ist. Ich würde
den Zugriff auf die Variable selbst durch eine besondere Syntax
innerhalb der Klasse von a auf eine Variable b zugreifen will.
Wo ist da genau der Vorteil von C# beziehungsweise der
unterschied zu Ruby?
a.b // Zugriff auf Variable
a.b() // Zugriff auf Methode
Entspricht also genau Deiner Forderung den Variablenzugriff
deutlich zu unterscheiden.

das sich
a.getB()
eingebürgert hat ist IMHO kein Problem der Sprache.
bye
TT
--
PGP: 0x273c213E
Daniel Urban
2004-06-09 22:49:54 UTC
Permalink
Post by Timothy Truckle
Stefan Matthias Aust schrieb am Mittwoch, 9. Juni 2004 11:15 in
Post by Stefan Matthias Aust
Post by Ortwin Glück
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu
benutzen finde
ich da wesentlich wichtiger und brauche ich häufiger. Schön, dass C#
das kann. Java wird's ab 1.5 können.
Dafür gibt es die Polymorphie.
Dann bitte baue mir per Methodenüberladung mal bitte ein printf
mit bis zu 6 Parameter, die alle beliebigen primitiven Typen
sein können.
Was spricht hier gegen das normale 'System.out.println()'?
printf war wohl nur ein Beispiel. Es ist einfach sehr viel leserlicher und
intuitiver wenn man foo(a,b,c,...) schreiben kann, als foo(new
Object[]{a,b,c,...})

Gruß,

Daniel
Timothy Truckle
2004-06-10 08:49:08 UTC
Permalink
Daniel Urban schrieb am Donnerstag, 10. Juni 2004 00:49 in
Post by Daniel Urban
printf war wohl nur ein Beispiel. Es ist einfach sehr viel
leserlicher und intuitiver wenn man foo(a,b,c,...) schreiben
kann, als foo(new Object[]{a,b,c,...})
Da gebe ich Dir estmal recht.
Was bleibt ist Die Frage, ob ich denn nicht beim Desing etwas
falsch mache, wenn ich Methoden mit unbestimmter Parameterzahl
benötige.

bye
TT
--
PGP: 0x273c213E
Daniel Urban
2004-06-10 19:57:49 UTC
Permalink
Post by Timothy Truckle
Daniel Urban schrieb am Donnerstag, 10. Juni 2004 00:49 in
Post by Daniel Urban
printf war wohl nur ein Beispiel. Es ist einfach sehr viel
leserlicher und intuitiver wenn man foo(a,b,c,...) schreiben
kann, als foo(new Object[]{a,b,c,...})
Da gebe ich Dir estmal recht.
Was bleibt ist Die Frage, ob ich denn nicht beim Desing etwas
falsch mache, wenn ich Methoden mit unbestimmter Parameterzahl
benötige.
Nicht zwangsweise, wie das Beispiel printf zeigt.

Gruß,

Daniel
Timothy Truckle
2004-06-10 22:19:05 UTC
Permalink
Daniel Urban schrieb am Donnerstag, 10. Juni 2004 21:57 in
Post by Daniel Urban
Post by Timothy Truckle
Was bleibt ist Die Frage, ob ich denn nicht beim Desing etwas
falsch mache, wenn ich Methoden mit unbestimmter Parameterzahl
benötige.
Nicht zwangsweise, wie das Beispiel printf zeigt.
Doch, wie gerade das Beispiel printf zeigt.
Post by Daniel Urban
Was spricht hier gegen das normale 'System.out.println()'?
Da kannst Du deine Primitiven Typen direkt per '+' Operator mit
den Statischen Text verknüpfen.
Ich denke, das ist nicht weniger komfortabel als ein
"C"-like printf().
bye
TT
--
PGP: 0x273c213E
Daniel Urban
2004-06-11 21:00:11 UTC
Permalink
Post by Timothy Truckle
Daniel Urban schrieb am Donnerstag, 10. Juni 2004 21:57 in
Post by Daniel Urban
Post by Timothy Truckle
Was bleibt ist Die Frage, ob ich denn nicht beim Desing etwas
falsch mache, wenn ich Methoden mit unbestimmter Parameterzahl
benötige.
Nicht zwangsweise, wie das Beispiel printf zeigt.
Doch, wie gerade das Beispiel printf zeigt.
Post by Daniel Urban
Was spricht hier gegen das normale 'System.out.println()'?
Da kannst Du deine Primitiven Typen direkt per '+' Operator mit
den Statischen Text verknüpfen.
Ich denke, das ist nicht weniger komfortabel als ein
"C"-like printf().
Da waren wir schon mal. Es ist lediglich ein Beispiel. Du kannst andere
Parameter nun einmal nicht konkatinieren. Und printf macht so wie es ist
schon Sinn, zumindest würde ich es nicht als schlechtes Design bezeichnen.
Genausowenig die println() Lösung.

Gruß,

Daniel
Christian Wederhake
2004-06-10 20:24:41 UTC
Permalink
Post by Daniel Urban
Post by Timothy Truckle
Post by Daniel Urban
printf war wohl nur ein Beispiel. Es ist einfach sehr viel
leserlicher und intuitiver wenn man foo(a,b,c,...) schreiben
kann, als foo(new Object[]{a,b,c,...})
Da gebe ich Dir estmal recht.
Was bleibt ist Die Frage, ob ich denn nicht beim Desing etwas
falsch mache, wenn ich Methoden mit unbestimmter Parameterzahl
benötige.
Nicht zwangsweise, wie das Beispiel printf zeigt.
Naja, dann stehe ich wohl mit der Auffassung, dass printf eigentlich nur
sinnvoll beim schnellen Schreiben von debug-Ausgaben verwendbar ist,
und ansonsten eine Loesung a'la java.text.Format immer vorzuziehen
ist, wenn es um sinnvolle Probleme geht, relativ alleine da...
Und ja, ich weiss, dass "sinnvolle Probleme" ein durchaus schwammiger
Begirff ist... Nicht ohne Grund... :-)

Ciao
Chris
--
"Die dem Weibe innewohnende frische Natürlichkeit wird gebrochen,
wenn dasselbe sich in den Jahren der Entwicklung denselben geistigen
Strapazen auszusetzen hat, wie unsere männliche Jugend."
(Prof. Dr. Friedrich Albrecht Weber *1825)
Stefan Matthias Aust
2004-06-11 07:41:07 UTC
Permalink
Post by Timothy Truckle
Post by Stefan Matthias Aust
Dann bitte baue mir per Methodenüberladung mal bitte ein printf
mit bis zu 6 Parameter, die alle beliebigen primitiven Typen
sein können.
Was spricht hier gegen das normale 'System.out.println()'?
Das war ein Beispiel. Und dagegen würde sprechen, dass du jetzt
mindestens 6 Zeilen (gleichgesetzt mit Statements) braucht wo ich nur
eine bräuchte. Das allein scheint mir ein Vorteil. Programme sollten
kurz und prägnant (aber nicht kürzer) sein.
Post by Timothy Truckle
Wo ist da genau der Vorteil von C# beziehungsweise der
unterschied zu Ruby?
a.b // Zugriff auf Variable
a.b() // Zugriff auf Methode
Entspricht also genau Deiner Forderung den Variablenzugriff
deutlich zu unterscheiden.
Properties sind ein schäbiges syntaktisches Hilfsmittel, den Ballast von
Methodenaufrufen zu reduzieren. Natürlich ist semantisch kein
Unterschied zwischen a.b (wenn b property in C#) und a.getB().
Tatsächlich benutzt die CLR bei a.b intern a.get_b().

Eigentlich sollten sie nicht nötig sein, sollte beides syntaktisch
vereinheitlicht und semantisch werden - etwa dadurch dass Methoden ohne
Argumente keine Klammern brauchen und das a.b = c automatisch zu einem
Setter wird. In Ruby heißt diese Methode sogar "b=" (vielleicht
abgeguckt auch Smalltalk-76, da war das auch so).

Ich finde einfach ein

a.b += c

einfacher hinzuschreiben und damit eleganter als ein

a.setB(a.getB() + c)

oder sogar

a.setB(a.getB().add(c))

Ist wohl ein bisschen persönlicher Geschmack dabei.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Jochen Theodorou
2004-06-09 09:18:16 UTC
Permalink
Post by Stefan Matthias Aust
Schon gesehen? ->
http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/
Ein IMHO sehr interessanter Vergleich von Java und C#. Verglichen
[...]
Post by Stefan Matthias Aust
Alias bei import ist nett, aber bis auf den unsäglichen Konflikt bei
awt/util.List und Date hatte ich bislang noch keine Probleme, auch wenn
es in der Theorie nett wäre, Namenskonflikte durch Umbenennen während
des Imports zu lösen.
ich mag solche aliase nicht. Bei Java wird in einigen Styleguides
gefordert, dass man alle imports ausschreibt. Konsequent weitergedacht
verbietet ein solcher Styleguide auch die Nutzung von aliasen. Während
ich die Sache mit den imports zum Teil übertrieben finde, würde ich
keine aliase benutzen wollen und hoffen sie nicht benutzen zu müssen.
Die Fälle, wo man wirklich einen Alias bräuchte sind extrem selten. Ds
rechtfertigt meiner Meinung nach nicht die zusätzliche Komplexität...
aber wenn es um Komplexität geht ist bei C# eh alles verloren.
Post by Stefan Matthias Aust
Einen Präprozessor als Teil der Sprachdefinition halte ich für unnötig.
Diesen kann man, wenn man es benötigt, durch externe Werkzeuge nachrüsten.
Naja, es kann helfen Probleme zu vermeiden. Wenn es zur Sprache gehört
haben Leute, die den Source bekommen keine Probleme die
Präprozessorsyntax zu lesen - theoretisch zumindest. Ich könnte derzeit
immer auf einen Präprozessor in Java verzichten. In C nicht.
Post by Stefan Matthias Aust
Einen Finalizer mit Destruktor-Syntax zu notieren so wie C# es macht
halte ich für irreführend.
Konnte man nicht in C# den GC zwingen ein Object zu finalizen? In dem
Fall wäre es ja tatsächlich ein Destruktor.

[...]
Post by Stefan Matthias Aust
Automatisches Boxing und Unboxing - und damit eine Vereinheitlichung der
Typhierarchie von primitiven und Objekttypen bietet Java leider erst mit
1.5. Bis dahin ist das ein Plus-Punkt für C#.
Nicht nur bis dahin, das autoboxing geht doch in C# deutlich weiter als
in Java, oder?

[...]
Post by Stefan Matthias Aust
Strings können in C# mit == verglichen werden, was dafür übergeschrieben
wurde. Vermeidet sicherlich viele Anfängerfehler, macht es aber lästig,
wenn man tatsächlich die Referenzen vergleichen will
((object) "a") == ((object) "b")
was zumindest ich in Java häufig brauche, weil ich gerne (aus
Effizienzgründen - ich kann nicht anders) mit intern'ten String arbeite.
Ob es derartige Strings in C# gibt, wird nicht erwähnt und ich weiss es
gerade nicht.
Wahrscheinlich implementierungsabhängig ;)
Ein "==" zählt für mich nicht gerade zu den Operatoren, die ich gerne
überschrieben sehe.
Post by Stefan Matthias Aust
Strings, in denen \ kein Escape ist mögen für Windows-Dateinamen und
Reguläre Ausdrücke eine Erleichterung bieten, sind aber IMHO nicht
wirklich wichtig.
man benutzt ja auch / als Pfadseparator ;) Nicht wirklich wichtig, richtig.
Post by Stefan Matthias Aust
C# hat "unsigned" Datentypen. Macht das Rechnen einfacher. Ich finde
aber inkonsequent, dass es sonst immer T und uT gibt nur bei byte ist es
anders herum und dort ist byte unsigned unt sbyte ist die
vorzeichenbehaftere Variante.
Also es gibt schon Fälle wo ich gerne unsinged Datentyp gehabt hätte...
aber was das nachsich zieht....

String halloWelt = "Hallo Welt";
int pos = halloWelt.indexOf("Welt");
String Welt = halloWelt.subString(pos);

ansich ganz einfach, aber die Fehlerbehandlung erfolgt mit pos==-1 Wenn
das erhalten werden soll dann muss pos signed sein. Für subString macht
ein signed aber keinen Sinn, sollte also signed sein. Das heisst:

sInt pos = halloWelt.indexOf("Welt");
String Welt = halloWelt.subString((int) pos);

und wenn man die Fehlerbehandlung vergisst... wie macht man denn sowas
in C#?
Post by Stefan Matthias Aust
Die Unterscheidung zwischen Werttypen und Referenztypen bei C# (bzw. der
CLR) ist eine wichtige, insbesondere da man mit "struct" eigene
Werttypen definieren kann. Noch ein Pluspunkt für C#.
Na ich weiss nicht.... ich lasse mich da gerne überzeugen, aber gib mir
doch mal ein Beispiel wo das so extrem von Vorteil ist und einem Klassen
im Weg sind.
Post by Stefan Matthias Aust
Ebenfalls hilfreich ist, dass wahlweise integer Berechnung nicht einfach
klamheimlich überlaufen und das Vorzeichen wechseln. Ich verstehe
nicht, warum das nicht standardmäßig einen Fehler gibt. Wahrscheinlich
weil sonst zu viele unwissende oder schlampige Programmierer merken
würden, dass sie fehlerhaften Code schreiben.
Ich glaube es gab dafür tatsächlich einen Grund.... Ich meine es ging
darum dass Java auch für Prozessoren geplant war wo man diesen Überlauf
nicht erkennen konnte bzw. wo dieser Überlauf keinen Flag auslöst oder
was ähnliches so dass man sich nciht einschränken wollte. Ist aber nur
extremes Halbwissen... sicher weiss das jemand hier besser. Ob das nötig
ist, ist nochmal eine ganz andere Frage, dennoch ist *keine*
Fehlerbehandlung in diesem Fall der allgemeinere Fall finde ich.
Post by Stefan Matthias Aust
Der Sinn von typeof und sizeof von C# erschließt sich mir nicht. Was
unterscheidet ersteres von .getType() und beim zweiten Operator kann ich
doch einfach in der Spec nachgucken...
typeOf entspricht wohl dem .class und getType hat in Java keine direkte
Entsprechung scheint mir. Jedenfalls müsste bei einem

Customer c = new Customer();
Object o = c;
Type type = typeOf(o);
Type runtimetype = o.getType();

einmal Object und einmal Costumer herauskommen... so wie ich es im Text
gelesen habe erwarte ich die type==Object, wenn ich das hier lese ewarte
ich type==Object... irgendwas habe ich da wohl auch falsch verstanden.
Post by Stefan Matthias Aust
Switch ist IMHO besser gelöst als in Java und man hat sich von
C-Kompatibiliät gelöst, was an sich schon mal gut ist :) Noch ein
Pluspunkt.
Ja, stimmt... wobei sich hier die Frage stellt wie würde man das in Java
machen? Immer ein Vergleich mit == Dann würde das auch in Java
funktionieren, aber bei Objekten, wo ein .equals notwendig ist wird das
switch gleich wieder unbrauchbar. In C# wird dafür == überladen... und
davon halte ich nichts.

[...]
Post by Stefan Matthias Aust
Den Zugriffsmodifikator "internal" finde ich gelungener als Javas
"package" Sichtbarkeit, die, da auf ein Package beschränkt,
normalerweise zu klein ist und unnötig oft zu "public" zwingt. Auch die
Entscheidung, private als default zu nehmen finde ich besser. Noch ein
Plus-Punkt.
Das die Leute bei Sun beim Entwurf von Java erst spät an was anderes als
eine monolitische Struktur dachten macht sich dann unter anderem so
bemerkbar ;)

[...]
Post by Stefan Matthias Aust
Call-by-reference für Variablen ist nett... noch besser hätte ich aber
gefunden, wenn die Sprachen Tupel-Typen hätten und demzufolge mehrfache
Rückgabewerte zulassen würde. Bietet dummerweise weder Java noch C#.
Was sind TupelTypen? Oder meinst du sowas:

(int,int) div(int a, in b) {
int modulo = a%b;
int div = a/b;
return (a,b);
}

kann ich ehrlich gesagt drauf verzichten, da die Notwendigkeit eines
solchen Konstrukts in der Regel ein Indiz dafür ist, dass man eigentlich
einen Zustand modellieren will und eigentlich eine Klasse nutzen sollte.
Natürlich gibt es immer ein Beispiel wo das nicht so ist, aber meiner
Erfahrung nach ist es meisten so.

[...]
Post by Stefan Matthias Aust
Properties machen IMHO den Code lesbarer - allerdings zu dem Preis von
mehr Syntax und der ewigen Entscheidung - nehme ich eine parameterlose
Funktion oder doch ein Property...
mir erscheint die Syntax dafür umständlich und unschön. Ausserdem habe
ich gegenüber expliziten Methoden nicht an Platz gespart. Der syntaktic
sugar hält sich also Arg in Grenzen.
Post by Stefan Matthias Aust
C# hat echte mehrdimensionale Array - ein Vorteil gegenüber Java. Punkt.
keine Diskussion? Zum Beispiel darüber wann man echte mehrdimensionale
Arrays überhaupt braucht? Oder wo sie wenigstens was erleichtern?

[...]
Post by Stefan Matthias Aust
Das man in C# überschriebene Methoden mit "override" kennzeichnen muss
finde ich gut. Das man "virtual" 'dranschreiben muss finde ich
schlecht. Das man dadurch auch Methoden mit gleichen Namen in
Unterklassen definieren kann, ebenfalls, da nur verwirrend.
verwirrend? Ich finde das furchtbar. Wir wissen ja was static anrichten
kann, bei C# wird das sicherlich nochmal eines drauf legen...
Allerdings, wenn man aus dem C++-Bereich kommt ist dieses Verhalten in
C# wohl normaler.

cool finde ich ja dass Beispiel mit dem base... Kann mir jemand den
Unterschied zwischen base und super erklären?
Post by Stefan Matthias Aust
Wie ich schon sagte, ich finde Operator-Overloading gut und finde
schade, dass Java das nicht bietet.
ich, so allgemein gesagt, finde das nicht schade ;)
Post by Stefan Matthias Aust
Dumm ist aber, dass es Operatoren
überhaupt gibt. Schöner und eleganter wäre, wenn das einfach
syntaktischer Zucker für normale Methoden wäre. Das hat keine Sprache
begriffen und implementiert. Man muss da zu Lisp, Smalltalk, Python,
Ruby gucken.
Was nicht begriffen? Das man eine Methode schreibt wie

public int operator+(int left, int right) {
return left+right;
}

Das gibt es ja durchaus, in Ada zum Beispiel. In gewissen, sehr engen,
Grenzen fände ich das auch in Java gut, aber nur wenn dabei nicht
zuviele automatische Typumwandlungen passieren, und auf keinen Fall
Operatoren für () oder ==.
Aber wenn wir wieder anfangen darüber zu diskutieren wird das ein sehr
langer Thread.

[...]
Post by Stefan Matthias Aust
Exceptions in C# sind niemals checked. Ich könnte damit leben. Ob es
ein Vorteil oder doch Nachteil ist, kann ich nicht sagen - tendiere aber
zu einem Vorteil, weil ich doch zu häufig in Java schon "normale"
Exceptions in Runtime-Exceptions verpacken musste, nur um sie durch
vordefinierte Interfaces zu schleusen.
kommt bei mir auch, aber recht selten vor. Von daher ist das bei mir
kein so doller Vorteil.

[...]
Post by Stefan Matthias Aust
In C# kann man Regionen als Unsafe erklären und dann mit Pointer
spielen, sodass jeder C-Entwickler neidisch werden kann. Das mag für
bestimmte Fälle hilfreich sein, ist aber natürlich tödlich für
plattformübergreifende Entwicklungen. Auch kann man sich damit u.U. die
allerseits beliebten Buffer-Overrun-Exploits einhandeln. Zumindest kann
man per Security-Einstellungen festlegen, ob Programme mit
unsafe-Einschlüssen gestartet werden dürfen oder nicht.
was nicht viel hilft, wenn man das Programm eigentlich laufen lassen
müsste ;)

[...]
Post by Stefan Matthias Aust
Fazit: Die Sprache C# ist deutlich größer und komplexer und bietet
dafür einige interessante Zusatzfeatures.
Metadaten haben meiner Meinung nch für DB-Anwendungen ein grosses
Potential. Ob das in Java dazu geeignet ist muss man noch sehen.

[...]
Post by Stefan Matthias Aust
Wer auf mehrdimensionale Array und Werttypen
angewiesen ist - etwa für komplexe mathematische Berechnungen - der ist
mit C# besser 'dran als mit Java.
da dürfte was dran sein.

[...]
Post by Stefan Matthias Aust
Allerdings wird auch hier aufgerüstet und C# 2.0 soll einige
interessante Neuerungen bieten - und die Sprache noch komplexer machen.
Ich finde C# jetzt schon zu komplex. Ich meine mich wage da noch eine
Versionierung von Assemblies zu erinnern und dass das der Punkt war, wo
ich vor lauter Entsetzen das C#-Buch geschlossen habe ;)
Post by Stefan Matthias Aust
Dank closures wird C# erstmalig in die Austsche "languages which does
not suck immediately"-Kategorie aufgenommen werden können.
Hätte ich neulich wirklich brauchen können und musste dann statt dessen
einen Krampf mit inneren Klassen aufbauen.
Post by Stefan Matthias Aust
Polymophe
Typen (aka generics) wird es auch geben - zusammen mit dem Versprechen,
dass diese im Gegensatz zu Java auch für primitive aka Wert-Datentypen
funktionieren.
wahrscheinlich über boxing, oder?
Post by Stefan Matthias Aust
Iteratoren sind deutlich besser als in Java und es wird
"nullable"-Typen geben, also ein int, das auch keinen Wert haben kann -
Kompatibilität zu Datenbank, yeah.
das ist in der Tat interessant. Hätte Java das, könnte man sich die
ganzen Vergleiche auf -1 sparen und das gescheit machen... damit ist
dann auch das Problem von oben geklärt.

Gruss theo
Stefan Matthias Aust
2004-06-09 09:40:22 UTC
Permalink
Post by Jochen Theodorou
Konnte man nicht in C# den GC zwingen ein Object zu finalizen? In dem
Fall wäre es ja tatsächlich ein Destruktor.
Ich meine, es gibt nur die Syntax

using (IDisposable d = bla()) {
machwasmit(d);
}

was dann eben

IDisposable d = ...
try {
machwasmit(d);
} finally {
d.dispose();
d = null;
}

mit

interface IDisposable {
public void dispose();
}

entspricht. Das ruft aber nicht notwendigerweise einen finalizer auf.
Post by Jochen Theodorou
Nicht nur bis dahin, das autoboxing geht doch in C# deutlich weiter als
in Java, oder?
Weiss nicht. Ich dachte/hoffe nicht...
Post by Jochen Theodorou
String halloWelt = "Hallo Welt";
int pos = halloWelt.indexOf("Welt");
String Welt = halloWelt.subString(pos);
ansich ganz einfach, aber die Fehlerbehandlung erfolgt mit pos==-1 Wenn
das erhalten werden soll dann muss pos signed sein.
Das ist aber nur ein Problem der Unsitte, bestimmte Werte eines
Datentyps als Marker für Fehlerfälle zu benutzen. Sauberer wäre IMHO,
entweder einen optional-Type zu benutzen:

int? pos = "a".indexOf("a")
if (pos.hasValue) ...

oder aber das if gleich mit wenigzurationalisieren, also

^hallo subStringStartingAt:
(hallo find: "a" ifAbsent: [^"nix gefunden"]).
Post by Jochen Theodorou
Ich glaube es gab dafür tatsächlich einen Grund.... Ich meine es ging
darum dass Java auch für Prozessoren geplant war wo man diesen Überlauf
nicht erkennen konnte bzw. wo dieser Überlauf keinen Flag auslöst oder
was ähnliches so dass man sich nciht einschränken wollte.
Das erklärt, entschuldigt aber nicht. Wäre die Sprache in ihrer
Settop-Box Nische geblieben, okay. Aber proklamierter Cobol-Nachfolger
speziell für Geschäftsanwendungen - nein danke.
Post by Jochen Theodorou
Ja, stimmt... wobei sich hier die Frage stellt wie würde man das in Java
machen?
So wie in Ruby? Dort gibt es den "===" operator für case-Vergleiche.
Den kann jeder Überschreiben der mitspielen möchte.
Post by Jochen Theodorou
(int,int) div(int a, in b) {
int modulo = a%b;
int div = a/b;
return (a,b);
}
Ja.
Post by Jochen Theodorou
kann ich ehrlich gesagt drauf verzichten, da die Notwendigkeit eines
solchen Konstrukts in der Regel ein Indiz dafür ist, dass man eigentlich
einen Zustand modellieren will und eigentlich eine Klasse nutzen sollte.
Klassen sind in diesem Fall viel zu schwergewichtig. IMHO...
Post by Jochen Theodorou
Post by Stefan Matthias Aust
C# hat echte mehrdimensionale Array - ein Vorteil gegenüber Java. Punkt.
keine Diskussion? Zum Beispiel darüber wann man echte mehrdimensionale
Arrays überhaupt braucht? Oder wo sie wenigstens was erleichtern?
Frag Peter Luschny. Der klagte mal darüber bei Java :)
Post by Jochen Theodorou
Was nicht begriffen?
Ich war zu pauschal.
Post by Jochen Theodorou
Ich finde C# jetzt schon zu komplex.
Dieses Gefühl hege ich momentan auch. Anderseits fordere ich ja für
meine Traumsprache auch mehr features als Java sie momentan bietet...
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Polymophe Typen (aka generics) wird es auch geben - zusammen mit dem
Versprechen, dass diese im Gegensatz zu Java auch für primitive aka
Wert-Datentypen funktionieren.
wahrscheinlich über boxing, oder?
Nein, die VM wird derart geändert, dass sie beim laden einer
Klassenbeschreibung erkennt, dass das was generisches ist (im Gegensatz
zu Java wird das nicht mittels type erasure als den Metadaten entfernt)
und dann je nach primitiven Datentyp eine Version kompiliert sowie
nochmal eine generelle Version für alle Referenztypen. Eigentlich eine
gute Lösung. Wird Sun bestimmt auch irgendwann (falls wir das ob der
ewig langen Release-Zyklen noch erleben) machen.
Post by Jochen Theodorou
das ist in der Tat interessant. Hätte Java das, könnte man sich die
ganzen Vergleiche auf -1 sparen und das gescheit machen... damit ist
dann auch das Problem von oben geklärt.
Eben. Siehe oben :)


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Michael Rauscher
2004-06-09 10:25:19 UTC
Permalink
Post by Stefan Matthias Aust
Post by Jochen Theodorou
String halloWelt = "Hallo Welt";
int pos = halloWelt.indexOf("Welt");
String Welt = halloWelt.subString(pos);
ansich ganz einfach, aber die Fehlerbehandlung erfolgt mit pos==-1
Wenn das erhalten werden soll dann muss pos signed sein.
Das ist aber nur ein Problem der Unsitte, bestimmte Werte eines
Datentyps als Marker für Fehlerfälle zu benutzen. Sauberer wäre IMHO,
int? pos = "a".indexOf("a")
if (pos.hasValue) ...
*ekel* ;-)

Mal davon ausgehend, dass indexOf die Position des Substrings im String
liefert, gefällt mir ja

Integer pos = "a".indexOf("a");
if ( pos != null ) ...

oder abstrakter

Position pos = "a".indexOf("a");
if ( pos != null ) ...

noch besser.

Die Variante oben gleicht wohl eher einem

Result result = "a".indexOf("a");
if ( result.hasResult() ) ...

Gruß
Michael
Stefan Matthias Aust
2004-06-09 18:47:25 UTC
Permalink
Post by Michael Rauscher
*ekel* ;-)
Deine Lösungen sind auch nicht besser - IMHO - denn sie nutzen alle
explizit null. Und ein generisches "null" sollte es möglichst gar nicht
geben. Das ist nicht wirklich typsicher.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Michael Rauscher
2004-06-09 22:11:39 UTC
Permalink
Post by Stefan Matthias Aust
Post by Michael Rauscher
*ekel* ;-)
Deine Lösungen sind auch nicht besser - IMHO - denn sie nutzen alle
explizit null. Und ein generisches "null" sollte es möglichst gar nicht
geben. Das ist nicht wirklich typsicher.
Wie soll ich das verstehen und was hat null mit Typsicherheit zu tun?

verwirrt
Michael
Daniel Urban
2004-06-09 22:42:45 UTC
Permalink
Post by Michael Rauscher
Post by Stefan Matthias Aust
Deine Lösungen sind auch nicht besser - IMHO - denn sie nutzen alle
explizit null. Und ein generisches "null" sollte es möglichst gar nicht
geben. Das ist nicht wirklich typsicher.
Wie soll ich das verstehen und was hat null mit Typsicherheit zu tun?
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.

Gruß,

Daniel
Michael Rauscher
2004-06-09 23:13:57 UTC
Permalink
Post by Daniel Urban
Post by Michael Rauscher
Post by Stefan Matthias Aust
Deine Lösungen sind auch nicht besser - IMHO - denn sie nutzen alle
explizit null. Und ein generisches "null" sollte es möglichst gar nicht
geben. Das ist nicht wirklich typsicher.
Wie soll ich das verstehen und was hat null mit Typsicherheit zu tun?
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
Ich finde es sehr schön, mit null "nichts" ausdrücken zu können. Und was
hilft mir ein typsicheres "nichts"? Ich verstehe es immer noch nicht :-(

Gruß
Michael
Marian Aldenhövel
2004-06-09 23:20:29 UTC
Permalink
Hi,
Post by Daniel Urban
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
Welchen Typ sollte denn die null in Michaels pos-Beispiel haben?

Integer? Das wäre gelogen, denn es steckt keine Zahl drin. Einen
neuen Typ DiesIstKeinInteger mit einer einzigen Ausprägung? Das
erscheint mir die Typsicherheit ein wenig zu übertreiben.

Um "kein Tisch" oder "kein Bett" sagen zu können, braucht man doch
nicht zwei verschiedene keins.

Ciao, MM
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"Wie trennt man drei Schlampen von zwei Säufern? Cockpittüre zu!"
Stefan Matthias Aust
2004-06-10 09:01:14 UTC
Permalink
Post by Marian Aldenhövel
Post by Daniel Urban
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
Welchen Typ sollte denn die null in Michaels pos-Beispiel haben?
"null" hat den Typ null. Doch dieser Typ ist zuweisungskompatibel zu
jedem anderen Referenztyp - ist also damit ein Untertyp dieser Typen.

Du kannst dir den Typ String etwa als den Typ String' vereinigt mit dem
Typ Null (ich schreib den mal groß) vorstellen. Erster Typ enthält
jetzt nur "echte" Strings.
Post by Marian Aldenhövel
Um "kein Tisch" oder "kein Bett" sagen zu können, braucht man doch
nicht zwei verschiedene keins.
Nein, aber man bräuchte die Möglichkeit, zwischen einer Variablen die
garaniert immer einen String und einer, die möglicherweise einen String
enthält zu unterscheiden. Und bei zwei verschiedenen Variablen (für
Betten und Tische) ist eben kein-Bett etwas anderes als kein-Tisch.


(Ich glaube, das war jetzt verwirrend - egal... keine Zeit)

bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Marian Aldenhövel
2004-06-10 10:53:32 UTC
Permalink
Hi,
Und bei zwei verschiedenen Variablen (für Betten und Tische) ist
eben kein-Bett etwas anderes als kein-Tisch.
Davon bin ich nicht überzeugt.

"2 Äpfel" ist etwas anderes als "2 Birnen". Nicht mal "0 Äpfel" sind
"0 Birnen". Aber "kein Apfel" ist auch gleichzeitig "keine Birne",
jedenfalls wenn man "kein" als "nix" liest und nicht als
"vielleicht etwas anderes".

Diese Denkrichtung tut meinem Hirn aber heute weh, vielleicht lassen
wir es einfach.

Ciao, MM
--
Marian Aldenhövel, Rosenhain 23, 53123 Bonn.
Fon +49 228 624013, Fax +49 228 624031.
http://www.marian-aldenhoevel.de
"Wie trennt man drei Schlampen von zwei Säufern? Cockpittüre zu!"
Stefan Ram
2004-06-09 23:27:04 UTC
Permalink
Post by Daniel Urban
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
"The null type has one value, the null reference,
represented by the literal null, which is formed from
ASCII characters. A null literal is always of the null
type."
Java Language Specification Second Edition, 3.10.7 The Null Literal
Christian Wederhake
2004-06-10 02:16:43 UTC
Permalink
Post by Stefan Ram
Post by Daniel Urban
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
"The null type has one value, the null reference,
represented by the literal null, which is formed from
ASCII characters. A null literal is always of the null
type."
Java Language Specification Second Edition, 3.10.7 The Null Literal
Dann haetten sie sich mal besser auch daran gehalten.
Weder gibt es ein Reflection-Aequivalent fuer den "null type", also eine
Instanz der Klasse Class, noch schlaegt folgendes fehl:
# null instanceof IrgendeineKlasse
Im Gegenteil, es ergbit *immer* true.
Und daraus leitet sich fuer mich ab, dass "null" mindestens jeden
nicht-primitiven Typ hat.

Ciao
Chris
--
"Der Frauen höchstes Ziel muss der hausliche Herd, das Familienleben
bleiben, soll anders die Weltordnung nicht verschoben werden."
(Prof. Dr. med. Franz Riegel *1843)
Paul Ebermann
2004-06-10 07:38:09 UTC
Permalink
Post by Christian Wederhake
Post by Stefan Ram
Post by Daniel Urban
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
"The null type has one value, the null reference,
represented by the literal null, which is formed from
ASCII characters. A null literal is always of the null
type."
Java Language Specification Second Edition, 3.10.7 The Null Literal
Dann haetten sie sich mal besser auch daran gehalten.
Weder gibt es ein Reflection-Aequivalent fuer den "null type", also eine
Instanz der Klasse Class,
Das ist natürlich ein Problem - wo es sogar für void
einen gibt ...
Post by Christian Wederhake
# null instanceof IrgendeineKlasse
Im Gegenteil, es ergbit *immer* true.
Nein, es sollte immer false geben.

Du meinst wohl den Cast

(IrgendeineKlasse)null;

welcher nie fehlschlägt.
Post by Christian Wederhake
Und daraus leitet sich fuer mich ab, dass "null" mindestens jeden
nicht-primitiven Typ hat.
Man kann den null-Typ als Subtyp aller nicht-primitiven
Typen auffassen.
(Ob das sinnvoll ist, ist eine andere Frage.)

De facto existiert der null-Typ nur für den Compiler,
nicht für die VM.


Paul
Christian Wederhake
2004-06-10 20:04:03 UTC
Permalink
[... null hat nach langspec keinen Typ...]
Post by Christian Wederhake
Dann haetten sie sich mal besser auch daran gehalten.
Weder gibt es ein Reflection-Aequivalent fuer den "null type", also eine
Instanz der Klasse Class,
Das ist natürlich ein Problem - wo es sogar für void einen gibt ...
Ebent...
Post by Christian Wederhake
# null instanceof IrgendeineKlasse
Im Gegenteil, es ergbit *immer* true.
Nein, es sollte immer false geben.
Du meinst wohl den Cast
(IrgendeineKlasse)null;
welcher nie fehlschlägt.
*grummelzeterschimpfmeckermotz*
Du hast es heute wohl damit, mich zu korrigieren und ich habe es damit,
Unsinn zu verzapfen... Weia...Vielleicht gehoere ich doch auf's
Altenteil... :-)
Post by Christian Wederhake
Und daraus leitet sich fuer mich ab, dass "null" mindestens jeden
nicht-primitiven Typ hat.
Man kann den null-Typ als Subtyp aller nicht-primitiven
Typen auffassen.
(Ob das sinnvoll ist, ist eine andere Frage.)
Das waere imho nur eine verkomplizierte Version der "null hat jeden Typ"
Aussage, da mit der zusaetzlichen Schicht "Subtyp" kein Verstaendnisgewinn
erzielt wird. Obwohl: Wenn man Stefans Aussage ueber die interne virtuelle
Klasse Class' fuer jede Klasse hinzunimmt, wuerde es dann doch verstaendlicher...
Hmm... Komische Sache dat... Nur gut, dass ich es nie jemandem derart
erklaeren musste... :-)
De facto existiert der null-Typ nur für den Compiler, nicht für die VM.
Nack.
Fuer die VM gibt es ja nur eine Handvoll Typen, naemlich einige primitive
sowie "reference" (weswegen meiner Ansicht nach die
"CallByReference"-Diskussion ja unnoetig ist, da es so klar ist, dass es
nur "CallByValue" gibt). Letztere enthaelt halt "null" in ihrem Wertebereich,
als Referenz auf die nicht existierende Instanz.
Die meisten VM-Implementationen duerften das "reference"-Primitiv
ueber eine Speicheradresse implementieren und "null" ueber deren
0-Wertigkeit.

Ciao
Chris
--
"Ich habe eine Menge Geld für Sauferei, leichte Mädchen
und schnelle Autos ausgegeben. Den Rest habe ich einfach
verplempert." (George Best)
Stefan Matthias Aust
2004-06-11 07:31:13 UTC
Permalink
Post by Christian Wederhake
*grummelzeterschimpfmeckermotz*
Du hast es heute wohl damit, mich zu korrigieren und ich habe es damit,
Unsinn zu verzapfen...
Jepp - darin ist Paul gut und unerbittlich... Passiert mir auch laufend :)


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Matthias Aust
2004-06-10 08:49:24 UTC
Permalink
Post by Stefan Ram
Post by Daniel Urban
null hat keinen bzw. jeden Typ. Also nicht besonders typsicher.
"The null type has one value, the null reference,
represented by the literal null, which is formed from
ASCII characters. A null literal is always of the null
type."
Java Language Specification Second Edition, 3.10.7 The Null Literal
So what? Dummerweise ist der null type aber untertyp eines jeden
Referenztyps und damit ist Daniels Aussage nach dem bzw. trotzdem
richtig - wenn man "jeden" als "jeden Referenztyp" liest :) Und die
Schlussfolgerung stimmt auch - wenn man "statisch" ergänzt.

Es ist ja an sich nicht schlimm, ein Fehler zur Laufzeit ist ja auch
handhabbar. Aber man sollte eben nicht gleichzeitig das tolle statische
Typsystem loben und wie es hilft Fehler zu finden.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Timothy Truckle
2004-06-10 09:28:19 UTC
Permalink
Stefan Matthias Aust schrieb am Donnerstag, 10. Juni 2004 10:49
[...] Aber man sollte eben nicht gleichzeitig das tolle
statische Typsystem loben und wie es hilft Fehler zu finden.
Entschuldige, aber ich denke, wenn ich in mein Programm bewußt
"null" Übergebe ist es dann nicht auch meine Aufgabe darauf zu
achten, das dieses Objekt den richtigen Typ hat (zum Beispiel
mittels eines Casts)?

bye
TT
--
PGP: 0x273c213E
Stefan Matthias Aust
2004-06-10 09:36:27 UTC
Permalink
Post by Timothy Truckle
Entschuldige, aber ich denke, wenn ich in mein Programm bewußt
"null" Übergebe ist es dann nicht auch meine Aufgabe darauf zu
achten, das dieses Objekt den richtigen Typ hat (zum Beispiel
mittels eines Casts)?
Eine Sprache, die casts kennt ist nicht statisch typsicher. Das ist,
wie schon mehrfach gesagt, nicht so schlimm, aber ich sage das nur gerne
immer um dem (von dir gar nicht vorgebrachten) Argument, "das Typsystem
von Java ist toll, denn es gibt mir statische Typsicherheit" gleich
vorzubeugen.

Ich sehe das so, wenn du meinst, es ist die Aufgabe des Entwicklers auf
Typkompatibilität zu achten - was ich durchaus unterschreiben kann -
dann will ich aber auch kein Typsystem, was gerade umständlich genug
ist, dass es mir in laufend in die Quere kommt ohne das ich wirklich
einen Gewinn davon habe.

Ich habe vor Java jahrelang Smalltalk programmiert (reine streng
getrypte Sprache ohne statisches Typsystem a la Java) und niemals ein
Problem gehabt, was das statische Typsystem von Java hätte lösen können.
Einzig das Äquivalent von NullPointerExceptions war auch dort ein
Problem - wenn auch nicht so groß, da nil dort ebenfalls ein Objekt ist,
dem man Verhalten geben kann. Das waren fast immer Probleme von
nicht-initialisierten Variablen. Ab und zu litt man auch unter dem
Äquivalent einer ClassCastException - wenn man irgendein OBjekt mal
wieder eine bestimmte Nachricht nicht verstand weil man was verwechselt hat.

Das statische Typsystem von Java ist IMHO nützlich, weil es die Sprache
simpel genug macht, dass die IDE schnell eine Code Completion mit den
passenden Methoden anzeigen kann.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Matthias Aust
2004-06-10 08:13:34 UTC
Permalink
Post by Michael Rauscher
Wie soll ich das verstehen und was hat null mit Typsicherheit zu tun?
Eine Sprache, die zur Laufzeit NullPointerExceptions (besser wäre ja
MissingObjectException) werfen kann, ist statisch nicht typsicher.
Javas statisches Typsystem erlaubt aber "null" explizit als Element
jedes Typs. Damit kann man statisch nicht ermitteln, ob nun ein Objekt
vorliegt oder fehlt und es kann zu Laufzeitfehlern kommen.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Timothy Truckle
2004-06-10 09:14:44 UTC
Permalink
Stefan Matthias Aust schrieb am Donnerstag, 10. Juni 2004 10:13
Post by Stefan Matthias Aust
Post by Michael Rauscher
Wie soll ich das verstehen und was hat null mit Typsicherheit
zu tun?
Eine Sprache, die zur Laufzeit NullPointerExceptions (besser
wäre ja MissingObjectException) werfen kann, ist statisch nicht
typsicher. Javas statisches Typsystem erlaubt aber "null"
explizit als Element jedes Typs. Damit kann man statisch nicht
ermitteln, ob nun ein Objekt vorliegt oder fehlt und es kann zu
Laufzeitfehlern kommen.
Es ist Doch eindeutig: Wenn die Refferenz auf das Objekt "null"
verweist fehlt ein Objekt.
Wozu brauche ich den für jeden Typ (also jede Klasse) eine
spezielle leere Refferenz um anzuzeigen, das die Refferenz nicht
auf ein gültiges Objekt zeigt?

BTW: wenn Du jetzt argumentierst, die leeren Refferenzen könnten
alle auf die selbe speziell reservierte Speicheradresse zeigen
bist Du genau wieder beim allgemeinen "null" Objekt.

bye
TT
--
PGP: 0x273c213E
Jan Sauerwein
2004-06-10 12:28:28 UTC
Permalink
On Thu, 10 Jun 2004 11:14:44 +0200, Timothy Truckle
Post by Timothy Truckle
Stefan Matthias Aust schrieb am Donnerstag, 10. Juni 2004 10:13
Post by Stefan Matthias Aust
Post by Michael Rauscher
Wie soll ich das verstehen und was hat null mit Typsicherheit zu tun?
Eine Sprache, die zur Laufzeit NullPointerExceptions (besser
wäre ja MissingObjectException) werfen kann, ist statisch nicht
typsicher. Javas statisches Typsystem erlaubt aber "null"
explizit als Element jedes Typs. Damit kann man statisch nicht
ermitteln, ob nun ein Objekt vorliegt oder fehlt und es kann zu
Laufzeitfehlern kommen.
Es ist Doch eindeutig: Wenn die Refferenz auf das Objekt "null"
verweist fehlt ein Objekt. Wozu brauche ich den für jeden Typ (also jede
Klasse) eine
spezielle leere Refferenz um anzuzeigen, das die Refferenz nicht
auf ein gültiges Objekt zeigt?
BTW: wenn Du jetzt argumentierst, die leeren Refferenzen könnten
alle auf die selbe speziell reservierte Speicheradresse zeigen
bist Du genau wieder beim allgemeinen "null" Objekt.
Object o = null;

oder

String s = "",

oder

JFrame f = null;

sind (besser müssten sein) drei verschiedene Null, denn ich gebe bei ihrer
Erzeugung explizit ihren Typ an.

Jan
Timothy Truckle
2004-06-10 22:00:08 UTC
Permalink
Jan Sauerwein schrieb am Donnerstag, 10. Juni 2004 14:28 in
Post by Jan Sauerwein
Object o = null;
oder
String s = "",
oder
JFrame f = null;
sind (besser müssten sein) drei verschiedene Null,
Nein.
String s =""; ist keine Refferenz auf 'null' sonderen auf ein
String-Objekt ohne Inhalt.
Post by Jan Sauerwein
denn ich
gebe bei ihrer Erzeugung explizit ihren Typ an.
Ja, und zur Compile-Zeit beschwehrt sich Java, wenn Du die
Refferenz an eine unpassende Methode weiter gibst. Was willst Du
mehr?
Oder um beim Thema zu bleiben: Was macht C# anders/besser?

bye
TT
--
PGP: 0x273c213E
Michael Rauscher
2004-06-10 10:28:12 UTC
Permalink
Post by Stefan Matthias Aust
Post by Michael Rauscher
Wie soll ich das verstehen und was hat null mit Typsicherheit zu tun?
Eine Sprache, die zur Laufzeit NullPointerExceptions (besser wäre ja
MissingObjectException) werfen kann, ist statisch nicht typsicher. Javas
statisches Typsystem erlaubt aber "null" explizit als Element jedes
Typs. Damit kann man statisch nicht ermitteln, ob nun ein Objekt
vorliegt oder fehlt und es kann zu Laufzeitfehlern kommen.
Ich würde doch annehmen, dass ein

int? pos = "a".indexOf("a");
int x = pos;

zu einer MissingObjectException führt, wenn pos.hasValue==false gilt.

Wie sieht eigentlich die Rückgabe in indexOf aus, wenn indexOf nichts
zurückgeben möchte?

Gruß
Michael
Timothy Truckle
2004-06-09 22:23:50 UTC
Permalink
Michael Rauscher schrieb am Mittwoch, 9. Juni 2004 12:25 in
[Fehler bei 'indexOf()' abfangen]
Ich fände eine Exception konsequent.

String a="abc";
try{
a.indexOf("e");
}
catch(NoMatchFoundException e){
e.printStackTrace();
}
--
PGP: 0x273c213E
Daniel Urban
2004-06-09 22:41:25 UTC
Permalink
Post by Timothy Truckle
Michael Rauscher schrieb am Mittwoch, 9. Juni 2004 12:25 in
[Fehler bei 'indexOf()' abfangen]
Ich fände eine Exception konsequent.
String a="abc";
try{
a.indexOf("e");
}
catch(NoMatchFoundException e){
e.printStackTrace();
}
Auf keinen Fall. ;-) Macht den Code meiner Meinung nach zu aufgebläht und
häßlich. Außerdem ist es inperformant.

Gruß,

Daniel
Timothy Truckle
2004-06-10 09:08:47 UTC
Permalink
Daniel Urban schrieb am Donnerstag, 10. Juni 2004 00:41 in
Post by Daniel Urban
Post by Timothy Truckle
Ich fände eine Exception konsequent.
Auf keinen Fall. ;-) Macht den Code meiner Meinung nach zu
aufgebläht und häßlich.
Wenn die von Michael vorgeschlagene Prüfmethode dazu kommt kann
man auf die Pflichtexception verzichten und hat nur noch ein
'if'. Das brauche ich ja ohnehin.
Die Exception gibts dann nur, wenn das Vorhandensein des
Teilstrings vor dem Aufruf nicht sichergestellt wurde. Analog zu
'Integer.parseInt()' brauche ich also im Normalfall keine
Exception abzufangen.
Post by Daniel Urban
Außerdem ist es inperformant.
Dazu kann ich keine fundierte Aussage machen, halte es aber für
nicht wesentlich problematische als ein 'if'.

bye
TT
--
PGP: 0x273c213E
Daniel Urban
2004-06-10 20:10:07 UTC
Permalink
Post by Timothy Truckle
Daniel Urban schrieb am Donnerstag, 10. Juni 2004 00:41 in
Post by Daniel Urban
Post by Timothy Truckle
Ich fände eine Exception konsequent.
Auf keinen Fall. ;-) Macht den Code meiner Meinung nach zu
aufgebläht und häßlich.
Wenn die von Michael vorgeschlagene Prüfmethode dazu kommt kann
man auf die Pflichtexception verzichten und hat nur noch ein
'if'. Das brauche ich ja ohnehin.
Die Exception gibts dann nur, wenn das Vorhandensein des
Teilstrings vor dem Aufruf nicht sichergestellt wurde. Analog zu
'Integer.parseInt()' brauche ich also im Normalfall keine
Exception abzufangen.
Eine Prüfmethode bevorzuge ich sowieso, dann wäre eine Exception meiner
Meinung nach bei parseInt() wieder in Ordnung. Genauso wie ich eigentlich
ein if (x == null) erwarte um so zu verhindern dass eine NPE fliegt.
Post by Timothy Truckle
Post by Daniel Urban
Außerdem ist es inperformant.
Dazu kann ich keine fundierte Aussage machen, halte es aber für
nicht wesentlich problematische als ein 'if'.
Dazu gab es hier in der Newsgroup schon Diskussion, Du darft gerne
nachlesen. ;-) Der Unterschied ist größer.

Gruß,

Daniel
Michael Rauscher
2004-06-09 22:46:34 UTC
Permalink
Post by Timothy Truckle
Michael Rauscher schrieb am Mittwoch, 9. Juni 2004 12:25 in
[Fehler bei 'indexOf()' abfangen]
Ich fände eine Exception konsequent.
String a="abc";
try{
a.indexOf("e");
}
catch(NoMatchFoundException e){
e.printStackTrace();
}
Könnte man natürlich auch machen, würde ich aber nicht, da ich indexOf
als Suchmethode ansehe. Exceptions verwende ich, wenn Verträge verletzt
werden, was die Ausnahme von der Regel darstellt.

Jetzt kommt es darauf an, was man unter indexOf versteht:
1. Suchmethode
2. Positionsbestimmungsmethode

Bei 1 ist es keine Ausnahme, dass etwas nicht gefunden wird. Es gehört
zur Suche dazu, festzustellen, dass etwas nicht vorhanden ist. Bei 2
kann man es durchaus zur Vorbedingung machen, dass der "gesuchte" String
Teil des durchsuchten Strings ist.

Damit sollte es aber der Vollständigkeit halber noch eine Suchmethode
geben, die es dem Aufrufer erlaubt, festzustellen, ob der gesuchte
String tatsächlich Teil des durchsuchten Strings ist oder nicht.

Warum also nicht gleich beides vereinen?

Gruß
Michael
Timothy Truckle
2004-06-10 08:58:48 UTC
Permalink
Michael Rauscher schrieb am Donnerstag, 10. Juni 2004 00:46 in
Post by Michael Rauscher
1. Suchmethode
2. Positionsbestimmungsmethode
[super Erklärug]
Warum also nicht gleich beides vereinen?
Weil für uns Unixer der Grundsatz gillt "Eine Aufgabe - ein
Werkzeug."

Aber im Ernst:
Ausgangspunkt war doch, dass die gemischte Anwendung dieser
Funktion Probleme aufwirft, wenn man mit Vorzeichenlosen
Integerwerten arbeiten möchte weil Vorzeichenbehaftete
Rückgabewerte beim nachfolgenden Einsatz nicht notwendig sind.
Ohne Suchfunktion und Positionsbestimmungsfunktion zu trennen ist
das nicht sinnvoll möglich.

bye
TT
--
PGP: 0x273c213E
Michael Rauscher
2004-06-10 10:29:58 UTC
Permalink
Post by Timothy Truckle
Michael Rauscher schrieb am Donnerstag, 10. Juni 2004 00:46 in
Post by Michael Rauscher
1. Suchmethode
2. Positionsbestimmungsmethode
[super Erklärug]
Warum also nicht gleich beides vereinen?
Weil für uns Unixer der Grundsatz gillt "Eine Aufgabe - ein
Werkzeug."
:-)
Post by Timothy Truckle
Ausgangspunkt war doch, dass die gemischte Anwendung dieser
Funktion Probleme aufwirft, wenn man mit Vorzeichenlosen
Integerwerten arbeiten möchte weil Vorzeichenbehaftete
Rückgabewerte beim nachfolgenden Einsatz nicht notwendig sind.
Ohne Suchfunktion und Positionsbestimmungsfunktion zu trennen ist
das nicht sinnvoll möglich.
Wenn man Werte eines primitiven, vorzeichenlosen Datentyps
zurückliefert, ist es in der Tat nicht sinnvoll möglich.

Die Frage wäre dann, ob der gewählte Datentyp für diese Situation der
geeignete ist. Z.B. könnte die Klasse Position keine negativen Werte
zulassen. Schließlich wollen wir ja nicht einfach nur eine Zahl
zurückgeben sondern eine Position.

Gruß
Michael
Stefan Matthias Aust
2004-06-10 09:03:25 UTC
Permalink
Post by Timothy Truckle
[Fehler bei 'indexOf()' abfangen]
Ich fände eine Exception konsequent.
Eine Exception soll einen unvorhergesehenen Zustand ausdrücken. Das ein
String nicht in ienem anderen enthalten ist, ist aber nicht
notwendigerweise unvorhergesehen. Das ist genauso wahrscheinlich wie
das Enthaltensein. Daher ist eine Exception hier allgemein falsch.

Abgesehen davon ist das denkbar umständlich zu formulieren.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Timothy Truckle
2004-06-10 09:23:48 UTC
Permalink
Stefan Matthias Aust schrieb am Donnerstag, 10. Juni 2004 11:03
Post by Stefan Matthias Aust
Post by Timothy Truckle
[Fehler bei 'indexOf()' abfangen]
Ich fände eine Exception konsequent.
Eine Exception soll einen unvorhergesehenen Zustand ausdrücken.
Das ein String nicht in ienem anderen enthalten ist, ist aber
nicht
notwendigerweise unvorhergesehen. Das ist genauso
wahrscheinlich wie
das Enthaltensein.
Das sehe ich analog zu 'Integer.parseInt()'. Auch hier gibt es
eine Exception, selbst wenn der String außer den Ziffern "nur"
ein Leerzeichen enthält. Nur ist es nicht Pflicht, diese
'NumberFormatException' abzufangen.
Aus meiner Sicht spricht nichts dagegen, String.indexOf()' genau
so zu behandeln.
Post by Stefan Matthias Aust
Abgesehen davon ist das denkbar umständlich zu formulieren.
Wenn man Exceptions als lästig und umständlich empfindet...

bye
TT
--
PGP: 0x273c213E
Stefan Matthias Aust
2004-06-10 09:28:25 UTC
Permalink
Post by Timothy Truckle
Das sehe ich analog zu 'Integer.parseInt()'. Auch hier gibt es
eine Exception, selbst wenn der String außer den Ziffern "nur"
ein Leerzeichen enthält. Nur ist es nicht Pflicht, diese
'NumberFormatException' abzufangen.
Aus meiner Sicht spricht nichts dagegen, String.indexOf()' genau
so zu behandeln.
Da halte ich die Exception auch für schlechtes Design und hätte eine
optionales Ergebnis besser gefunden. Lässt sich aber in Java nicht
machen, denn es wird ja ein primitiver Datentyp geliefert, wo es kein
Äquivalent für null gibt. Java ist eben keine elegante Sprache.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Timothy Truckle
2004-06-10 10:13:47 UTC
Permalink
Stefan Matthias Aust schrieb am Donnerstag, 10. Juni 2004 11:28
Post by Stefan Matthias Aust
Post by Timothy Truckle
Das sehe ich analog zu 'Integer.parseInt()'. Auch hier gibt es
eine Exception, selbst wenn der String außer den Ziffern "nur"
ein Leerzeichen enthält. Nur ist es nicht Pflicht, diese
'NumberFormatException' abzufangen.
Aus meiner Sicht spricht nichts dagegen, String.indexOf()'
genau so zu behandeln.
Da halte ich die Exception auch für schlechtes Design und hätte eine
optionales Ergebnis besser gefunden. Lässt sich aber in Java
nicht machen, denn es wird ja ein primitiver Datentyp
geliefert, wo es kein
Äquivalent für null gibt.
Das liegt aber an der Mathematik und nicht an Java.
Post by Stefan Matthias Aust
Java ist eben keine elegante
Sprache.
Ein besondere Situation abweichen vom normalen Verlauf zu
handhaben finde ich eigentlich sehr elegant.

Mag sein, das alte "C"-Hasen das anders sehen...

bye
TT
--
PGP: 0x273c213E
Peter Luschny
2004-06-09 12:00:07 UTC
Permalink
"Stefan Matthias Aust" schrieb
Post by Stefan Matthias Aust
Frag Peter Luschny. Der klagte mal darüber bei Java :)
Mein automatisches Usenet-Frühwarnsystem hat
angeschlagen. Habe im Moment leider keine Zeit
euerer interessanten Diskussion zu folgen.

Übrigens, wenn es einen guten Grund geben sollte,
die Kieler Woche zu besuchen, dann diesen:

Vortragsankündigung
===================

Am Freitag, 25. Juni 2004, 14:15 Uhr, hält Leslie Lamport
einen Vortrag mit dem Thema ``Thinking for Programmers''
an der Christian-Albrechts-Universität zu Kiel.

Wer sich also einmal einen Eindruck des Schöpfers von
LaTeX 2.09 verschaffen möchte, sollte zum obigen Termin
in den Hörsaal 3 am Christian-Albrechts-Platz 3, 24118 Kiel,
kommen.

Der Vortrag ist in englischer Sprache und sollte auch für
Nichtinformatiker interessant sein.

Abstract: There is a very effective software development
tool that is not used nearly enough -- *the brain*.
The many impediments to its proper use devised by computer
scientists can be overcome.

http://www.informatik.uni-kiel.de/inf/deRoever/lamport/2004/

--------

Dank an Ben Lukoschus für den Hinweis!
Das könnte sogar mich ins Reich der Sprotten locken ;-)

Gruss Peter
Paul Ebermann
2004-06-09 19:49:19 UTC
Permalink
Post by Peter Luschny
"Stefan Matthias Aust" schrieb
Post by Stefan Matthias Aust
Frag Peter Luschny. Der klagte mal darüber bei Java :)
Mein automatisches Usenet-Frühwarnsystem hat
angeschlagen.
Ich glaube, das sollte ich mir auch zulegen.
Gibt es das im Netz?


Paul
Magnus Benjes
2004-06-10 12:17:45 UTC
Permalink
Post by Stefan Matthias Aust
Schon gesehen? ->
http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/
Ein IMHO sehr interessanter Vergleich von Java und C#. Verglichen
Es wird erwähnt, dass C# mehrere public toplevel classes in einer Datei
haben kann. Finde ich irrelevant,
Alle Vergleiche halte ich für die Frage "Java oder C#?" für
irrelevant.
In dem Artikel wird die von vielen Studenten in Klausuren und
mündlichen Prüfungen benutzte Strategie verwendet:
"Wenn mir schon nichts zur Lösung der Aufgabe einfällt, so schreibe
ich wenigstens alle Gleichungen auf die zu dem Themenkomplex gehören
und zeige somit, dass ich gebüffelt habe (jedoch nicht gelernt)."

Es wird immer nur die Syntax verglichen. Da C# wesentlich mehr
Schlüsselworte enthält als Java, sollte es auch viele Dinge geben, die
in C# eleganter gehen als in Java,
ABER
1.) Eleganz ist nicht das Entscheidende (sonst gebe es wohl nicht mehr
Stellenanzeigen für ABAP als für Java, C# und C++ zusammen).
2.) Viele Schlüsselworte zu haben ist ein Nachteil einer Sprache (wer
kennt schon "volatile" aus Java?)

Viel entscheidender als die Syntax ist doch die Plattform und die
Zukunftssicherheit (wird mein Code in 10 Jahren noch compilieren und
laufen?)

Plattform:
1.) Bei Java 1.4 haben J2SE und J2EE über 3000 Klassen. Wie viele hat
.net?
2.) Komponentenmodell, das ohne Registry funktioniert (ich habe auch
COM mit VB6 programmiert, da ist es nicht so).
3.) Tomcat, Ant, Eclipse, Castor, Linux, ... die Welt von Open Source
steht mir offen.
4.) J2ME: auf welchem Handy läuft .net?

Zukunftssicherheit:
VB.net ist keine Weiterentwicklung von VB6, sondern C#-Light. Die
Gemeinsamkeiten zwischen VB.net und Java sind damit größer, als
zwischen VB6 und VB.net. Welches 5 Jahre alte Visual Studio Projekt
compiliert unter Visual Studio .net? Warum sollte das in der Zukunft
anders sein?

Hier meine persönlichen Java Goodies, die Java .net voraus hat.
1.) Serialisierung, gibt's erst ab .net 2.0.
2.) HTML in einer Dialogbox oder im Tooltip.
3.) TreeModel und TableModel, wunderschönes MVC Pattern
4.) Zwang zu Exception-Handling
5.) Ant

Gruß
Magnus
Markus Brombach
2004-06-10 12:38:20 UTC
Permalink
Post by Magnus Benjes
Alle Vergleiche halte ich für die Frage "Java oder C#?" für
irrelevant.
Das kommt darauf an, wozu der Vergleich dienen soll.

Wenn mit dem Vergleich die Frage "In welcher Sprache soll ich
programmieren?" beantwortet werden soll, gebe ich dir recht.

Wenn die Frage aber lautet "Was kann ich vom Klassenfeind lernen?" oder
"Wie kann ich C#-Programmierer beleidigen?", dann ist das sicherlich
keine unnütze Sache.

- Markus
Stefan Matthias Aust
2004-06-11 08:03:10 UTC
Permalink
Post by Markus Brombach
Post by Magnus Benjes
Alle Vergleiche halte ich für die Frage "Java oder C#?" für
irrelevant.
Das kommt darauf an, wozu der Vergleich dienen soll.
Er soll zwei Sprachen vergleichen. Seht auch meine Antwort an Stefan W.
Du zählt eine reihe von Argumenten aus ganz anderen Bereichen auf, die
der Artikel überhaupt nicht vergleichen will (vielleicht auch weil C#
dann nicht mehr so gut abschneiden würde, vielleicht weil dem Autoren
diese Punkte nicht wichtig erschienen).


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Wischnewski
2004-06-10 13:05:22 UTC
Permalink
Post by Magnus Benjes
1.) Bei Java 1.4 haben J2SE und J2EE über 3000 Klassen. Wie viele hat
.net?
Mehr Klassen = besser ?
Es kommt doch eher auf die Leistungsfähigkeit an. Und mancher sieht das
JDK mittlerweile als überladen an. Mich interessiert eher, was ich bei
Bedarf dazubekomme. Also Punkt 3.
Post by Magnus Benjes
2.) Komponentenmodell, das ohne Registry funktioniert (ich habe auch
COM mit VB6 programmiert, da ist es nicht so).
Welches Komponentenmodell meinst du ?
Post by Magnus Benjes
3.) Tomcat, Ant, Eclipse, Castor, Linux, ... die Welt von Open Source
steht mir offen.
Ja. Keine Ahnung, wie es für .net aussieht.
Post by Magnus Benjes
4.) J2ME: auf welchem Handy läuft .net?
Mal ehrlich: wen interessiert das ?
Post by Magnus Benjes
Hier meine persönlichen Java Goodies, die Java .net voraus hat.
1.) Serialisierung, gibt's erst ab .net 2.0.
2.) HTML in einer Dialogbox oder im Tooltip.
3.) TreeModel und TableModel, wunderschönes MVC Pattern
4.) Zwang zu Exception-Handling
5.) Ant
Damit könntest du einen Schlips-Träger nicht wirklich für Java als
Plattform überzeugen.

Stefan
Daniel Urban
2004-06-10 20:26:51 UTC
Permalink
Post by Magnus Benjes
Post by Stefan Matthias Aust
Schon gesehen? ->
http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/
Ein IMHO sehr interessanter Vergleich von Java und C#. Verglichen
Es wird erwähnt, dass C# mehrere public toplevel classes in einer Datei
haben kann. Finde ich irrelevant,
Alle Vergleiche halte ich für die Frage "Java oder C#?" für
irrelevant.
Kommt darauf an, was sie aussagen wollen. Wenn ich herausfinden will, welche
die bessere Sprache ist, ist das sicher Unfug. Aber wenn ich mich bei einem
Projekt zum Beispiel für eine Sprache entscheiden muß, mit der ich die
Lösung implementieren soll. Dann kann so ein Vergleich durchaus Sinn machen.
Vermutlich kann man mit jeder halbwegs universellen Sprache alles
implementieren, aber nicht in jeder Sprache ist es entsprechend einfach und
gut möglich.
Post by Magnus Benjes
Es wird immer nur die Syntax verglichen. Da C# wesentlich mehr
Schlüsselworte enthält als Java, sollte es auch viele Dinge geben, die
in C# eleganter gehen als in Java,
ABER
1.) Eleganz ist nicht das Entscheidende (sonst gebe es wohl nicht mehr
Stellenanzeigen für ABAP als für Java, C# und C++ zusammen).
Sicher, aber wenn man zwei gleichwertige Sprachen hat, könnte es den
Auschlag geben.
Post by Magnus Benjes
2.) Viele Schlüsselworte zu haben ist ein Nachteil einer Sprache (wer
kennt schon "volatile" aus Java?)
Falsch. Das liegt nicht an der Anzahl, sondern an der Häufigkeit mit der man
die Schlüsselwörter verwendet. Und Schlüsselwörter die man nie gebraucht
sind auch nicht unbedingt schädlich.
Post by Magnus Benjes
Viel entscheidender als die Syntax ist doch die Plattform und die
Zukunftssicherheit (wird mein Code in 10 Jahren noch compilieren und
laufen?)
Der geklammerte Text ist absolut nicht entscheidend. Kaum eine Software lebt
10 Jahre. D.h. ohne entsprechende Updates, Upgrades, Redesigns usw. Als ist
es absolut egal mit welcher Sprache Du das Programm schreibst. Im Notfall
wird es in 10 Jahren in einer anderen Sprache noch besser und schönder
implementiert.
Post by Magnus Benjes
1.) Bei Java 1.4 haben J2SE und J2EE über 3000 Klassen. Wie viele hat
.net?
Was hat das mit Zukunftsicherheit zu tun? Wer mehr Klassen hat ist besser?
Das ist genau das gleiche wie, wer mehr Schlüsselwörter hat ist besser.
Post by Magnus Benjes
2.) Komponentenmodell, das ohne Registry funktioniert (ich habe auch
COM mit VB6 programmiert, da ist es nicht so).
Kannst Du das auch begründen? Ich meine, man könnte auch das Gegenteil
behaupten (was ich nich mache).
Post by Magnus Benjes
3.) Tomcat, Ant, Eclipse, Castor, Linux, ... die Welt von Open Source
steht mir offen.
Nun gut, aber so alt ist .NET noch nicht, daß es schon eine große Open
Source Gemeinde gäbe. Das ist der Vorteil von Alter, aber wer sagt Dir denn,
daß das in 10 Jahren, wenn .NET so alt ist, wie Java heute, nicht genauso
ist?
Post by Magnus Benjes
4.) J2ME: auf welchem Handy läuft .net?
Du weißt aber schon, daß Java dazu einige Jahre gebraucht hat und daß .NET
noch nicht so alt ist. Und zumindest auf den PocketPC gibt es .NET bereits.
Dort findest Du dann von Mal zu Mal weniger Java.
Post by Magnus Benjes
Hier meine persönlichen Java Goodies, die Java .net voraus hat.
1.) Serialisierung, gibt's erst ab .net 2.0.
2.) HTML in einer Dialogbox oder im Tooltip.
3.) TreeModel und TableModel, wunderschönes MVC Pattern
4.) Zwang zu Exception-Handling
5.) Ant
Du vergißt, daß Java wesentlich älter ist. So etwas braucht Zeit.

Gruß,

Daniel
Magnus Benjes
2004-06-11 06:05:20 UTC
Permalink
Post by Daniel Urban
Post by Magnus Benjes
Viel entscheidender als die Syntax ist doch die Plattform und die
Zukunftssicherheit (wird mein Code in 10 Jahren noch compilieren und
laufen?)
Der geklammerte Text ist absolut nicht entscheidend. Kaum eine Software lebt
10 Jahre. D.h. ohne entsprechende Updates, Upgrades, Redesigns usw. Als ist
es absolut egal mit welcher Sprache Du das Programm schreibst. Im Notfall
wird es in 10 Jahren in einer anderen Sprache noch besser und schönder
implementiert.
Meine Software wird 10 Jahre leben.

Im Maschinen- und Anlagenbau laufen die Anlagen Jahrzehnte. Was ist
wenn der Kunde nach 10 Jahren die Anlage ERWEITERT haben will? Sagst
Du ihm dann, nein das machen wir alles neu, schöner und besser?

Wie lange laufen ABAP's und COBOL's? Was ist wenn die Buchhaltung ein
10 Jahre altes Modul ERWEITERT haben will (z.B. wurde in Schweden vor
ein paar Jahren eine 3.Mwst für Druckerzeugnisse eingeführt), dann
auch alles neu, schöner besser?
Post by Daniel Urban
Post by Magnus Benjes
1.) Bei Java 1.4 haben J2SE und J2EE über 3000 Klassen. Wie viele hat
.net?
Was hat das mit Zukunftsicherheit zu tun? Wer mehr Klassen hat ist besser?
Nichts, es ist ein anderes Thema.
Post by Daniel Urban
Das ist genau das gleiche wie, wer mehr Schlüsselwörter hat ist besser.
Nein, viele hier im Thread haben die Ansicht geäußert, dass Sie
Funktionen aus dem Sprachumfang lieber als Klassen in der
Klassenbibliothek hätten.
Außerdem hat es mich wirklich interessiert, wie groß die .net
Klassenbibliothek ist.
Post by Daniel Urban
Post by Magnus Benjes
2.) Komponentenmodell, das ohne Registry funktioniert (ich habe auch
COM mit VB6 programmiert, da ist es nicht so).
Kannst Du das auch begründen? Ich meine, man könnte auch das Gegenteil
behaupten (was ich nich mache).
Das Zusammenspiel von VB6, COM und Registry war oftmals nicht
reversibel, reproduzierbar und deterministisch. Der Build-Prozess war
extrem Rechnerabhängig. Um ein altes VB4 Projekt zu erweitern solltest
Du ein Image von Deinem damaligen PC aufgehoben haben. Das liegt an
diesen verdammten GUID's.
Post by Daniel Urban
Post by Magnus Benjes
3.) Tomcat, Ant, Eclipse, Castor, Linux, ... die Welt von Open Source
steht mir offen.
Nun gut, aber so alt ist .NET noch nicht, daß es schon eine große Open
Source Gemeinde gäbe.
Das hat auch andere Gründe, Open Source und Microsoft das passt
einfach nicht.
Post by Daniel Urban
Das ist der Vorteil von Alter, aber wer sagt Dir denn,
daß das in 10 Jahren, wenn .NET so alt ist, wie Java heute, nicht genauso
ist?
Das Alter bringt nicht nur Vorteile, sondern auch Altlasten. Wenn die
Altlasten die Vorteile überwiegen ist es Zeit für etwas Neues. Wie
schnell so etwas geht hängt von der Qualität ab. Microsoft hat es
bisher nicht geschafft eine Programmiersprache 10 Jahre kontinuierlich
weiterzuentwickeln. Warum soll das in der Zukunft anders sein?
Post by Daniel Urban
Post by Magnus Benjes
4.) J2ME: auf welchem Handy läuft .net?
Du weißt aber schon, daß Java dazu einige Jahre gebraucht hat und daß .NET
noch nicht so alt ist.
Siehe oben, forever young ...
Post by Daniel Urban
Und zumindest auf den PocketPC gibt es .NET bereits.
Dort findest Du dann von Mal zu Mal weniger Java.
Ich glaube nicht an den PocketPC, ich glaube an das PDA-GPS-Handy
(Scottie beam me up)

Gruß
Magnus
Daniel Urban
2004-06-11 21:18:36 UTC
Permalink
Post by Magnus Benjes
Post by Daniel Urban
Post by Magnus Benjes
Viel entscheidender als die Syntax ist doch die Plattform und die
Zukunftssicherheit (wird mein Code in 10 Jahren noch compilieren und
laufen?)
Der geklammerte Text ist absolut nicht entscheidend. Kaum eine Software lebt
10 Jahre. D.h. ohne entsprechende Updates, Upgrades, Redesigns usw. Als ist
es absolut egal mit welcher Sprache Du das Programm schreibst. Im Notfall
wird es in 10 Jahren in einer anderen Sprache noch besser und schönder
implementiert.
Meine Software wird 10 Jahre leben.
Das sagt Dir Deine Glaskugel? :-)
Post by Magnus Benjes
Im Maschinen- und Anlagenbau laufen die Anlagen Jahrzehnte. Was ist
wenn der Kunde nach 10 Jahren die Anlage ERWEITERT haben will? Sagst
Du ihm dann, nein das machen wir alles neu, schöner und besser?
Also ich kenne Firmen, die anscheinend genau das wollen. Ich würde auch
nicht mehr von der Vergangenheit, wo das sicher noch so war, auf die Zukunft
schließen. Die Zeiten sind vorbei. Die Mentalität hat sich erheblich
geändert. Aber Einzelfälle wird es sicher irgendwo geben.
Post by Magnus Benjes
Wie lange laufen ABAP's und COBOL's? Was ist wenn die Buchhaltung ein
10 Jahre altes Modul ERWEITERT haben will (z.B. wurde in Schweden vor
ein paar Jahren eine 3.Mwst für Druckerzeugnisse eingeführt), dann
auch alles neu, schöner besser?
Also SAP schwänkt zum Beispiel auch auf Java um. Natürlich haben sie ABAP
noch nicht ausgetauscht, aber das liegt sicher auch daran, daß es sehr teuer
wäre. Aber es gibt zum Beispiel einen Applikation Server oder eine SAP
Mobile Engine. Da wird schon sehr viel Java eingesetzt.
Post by Magnus Benjes
Post by Daniel Urban
Das ist genau das gleiche wie, wer mehr Schlüsselwörter hat ist besser.
Nein, viele hier im Thread haben die Ansicht geäußert, dass Sie
Funktionen aus dem Sprachumfang lieber als Klassen in der
Klassenbibliothek hätten.
Den Eindruck hatte ich nicht. Zumal Klassenbibliotheken keine
Schlüsselwörter ersetzen können und umgekehrt auch nicht. Das sind zwei
unterschiedliche Bereiche.
Post by Magnus Benjes
Post by Daniel Urban
Post by Magnus Benjes
3.) Tomcat, Ant, Eclipse, Castor, Linux, ... die Welt von Open Source
steht mir offen.
Nun gut, aber so alt ist .NET noch nicht, daß es schon eine große Open
Source Gemeinde gäbe.
Das hat auch andere Gründe, Open Source und Microsoft das passt
einfach nicht.
Abwarten...
Post by Magnus Benjes
Post by Daniel Urban
Das ist der Vorteil von Alter, aber wer sagt Dir denn,
daß das in 10 Jahren, wenn .NET so alt ist, wie Java heute, nicht genauso
ist?
Das Alter bringt nicht nur Vorteile, sondern auch Altlasten. Wenn die
Altlasten die Vorteile überwiegen ist es Zeit für etwas Neues. Wie
schnell so etwas geht hängt von der Qualität ab. Microsoft hat es
bisher nicht geschafft eine Programmiersprache 10 Jahre kontinuierlich
weiterzuentwickeln. Warum soll das in der Zukunft anders sein?
Weil sich die Zeiten geändert haben? Ich würde nicht darauf wetten, aber ich
würde es auch nicht ausschließen. Und ich würde deswegen .NET nicht
ignorieren. So etwas kann auch in die Hose gehen.
Post by Magnus Benjes
Post by Daniel Urban
Und zumindest auf den PocketPC gibt es .NET bereits.
Dort findest Du dann von Mal zu Mal weniger Java.
Ich glaube nicht an den PocketPC, ich glaube an das PDA-GPS-Handy
Tja, da wird aber auch PocketPC drauf sein. Davon gibt es doch schon einige.

Gruß,

Daniel
Marcus Woletz
2004-06-10 15:41:23 UTC
Permalink
Hallo Stefan,

Stefan Matthias Aust schrieb:

[ausführlicher Vergleich zwischen Java und C#]

wenn ich mir so diverse Programmiersprachen, die nennenswert
verbreitet sind, anschaue, dann sind die Unterschiede zwischen
Java und C# dagegen marginal. Und im Verhältnis zu anderen
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Ich möchte hier ja keinen OT-Flamewar anzetteln, aber ich kann
mich z.B. sehr schwer mit Perl und Tcl anfreunden, und auch
Bash-Skripte machen mir nicht wirklich Spaß.

ciao
Marcus
Stefan Matthias Aust
2004-06-11 07:13:05 UTC
Permalink
Post by Marcus Woletz
[ausführlicher Vergleich zwischen Java und C#]
wenn ich mir so diverse Programmiersprachen, die nennenswert
verbreitet sind, anschaue, dann sind die Unterschiede zwischen
Java und C# dagegen marginal.
Das ist IMHO eine korrekte Beobachtung. Ich möchte es so drehen:
Offenbar muss eine Sprache, damit sie zum Mainstream zählt, nahezu
identisch zu den vorhandenen Mainstream-Sprachen sind. Oder
provokanter: Offensichtlich sind Mainstream-Software-Entwickler nicht in
der Lage oder willens, sich auf größere Änderungen (die dann auch das
Potential für größere Verbesserungen haben) einzulassen.
Post by Marcus Woletz
Und im Verhältnis zu anderen
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Das ist mir viel zu pauschal. Eleganter zu C? Wahrscheinlich. Zu Perl?
Wenn man's von der Syntax her sieht, sicherlich. Blickt man hinter die
Syntax, bietet Perl eine deutlich größere Ausdruckskraft. Eleganter als
z.B. Ruby? Definitiv nicht. Und dann kommen natürlich persönliche
Vorlieben, wo ich nichts auf Smalltalk kommen lassen würde was ich
persönlich für eine der elegantesten Sprachen halte... :)

Aber um darüber zu streiten, sollte man erstmal definieren (oder es
versuchen), was Eleganz eigentlich bedeutet. Ich will es versuchen -
für mich ist es Minimalismus bei maximaler Ausdruckskraft.
Orthogonalität kann man es vielleicht nennen.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Wischnewski
2004-06-11 07:36:01 UTC
Permalink
Post by Stefan Matthias Aust
Post by Marcus Woletz
[ausführlicher Vergleich zwischen Java und C#]
wenn ich mir so diverse Programmiersprachen, die nennenswert
verbreitet sind, anschaue, dann sind die Unterschiede zwischen
Java und C# dagegen marginal.
Offenbar muss eine Sprache, damit sie zum Mainstream zählt, nahezu
identisch zu den vorhandenen Mainstream-Sprachen sind. Oder
provokanter: Offensichtlich sind Mainstream-Software-Entwickler nicht in
der Lage oder willens, sich auf größere Änderungen (die dann auch das
Potential für größere Verbesserungen haben) einzulassen.
Ja was ist denn das? Ein Mainstream-Software-Entwickler?
Bei vielen Projekten ist mangelnder Wille zur Veränderung wohl kaum den
Entwicklern anzukreiden.
Und eine "Mainstream"-Sprache zu wählen, ist durchaus sinnvoll. Können
meine Entwickler mit Java umgehen, werden sie wahrscheinlich ohne
größeren Lern- und Kostenaufwand zu C# wechseln können. Wie ist das
Verhältnis von Java/C#/VB-Entwicklern zu Smalltalk-Kundigen? Und das
Angebot zusätzlicher Software?
Welche konkreten Vorteile hat es, ein Projekt in Smalltalk anstatt in
Java durchzuziehen?

Stefan
Stefan Matthias Aust
2004-06-11 07:51:26 UTC
Permalink
Post by Stefan Wischnewski
Ja was ist denn das? Ein Mainstream-Software-Entwickler?
Ein Entwickler, der Mainstream-Software benutzt. :)
Post by Stefan Wischnewski
Bei vielen Projekten ist mangelnder Wille zur Veränderung wohl kaum den
Entwicklern anzukreiden.
Ich versuche zwischen technischen Argumenten und kaufmännischen
Argumenten zu unterscheiden. Letztere versuche ich bei dieser
Diskussion außen vor zu lassen. Vielleicht ist daher ja ein MSE, dem
die kaufmännischen Aspekte wichtiger sind :)
Post by Stefan Wischnewski
Und eine "Mainstream"-Sprache zu wählen, ist durchaus sinnvoll.
Unbestritten. Aber dadurch wird sie nicht besser und darum dreht sich
diese Diskussion IMHO.
Post by Stefan Wischnewski
Können
meine Entwickler mit Java umgehen, werden sie wahrscheinlich ohne
größeren Lern- und Kostenaufwand zu C# wechseln können.
Was natürlich der Grund ist, warum C# genau so aussieht - die
spekulieren warscheinlich noch eher auf Umsteiger von C++ und C, daher
ist C# auch so benannt.
Post by Stefan Wischnewski
Welche konkreten Vorteile hat es, ein Projekt in Smalltalk anstatt in
Java durchzuziehen?
Das ist nicht die für mich spannende Frage. Diese lautet eher, welche
Vorteile hat ein Entwickler bei allen Projekten, wenn er diese Sprache
beherrscht. Eine Kenntnis mehrere Sprachen und damit auf der Vor- und
Nachteile verschiedener Sprachen bietet einen breiteren Fundus an
Lösungsmöglichkeiten für Probleme.


Und abgesehen davon, eigentlich wollte ich nur auf den Artikel von
Microsoft hinweisen und Java vielleicht ein bisschen verteiden. Ist
irgendwie schief gegangen :)


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Wischnewski
2004-06-11 08:11:04 UTC
Permalink
Post by Stefan Matthias Aust
Post by Stefan Wischnewski
Welche konkreten Vorteile hat es, ein Projekt in Smalltalk anstatt in
Java durchzuziehen?
Das ist nicht die für mich spannende Frage. Diese lautet eher, welche
Vorteile hat ein Entwickler bei allen Projekten, wenn er diese Sprache
beherrscht. Eine Kenntnis mehrere Sprachen und damit auf der Vor- und
Nachteile verschiedener Sprachen bietet einen breiteren Fundus an
Lösungsmöglichkeiten für Probleme.
Sicher, Wissen nützt meistens. Aber hat es wirklich Auswirkungen auf das
Arbeitsergebnis wenn jemand nur eine Sprache kennt?
Meine Frage finde ich trotzdem gar nicht so schlecht. Und du als
Smalltalk-Advokat...
Post by Stefan Matthias Aust
Und abgesehen davon, eigentlich wollte ich nur auf den Artikel von
Microsoft hinweisen und Java vielleicht ein bisschen verteiden. Ist
irgendwie schief gegangen :)
Glaube, ich habe noch keinen derartigen Artikel gelesen, der wirklich
objektiv war oder es zumindest versuchte, ob es um Java/C# ging oder um
die heilige Frage der Datenspeicherung. Sollte man eigentlich
ignorieren, aber ich lese das Zeug auch ;-)

Stefan
Stefan Matthias Aust
2004-06-11 08:45:55 UTC
Permalink
Post by Stefan Wischnewski
Meine Frage finde ich trotzdem gar nicht so schlecht. Und du als
Smalltalk-Advokat...
Was soll ich dazu sagen: Unter gleichen Startvoraussetzungen wären ich
mit Smalltalk schneller. Und es würde mehr Spass machen - klingt komisch
als Argument, aber die Erfahrung zeigte, dass den meisten Entwicklern
der Umgang mit Smalltalk (wenn sie ihn dann gelernt hatten) Spass machte
und durch diese positive Einstellung ist man auch produktiver.

Was sind gleiche Startvoraussetzung: Etwa das ich ohne den Rückgriff aus
vorhandene 3rd Party Bibliotheken arbeite. Natürlich kann die Sprache
Smalltalk nicht den Aufwand ausgleichen, dem man hätte, um sich erstmal
etwas wie Tomcat in Smalltalk zu bauen. Doch wenn wir unter der Annahme
vergleichen, für beide Sprachen wäre ein Tomcat vorhanden, dann sehe ich
einen Vorteil - eben aufgrund der einfacheren und gleichzeitig
mächtigeren Sprache.
Post by Stefan Wischnewski
objektiv war oder es zumindest versuchte, ob es um Java/C# ging oder um
die heilige Frage der Datenspeicherung.
Was ist daran so schwer? Man überlegt etwas und nimmt dann doch Oracle
:) So kenne ich das jedenfalls aus den meisten größeren Projekten...

Karsten sagte mir mal vor einigen Jahren auf die Frage, welchen Drucker
ich mir kaufen sollte "Schau dir alle an, überlege, und kaufe dann einen
HP..."

Merke: Der Große gewinnt - meist. Doch seit zwei Jahren habe ich jetzt
einen Kyocera und bin damit wesentlich zufriedener...


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Wischnewski
2004-06-11 09:19:07 UTC
Permalink
Post by Stefan Matthias Aust
Post by Stefan Wischnewski
Meine Frage finde ich trotzdem gar nicht so schlecht. Und du als
Smalltalk-Advokat...
Was soll ich dazu sagen: Unter gleichen Startvoraussetzungen wären ich
mit Smalltalk schneller. Und es würde mehr Spass machen - klingt komisch
als Argument, aber die Erfahrung zeigte, dass den meisten Entwicklern
der Umgang mit Smalltalk (wenn sie ihn dann gelernt hatten) Spass machte
und durch diese positive Einstellung ist man auch produktiver.
Ok.
Sich in Neues einzuarbeiten, kostet leider immer viel Zeit. Wenn ich
privat Lust zum Programmieren, versuche ich mich dann lieber z.B. in der
Spieleprogrammierung - mit Java.
Post by Stefan Matthias Aust
Post by Stefan Wischnewski
objektiv war oder es zumindest versuchte, ob es um Java/C# ging oder
um die heilige Frage der Datenspeicherung.
Was ist daran so schwer? Man überlegt etwas und nimmt dann doch Oracle
:) So kenne ich das jedenfalls aus den meisten größeren Projekten...
Karsten sagte mir mal vor einigen Jahren auf die Frage, welchen Drucker
ich mir kaufen sollte "Schau dir alle an, überlege, und kaufe dann einen
HP..."
Merke: Der Große gewinnt - meist. Doch seit zwei Jahren habe ich jetzt
einen Kyocera und bin damit wesentlich zufriedener...
Bin auch gewechselt - jetzt habe ich einen Drucker, der mich
bevormundet, indem er die Patronen nur herausgibt, wenn ER meint, sie
seien leer.
Stefan Matthias Aust
2004-06-11 09:25:29 UTC
Permalink
Post by Jan Sauerwein
Wenn ich
privat Lust zum Programmieren, versuche ich mich dann lieber z.B. in der
Spieleprogrammierung - mit Java.
Na, da habe ich doch in Kürze ein Angebot für dich... :) Ich will mich
anhand eines einfachen Strategie-Bei-Spiels in SWT 3.0 einarbeiten und
würde mich über Mitstreiter freuen...
Post by Jan Sauerwein
Bin auch gewechselt - jetzt habe ich einen Drucker, der mich
bevormundet, indem er die Patronen nur herausgibt, wenn ER meint, sie
seien leer.
Ist es nicht schön, wenn andere für einen denken? ;)


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Stefan Wischnewski
2004-06-11 11:27:33 UTC
Permalink
Post by Stefan Matthias Aust
Wenn ich privat Lust zum Programmieren, versuche ich mich dann lieber
z.B. in der Spieleprogrammierung - mit Java.
Na, da habe ich doch in Kürze ein Angebot für dich... :) Ich will mich
anhand eines einfachen Strategie-Bei-Spiels in SWT 3.0 einarbeiten und
würde mich über Mitstreiter freuen...
Tja, habe in letzter Zeit gar nichts mehr gemacht und dann habe ich auch
noch ein angefangenes Framework liegen, für klassische
2D-Scrolling-Spiele...

Stefan
Jochen Theodorou
2004-06-11 11:28:04 UTC
Permalink
[....]
Post by Stefan Matthias Aust
Post by Marcus Woletz
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Das ist mir viel zu pauschal.
Was ist denn überhaupt elegant? Ich finde elegant ist, wenn man ein
Programm hat, es ansieht und versteht ohne lange darüber nachzudenken.
Dabei hilft ein kurzes Programm und eine nicht so kryptische Syntax.
Aber da muss noch mehr sein, denn obwohl Lisp-Programm keine kryptische
Syntax hat und die Programme sehr viel kurzer sind verstehe ich die
Programme oft nciht gleich. Wenn ich sie selber schreibe ist es ja kein
Problem, aber wenn ich ein Lisp-Programm von jemand anderem bekomme,
dann muss ich mich da erstmal reindenken. in Java, C und C++ bin ich
wesentlich schneller, wenn es darum geht den Sinn des Programmes zu
erkennen. Ich denke es liegt doch irgendwie an der Syntax... Lisp ist zu
kurz.
Post by Stefan Matthias Aust
Und dann kommen natürlich persönliche
Vorlieben, wo ich nichts auf Smalltalk kommen lassen würde was ich
persönlich für eine der elegantesten Sprachen halte... :)
Smalltalk finde ich auch recht kryptisch... sicherlich nur eine Sache
der Gewöhnung.
Post by Stefan Matthias Aust
Aber um darüber zu streiten, sollte man erstmal definieren (oder es
versuchen), was Eleganz eigentlich bedeutet. Ich will es versuchen -
für mich ist es Minimalismus bei maximaler Ausdruckskraft.
Orthogonalität kann man es vielleicht nennen.
Mir ist die Lesbarkeit wesentlich wichtiger als Minimalismus und
Ausdruckskraft. Man stelle sich eine Sprache vor, die aus so vielen
Makros besteht, dass man fast alles in einer Zeile Programmieren kann...
ist das elegant?

Gruss theo
Jan Sauerwein
2004-06-11 12:02:39 UTC
Permalink
Post by Jochen Theodorou
[....]
Post by Stefan Matthias Aust
Post by Marcus Woletz
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Das ist mir viel zu pauschal.
Was ist denn überhaupt elegant? Ich finde elegant ist, wenn man ein
Programm hat, es ansieht und versteht ohne lange darüber nachzudenken.
Dabei hilft ein kurzes Programm und eine nicht so kryptische Syntax.
Aber da muss noch mehr sein, denn obwohl Lisp-Programm keine kryptische
Syntax hat und die Programme sehr viel kurzer sind verstehe ich die
Programme oft nciht gleich. Wenn ich sie selber schreibe ist es ja kein
Problem, aber wenn ich ein Lisp-Programm von jemand anderem bekomme, dann
muss ich mich da erstmal reindenken. in Java, C und C++ bin ich
wesentlich schneller, wenn es darum geht den Sinn des Programmes zu
erkennen. Ich denke es liegt doch irgendwie an der Syntax... Lisp ist zu
kurz.
Ich kenne viele Mathematiker, die genau das Gegenteil behaupten. Gewöhnung
ist ein ziemlich gewaltiger Faktor, wenn es darum geht sich in ein Programm
einzufinden. Wenn man mit der Denkweise des anderen Entwicklers vertraut
ist.
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Und dann kommen natürlich persönliche Vorlieben, wo ich nichts auf
Smalltalk kommen lassen würde was ich persönlich für eine der
elegantesten Sprachen halte... :)
Smalltalk finde ich auch recht kryptisch... sicherlich nur eine Sache der
Gewöhnung.
Smalltalk hat den Nachteil, dass C und C++ und eigentlich auch Pascal und
Delphi existieren. Die Denkweise hinter Smalltalk ist doch für die
geprägten imparativ programmierenden Entwickler ein harter Brocken. Wenn
man jedoch Smalltalk völlig vorurteilsfrei nähert, kann ich mir kaum
vorstellen, dass man nach ein zwei Wochen eine gewisse Süchtigkeit
verspürt. Nicht das Smalltalk jetzt keine Mängel hat, aber das Konzept der
Sprache, wirklich alles als Objekt und Nachricht aufzufassen ist doch
ziemlich gemütlich. Vor allem wenn man fremden Code lesen muss.
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Aber um darüber zu streiten, sollte man erstmal definieren (oder es
versuchen), was Eleganz eigentlich bedeutet. Ich will es versuchen -
für mich ist es Minimalismus bei maximaler Ausdruckskraft.
Orthogonalität kann man es vielleicht nennen.
Mir ist die Lesbarkeit wesentlich wichtiger als Minimalismus und
Ausdruckskraft. Man stelle sich eine Sprache vor, die aus so vielen
Makros besteht, dass man fast alles in einer Zeile Programmieren kann...
ist das elegant?
Nein, zumindest wenn dieses Programm sehr aussagelos ist (nicht zu
verwechseln mit es tut nichts). Aber wie in jeder normalen Sprache gilt,
alles was kurz und prägnant formuliert ist, wird für den Zuhörer/Leser
verständlich. Wenn mich die Syntax von der eigentlichen Aufgabe des
Programms ablenkt, ist das genauso unschön, wie der Fall, wenn ich ein
Programm in einem Stakato-Stil vorliegen habe, bei dem die Erkenntnis nur
stoßweise vordringt.

Jan
Daniel Urban
2004-06-11 21:29:06 UTC
Permalink
Post by Jochen Theodorou
[....]
Post by Stefan Matthias Aust
Post by Marcus Woletz
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Das ist mir viel zu pauschal.
Was ist denn überhaupt elegant? Ich finde elegant ist, wenn man ein
Programm hat, es ansieht und versteht ohne lange darüber nachzudenken.
Und dann implementierst Du objektorientiert? Da gibt es
Programmierparadigmen, die das vestehen von Programmen deutlich erleichtern.
Also das alleine kann es nicht sein, sonst würdest Du nicht in Java
implementieren.
Post by Jochen Theodorou
Aber da muss noch mehr sein, denn obwohl Lisp-Programm keine kryptische
Syntax hat und die Programme sehr viel kurzer sind verstehe ich die
Programme oft nciht gleich. Wenn ich sie selber schreibe ist es ja kein
Problem, aber wenn ich ein Lisp-Programm von jemand anderem bekomme,
dann muss ich mich da erstmal reindenken. in Java, C und C++ bin ich
wesentlich schneller, wenn es darum geht den Sinn des Programmes zu
erkennen. Ich denke es liegt doch irgendwie an der Syntax... Lisp ist zu
kurz.
Sicher hat das auch etwas mit Gewöhnung und Training zu tun.
Post by Jochen Theodorou
Post by Stefan Matthias Aust
Aber um darüber zu streiten, sollte man erstmal definieren (oder es
versuchen), was Eleganz eigentlich bedeutet. Ich will es versuchen -
für mich ist es Minimalismus bei maximaler Ausdruckskraft.
Orthogonalität kann man es vielleicht nennen.
Mir ist die Lesbarkeit wesentlich wichtiger als Minimalismus und
Ausdruckskraft. Man stelle sich eine Sprache vor, die aus so vielen
Makros besteht, dass man fast alles in einer Zeile Programmieren kann...
ist das elegant?
Aber wenn ich sechsmal delegiere bis ich an die eigentliche Implementierung
der Methode komme, dann ist das übersichlich und leicht verständlich? Alles
Gewöhnungssache...

Gruß,

Daniel
Jan Sauerwein
2004-06-12 07:09:14 UTC
Permalink
Post by Daniel Urban
Post by Jochen Theodorou
[....]
Post by Stefan Matthias Aust
Post by Marcus Woletz
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Das ist mir viel zu pauschal.
Was ist denn überhaupt elegant? Ich finde elegant ist, wenn man ein
Programm hat, es ansieht und versteht ohne lange darüber nachzudenken.
Und dann implementierst Du objektorientiert? Da gibt es
Programmierparadigmen, die das vestehen von Programmen deutlich erleichtern.
Also das alleine kann es nicht sein, sonst würdest Du nicht in Java
implementieren.
Welche Entwicklungstechniken sind denn deiner Meinung nach besser.
(Irrelevant sind jetzt Programme unter 20000 Programmzeilen, da man da
eigentlich so ziemlich jeder Technik ohne größere Probleme verstehen kann.)
Skriptsprachen wie PHP, Perl, Python und auch Ruby haben bis zu einer
gewissen Größe mit ihrem imparativen, teilprozeduralen Stil ihre Vorteile.
Ihre Lesbarkeit nimmt jedoch mit wachsendem Code rapide ab. Die klassischen
prozeduralen Sprachen wie C und Pascal leiden auch schnall unter dem
Bandwurm-Problem, da das gliedern in sinnvolle Einheiten meist versäumt
oder aber nachträglich aufgeweicht wird. Units und Bibliotheken bieten
einfach nicht die gleichen Sinnzusammenhänge wie Klassen und Pakete. Jetzt
könnten wir auf die Ebene der Basics zurück? Hast du dir mal den Code alter
C64-oder Amigaspiele angesehen? Ich beneide keinen der Entwickler die mit
einem Basic die Spiele schreiben musst, einfach aus Mangel an Alternativen.
Bleiben die Techniken, ausserhalb der imperativen Welt und neuere Ansätze.
Ich kenne sehr viele, die bei Prolog schon bei kleineren Programmen
aussteigen, vielleicht auch nur, weil ihnen das Denken in Prädikatenlogik
Schmerzen bereitet. Genauso sadistisch ist es meist Nicht-Mathematiker mit
funktionalen Ansätzen zu quälen.

Bei den neueren Ideen, viele mir jetzt als Besserung im Entwicklungsprozess
Aspect-Oriented-Programming ein. Dies ist wunderbar beim entwickeln, nur
hatte ich mal das vergnügen mich in ein solches Projekt einarbeiten zu
müssen: Horror! Auf Objektebene zurückzugehen bringt hier nichts, da diese
nur maschinenerzeugte Konstrukte sind - und dementsprechend "leicht" zu
verstehen. In den Aspektschichten kann das Ganze aber auch hart werden,
denn auf dieser Ebene aller Zusammenhänge zwischen den Aspekten zu erkennen
ist doch nicht immer auf den ersten Blick zu erkennen. Da es hierfür aber
noch keine Sprache gibt, und es wohl auch nicht geben wird, da dies ein
anderer Ansatz ist, gehe ich mal davon aus du meinst eine der
imperativ/prozeduralen Sprachen, als verständliche Beispiele im Gegensatz
zu objektorientierten Sprachen.

Das es bessere objekt-orientierte Sprachen gibt als Java, wird von mir
nicht bestritten, aber ich halte das Konzept der Objektorientierung doch
für einer der leicht lesbarsten Konzepte.

Jan
Daniel Urban
2004-06-12 09:40:52 UTC
Permalink
On Fri, 11 Jun 2004 23:29:06 +0200, Daniel Urban
Post by Daniel Urban
Post by Jochen Theodorou
[....]
Post by Stefan Matthias Aust
Post by Marcus Woletz
Sprachen sind beide IMO _wesentlich_ eleganter zu verwenden.
Das ist mir viel zu pauschal.
Was ist denn überhaupt elegant? Ich finde elegant ist, wenn man ein
Programm hat, es ansieht und versteht ohne lange darüber nachzudenken.
Und dann implementierst Du objektorientiert? Da gibt es
Programmierparadigmen, die das vestehen von Programmen deutlich erleichtern.
Also das alleine kann es nicht sein, sonst würdest Du nicht in Java
implementieren.
Welche Entwicklungstechniken sind denn deiner Meinung nach besser.
Es geht nicht um besser. Es ging um das Verstehen. Ich halte Modula
(zumindest an den Teil an den ich mich erinnere) für deutlich
verständlicher, was sicher auch daran liegt, daß es eine Lehrsprache ist,
die (teilweise) aus diesem Grund entwickelt wurde.

Und grundsätzlich würde ich behaupten, je weniger mächtig eine Sprache ist,
desto einfacher ist sie zu verstehen. Ausnamhen gibt es dabei natürlich
immer.
Ihre Lesbarkeit nimmt jedoch mit wachsendem Code rapide ab. Die klassischen
prozeduralen Sprachen wie C und Pascal leiden auch schnall unter dem
Bandwurm-Problem, da das gliedern in sinnvolle Einheiten meist versäumt
oder aber nachträglich aufgeweicht wird.
Jetzt vermischst Du aber die Sprache/Paradigma mit dem Gebrauch. Ich kann in
jeder Sprache/Paradigmen unverständlich implementieren oder mich an die
Konzepte halten. Wir dürfen daher nur die konzepttreuen Beispiele
vergleichen. Sonst macht die Diskussion überhaupt keinen Sinn.
Ich kenne sehr viele, die bei Prolog schon bei kleineren Programmen
aussteigen, vielleicht auch nur, weil ihnen das Denken in Prädikatenlogik
Schmerzen bereitet. Genauso sadistisch ist es meist Nicht-Mathematiker mit
funktionalen Ansätzen zu quälen.
Da kommen wir eben wieder auf meinen Hauptpunkt. Die
Eleganz/Lesbarkeit/Verständlichkeit einer Sprache hängt eben auch vom
Problem ab. Deswegen würde ich die Sprache problem-/anforderungsorientiert
aussuchen.
Das es bessere objekt-orientierte Sprachen gibt als Java, wird von mir
nicht bestritten, aber ich halte das Konzept der Objektorientierung doch
für einer der leicht lesbarsten Konzepte.
Gewöhnungssache und vermutlich auch eine Frage, was Du wann gelernt hast.
Wenn Du Java und OO gleichsetzt, vergißt Du den doch starken imperativen
Teil an Java. Ich erinnere mich nur schwach an Smalltalk, da ich in der Uni
nur ein halbes Jahr damit zu tun hatte, aber ich fand die Sprache und deren
Konzepte sehr gewöhnungsbedürftig.

Gruß,

Daniel

Stefan Matthias Aust
2004-06-12 08:03:00 UTC
Permalink
Post by Jochen Theodorou
Was ist denn überhaupt elegant? Ich finde elegant ist, wenn man ein
Programm hat, es ansieht und versteht ohne lange darüber nachzudenken.
Ich habe versucht, es objektiv zu definieren. Du aber argumentierst mit
einer sehr subjektiven Lesbarkeit. Das Wort ist vielleicht auch
schlecht gewählt. Denn wir meinen beide sicherlich keinen modischen
Geschmack (denn über geschmack lässt sich streiten) sondern bestenfalls
die sekundäre Bedeutung Gewandheit.
Post by Jochen Theodorou
Ich denke es liegt doch irgendwie an der Syntax... Lisp ist zu kurz.
Vielleicht unterliegst du auch einfacher einer Fehleinschätzung. Ein
Rechenbeispiel: Angenommen, du ein 5000-Zeilen-C/Java-Programm und
brauchst 5h um es zu verstehen. Dieses Programm in Lisp würde 1000
Zeilen umfassen. Ein 5000 Zeilen-Lisp-Programm wäre damit schon fünf
mal so komplex wie das Ursprungsprogramm. Wenn du jetzt dafür sagen wir
15h brauchst, um es zu verstehen, dauert das zwar auf den ersten Blick
länger, aber auf die ursprüngliche Komplexität runtergerechnet, wärst du
mit 3h eben doch schneller.

Den Faktor 5 mache ich an meinem Experiment fest, dass ich mal ein ca.
5000 zeiliges C-Programm (welches in gutem, knappen Stil geschrieben
war) auf ein meiner bescheidenen Meinung nach ebenfalls in guten Stil
geschriebenen Ruby-Programm mit 1300 Zeilen reduzieren konnte. Ein 8000
zeiliges anderes C-Programm, so habe ich mal hochgerechnet, hätte ich in
ca. 3000 Zeilen Smalltalk ausdrücken können - war mir dann aber zu viel
Arbeit, das durchzuziehen :) Interessanterweise gelingt es mir in Java
nicht (wie an rogue -> jrogue ausprobiert) die Zeilenzahl signifikant zu
senken.

LOC ist zwar an sich ein schlechtes Maß, aber da man grob sagen kann
eine Zeilen = eine Anweisung und ich Kommentare nicht mitgerechnet habe,
ist es ein grobes Maß für die Komplexität.
Post by Jochen Theodorou
Smalltalk finde ich auch recht kryptisch... sicherlich nur eine Sache
der Gewöhnung.
Siehe Jans Argumente...

Smalltalk empfinde ich als eine der lesbarsten Sprachen überhaupt. Man
darf nur nicht versuchen, alles durch die Brille der geschweiften
Klammern zu sehen.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Wanja Gayk
2004-06-10 22:21:45 UTC
Permalink
Stefan Matthias Aust said...
Post by Stefan Matthias Aust
Bei den Datentypen hat C# in für Geschäftsanwendungen wichtigen Datentyp
"decimal". Diesen könnte man duch BigInteger bzw. BigDecimal bei Java
realisieren, aber wegen des fehlenden operator overloadings ist es
anstrengend, mit diesen Objekten zu arbeiten. C# hat operator
overloading. Warum es daher ein eigener primitiver Datentyp sein musste
erschließt sich mir nicht.
Java hingegen könnte ihn demnach brauchen.
Post by Stefan Matthias Aust
C# hat "unsigned" Datentypen. Macht das Rechnen einfacher.
Hätte ich in Java auch gerne. Diesen "&0xff"-Workaround halte ich für
eine schmutzigen Hack der nicht sein muss.
Post by Stefan Matthias Aust
Switch ist IMHO besser gelöst als in Java und man hat sich von
C-Kompatibiliät gelöst, was an sich schon mal gut ist :) Noch ein
Pluspunkt.
Ich halte den Fallthrough als default für OK, wenn auch problematisch
für Anfänger.
ein

switch(type){
case CONSTANT_1: //fall through
case CONSTANT_2: //fall through
case CONSTANT_3: //fall through
default: throw new IllegalArgumentException("Unknown type, use "
+getClass().getName()+" constants!");
}

Finde ich ab und zu recht hilfreich, wenn's nicht zu viele Konstanen
sind.
Kann man allerdings auch mit "assert" erschlagen, was aber nur bedeutet,
dass man zusätzlichen Aufwand treiben muss, um sicherzustellen, dass
diese auch aktiviert sind - bei Bibliotheken halte ich assert daher für
unpassend.
Wie auch immer, ich schweife ab.

Mir graut aber vor den Konstrukten, die mit dem goto im switch zu
treiben sind, ich neige dazu das als potentiellen Spaghetticodemacher zu
bezeichnen.
Gut hingegen finde ich, dass Strings im Switch Statement erlaubt sind.
Man könnte auch in Java ein Switch mit Objekten im allgemeinen zulassen,
IMHO, zur Auswertng könnte man die Equals-Methode hernehmen.
Post by Stefan Matthias Aust
Auch die
Entscheidung, private als default zu nehmen finde ich besser. Noch ein
Plus-Punkt.
Ack.
Unter Java finde ich es übrigens etwas merkwürdig, von der Namengebung
her, dass "package" eingeschränkter ist, als "protected". Nunja.. egal.
Post by Stefan Matthias Aust
Mehr Freiheit bei der Signatur der Main-Methoden bei C# finde ich auch
nicht erstrebenswert.
Ich find's okay, warum auch nicht?
Post by Stefan Matthias Aust
Call-by-reference für Variablen ist nett... noch besser hätte ich aber
gefunden, wenn die Sprachen Tupel-Typen hätten und demzufolge mehrfache
Rückgabewerte zulassen würde. Bietet dummerweise weder Java noch C#.
Da liesse sich vielleicht ein wenig Overhead sparen, der beim
Instanzieren von Arrays oder Collections anfällt, aber wie löst man das
syntaktisch stimmig zur bisherigen Lösung?
Post by Stefan Matthias Aust
Variable Argumente direkt statt extra ein Object[] zu benutzen finde ich
da wesentlich wichtiger und brauche ich häufiger. Schön, dass C# das
kann. Java wird's ab 1.5 können.
Dazu würden zumindest multiple Rückgabewerte passen.
Post by Stefan Matthias Aust
Das man in C# überschriebene Methoden mit "override" kennzeichnen muss
finde ich gut.
Das mag in der einen oder anderen Situation für mehr Lesbarkeit und
weniger Flüchtigkeitsfehler sorgen, ich schätze aber, dass es beim
Refactoring ohne Hilfswerkzeuge echt Lästig sein kann.
Post by Stefan Matthias Aust
Das man "virtual" 'dranschreiben muss finde ich
schlecht. Das man dadurch auch Methoden mit gleichen Namen in
Unterklassen definieren kann, ebenfalls, da nur verwirrend.
Ack.
Post by Stefan Matthias Aust
Und wenn schon nicht Operator-Overloading generell, dann wäre ich
glücklich wenn nur der Index-Operator [] überschreibbar wäre. Ein
map["Hallo"] = map["Welt"]
Hm, ich war der Meinung unter TurboPascal mal Buchstaben als Indizes
benutzt zu haben, aber das waren wohl nur character.
Post by Stefan Matthias Aust
finde ich so viel besser und einheitlicher als
integerArray[0]
string.charAt(0)
list.get(0)
map.get(0)
Naja, zur Not nimmt man halt ein paar Konstanten her, wenn die
Positionen fix sind.
Post by Stefan Matthias Aust
Exceptions in C# sind niemals checked. Ich könnte damit leben. Ob es
ein Vorteil oder doch Nachteil ist, kann ich nicht sagen - tendiere aber
zu einem Vorteil, weil ich doch zu häufig in Java schon "normale"
Exceptions in Runtime-Exceptions verpacken musste, nur um sie durch
vordefinierte Interfaces zu schleusen.
Nunja, aber wenn man's genau nimmt, untergräbt man damit die Definition
des Interfaces, was man ja *eigentlich* nicht tun sollte.. manchmal muss
man halt auch mal ne Kröte schlucken.
Post by Stefan Matthias Aust
In C# kann man Regionen als Unsafe erklären und dann mit Pointer
spielen, sodass jeder C-Entwickler neidisch werden kann. Das mag für
bestimmte Fälle hilfreich sein, ist aber natürlich tödlich für
plattformübergreifende Entwicklungen.
Ack. Die Gefahrist hoch, dass man damit aus falsch verstandem Ehrgeiz
optimiert, wo man nicht muss und die Sicherheit im allgemeinen
Gefährdet.
Post by Stefan Matthias Aust
Auch kann man sich damit u.U. die
allerseits beliebten Buffer-Overrun-Exploits einhandeln. Zumindest kann
man per Security-Einstellungen festlegen, ob Programme mit
unsafe-Einschlüssen gestartet werden dürfen oder nicht.
Nunja, ob das der Weisheit letzter Schluss ist? Erinnert mich jetzt
irgendwie an nicht zertifizierte Treiber, da hat man im Prinzip auch
keine Wahl, als das Zeug zu installieren.
Post by Stefan Matthias Aust
Was der Artikel nicht erwähnt ist PInvoke, eine Funktion, um einfach
DLLs aufzurufen. Auch nicht wirklich plattformübergreifend, aber doch
bei Mono z.B. der Grund, warum es schnell sehr viele existierende
Linux-Bibliotheken angebunden wurden konnten und deutlich bequemer als
der Krampf bei Java, jedes Mal den C-Compiler hervorzuholen und soll
blöde Glue-DLLs selbst zu schreiben. Etwas wie PInvoke kann man
natürlich auch in Java realisieren und es gibt IMHO Anbieter von
vergleichbaren Lösungen für Java.
Ich hätte ja schon gerne mal ein wenig was mit Sachen wie FMOD probiert,
aber dieser Wiggle unter Java hielt mich immer davon ab.

Gruß,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Stefan Matthias Aust
2004-06-11 07:29:40 UTC
Permalink
Post by Wanja Gayk
Ich halte den Fallthrough als default für OK, wenn auch problematisch
für Anfänger.
nicht nur für Anfänger... Sprungtabellen sind ein fremdartiges Konzept
in einer Sprache, die sonst nur Blöcke benutzt. Ein switch/case sollte
sich ebenfalls der Blockstruktur verpflichtet fühlen und eine
Vereinfachung für if/else-if-Kaskaden sein. Mehr nicht. IMHO.
Post by Wanja Gayk
Finde ich ab und zu recht hilfreich, wenn's nicht zu viele Konstanen
sind.
Die bessere Lösung für Aufzählungen wäre IMHO

case 1, 2:
case 2..4:

wobei 2..4 ein Objekt vom Typ "Range" oder "Interval" oder ähnliches
ist. Den ersten Fall kann der Compiler in ein "or" aufblähen.
Post by Wanja Gayk
Mir graut aber vor den Konstrukten, die mit dem goto im switch zu
treiben sind, ich neige dazu das als potentiellen Spaghetticodemacher zu
bezeichnen.
Damit geht nicht mehr und nicht weniger als mit dem fall-through, wenn
du nur deine Cases richtig ordnest und ggf. noch ein benanntes
while(true) drumrumknüpfst, um Rückwärtssprünge zu erlauben.
Post by Wanja Gayk
Gut hingegen finde ich, dass Strings im Switch Statement erlaubt sind.
Schlecht ist, dass es wieder einmal auf nur zwei Datentypen beschränkt
ist. Warum? Jedes Objekt sollte in einem switch gehen, wenn es nur die
richtige Vergleichsmethode implementiert! Bislang habe ich nur Ruby und
einige Implementierungen von Smalltalk gesehen, die das IMHO richtig machen.
Post by Wanja Gayk
Man könnte auch in Java ein Switch mit Objekten im allgemeinen zulassen,
IMHO, zur Auswertng könnte man die Equals-Methode hernehmen.
Nein, equals geht nicht. Es muss eine besondere Methode sein, denn
sonst gehen Vergleiche mit Listen und Intervallen (wo man ein contains
als Semantik haben will) nicht.
Post by Wanja Gayk
Post by Stefan Matthias Aust
Mehr Freiheit bei der Signatur der Main-Methoden bei C# finde ich auch
nicht erstrebenswert.
Ich find's okay, warum auch nicht?
Es sollte immer nur einen Weg geben (nein, ich mag Perl nicht
sonderlich). Ich will auf einen Blick die Main-Methode erkennen können
und nicht erst überlegen, ob es nun die mit dem Rückgabetyp oder die
ohne ist. Ob es die mit Argumenten oder die ohne ist. Welche würde
wohl genommen werden, wenn man alle implementiert? Das sind Fragen, die
man sich gar nicht stellen muss, wenn die Antwort eindeutig wäre.
Post by Wanja Gayk
Nunja, ob das der Weisheit letzter Schluss ist? Erinnert mich jetzt
irgendwie an nicht zertifizierte Treiber, da hat man im Prinzip auch
keine Wahl, als das Zeug zu installieren.
Es ist IMHO die einzig praktikable Lösung - aber auch eine ganz andere
Diskussion :) Und das mit den nicht-zertifizierten Treibern kann man
dadurch lösen, dass man eben derartige Hardware nicht kauft. Es könnte
sogar reichen dass Microsoft (oder welcher Hersteller auch immer dieses
Prinzip benutzt) droht, dass sich derartige Treiber gar nicht mehr
installieren lassen. Soll(te) doch mit dem Trusted Computing Dingens
kommen...


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Wanja Gayk
2004-06-11 16:45:06 UTC
Permalink
Stefan Matthias Aust said...
Post by Stefan Matthias Aust
Post by Wanja Gayk
Man könnte auch in Java ein Switch mit Objekten im allgemeinen zulassen,
IMHO, zur Auswertng könnte man die Equals-Methode hernehmen.
Nein, equals geht nicht. Es muss eine besondere Methode sein, denn
sonst gehen Vergleiche mit Listen und Intervallen (wo man ein contains
als Semantik haben will) nicht.
Über ein Interface gelöst kämen wir im Endeffekt wieder bei einer Art
Comparator an.
Post by Stefan Matthias Aust
Post by Wanja Gayk
Post by Stefan Matthias Aust
Mehr Freiheit bei der Signatur der Main-Methoden bei C# finde ich auch
nicht erstrebenswert.
Ich find's okay, warum auch nicht?
Es sollte immer nur einen Weg geben (nein, ich mag Perl nicht
sonderlich). Ich will auf einen Blick die Main-Methode erkennen können
und nicht erst überlegen, ob es nun die mit dem Rückgabetyp oder die
ohne ist.
Da gäbe es eine einfache Lösung durch eine Einschränkung: nur eine
statische Methode darf "main" heissen, ganz egal welche Signatur sie hat
und das ist *die* main-Methode. Das liesse immernoch Freiheiten in der
Signatur, aber dennoch keine Zweifel offen.

Gruß,
-Wanja-
--
At a funeral, the Real Programmer is the one saying "Poor George. And he
almost had the sort routine working before the coronary."
[http://www.pbm.com/~lindahl/real.programmers.html]
Lesen Sie weiter auf narkive:
Loading...