Wednesday, August 2nd 2006, 11:00pm
Quoted
Original von Markus
Original von julianr
Und weils zum Thema "schöner arbeiten mit Arrays" so schön passt, auch gleich den noch hinterher: http://www.joelonsoftware.com/items/2006/08/01.html
Den merke ich mir wenn das nächste Semester losgeht und in den Analen des Forum wieder die Schreie dutzender verzweifelter ErSies wiederhallen "Warum machen wir Scheme und nicht Java".
Thursday, August 3rd 2006, 10:59am
Original von julianr
Original von Joachim
Allerdings legt die mehrfache Verwendung einer Methode den Schluß nahe, daß diese Methode von allgemeiner Bedeutung für die verwendete Datenstruktur ist. Von daher wäre es vielleicht besser, die Methode in eine neue Klasse auszulagern, die die verwendete Datenstruktur modelliert.
Das kann man analog über jede Art von lokaler Definition sagen - verschachtelte Klassen, lokale Konstanten usw.
Aber Aufgeräumtheit und minimalistische Interfaces sind ja eh was, wofür Java ganz falsch ist... Ernsthaft, muss das einer Sprache nicht peinlich sein, wenn die IDEs sich damit überbieten, welche den meisten Fließbandcode automatisch generiert? Ich musste jetzt einfach mal trollen, weil ich die Kombination aus Java und Spaß nie verstehen werde :x
Und weils zum Thema "schöner arbeiten mit Arrays" so schön passt, auch gleich den noch hinterher: http://www.joelonsoftware.com/items/2006/08/01.html
Date of registration: Feb 18th 2003
Location: Göttingen
Occupation: Linux Coder (ex Mathe SR Inf Student)
Thursday, August 3rd 2006, 12:11pm
Ich bevorzuge eine Schriftgröße bei der ich bei maximiertem Fenster 28 Zeilen im Editor auf den 15" Bildschirm kriege. Und das ist definitiv nicht genug für manche Algorithmen. Denn manchmal will man auch performanten Code schreiben und nicht nur GUI Code bei dem letztendlich der Benutzer das langsamste Element ist. Auch im Quellcode von SUNs Java Klassen finden sich Methoden die deutlich länger sind.
Original von dluebke
Was mich daran aber am meisten stören würde ist, dass es dann mehrere Elemente gäbe, die nicht mehr auf eine Bildschirmseite passen: In Java ist eine Klasse länger als dieses Limit, Methoden sollten es nicht sein.
Ich habe auch sonst nirgendswo GUI-Builder etc. gesehen die kurze Quelltexte(!) generieren.
Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Thursday, August 3rd 2006, 7:38pm
28 Zeilen finde ich schon recht viel. Gerade bei Algorithmen, die mehr Zeilen bei der Implementierung bräuchten, bieten sich ja Zerlegungen an.
Original von denial
Ich bevorzuge eine Schriftgröße bei der ich bei maximiertem Fenster 28 Zeilen im Editor auf den 15" Bildschirm kriege. Und das ist definitiv nicht genug für manche Algorithmen.
Original von dluebke
Was mich daran aber am meisten stören würde ist, dass es dann mehrere Elemente gäbe, die nicht mehr auf eine Bildschirmseite passen: In Java ist eine Klasse länger als dieses Limit, Methoden sollten es nicht sein.
Die Optimierung des Code ist sowieso eine ganz andere Baustelle. Zunächst sollte meiner Meinung nach der Code auf Verständlichkeit, Wartbarkeit, Übersichtlichkeit und natürlich Korrektheit auslegt sein. Hier halte ich die Regel "höchstens eine Bildschirmseite Code pro Methode" für sinnvoll.
Denn manchmal will man auch performanten Code schreiben und nicht nur GUI Code bei dem letztendlich der Benutzer das langsamste Element ist.
Der Code von Sun soll auch kein Vorbild sein; und ist an vielen Stellen auch alles andere als das. Beispielsweise wurde vor einiger Zeit hier an der Uni vom KBS untersucht, inwieweit im Code der Java API von Sun die Regel "program to an interface, not an implementation" berücksichtigt wurde: das Ergebnis war, daß dies längst nicht in dem Maße der Fall ist wie es möglich wäre.
Auch im Quellcode von SUNs Java Klassen finden sich Methoden die deutlich länger sind.
This post has been edited 1 times, last edit by "Joachim" (Aug 3rd 2006, 7:39pm)
Friday, August 4th 2006, 12:05am
Original von dluebke
Ich finde schon inner und nested classes recht unschön, weil man dann wirklich gute Editoren braucht. Und mit Funktionen ist das nicht anders: Um dann noch die Übersicht zu behalten, ob die in einer Funktion oder ausserhalb steht, braucht man wohl Code-Folding und visuelle Elemente.
Mal abgesehen von J2EE <= 1.4 (was in der 1.5/5.0er schon deutlich besser aussieht) gibt es in Java nicht mehr Fließbandcode als in anderen Sprachen auch.
).
Also erstmal gibt es keine Funktionen in objektorientierten Sprachen, sondern halt nur - welch Überraschung - Objekte (und Klassen). Das ist wohl sein Hauptproblem.
- Funktional macht es keinen Unterschied, ob ich eine Funktion oder ein Objekt mit definierter Methode übergebe.
- Ich kenne wenige Fälle, in denen ich eine Schleife wegabstrahieren musste.
|
Source code |
1 2 |
Person heinz = personen.find { ?|p| p.name == "Heinz" }
personen.sort_by { |p| p.schuhgröße }
|
Eigentlich dürfte sie deshalb auch nicht mehr Cook heißen sondern AlertAndCallAFunction. Und alleine daran sieht man, dass der Gute soweit wegabstrahiert hat, dass es doch sehr generisch und beliebig geworden ist.
...die dann sogar mehr als eine Methode haben dürfen, was dann sogar noch besser ist, z.B. nicht nur mit 2 Parametern arbeiten sondern über eine Liste iterieren, dabei eine Methode aufrufen (putInPot) und zum Schluß eine andere Methode aufrufen (heat)). Zusätzlich kriegt man ein Objekt, d.h. man hat einen Zustand, den eine Funktion nicht haben kann. Das hat manchmal auch Vorteile.
Aber alles in allem ist es eine runde OO-Sprache, mit der man viel machen kann und die sicherlich auch ihre Stärken hat (vom Handy bis zum Server z.B.)
Friday, August 4th 2006, 2:58pm
Original von denial
GUI sollte IMHO niemals in Quellcode umgesetzt werden. Der Code ist immer häßlich und sogar kompiliert noch riesengroß. Zu Atari ST Zeiten gab es .rsc Dateien, Apple hat(te?) seine Resource Forks, unter Windows gibt es Resourcen Segmente und mit libglade kann man GLADE XML Dateien durch drei Zeilen Code einbinden. Ein Vorteil ist, daß man die GUI übersetzen, oder sogar komplett umstellen kann, ohne auch nur eine Zeile des Codes anzufassen. Das einzige was ein GUI Builder an Code erzeugen darf, sind leere Stubs für die gewünschten Handler.
Ein Beispiel:
gtk-gnutella 0.96.1 hat in src/ui/gtk/gtk1 eine interface-glade.c Datei deren zweite Zeile "DO NOT EDIT THIS FILE - it is generated by Glade." lautet.
Diese Datei ist 946848 Byte groß und kompiliert auf 428426 Byte (allein das Textsegment).
Die dazugehörige .glade Datei ist gzip komprimiert (damit kann der XML Parser umgehen) 46290 Byte groß.
Libglade 0.17 ist kompiliert 98340 Byte groß.
Ok, libxml und libz kommen noch dazu, aber die könnten vom Programm sowieso gebraucht werden. Außerdem linken wir dynamisch.
Friday, August 4th 2006, 3:18pm
Original von julianr
Weiß nicht, ich finde Einrückung reicht, vielleicht bin ich Pascal-vorgeschädigt.
Du gehst aber anscheinend davon aus, dass man das nur verwenden würde, um riesige Algorithmen aufzuteilen. Sehe ich anders, auch in einer Funktion, die keinen Bildschirm füllt, will man vllt einfach drei Schritte, die man an wenigen verschiedenen Stellen auf irgendeine Variable anwendet, kurzerhand auslagern - einfach um Redundanz auf dem Minimum zu halten. Und vielleicht sieht die Ursprungsfunktion von kleinen Wiederholungen befreit auf einmal ja auch sehr kompakt und eindeutig aus, wenn die innere Funktion auch noch gut benannt wurde?
Mal abgesehen von J2EE <= 1.4 (was in der 1.5/5.0er schon deutlich besser aussieht) gibt es in Java nicht mehr Fließbandcode als in anderen Sprachen auch.
Bei GUIs sehe ich es so, dass man die einfach nicht als Quelltext speichern sollte. Ich dachte eher an triviale Sachen wie Getter/Setter (pfui von vornherein
Oder eben den Code, den man braucht, um den Mangel an Lambda-Ausdrücken auszugleichen - wobei einem das die IDE ja nicht einmal abnimmt, afaik.
Also erstmal gibt es keine Funktionen in objektorientierten Sprachen, sondern halt nur - welch Überraschung - Objekte (und Klassen). Das ist wohl sein Hauptproblem.
Sein (und mein) Hauptproblem ist wohl, dass Java krampfhaft einseitig objektorientiert ist - und der Horizont der Sprache da auch endet.
- Funktional macht es keinen Unterschied, ob ich eine Funktion oder ein Objekt mit definierter Methode übergebe.
- Ich kenne wenige Fälle, in denen ich eine Schleife wegabstrahieren musste.
Es macht auch keinen Unterschied, ob man nun Objekte verwendet, oder structs und viele globale Funktionen mit einem this-Zeiger.
Lambdas in C# sind auch nur platter syntaktischer Zucker, so wie Objekte in vielen Sprachen. Letztendlich kann man alles nachbauen. Aber wenn eine Sprache einen einfach schreiben lässt, was man denkt, dann hat das nunmal nur Vorteile. Hallo Ruby:
Source code
Person heinz = personen.find { ?|p| p.name == "Heinz" } personen.sort_by { |p| p.schuhgröße }
Für das erste würde man in vielen Sprachen eine for-Schleife nehmen - wie für fast alles, weswegen man erstmal genau hingucken muss, was eigentlich passiert. Für das zweite eine Funktion, der man irgendeine Art von Functor übergibt.
Niemand zwingt einen dazu, die zu Grunde liegenden Schleifen (oder was auch immer) wegzuabstrahieren, aber an Les- und Wartbarkeit macht man da imho einen ganz schönen Gewinn.
Eigentlich dürfte sie deshalb auch nicht mehr Cook heißen sondern AlertAndCallAFunction. Und alleine daran sieht man, dass der Gute soweit wegabstrahiert hat, dass es doch sehr generisch und beliebig geworden ist.
Schon, aber andersrum finde ich es oft ziemlich einschränkend, dass man sich als Autor einer Klasse in Java schon im Voraus Gedanken machen muss, was man damit vielleicht mal alles machen will (konkret, welche Interfaces man implementiert). In Fragen der Typsicherheit fehlt imho vielen (allen?) Sprachen der Mittelweg.
...die dann sogar mehr als eine Methode haben dürfen, was dann sogar noch besser ist, z.B. nicht nur mit 2 Parametern arbeiten sondern über eine Liste iterieren, dabei eine Methode aufrufen (putInPot) und zum Schluß eine andere Methode aufrufen (heat)). Zusätzlich kriegt man ein Objekt, d.h. man hat einen Zustand, den eine Funktion nicht haben kann. Das hat manchmal auch Vorteile.
Ersteres würde auch mit zwei Lambda-Ausdrücken gehen. Zweiteres stimmt, aber ist halt nunmal nicht immer gegeben. Es hat ja niemand hier etwas gegen Objekte, aber sie sind nicht das Allheilmittel, als das sie in Java angepriesen werden.
Aber alles in allem ist es eine runde OO-Sprache, mit der man viel machen kann und die sicherlich auch ihre Stärken hat (vom Handy bis zum Server z.B.)
Java ist einfach runtergezähmt auf den kleinsten allgemein verstandenen Nenner, und selbst da steckt noch der Wurm drin (primitive Datentypen, ineffiziente Generics, C-switch), was der Hype aber gut ausgeglichen hat. Nur weil etwas verbreitet ist, ist es noch lange nicht für jeden speziellen Fall die beste Lösung... eigentlich fallen mir viel mehr Beispiele ein, wo das Gegenteil der Fall ist
Date of registration: Feb 18th 2003
Location: Göttingen
Occupation: Linux Coder (ex Mathe SR Inf Student)
Friday, August 4th 2006, 4:19pm
Manchmal ist Data Hiding auch absolut überflüssig. Wenn ich eine Variable X habe und ich bin mir absolut sicher, daß sie niemals etwas anderes als ein int sein wird (weil etwas anderes keinen Sinn machen würde) und ich will sie von außen les- und setzbar machen, dann sollte es legitim sein sie als public zu deklarieren, statt Getter und Setter zu schreiben.
Original von dluebke
Original von julianr
Bei GUIs sehe ich es so, dass man die einfach nicht als Quelltext speichern sollte. Ich dachte eher an triviale Sachen wie Getter/Setter (pfui von vornherein
Was ist daran pfui? Gerade diese sind wichtig für das Data Hiding...
Friday, August 4th 2006, 5:13pm
Was ist daran pfui? Gerade diese sind wichtig für das Data Hiding...
In dem Artikel ging es halt um Schwächen, die in meinen Augen keine sind, weil sie leicht in OO nachzubilden sind.
Mit dem Nachteil, dass die Sprache doch recht viele Syntaxkonstrukte braucht (?, ||).
Der Vorteil, der hier im Beispiel am meisten zum Tragen kommt, ist halt das sehr späte Binden, d.h. man darf p.name schreiben, ohne halt direkt schon zu wissen, was für ein Objekt da kommen mag.
|
|
Source code |
1 |
List<Person> erwachsene = personen.FindAll(delegate(Person p) { return p.alter >= 18; });
|
|
|
Source code |
1 2 3 4 |
// Mit Typechecks List<Person> erwachsene = personen.FindAll((Person p) => p.alter >= 18); // Mit Typinferenz var erwachsene = personen.FindAll(p => p.alter >= 18); |
Warum muss ich mir immer vorher überlegen, was die Klasse können soll. Ein Interface zuzufügen ist nun das leichteste der Welt...
Allheilmittel ist halt gar nichts. Aber man muss sich irgendwann für ein Konzept entscheiden und das durchziehen. [...] Man tut sich leichter, wenn alles ein Objekt ist, als wenn da alles rumfliegt.
Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Friday, August 4th 2006, 6:15pm
Damit nimmt sich jedoch (zumindest in Java) die Möglichkeit, auf Änderungen dieser Variable (oder auf Zugriffe allgemein) zu reagieren. Sollte diese Funktionalität irgendwann einmal benötigt werden, müssen Getter und Setter eingeführt werden, was natürlich auch Änderungen aller zugreifenden Klassen nach sieht zieht.
Original von denial
Manchmal ist Data Hiding auch absolut überflüssig. Wenn ich eine Variable X habe und ich bin mir absolut sicher, daß sie niemals etwas anderes als ein int sein wird (weil etwas anderes keinen Sinn machen würde) und ich will sie von außen les- und setzbar machen, dann sollte es legitim sein sie als public zu deklarieren, statt Getter und Setter zu schreiben.
Monday, August 7th 2006, 1:12pm
Original von julianr
Was ist daran pfui? Gerade diese sind wichtig für das Data Hiding...
Naja, sie sind etwas besser als public-Variablen.
Sicher gibt es öfter mal Funktionen, die mit get und set anfangen, aber imho sollte man sich immer gut überlegen, ob man die anlegt (und deshalb finde ich automatisch generierte Getter/Setter-Paare eher kontraproduktiv). Wenn man von außen etwas mit einem Objekt tut, was übermäßig viel get/set benötigt, sollte man sich fragen, ob das nicht eher ins Objekt selbst gehört.
In dem Artikel ging es halt um Schwächen, die in meinen Augen keine sind, weil sie leicht in OO nachzubilden sind.
Man kann Schrauben auch verhältnismäßig leicht mit einem Hammer in die Wand schlagen. Aber kein normaler Mensch würde sich deshalb auf nur ein Werkzeug festnageln lassen (uh, SCNR). Genau den Weg geht Java damit, sich stur auf OO einzuschießen, und verkauft das auch noch als "Reinheit". Aber dazu unten mehr.
Mit dem Nachteil, dass die Sprache doch recht viele Syntaxkonstrukte braucht (?, ||).
Der Vorteil, der hier im Beispiel am meisten zum Tragen kommt, ist halt das sehr späte Binden, d.h. man darf p.name schreiben, ohne halt direkt schon zu wissen, was für ein Objekt da kommen mag.
Das "?" war nur ein Typo, eigentlich braucht man in beiden Fällen die gleiche {|| }-Syntax.
Ich habe auch nichts gegen typisierte Sprachen, kommt immer darauf an, was man machen will. Aber die unterscheiden sich hierbei nicht viel von den untypisierten. Natürlich ist die Syntax in einer einfach gebauten, stark typisierten Sprache (C#2.0) erstmal unhandlicher:
Source code
List<Person> erwachsene = personen.FindAll(delegate(Person p) { return p.alter >= 18; });
Selbst das ist ja wohl noch schicker als alles, was Java zu bieten hat.
|
|
Source code |
1 2 3 4 5 6 |
List<Person> erwachsener = personen.find(new Matcher() {
public void match(Person p)
{
return p.getAlter() >= 18;
}
});
|
|
|
Source code |
1 |
List<Person> erwachsener = personen.find(PersonenList.ADULT_MATCHER); |
Und außerdem gibt es ja immer noch das schöne Konzept der Typinferenz, mit der das dann auf Folgendes schrumpft (C#3.0):
Source code
Warum muss ich mir immer vorher überlegen, was die Klasse können soll. Ein Interface zuzufügen ist nun das leichteste der Welt...
Solange man jeden im Projekt verwendeten Quellcode frei verändern möchte und darf. In C++ wären sicher nicht so viele geniale template-Ideen entstanden, wenn die Entwickler der Standardbibliothek sich vorher alle nur erdenklichen Konzepte hätten ausdenken und als Interfaces formulieren müssen.
Allheilmittel ist halt gar nichts. Aber man muss sich irgendwann für ein Konzept entscheiden und das durchziehen. [...] Man tut sich leichter, wenn alles ein Objekt ist, als wenn da alles rumfliegt.
Und um darauf zurückzukommen, ich glaube genau hier werden wir uns nicht mehr einig. Ich finde es nicht nur unnötig, sich auf eine einzige Denkweise zu festzulegen, sondern auch sehr einschränkend. Natürlich kann man sich in zu vielen Ansätzen verrennen, aber in einem einzigen genauso. Und in der Zeit, die man braucht, um jedes Problem in die passende Form zu pressen, hätte man auch zwei Sprachmittel mehr lernen können.
Friday, August 25th 2006, 8:07pm
Hmm, also das habe ich überhaupt nicht verstanden... Die C++-Leute haben sich die ganzen Dinger überlegt oder übernommen.
This post has been edited 1 times, last edit by "julianr" (Aug 25th 2006, 8:08pm)
