Getter & Setter
Peter Horlock
mich beschäftigt seit längerer Zeit folgende Fragen -
es ist ein fundamentales Konzept für Formobjekte, also
Objekte, die nur Daten enthalten, also Beans, public getter und setter
Methode zu implementieren, und die Attribute selbst als private zu
deklarieren.
Was aber ist, wenn man eine Klasse bzw. ein Objekt immutable machen
möchte, und daher keine Setter Methoden zur Verfügung stellen möchte -
macht es dennoch Sinn, private setter Methoden zu nutzen, oder wäre es
dann nicht sinniger, aus der Klasse heraus direkt auf die Attribute zu
zugreifen - oder, um die Frage noch genereller auszudrücken -
sollte man innerhalb einer Klasse die Getter und Setter Methoden nutzen,
oder lieber direkt auf die Attribute zugreifen?
Ein Grund für generellen Zugriff über Getter und Setter, unabhängig ob
sie private oder public sind wäre wohl Threadsicherheit - Methoden kann
man synchronisieren. Aber was, wenn man das z.B. nicht brauchen wird?
Danke,
Peter
Christoph Herrmann
> Ein Grund für generellen Zugriff über Getter und Setter, unabhängig ob
> sie private oder public sind wäre wohl Threadsicherheit - Methoden kann
> man synchronisieren. Aber was, wenn man das z.B. nicht brauchen wird?
ich nutze generell, egal ob innerhalb oder von außen, immer Getter und
Setter, weil:
- ich sehr schnell den Zugriff regeln kann (ich muss, wenn es benötigt
wird nicht nachträglich Getter und Setter implementieren)
- Der Zugriff auf Attribute ist bei JEDER Klasse gleich über die Getter
und Setter, ich muss keine Unterscheidungen machen
- ich kann nachträglich noch Prüfungen oder ähnliches hinzufügen, ohne
an anderen Stellen etwas ändern zu müssen
Ich glaub der größte Grund ist der einheitliche Zugriff, das beugt etwas
vor aus versehen direkt ein Attribut zu setzen, obwohl ein Setter da
gewesen wäre (der nötig wäre).
--
Mit freundlichen Grüßen,
Christoph Herrmann
Daniel Urban
> ich nutze generell, egal ob innerhalb oder von außen, immer Getter und
> Setter, weil:
>
> - ich sehr schnell den Zugriff regeln kann (ich muss, wenn es benötigt
> wird nicht nachträglich Getter und Setter implementieren)
Implementieren? Mmm... bei den meisten IDEs sind das zwei Clicks. Außerdem
scheinst Du mir dann ein wenig das Konzept Information-Hiding zu verletzen.
Grundsätzlich ist erst einmal alles private und erst, wenn es nötig ist,
mache ich die Sachen public. Das nachträgliche Ändern ist daher kein
Nachteil, sondern eher Konzept.
Das nachträgliche Ändern auf private dagegen wird Dir schwer fallen, es sei
denn, Du verwendest auch für private Attribute entsprechend private Getter
und Setter. Das habe ich bisher noch nicht gesehen, aber man lernt doch nie
aus.
> - Der Zugriff auf Attribute ist bei JEDER Klasse gleich über die Getter
> und Setter, ich muss keine Unterscheidungen machen
Naja, hängt davon ab, ob Du in den Getter und Setter Logik implementierst.
Wenn Du das machst, wirst Du vermutlich auch Fälle haben, wo das an
verschiedenen Stellen unterschiedlich ist. Wobei ich hier sowieso zwei
Attribute halten würde. Ein privates ohne Logik und ein öffentliches mit
Logik. Beide hätten natürlich unterschiedliche Namen, wobei das öffentliche
auf das private zufreifen würde.
Gruß,
Daniel
Daniel Urban
> mich beschäftigt seit längerer Zeit folgende Fragen -
>
> es ist ein fundamentales Konzept für Formobjekte, also
> Objekte, die nur Daten enthalten, also Beans, public getter und setter
> Methode zu implementieren, und die Attribute selbst als private zu
> deklarieren.
Wobei mal hinterfragt werden sollte, warum dieses Konzept eingeführt wurde
und nicht direkt auf die Attribute zugegriffen wird. Der einzige für mich
sinnvolle Grund, liegt in der Separierung von lesendem und schreibendem
Zugriff. Allerdings finde ich die Lösung in C# besser.
> Was aber ist, wenn man eine Klasse bzw. ein Objekt immutable machen
> möchte, und daher keine Setter Methoden zur Verfügung stellen möchte -
> macht es dennoch Sinn, private setter Methoden zu nutzen, oder wäre es
> dann nicht sinniger, aus der Klasse heraus direkt auf die Attribute zu
> zugreifen - oder, um die Frage noch genereller auszudrücken -
> sollte man innerhalb einer Klasse die Getter und Setter Methoden nutzen,
> oder lieber direkt auf die Attribute zugreifen?
Also ich habe bisher noch keine privaten Getter oder Setter gesehen. Ich bin
der Meinung, dass man in der Klasse möglichst auch auf die internen Methoden
und Attribute zugreifen sollte. Lediglich um Reuse zu ermöglichen, würde ich
auch auf die öffentlichen Methoden und Attribute zugreifen. Aber das ist
kein Dogma.
Gruß,
Daniel
Malte Schirmacher
> "Peter Horlock"
>> mich beschäftigt seit längerer Zeit folgende Fragen -
>>
>> es ist ein fundamentales Konzept für Formobjekte, also
>> Objekte, die nur Daten enthalten, also Beans, public getter und setter
>> Methode zu implementieren, und die Attribute selbst als private zu
>> deklarieren.
>
> Wobei mal hinterfragt werden sollte, warum dieses Konzept eingeführt
> wurde und nicht direkt auf die Attribute zugegriffen wird. Der einzige
> für mich sinnvolle Grund, liegt in der Separierung von lesendem und
> schreibendem Zugriff. Allerdings finde ich die Lösung in C# besser.
Wenn du deine API so modellierst, dass Zugriff auf die Attribute direkt
ohne Umweg über Getter und Setter ermöglichst kannst du das danach nie
wieder ändern, weil sonst die Benutzer deiner API kaputte Programme haben.
Daniel Urban
> Daniel Urban schrieb:
>> Wobei mal hinterfragt werden sollte, warum dieses Konzept eingeführt
>> wurde und nicht direkt auf die Attribute zugegriffen wird. Der einzige
>> für mich sinnvolle Grund, liegt in der Separierung von lesendem und
>> schreibendem Zugriff. Allerdings finde ich die Lösung in C# besser.
>
> Wenn du deine API so modellierst, dass Zugriff auf die Attribute direkt
> ohne Umweg über Getter und Setter ermöglichst kannst du das danach nie
> wieder ändern, weil sonst die Benutzer deiner API kaputte Programme haben.
Wo ist jetzt der Unterschied zur Methode? Auch eine Methode kann ich nicht
mehr ändern, ohne zu riskieren, dass Programme, die diese Methode verwenden,
kaputt gehen. Zumal zu fragen wäre, was man an einem Attribute schon ändern
kann? Ich kann es entfernen, aber sonst...?
Gruß,
Daniel
Malte Schirmacher
>
> Wo ist jetzt der Unterschied zur Methode? Auch eine Methode kann ich
> nicht mehr ändern, ohne zu riskieren, dass Programme, die diese Methode
> verwenden, kaputt gehen.
Ich kann beliebige Aktionen in der Methode durchführen solange das
Ergebnis das ist was der Client erwartet.
Beispielsweise Logging, oder defensive Kopien anfertigen, etc.
Das alles geht beim direkten Zugriff auf das Attribut nicht.
> Zumal zu fragen wäre, was man an einem
> Attribute schon ändern kann? Ich kann es entfernen, aber sonst...?
Du kannst es Ändern was nicht gewünscht sein kann.
Gib mir doch mal Rootzugriff auf deinen Computer. Was kann ich schon
groß Ändern? Alle Daten löschen, aber sonst...?
Daniel Urban
> Daniel Urban schrieb:
>>
>> Wo ist jetzt der Unterschied zur Methode? Auch eine Methode kann ich
>> nicht mehr ändern, ohne zu riskieren, dass Programme, die diese Methode
>> verwenden, kaputt gehen.
>
> Ich kann beliebige Aktionen in der Methode durchführen solange das
> Ergebnis das ist was der Client erwartet.
> Beispielsweise Logging, oder defensive Kopien anfertigen, etc.
>
> Das alles geht beim direkten Zugriff auf das Attribut nicht.
Muss es doch auch nicht. Wenn Du dies speziell benötigst, kannst Du eine
Methode anbieten. Wenn die Methode unterschiedliche Werte zurückliefert oder
setzt, als das Attribute, dann sind das meiner Meinung nach sowieso zwei
unterschiedliche Attribute.
Die meisten Setter und Getter reichen den Wert meiner Erfahrung nach nur
durch.
>> Zumal zu fragen wäre, was man an einem
>> Attribute schon ändern kann? Ich kann es entfernen, aber sonst...?
>
> Du kannst es Ändern was nicht gewünscht sein kann.
Dann machst Du es private. Wo ist das Problem?
> Gib mir doch mal Rootzugriff auf deinen Computer. Was kann ich schon
> groß Ändern? Alle Daten löschen, aber sonst...?
Unfug! Ich habe nicht gesagt, dass alle Attribute öffentlich sein sollen,
sondern dass alle öffentlichen Attribute auch direkt zugegriffen werden
können. Und selbst das habe ich so pauschal auch nicht gesagt, sondern
hinterfragt, warum man das nicht machen soll.
Gruß,
Daniel
Malte Schirmacher
> "Malte Schirmacher"
>> Daniel Urban schrieb:
> durch.
Können sie. Müssen sie aber nicht.
> Dann machst Du es private. Wo ist das Problem?
Dass du es nichtmehr private machen kannst, wenn du die API einmal mit
öffentlichen Attributen veröffentlicht hast.
>
>> Gib mir doch mal Rootzugriff auf deinen Computer. Was kann ich schon
>> groß Ändern? Alle Daten löschen, aber sonst...?
>
> Unfug! Ich habe nicht gesagt, dass alle Attribute öffentlich sein
> sollen, sondern dass alle öffentlichen Attribute auch direkt zugegriffen
> werden können.
Wenn du das nochmal als kompletten Satz wiederholst, kann ich dazu
vielleicht auch Stellung nehmen...
> Und selbst das habe ich so pauschal auch nicht gesagt,
> sondern hinterfragt, warum man das nicht machen soll.
Kam aber genau so rüber.
Daniel Urban
> Daniel Urban schrieb:
>> Dann machst Du es private. Wo ist das Problem?
>
> Dass du es nichtmehr private machen kannst, wenn du die API einmal mit
> öffentlichen Attributen veröffentlicht hast.
Mit Methoden kannst Du das aber auch nicht. Zumindest wird dann das Programm
nicht mehr funktionieren.
>>> Gib mir doch mal Rootzugriff auf deinen Computer. Was kann ich schon
>>> groß Ändern? Alle Daten löschen, aber sonst...?
>>
>> Unfug! Ich habe nicht gesagt, dass alle Attribute öffentlich sein
>> sollen, sondern dass alle öffentlichen Attribute auch direkt zugegriffen
>> werden können.
>
> Wenn du das nochmal als kompletten Satz wiederholst, kann ich dazu
> vielleicht auch Stellung nehmen...
Ich habe nicht gesagt, dass alle Attribute öffentlich sein sollen, sondern
dass man auf alle öffentlichen Attribute auch direkt zugegriffen kann.
>> Und selbst das habe ich so pauschal auch nicht gesagt,
>> sondern hinterfragt, warum man das nicht machen soll.
>
> Kam aber genau so rüber.
Dann hast Du offenbar reflexartig reagiert, da ich mit der Frage auch gleich
eine Begründung geliefert habe.
Um nicht eine Pseudodiskussion zu führen: Ich verwende für öffentliche
Attribute Getter und Setter. Ich denke aber, dass man schon wissen sollte,
warum man das macht. Das hilft dem OP dann vielleicht auch bei seiner Frage.
Meiner Meinung nach gibt es mindestens folgende Gründe Getter und Setter zu
verwenden:
1. Frameworks benötigen die Getter und Setter
2. Readonly und Writeonly Attribute
3. Attribute, die im Wertebereich eingegrenzt werden müssen
(IllegalArgumentException)
4. vereinheitlicher Zugriff auf öffentliche Attribute
Kein Argument IMHO - und daher führe ich die Diskussion überhaupt mit Dir -
ist das Thema Methoden sind besser inhaltlich zu ändern. Denn an einem
Attribute muss/kann ich nicht viel ändern. Wenn eine Methode einen anderen
Wert zurückgibt, als das Attribute hält, dann sind das für mich zwei
verschiedene Attribute, z.B. ein gespeichertes und ein berechnetes.
Die Änderung der Sichtbarkeit ist auch IMHO kein Argument, da dies genauso
Problem bei Methoden macht wie bei Attributen.
Wenn es um Logik geht, die nicht den eigentlichen Wert ändert, dann kann das
durchaus Sinn machen, aber deswegen würde ich noch nicht grundsätzlich und
überall so verfahren. Außerdem müsste man mir dann auch noch ein paar
bessere Beispiele, außer dem Logging bringen. Das Logging in Settern und
Getter ist AFAIK mir bisher auch noch nicht begegnet.
Gruß,
Daniel
Malte Schirmacher
> "Malte Schirmacher"
>> Daniel Urban schrieb:
>>> "Malte Schirmacher"
>>> Dann machst Du es private. Wo ist das Problem?
>>
>> Dass du es nichtmehr private machen kannst, wenn du die API einmal mit
>> öffentlichen Attributen veröffentlicht hast.
>
> Mit Methoden kannst Du das aber auch nicht. Zumindest wird dann das
> Programm nicht mehr funktionieren.
Wieso sollte ein Programm nichtmehr funktionieren, wenn ich alle
Zugriffe auf die Methode mitlogge?
>
>>>> Gib mir doch mal Rootzugriff auf deinen Computer. Was kann ich schon
>>>> groß Ändern? Alle Daten löschen, aber sonst...?
>>>
>>> Unfug! Ich habe nicht gesagt, dass alle Attribute öffentlich sein
>>> sollen, sondern dass alle öffentlichen Attribute auch direkt zugegriffen
>>> werden können.
>>
>> Wenn du das nochmal als kompletten Satz wiederholst, kann ich dazu
>> vielleicht auch Stellung nehmen...
>
> Ich habe nicht gesagt, dass alle Attribute öffentlich sein sollen,
> sondern dass man auf alle öffentlichen Attribute auch direkt zugegriffen
> kann.
Man gibt aber nunmal flexibilität auf wenn man direkten Zugriff erlaubt.
>
>>> Und selbst das habe ich so pauschal auch nicht gesagt,
>>> sondern hinterfragt, warum man das nicht machen soll.
>>
>> Kam aber genau so rüber.
>
> Dann hast Du offenbar reflexartig reagiert, da ich mit der Frage auch
> gleich eine Begründung geliefert habe.
>
> Um nicht eine Pseudodiskussion zu führen: Ich verwende für öffentliche
> Attribute Getter und Setter. Ich denke aber, dass man schon wissen
> sollte, warum man das macht. Das hilft dem OP dann vielleicht auch bei
> seiner Frage.
>
> Meiner Meinung nach gibt es mindestens folgende Gründe Getter und Setter
> zu verwenden:
>
> 1. Frameworks benötigen die Getter und Setter
Wieso?
> 2. Readonly und Writeonly Attribute
Nicht nur, wie du aber (imho grundlos) ignorierst
> 4. vereinheitlicher Zugriff auf öffentliche Attribute
Wieso sollte man denn irgendwas vereinheitlichen? Ist doch völlig unnötig!
>
> Kein Argument IMHO - und daher führe ich die Diskussion überhaupt mit
> Dir - ist das Thema Methoden sind besser inhaltlich zu ändern. Denn an
> einem Attribute muss/kann ich nicht viel ändern. Wenn eine Methode einen
> anderen Wert zurückgibt, als das Attribute hält, dann sind das für mich
> zwei verschiedene Attribute, z.B. ein gespeichertes und ein berechnetes.
Wenn das Attribut aber nunmal eine Collection ist, die verändert werden
kann und du eine Referenz auf die Collection zurückgibst kann jeder
Client diese ändern.
Wenn du also keine Methode dazwischen schiebst kannst du nicht
verhindern, dass der Client der API die Collection auch tatsächlich ändert.
> Wenn es um Logik geht, die nicht den eigentlichen Wert ändert, dann kann
> das durchaus Sinn machen, aber deswegen würde ich noch nicht
> grundsätzlich und überall so verfahren.
Wenn ich eine unveränderliche *Sicht* auf die Collection zurückgebe,
oder aber die Collection vor der Rückgabe *kopiere* ist das mit
Sicherheit kein anderes Attribut.
> Außerdem müsste man mir dann
> auch noch ein paar bessere Beispiele, außer dem Logging bringen. Das
> Logging in Settern und Getter ist AFAIK mir bisher auch noch nicht
> begegnet.
Ist auch nur ein furchtbar marginales Beispiel das dich davon überzeugen
sollte, dass der Wert des Attributs nicht geändert wird, dennoch aber
der Getter absolut unabdingbar für die Funktionalität ist.
Frank Strehlke
> "Christoph Herrmann"
>> (ich muss, wenn es benötigt
>> wird nicht nachträglich Getter und Setter implementieren)
>
> Implementieren? Mmm... bei den meisten IDEs sind das zwei Clicks.
Daher wird von vielen Anfängern auch gern die Kapselung aufgehoben indem
sie für alle Member öffentliche Getter und vor allem Setter
bereitstellen -- es ist ja so schön einfach. Das ist aber im Grunde
genauso schlecht wie alle Member public zu deklarieren.
Frank Strehlke
> Die meisten Setter und Getter reichen den Wert meiner Erfahrung nach nur
> durch.
Nur im einfachsten Fall. Aber Setter können auch den zu setzenden
Parameter prüfen und ggf. zurückweisen, mutable Objekte kopieren anstatt
sie direkt zu setzen, Typkonvertierungen oder Aggregierungen (z.B.
getFullName()) durchführen.
Christoph Herrmann
> Daher wird von vielen Anfängern auch gern die Kapselung aufgehoben indem
> sie für alle Member öffentliche Getter und vor allem Setter
> bereitstellen -- es ist ja so schön einfach. Das ist aber im Grunde
> genauso schlecht wie alle Member public zu deklarieren.
Kapselung heißt nicht private... Deswegen ist es auf jeden Fall nicht
genauso schlecht.
Christoph Herrmann
> "Christoph Herrmann"
>> wird nicht nachträglich Getter und Setter implementieren)
>
> Implementieren? Mmm... bei den meisten IDEs sind das zwei Clicks.
Wenn ich von direktem Zugriff aber auf Zugriff über die Methoden ändere
ist da noch etwas mehr als nur die Methoden schreiben. Nämlich alle
Stellen wo der Zugriff gemacht hat entsprechend anpassen.
> Außerdem scheinst Du mir dann ein wenig das Konzept Information-Hiding
> zu verletzen. Grundsätzlich ist erst einmal alles private und erst, wenn
> es nötig ist, mache ich die Sachen public. Das nachträgliche Ändern ist
> daher kein Nachteil, sondern eher Konzept.
Wieso verletzen? Bei mir sind Getter und Setter auch nur public, wenn es
nötig ist. Das sollte ja klar sein.
> Das nachträgliche Ändern auf private dagegen wird Dir schwer fallen, es
> sei denn, Du verwendest auch für private Attribute entsprechend private
> Getter und Setter. Das habe ich bisher noch nicht gesehen, aber man
> lernt doch nie aus.
Bei mir sind alle Attribute private und haben Setter und Getter. Ist der
Zugriff von außen gewünscht, sind diese public, ansonsten habe ich
private Setter und Getter für den Zugriff innerhalb der Klasse. Bei mir
ganz normal.
> Naja, hängt davon ab, ob Du in den Getter und Setter Logik
> implementierst. Wenn Du das machst, wirst Du vermutlich auch Fälle
> haben, wo das an verschiedenen Stellen unterschiedlich ist. Wobei ich
Was ist unterschiedlich? Die Logik ja, aber nicht der Zugriff, das ist
ja der Vorteil. Dem Benutzer ist es egal ob da Logik dahinter steckt
oder nicht, der Zugriff erfolgt immer über die Methoden.
> hier sowieso zwei Attribute halten würde. Ein privates ohne Logik und
> ein öffentliches mit Logik. Beide hätten natürlich unterschiedliche
> Namen, wobei das öffentliche auf das private zufreifen würde.
Wieso für jedes Attribute zwei Attribute machen? Das verstehe ich nicht,
wo da der Sinn dahinter sein soll... Beispiel?
Christoph Herrmann
> Wo ist jetzt der Unterschied zur Methode? Auch eine Methode kann ich
> nicht mehr ändern, ohne zu riskieren, dass Programme, die diese Methode
> verwenden, kaputt gehen. Zumal zu fragen wäre, was man an einem
> Attribute schon ändern kann? Ich kann es entfernen, aber sonst...?
Beispiel direkt:
Ich mache eine Banksoftware und biete das Attribut "saldo" für die
Klasse Konto an als double (Fliesskommazahl). An hunderten von Stellen
in der Software setze ich den Saldo nun per Fliesskommazahl direkt auf
die gewünschten Werte. Irgendwann merke ich, hey beim rechnen bekomme
ich Rundungsfehler ich muss ja integer nehmen und die Centbeträge (ganze
Zahlen). Viel spaß beim ändern... :)
Beispiel Methode:
ich hab am Anfang eine Methode gemacht:
public void setSaldo(double saldo)
{
this.saldo = saldo;
}
Später wenn ich umstellen will lasse ich die Schnittstelle der oberen
Methode einfach und füge eine Neue hinzu:
public void setSaldo(double saldo)
{
this.saldo = (int) (saldo * 100);
}
public void setSaldo(int saldo)
{
this.saldo = saldo;
}
Ich hoffe das Beispiel verdeutlicht den Vorteil. Das nennt man
Verbergung der inneren Datenstruktur und ist einer der Aspekte bei
Kapselung.
Frank Strehlke
> Kapselung heißt nicht private... Deswegen ist es auf jeden Fall nicht
> genauso schlecht.
>
Irgendwie werd ich aus deinem Halbsatz nicht schlau. Der Unterschied
zwischen den (unsinnigen) Klassen
class KeineKapsel {
public int status = 0;
public void start(){
this.status = 1;
try {
walk();
} catch (Exception e){
status = -1;
}
}
public boolean isRunning(){
return status == 1;
}
public boolean hasError(){
return status == -1;
}
}
und
class KeineKapsel {
private int status = 0;
public void start(){
this.status = 1;
try {
walk();
} catch (Exception e){
status = -1;
}
}
public boolean isRunning(){
return status == 1;
}
public boolean hasError(){
return status == -1;
}
public void setStatus(int status){
this.status = status;
}
public int getStatus(){
return this.status;
}
}
ist (fast) nur syntaktischer Natur. Ich habe eine Schnittstelle, die es
dem Aufrufer erlaubt eine start-Methode aufzurufen und über 2
boolean-Methoden den Status abzufragen -- mehr muss (und soll) der
Aufrufer nicht wissen. Wieso sollte ich nun die innere Struktur
veröffentlichen indem ich einen öffentlichen Getter für das int-Feld
bereitstelle und (noch schlimmer) einen öffentlichen Setter, der die
ganze "Logik" torpediert.
Allein durch den Umstand das man alle Member private macht und
stattdessen blind öffentliche getter/setter anbietet hat man (fast)
nichts verborgen -- wenn du das als deine öffentliche Schnittstelle
ansiehst solltest du darüber nochmal nachdenken.
Objekte verbergen ihre innere Struktur, es gibt eine definierte
Schnittstelle und nur diese ist nach aussen bekannt. Blind die gesamte
innere Datenstruktur (über getter/setter) zu veröffentlichen -- weil
Eclipse die so lustig generieren kann -- ist unnötig und entspricht dann
eher einer "Black-Box aus Einkaufsnetzen" als einer kapselung.
Das man den Zustand eines Objektes mindestens abfragen und oft auch
manipulieren können muss versteht sich von selbst -- dazu gibt es getter
und setter, die ggf. auch auf einzelne Member des Objekts verweisen.
Dieser scheinbar kleine Unterschied ist aber der wesentliche Aspekt der
Kapselung.
Das erinnert mich an ein Domain-Model in dem ich verwirrt feststellte,
dass man nciht nur inkonsistente Objekte über einen Default-Konstruktor
erzeugen konnte, sondern noch viel schlimmer ein öffentlicher Setter für
die ID (wie für alle anderen Attribute) angeboten wurde. Die genauso
verblüffende wie falsche Erklärung/Ausrede war, dass man das "wg.
Hibernate" so machen müsse.
Mag sein das viele Frameworks heute einen Defaultkonstruktor verlangen,
mag auch sein, dass diese Frameworks die Felder nicht direkt setzen,
sondern immer über die Getter/Setter gehen -- das heisst aber nicht das
diese Setter/Getter auch öffentlich sein müssen. Das heisst nur das man
die Felder nicht als final deklarieren kann.
Christoph Herrmann
> Irgendwie werd ich aus deinem Halbsatz nicht schlau. Der Unterschied
> zwischen den (unsinnigen) Klassen
> ist (fast) nur syntaktischer Natur. Ich habe eine Schnittstelle, die es
> dem Aufrufer erlaubt eine start-Methode aufzurufen und über 2
> boolean-Methoden den Status abzufragen -- mehr muss (und soll) der
Beide Klassen sind schwachsinnig, weil sie freien Zugriff auf den Status
erlauben und den Status ungewollt verändern können, obwohl der momentane
wirkliche Zustand vom Status anders wäre.
> Aufrufer nicht wissen. Wieso sollte ich nun die innere Struktur
> veröffentlichen indem ich einen öffentlichen Getter für das int-Feld
> bereitstelle und (noch schlimmer) einen öffentlichen Setter, der die
> ganze "Logik" torpediert.
>
> Allein durch den Umstand das man alle Member private macht und
> stattdessen blind öffentliche getter/setter anbietet hat man (fast)
> nichts verborgen -- wenn du das als deine öffentliche Schnittstelle
> ansiehst solltest du darüber nochmal nachdenken.
Wer sagt was von blind öffentliche Getter/Setter anbieten? Wenn auf ein
Attribut nicht zugegriffen werden soll, macht man die Getter/Setter
private, was ich in deinem Fall machen würde, wobei deine 3 Methoden
("start()", "isRunning()" und "hasError()") dann über die Getter/Setter
gehen sollten, sonst würden diese keinerlei Sinn ergeben.
PS: Hab in einem anderen Beitrag nen Beispiel gebracht mit einem Saldo
eines Kontos, vielleicht hilft das ein wenig weiter.
Frank Strehlke
Frank Strehlke schrieb:
> [...] für alle Member öffentliche Getter und vor allem Setter
> bereitstellen [...]. Das ist aber im Grunde
> genauso schlecht wie alle Member public zu deklarieren.
Christoph Herrmann schrieb:
> Kapselung heißt nicht private... Deswegen ist es auf jeden Fall nicht
> genauso schlecht.
Frank Strehlke schrieb:
> [Beispiel das es genauso schlecht ist]
Christoph Herrmann schrieb:
> Beide Klassen sind schwachsinnig, weil sie freien Zugriff auf den Status
> erlauben und den Status ungewollt verändern können, obwohl der momentane
> wirkliche Zustand vom Status anders wäre.
Genau das habe ich die ganze Zeit (und auch im letzten Posting) gesagt.
Obwohl du offensichtlich meiner Meinung bist, widersprichst du mir die
ganze Zeit. Liest du nicht richtig, widersprichst du gern oder ist das
so eine Outsider-Kunst ;o)
> Wer sagt was von blind öffentliche Getter/Setter anbieten?
Es ging darum das aktuelle IDEs Setter/Getter generieren können und
Anfänger daher gern und ausgiebig die Kapselung durch die vielen schönen
getter/setter aufheben.
> Wenn auf ein
> Attribut nicht zugegriffen werden soll, macht man die Getter/Setter
> private, was ich in deinem Fall machen würde, wobei deine 3 Methoden
> ("start()", "isRunning()" und "hasError()") dann über die Getter/Setter
> gehen sollten, sonst würden diese keinerlei Sinn ergeben.
Ob man nun private getter/setter nutzt oder direkt auf das Feld zugreift
ist Geschmackssache - beides hat seine Vor- und Nachteile und keines
verletzt -- da es ja private ist -- die Kapselung. Argumente für oder
gegen private Setter/Getter wurden schon gebracht.
Ich nutze i.A. immer Getter/Setter, da der Zugriff dann
eindeutiger/einheitlicher ist: Wenn ich wissen will wo ein Feld
manipuliert wird, muss ich nur die Referenzen des Setters prüfen.
Aber das ist kein Dogma -- es mag Fälle geben in denen ich von diesem
Muster abweiche.
> PS: Hab in einem anderen Beitrag nen Beispiel gebracht mit einem Saldo
> eines Kontos, vielleicht hilft das ein wenig weiter.
Danke. Mir ist der Sinn von Kapselung durchaus klar. ;o)
Christoph Herrmann
> Christoph Herrmann schrieb:
>> Kapselung heißt nicht private... Deswegen ist es auf jeden Fall nicht
>> genauso schlecht.
>
> Obwohl du offensichtlich meiner Meinung bist, widersprichst du mir die
> ganze Zeit. Liest du nicht richtig, widersprichst du gern oder ist das
> so eine Outsider-Kunst ;o)
Ich wollte damit eigentlich nur ausdrücken, dass Kapselung nicht nur
darin bestehen alles private zu machen (Zugriffskontrolle ist nur ein
Aspekt der Kapselung). Es gehört dazu klar, also nur öffentliche
Getter/Setter oder Attribute wären schwachsinnig. Aber Kapselung hat
noch weitere Vorteile und macht somit auch bei öffentlichen
Getter/Setter Sinn, wie Verbergung der inneren Datenstruktur.
> Es ging darum das aktuelle IDEs Setter/Getter generieren können und
> Anfänger daher gern und ausgiebig die Kapselung durch die vielen schönen
> getter/setter aufheben.
Nur den Aspekt der Zugriffskontrolle geben Sie damit auf. Klar die IDE
kann ja nicht wissen welchen Zugriff die Methoden haben dürfen, das muss
der Entwickler noch selbst entscheiden. Wenn es jemand halt nicht
entscheiden will ist das sein Problem.
> Ob man nun private getter/setter nutzt oder direkt auf das Feld zugreift
> ist Geschmackssache - beides hat seine Vor- und Nachteile und keines
> verletzt -- da es ja private ist -- die Kapselung. Argumente für oder
> gegen private Setter/Getter wurden schon gebracht.
Da bin ich anderer Meinung, mir ist die Verbergung der Datenstruktur
auch innerhalb der Klasse wichtig, ebenso wie die gleichbleibende art
des Zugriffs (bei mir halt IMMER über die Methoden ohne Unterscheidung
ob es nun gebraucht wird oder nicht). Gerade bei Attributen innerhalb
der Klasse ist es gefährlich ungewollt direkt zuzugreifen weil jemand
übersieht dass es Methoden gibt.
> Ich nutze i.A. immer Getter/Setter, da der Zugriff dann
> eindeutiger/einheitlicher ist: Wenn ich wissen will wo ein Feld
> manipuliert wird, muss ich nur die Referenzen des Setters prüfen.
> Aber das ist kein Dogma -- es mag Fälle geben in denen ich von diesem
> Muster abweiche.
Aso nutzt du doch immer Getter/Setter? ^^ Bei mir gabs bisher noch keine
Fälle, bei denen ich abgewichen bin.
>> PS: Hab in einem anderen Beitrag nen Beispiel gebracht mit einem Saldo
>> eines Kontos, vielleicht hilft das ein wenig weiter.
>
> Danke. Mir ist der Sinn von Kapselung durchaus klar. ;o)
Dann ist ja gut. :)
Wolfgang Rostek
stellen, aber an zwei Stellen stören sie mich doch
- In den Java IDEs und UML Editoren möchte ich sie
nur als Property sehen. Wenn ich in der IDE die
Signatur der Klasse ansehen, überschwemmen
micht diese Methoden. Mehr Bedeutung haben für
mich die Service Methoden der Klasse, nicht die
reinen setter. So aus dem Bauch heraus sind
dies weniger als 20% der Methoden, die mir die
IDE immer liefert.
- Auch im Code würde mir max. eine Zeile mit
den komprimiert dargestellten Eigenschaften
der Properties reichen. Wenn ich die Implementierung
sehen will, drücke ich halt '+' zum expandieren.
Da ich oft Code auf Papier lese, würde selbst der
Trick mit dem '+' nicht gehen.
Kurzum, zuviel zu lesen für den Informationsgehalt.
Gruß
Wolfgang R.
Patrick Roemer
> es ist ein fundamentales Konzept für Formobjekte, also
> Objekte, die nur Daten enthalten, also Beans, public getter und setter
> Methode zu implementieren, und die Attribute selbst als private zu
> deklarieren.
Beans an sich koennen und sollen durchaus normale POJOs mit Verhalten sein.
"A Java Bean is a reusable software component that can be manipulated
visually in a builder tool. [...] The methods a Java Bean exports are
just normal Java methods which can be called from other
components or from a scripting environment."
(JavaBeans Spec 1.01)
"Objekte, die nur Daten enthalten" als Konzept ist IMO grundsaetzlich
fragwuerdig. Natuerlich kann es durchaus mal "passieren", dass man
solche Klassen erhaelt, aber ebenso schnell kann es auch passieren, dass
eine solche Klasse mit der Zeit Verhalten "entwickelt" - z.B. weil API
und interne Repraesentation mit der Zeit divergieren, wie bereits
anderswo in diesem Thread angesprochen.
Das "fundamentale Konzept" ist schlicht, internen Zustand vor Clientcode
zu kapseln. Ich halte es im allgemeinen nicht fuer sinnvoll,
Gettern/Settern eine (ueber die Beans-Konvention hinausgehende)
konzeptuelle Sonderstellung einzuraeumen - sie sind Bestandteile der API
wie jede andere Methode auch.
> Was aber ist, wenn man eine Klasse bzw. ein Objekt immutable machen
> möchte, und daher keine Setter Methoden zur Verfügung stellen möchte -
> macht es dennoch Sinn, private setter Methoden zu nutzen, oder wäre es
> dann nicht sinniger, aus der Klasse heraus direkt auf die Attribute zu
> zugreifen - oder, um die Frage noch genereller auszudrücken -
> sollte man innerhalb einer Klasse die Getter und Setter Methoden nutzen,
> oder lieber direkt auf die Attribute zugreifen?
Ich wuerde private Getter/Setter nur aus denselben Gruenden einfuehren,
aus denen ich auch andere private Methoden ins Spiel bringen wuerde -
etwa um wiederholt benoetigtes Verhalten zu kapseln. Fuer einen
schlichten Feldzugriff sehe ich da ueberhaupt keinen Grund. Sinnvoll
wird es IMO erst, wenn tatsaechlich Verhalten (Caching, Transformation
oder sonstwas) ins Spiel kommt - und dann kann man ja problemlos vom
direkten Zugriff zu Gettern/Settern refaktorieren - es ist ja nur diese
Klasse betroffen.
> Ein Grund für generellen Zugriff über Getter und Setter, unabhängig ob
> sie private oder public sind wäre wohl Threadsicherheit - Methoden kann
> man synchronisieren. Aber was, wenn man das z.B. nicht brauchen wird?
Selbst wenn man es brauchen wuerde, waeren private Getter/Setter
vermutlich zu feingranular - die Synchronisierung waere dann meist
besser dort aufgehoben, wo "externer" Code auf die Klasse zugreifen
kann, eben auf API-Methoden-Ebene.
Viele Gruesse,
Patrick
Daniel Urban
Langsam habe ich den Eindruck, dass ich eine andere Sprache spreche. Wenn
ich schreibe "meisten", dann meine ich nicht: "auschließlich nur". Natürlich
gibt es sinnvolle Fälle. Wobei ich auch schon erwähnt habe, dass in einer
großen Zahl dieser Fälle, es sich für mich um neue (berechnete Attrubute)
handelt. Ich würde diese auch anders benennen.
Das Beispiel immutable Objekte zum Beispiel führt oft dazu, dass ein anderes
Interface zurückgegeben wird. Ob dahinter eine eigene Implementierung oder
die gleiche Implementierung steckt, ist für mich dann egal. Ich sehe darin,
zwei verschiedene Attribute. IMHO
Gruß,
Daniel
Daniel Urban
> Das "fundamentale Konzept" ist schlicht, internen Zustand vor Clientcode
> zu kapseln. Ich halte es im allgemeinen nicht fuer sinnvoll,
> Gettern/Settern eine (ueber die Beans-Konvention hinausgehende)
> konzeptuelle Sonderstellung einzuraeumen - sie sind Bestandteile der API
> wie jede andere Methode auch.
[...]
> Ich wuerde private Getter/Setter nur aus denselben Gruenden einfuehren,
> aus denen ich auch andere private Methoden ins Spiel bringen wuerde -
> etwa um wiederholt benoetigtes Verhalten zu kapseln. Fuer einen
> schlichten Feldzugriff sehe ich da ueberhaupt keinen Grund. Sinnvoll
> wird es IMO erst, wenn tatsaechlich Verhalten (Caching, Transformation
> oder sonstwas) ins Spiel kommt - und dann kann man ja problemlos vom
> direkten Zugriff zu Gettern/Settern refaktorieren - es ist ja nur diese
> Klasse betroffen.
Ich stimme Dir voll zu. Ich hoffe, dass Deine Erklärung besser verständlich
für die Anderen ist, als mein Erklärungsversuch, der hier offensichtlich
Verwirrung ausgelöst hat.
Gruß,
Daniel
Daniel Urban
> Ich möchte die Nutzung der getter/setter nicht in Frage
> stellen, aber an zwei Stellen stören sie mich doch
>
> - In den Java IDEs und UML Editoren möchte ich sie
> nur als Property sehen.
Das war der Punkt, wo ich meinte, dass C# es besser löst.
> - Auch im Code würde mir max. eine Zeile mit
> den komprimiert dargestellten Eigenschaften
> der Properties reichen. Wenn ich die Implementierung
> sehen will, drücke ich halt '+' zum expandieren.
> Da ich oft Code auf Papier lese, würde selbst der
> Trick mit dem '+' nicht gehen.
Sollte die IDe doch ermöglichen, oder?
Gruß,
Daniel
Daniel Urban
> Beispiel direkt:
>
> Ich mache eine Banksoftware und biete das Attribut "saldo" für die Klasse
> Konto an als double (Fliesskommazahl). An hunderten von Stellen in der
> Software setze ich den Saldo nun per Fliesskommazahl direkt auf die
> gewünschten Werte. Irgendwann merke ich, hey beim rechnen bekomme ich
> Rundungsfehler ich muss ja integer nehmen und die Centbeträge (ganze
> Zahlen). Viel spaß beim ändern... :)
Naja, das ist ein Bug, den würde ich dann auch an allen Stellen entfernen.
Die Arbeit sollte man sich schon machen. Alles andere würde ich als sehr
unschön bezeichnen.
Interessant wäre hier auch Dein Setter gewesen. Da ich eigentlich auch
erwarte, dass der Wert, den ich reinstecke in den Setter auch wieder aus dem
Setter kommt. Durch Deine Rundung wäre dies nicht mehr der Fall. Ich würde
also immer den Setter mit double entfernen, weil ich den als falsch (Bug)
empfinde. IMHO
Gruß,
Daniel
Daniel Urban
> Daniel Urban schrieb:
>> "Christoph Herrmann"
>>> - ich sehr schnell den Zugriff regeln kann (ich muss, wenn es benötigt
>>> wird nicht nachträglich Getter und Setter implementieren)
>>
>> Implementieren? Mmm... bei den meisten IDEs sind das zwei Clicks.
>
> Wenn ich von direktem Zugriff aber auf Zugriff über die Methoden ändere
> ist da noch etwas mehr als nur die Methoden schreiben. Nämlich alle
> Stellen wo der Zugriff gemacht hat entsprechend anpassen.
Der Kontext war doch AFAIK, dass direkt auf private Attributte zugegriffen
wird. Nun will man öffentliche Setter und/oder Getter für so ein Attribute
anlegen. Dann brauche ich doch keine Zugriffe ändern, denn die sind doch
alle intern in der Klasse. Wenn man in der Klasse intern auch die Getter und
Setter verwenden will, dann muss man natürlich etwas mehr machen. Aber ich
hatte zumindest für mich geschrieben, dass ich dies nicht mache, es sei denn
es gibt dafür nutzbringende Gründe (Reuse).
>> Außerdem scheinst Du mir dann ein wenig das Konzept Information-Hiding zu
>> verletzen. Grundsätzlich ist erst einmal alles private und erst, wenn es
>> nötig ist, mache ich die Sachen public. Das nachträgliche Ändern ist
>> daher kein Nachteil, sondern eher Konzept.
>
> Wieso verletzen? Bei mir sind Getter und Setter auch nur public, wenn es
> nötig ist. Das sollte ja klar sein.
Das möchte ich doch hoffen. ;-) Ich ging bei diesem Satz davon aus, dass es
keine privaten Setter und Getter gibt, wie man aus dem nachfolgendem Absatz
gut entnehmen konnte.
>> Das nachträgliche Ändern auf private dagegen wird Dir schwer fallen, es
>> sei denn, Du verwendest auch für private Attribute entsprechend private
>> Getter und Setter. Das habe ich bisher noch nicht gesehen, aber man lernt
>> doch nie aus.
>
> Bei mir sind alle Attribute private und haben Setter und Getter. Ist der
> Zugriff von außen gewünscht, sind diese public, ansonsten habe ich private
> Setter und Getter für den Zugriff innerhalb der Klasse. Bei mir ganz
> normal.
Will ich Dir auch nicht nehmen, bei mir ist es anders. Meine Gründe habe ich
versucht darzulegen und gleichzeitig gesagt, dass es kein Dogma ist. Wichtig
war mir, dass man sich darüber Gedanken macht, warum man Getter und Setter
verwendet und darüber sollte man dann auch die Frage des OP für sich
entscheiden können.
>> Naja, hängt davon ab, ob Du in den Getter und Setter Logik
>> implementierst. Wenn Du das machst, wirst Du vermutlich auch Fälle haben,
>> wo das an verschiedenen Stellen unterschiedlich ist. Wobei ich
>
> Was ist unterschiedlich? Die Logik ja, aber nicht der Zugriff, das ist ja
> der Vorteil. Dem Benutzer ist es egal ob da Logik dahinter steckt oder
> nicht, der Zugriff erfolgt immer über die Methoden.
Typisch Informatiker ;-) Der Vorteil kann genauso ein Nachteil sein. Wenn
ich eine Klasse verwende, dann benutze ich sie so, wie sie gedacht war. Wenn
ich die Klasse ändere muss ich mir an jeder Verwendungsstelle überlegen, ob
die Änderung hier gültig ist. D.h. wenn ich Logik in Getter oder Setter
implementiere muss ich sicher sein, dass dies an allen Aufrufstellen
sinnvoll ist. Wenn es Stellen gibt, in denen die Logik eben nicht sinnvoll
ist, dann muss ich mir etwas überlegen. Zumal wenn diese Stellen nicht in
meinem Änderungsbereich liegen.
>> hier sowieso zwei Attribute halten würde. Ein privates ohne Logik und ein
>> öffentliches mit Logik. Beide hätten natürlich unterschiedliche Namen,
>> wobei das öffentliche auf das private zufreifen würde.
>
> Wieso für jedes Attribute zwei Attribute machen? Das verstehe ich nicht,
> wo da der Sinn dahinter sein soll... Beispiel?
Wieso für jedes? Ich schreibe einen Satz und plötzlich soll der für alle
Fälle ausnahmslos gültig sein? Dem ist natürlich nicht so.
Mein Beispiel:
class Ware
{
private float preis;
public float getPreis()
{
return preis;
}
public void setPreis(float preis)
{
this.preis = preis;
}
}
Nun stellt man fest, dass man eigentlich zwischen netto und brutto
unterscheiden will, daher fügt man die Logik für die Mehrwertsteuer ein.
Natürlich kann ich das in den Preis mit einbauen, aber dann muss ich sicher
sein, dass alle Verwender das auch entsprchend berücksichtigen. Aber warum
nicht einfach ein zweites berechnetes Attribute?
public float getBruttoPreis()
{
return preis + (preis * 19 / 100); // hier fehlt noch ein Teil, um
nicht zu runden...
}
Gleiches kann ich auch für Readonly-Collections u.ä. machen.
Gruß,
Daniel
Daniel Urban
> Daniel Urban schrieb:
>> "Malte Schirmacher"
>>> Daniel Urban schrieb:
>>>> "Malte Schirmacher"
>>>> Dann machst Du es private. Wo ist das Problem?
>>>
>>> Dass du es nichtmehr private machen kannst, wenn du die API einmal mit
>>> öffentlichen Attributen veröffentlicht hast.
>>
>> Mit Methoden kannst Du das aber auch nicht. Zumindest wird dann das
>> Programm nicht mehr funktionieren.
>
> Wieso sollte ein Programm nichtmehr funktionieren, wenn ich alle
> Zugriffe auf die Methode mitlogge?
Du hast offenbar den Kontext verloren. Was hattLogging jetzt mit o.g.
private machen zu tun?
[...]
>> Ich habe nicht gesagt, dass alle Attribute öffentlich sein sollen,
>> sondern dass man auf alle öffentlichen Attribute auch direkt zugegriffen
>> kann.
>
> Man gibt aber nunmal flexibilität auf wenn man direkten Zugriff erlaubt.
Du gehörst zu der Fraktion, die gerne mal die eierlegende Wollmilchsau
implementiert? Ich kann nicht alles in mein Programm einbauen. Ich muss
immer den Nutzen mit den Kosten vergleichen. Flexibilität ist kein
Selbstzweck. Wenn es einen Nutzen gibt, mache ich es. Wenn es keinen Nutzen
hat, mache ich es nicht. Über den Nutzen diskutieren wir - hoffentlich.
>> Meiner Meinung nach gibt es mindestens folgende Gründe Getter und Setter
>> zu verwenden:
>>
>> 1. Frameworks benötigen die Getter und Setter
>
> Wieso?
Da musst Du die Entwickler der Frameworks fragen. Ich verwende die
Frameworks nur.
>> 2. Readonly und Writeonly Attribute
>
> Nicht nur, wie du aber (imho grundlos) ignorierst
Ich ignoriere nichts und schon gar nicht grundlos. Wir diskutieren doch
gerade darüber.
>> 4. vereinheitlicher Zugriff auf öffentliche Attribute
>
> Wieso sollte man denn irgendwas vereinheitlichen? Ist doch völlig unnötig!
Deine Meinung. Ich halte es für sinnvoll, gewisse Dinge zu vereinheitlich,
um Code besser lesen zu können und somit besser warten zu können. Aber alles
auch unter Berücksichtigung des Nutzens. Einheitlich könnte theoretisch auch
der Zugriff direkt auf das Attribut sein.
>> Kein Argument IMHO - und daher führe ich die Diskussion überhaupt mit
>> Dir - ist das Thema Methoden sind besser inhaltlich zu ändern. Denn an
>> einem Attribute muss/kann ich nicht viel ändern. Wenn eine Methode einen
>> anderen Wert zurückgibt, als das Attribute hält, dann sind das für mich
>> zwei verschiedene Attribute, z.B. ein gespeichertes und ein berechnetes.
>
> Wenn das Attribut aber nunmal eine Collection ist, die verändert werden
> kann und du eine Referenz auf die Collection zurückgibst kann jeder
> Client diese ändern.
Wenn man es so modelliert...
> Wenn du also keine Methode dazwischen schiebst kannst du nicht
> verhindern, dass der Client der API die Collection auch tatsächlich
> ändert.
Hier fehlt mir ein Beispiel. Ich kann mir da mehrere Lösungen vorstellen.
>> Wenn es um Logik geht, die nicht den eigentlichen Wert ändert, dann kann
>> das durchaus Sinn machen, aber deswegen würde ich noch nicht
>> grundsätzlich und überall so verfahren.
>
> Wenn ich eine unveränderliche *Sicht* auf die Collection zurückgebe,
> oder aber die Collection vor der Rückgabe *kopiere* ist das mit
> Sicherheit kein anderes Attribut.
Meiner Meinung nach schon. Kann man auf jeden Fall so modellieren und löst
Dein Problem.
>> Außerdem müsste man mir dann
>> auch noch ein paar bessere Beispiele, außer dem Logging bringen. Das
>> Logging in Settern und Getter ist AFAIK mir bisher auch noch nicht
>> begegnet.
> Ist auch nur ein furchtbar marginales Beispiel das dich davon überzeugen
> sollte, dass der Wert des Attributs nicht geändert wird, dennoch aber
> der Getter absolut unabdingbar für die Funktionalität ist.
Dann nenne doch mal ein Beispiel, welches mich besser überzeugen könnte.
Gruß,
Daniel
Hubert Partl
> macht es dennoch Sinn, private setter Methoden zu nutzen,
Ja, ich empfehle, immer setter-Methoden zu definieren,
auch wenn sie private sind,
und ja, ich empfehle, immer die setter-Methoden aufzurufen,
auch innerhalb der Klasse, die die privete Attribute direkt ansprechen
duerfte.
Grund (wie auch schon von anderen gesagt):
Falls ich (jetzt oder spaeter) in den setter-Methoden
irgendeine Ueberpruefung auf gueltige/ungueltige Werte
oder ein Logging
oder Datenbank-Synchronisieren
oder ein Neu-Berechnen von abhaengigen Werten
oder oder oder ...
einbauen will, dann muss ich (ausser dem Inhalt der setter-Methode)
nichts aendern.
Falls eine kuenftige Umstellung von lokalen Attributen auf Datenbanken
moeglicherweise sinnvoll oder zu erwarten ist,
sollte man sogar auch die getter-Methoden immer aufrufen,
damit man den Attribut-Zugriff auf eine Datenbank-Abfrage aendern kann.
--
Thomas Thiele
> Wobei mal hinterfragt werden sollte, warum dieses Konzept eingeführt wurde
> und nicht direkt auf die Attribute zugegriffen wird.
Das ist einfach.
Weil Setter und Getter mehr machen können als nur den Zugriff zu
ermöglichen.
Bei getX() z.B. kann es sein,
- dass es x gar nicht als Datenfeld gibt, sondern bei jedem Aufruf
z.B. aus y berechnet wird
- x erst beim Aufruf tatsächlich berechnet oder geholt wird ("lazy
fetching")
- x nur als Kopie zurückgeliefert wird um das interne x immutable für
aussen zu halten
- noch checks drin sind, die eine Exception werfen, wenn x nicht
valide ist
- syncronisation sicherstellen (locks und co)
usw.
Um dann nicht jedesmal die Schnittstelle anzupassen macht man es
gleich so.
> Allerdings finde ich die Lösung in C# besser.
Geschmacksfrage.
In C++ gibts noch die Unterscheidung const vs. nicht-const.
> Also ich habe bisher noch keine privaten Getter oder Setter gesehen. Ich bin
> der Meinung, dass man in der Klasse möglichst auch auf die internen Methoden
> und Attribute zugreifen sollte. Lediglich um Reuse zu ermöglichen, würde ich
> auch auf die öffentlichen Methoden und Attribute zugreifen. Aber das ist
> kein Dogma.
Obiges gilt auch intern.
Wobei da eine zusätzliche Funktion keine Schnittstellenänderung
bedeutet.
Deshalb bietet sich intern erstmal direkt zuzugreifen und erst wenn
man zusätzliche Funktionalität benötigt wird diese zu implementieren.
Thomas Thiele
> - In den Java IDEs und UML Editoren möchte ich sie
> nur als Property sehen.
IDE driven software...
IDE verweichlicht! Schreib den Code mit vi...;-)
Daniel Urban
> On 27 Sep., 18:37, "Daniel Urban" <urban...@cs.tu-berlin.de> wrote:
> > Wobei mal hinterfragt werden sollte, warum dieses Konzept eingeführt
> > wurde
> > und nicht direkt auf die Attribute zugegriffen wird.
> Das ist einfach.
Jezt können Fragen auch schon falsch sein?
Den Rest habe ich mal weggeschnitten, weil Du offensichtlich (noch) nicht
den ganzen Thread gelesen hast.
Gruß,
Daniel
Michael Paap
> "Thomas Thiele"
>> On 27 Sep., 18:37, "Daniel Urban" <urban...@cs.tu-berlin.de> wrote:
>
>> > Wobei mal hinterfragt werden sollte, warum dieses Konzept eingeführt
>> > wurde
>> > und nicht direkt auf die Attribute zugegriffen wird.
>
>> Das ist einfach.
>
> Jezt können Fragen auch schon falsch sein?
Nein, aber einfach.
> Den Rest habe ich mal weggeschnitten, weil Du offensichtlich (noch) nicht
> den ganzen Thread gelesen
Je nun, viel mehr als das, was Thomas geschrieben hat, kann man zu dem
Thema halt nicht schreiben, ohne dass man anfängt, unausgegorenes Zeug
zu posten. Wollt ihr den Thread nicht mal sterben lassen, bevor noch
mehr davon produziert wird?
Ich hab ein paar Leuten erzählt, das fachliche Niveau in dclj sei höher
als in den meisten Java-Webforen... hoffentlich sehen die diesen Thread
nicht.
Kopfschüttelnder Gruß,
Michael
Christoph Herrmann
> Je nun, viel mehr als das, was Thomas geschrieben hat, kann man zu dem
> Thema halt nicht schreiben, ohne dass man anfängt, unausgegorenes Zeug
> zu posten. Wollt ihr den Thread nicht mal sterben lassen, bevor noch
> mehr davon produziert wird?
>
> Ich hab ein paar Leuten erzählt, das fachliche Niveau in dclj sei höher
> als in den meisten Java-Webforen... hoffentlich sehen die diesen Thread
> nicht.
Ich kann nicht behaupten dass der Thread niedriges Niveau hat, es wurden
genügend Vor- / Nachteile diskutiert und auch Beispiele gebracht und wir
wurden glaub nicht mal Off Topic. ;)
Michael Paap
> Ich kann nicht behaupten dass der Thread niedriges Niveau hat, es wurden
> genügend Vor- / Nachteile diskutiert und auch Beispiele gebracht und wir
> wurden glaub nicht mal Off Topic. ;)
Meine Aussage war vielleicht etwas missverständlich... ich wollte
keineswegs jedem Posting im Thread das Niveau absprechen. Aber der
Gesamteindruck ist imho schon deprimierend. Und je länger, je schlimmer.
Deswegen hör ich jetzt auch auf, ihn weiter zu lesen. *g*
--> F'up an Poster
Gruß,
Michael
Thomas Thiele
> Jezt können Fragen auch schon falsch sein?
Ich steh grad auf dem Schlauch. Was meinst du jetzt?
Malte Schirmacher
> "Malte Schirmacher"
>> Daniel Urban schrieb:
>>> "Malte Schirmacher"
>>>> Daniel Urban schrieb:
>>>>> "Malte Schirmacher"
>>>>> Dann machst Du es private. Wo ist das Problem?
>>>>
>>>> Dass du es nichtmehr private machen kannst, wenn du die API einmal mit
>>>> öffentlichen Attributen veröffentlicht hast.
>>>
>>> Mit Methoden kannst Du das aber auch nicht. Zumindest wird dann das
>>> Programm nicht mehr funktionieren.
>>
>> Wieso sollte ein Programm nichtmehr funktionieren, wenn ich alle
>> Zugriffe auf die Methode mitlogge?
>
> Du hast offenbar den Kontext verloren.
Schon möglich.
> Was hattLogging jetzt mit o.g.
> private machen zu tun?
Nichts. War schon spät als ich das las. Meine korrekte Antwort hätte
lauten sollen:
Was soll denn das für ein Argument sein? Ich *will* doch meine Methode
garnicht private machen, ich will nur, dass intern andere Dinge ablaufen
als nur das Attribut zurückzugeben, ohne dass der Client der API was
davon mitbekommt. Das geht aber nicht beim direkten Zugriff auf Attribute.
>
> [...]
>>> Ich habe nicht gesagt, dass alle Attribute öffentlich sein sollen,
>>> sondern dass man auf alle öffentlichen Attribute auch direkt zugegriffen
>>> kann.
>>
>> Man gibt aber nunmal flexibilität auf wenn man direkten Zugriff erlaubt.
>
> Du gehörst zu der Fraktion, die gerne mal die eierlegende Wollmilchsau
> implementiert?
Was haben denn objektorientiertes Design und bewahrung von Flexibilität
mit diesen komischen Tieren zu tun?
> Ich kann nicht alles in mein Programm einbauen. Ich muss
> immer den Nutzen mit den Kosten vergleichen. Flexibilität ist kein
> Selbstzweck. Wenn es einen Nutzen gibt, mache ich es. Wenn es keinen
> Nutzen hat, mache ich es nicht. Über den Nutzen diskutieren wir -
> hoffentlich.
Wieso sollte die Bewahrung der Flexibilität, die andererseits keine
*Kosten* verursacht einfach aus dem Programm rausgeschmissen werden?.
>
>>> Meiner Meinung nach gibt es mindestens folgende Gründe Getter und Setter
>>> zu verwenden:
>>>
>>> 1. Frameworks benötigen die Getter und Setter
>>
>> Wieso?
>
> Da musst Du die Entwickler der Frameworks fragen. Ich verwende die
> Frameworks nur.
Also war das garkein Argument?
>>> 4. vereinheitlicher Zugriff auf öffentliche Attribute
>>
>> Wieso sollte man denn irgendwas vereinheitlichen? Ist doch völlig
>> unnötig!
>
> Deine Meinung. Ich halte es für sinnvoll, gewisse Dinge zu
> vereinheitlich, um Code besser lesen zu können und somit besser warten
> zu können. Aber alles auch unter Berücksichtigung des Nutzens.
> Einheitlich könnte theoretisch auch der Zugriff direkt auf das Attribut
> sein.
Nein, das ist nicht meine Meinung, aber es spiegelt nur das wieder was
du in meinem Empfinden zu Gettern und Settern sagst ("Was soll ich denn
damit")
Aber der Grund FÜR eben diese eigentlich ähnlicher Natur ist deine
Vereinheitlichung von Code.
>> Wenn das Attribut aber nunmal eine Collection ist, die verändert werden
>> kann und du eine Referenz auf die Collection zurückgibst kann jeder
>> Client diese ändern.
>
> Wenn man es so modelliert...
Du gehörst also zur Fraktion die niemal Fehler bei der Planung macht und
jedes Design von vornherein perfekt ist? Dann kann ich verstehen, dass
du Getter und Setter nicht brauchst.
>> Wenn du also keine Methode dazwischen schiebst kannst du nicht
>> verhindern, dass der Client der API die Collection auch tatsächlich
>> ändert.>
>
> Hier fehlt mir ein Beispiel. Ich kann mir da mehrere Lösungen vorstellen.
Lösung für was? Ein öffentliches Attribut private zu machen, ohne dass
die Clients kaputtgehen? Da fehlt mir ein Beispiel. ICH kann mir da
keine Lösung vorstellen.
>>> Wenn es um Logik geht, die nicht den eigentlichen Wert ändert, dann kann
>>> das durchaus Sinn machen, aber deswegen würde ich noch nicht
>>> grundsätzlich und überall so verfahren.
>>
>> Wenn ich eine unveränderliche *Sicht* auf die Collection zurückgebe,
>> oder aber die Collection vor der Rückgabe *kopiere* ist das mit
>> Sicherheit kein anderes Attribut.
>
> Meiner Meinung nach schon. Kann man auf jeden Fall so modellieren und
> löst Dein Problem.
Du kannst das vielleicht. Der Rest der Menschheit vermutlich nicht.
Wolfgang Rostek
> > - Auch im Code würde mir max. eine Zeile mit
> > den komprimiert dargestellten Eigenschaften
> > der Properties reichen. Wenn ich die Implementierung
> > sehen will, drücke ich halt '+' zum expandieren.
> > Da ich oft Code auf Papier lese, würde selbst der
> > Trick mit dem '+' nicht gehen.
>
> Sollte die IDe doch ermöglichen, oder?
dort?
Gruß
Wolfgang R.
Wolfgang Rostek
War das jetzt ein konstruktiver Beitrag? Hab durchaus
Kollegen, die mit vi/emacs extrem schnell sind. Aber
ich möchte lieber noch weicher werden ;)
Gruß
Wolfgang R.
Daniel Urban
> Daniel Urban schrieb:
>> Frameworks nur.
>
> Also war das garkein Argument?
Anscheinend fehlt uns eine gemeinsame Definition von "Argument". Meinem
Verständnis nach, war es eines. Wenn es keines in Deinem Sinne war, solltest
Du es erklären.
>> Deine Meinung. Ich halte es für sinnvoll, gewisse Dinge zu
>> vereinheitlich, um Code besser lesen zu können und somit besser warten
>> zu können. Aber alles auch unter Berücksichtigung des Nutzens.
>> Einheitlich könnte theoretisch auch der Zugriff direkt auf das Attribut
>> sein.
>
> Nein, das ist nicht meine Meinung, aber es spiegelt nur das wieder was
> du in meinem Empfinden zu Gettern und Settern sagst ("Was soll ich denn
> damit")
Dein Empfinden ist seltsam und widerspricht dem, was ich sogar wörtlich in
dem Thread geschrieben habe.
> Aber der Grund FÜR eben diese eigentlich ähnlicher Natur ist deine
> Vereinheitlichung von Code.
Bist Du schon wieder müde? Wo ist der Widerspruch? Was willst Du sagen?
>>> Wenn das Attribut aber nunmal eine Collection ist, die verändert werden
>>> kann und du eine Referenz auf die Collection zurückgibst kann jeder
>>> Client diese ändern.
>>
>> Wenn man es so modelliert...
>
> Du gehörst also zur Fraktion die niemal Fehler bei der Planung macht und
> jedes Design von vornherein perfekt ist? Dann kann ich verstehen, dass
> du Getter und Setter nicht brauchst.
Wo habe ich geschrieben, dass ich Setter und Getter nicht (ge)brauche?
Langsam bekommen ich den Eindruck, dass Du nur rumtrollen willst.
[...]
>> Meiner Meinung nach schon. Kann man auf jeden Fall so modellieren und
>> löst Dein Problem.
>
> Du kannst das vielleicht. Der Rest der Menschheit vermutlich nicht.
Sei nicht so bescheiden, Du kannst das sicher mit etwas Nachdenken auch.
Gruß,
Daniel
Malte Schirmacher
> Wo habe ich geschrieben, dass ich Setter und Getter nicht (ge)brauche?
> Langsam bekommen ich den Eindruck, dass Du nur rumtrollen willst.
Hmm diesen Eindruck hatte ich bei dir auch zum Schluss.
Ich schlage vor wir beenden das an dieser Stelle und gehen in
Freundschaft auseinander.
Daniel Urban
Vielleicht habe ich Dich falsch verstanden. Also bei mir in Eclipse kann man
Methoden einklappen und mit Plus ausklappen. Das sollte also für Setter und
Getter möglich sein. Bei Visual Studio und C# geht das auch für Properties.
Da ich Code nicht ausdrucke, weiß ich nicht, ob das dort auch anwendbar ist.
Gruß,
Daniel
Alfred
>>...
>> Wieso für jedes Attribute zwei Attribute machen? Das verstehe ich
>> nicht, wo da der Sinn dahinter sein soll... Beispiel?
>
> Wieso für jedes? Ich schreibe einen Satz und plötzlich soll der für alle
> Fälle ausnahmslos gültig sein? Dem ist natürlich nicht so.
>
> Mein Beispiel:
>
> class Ware
> {
>
> private float preis;
>
> public float getPreis()
> {
> return preis;
> }
>
> public void setPreis(float preis)
> {
> this.preis = preis;
> }
> }
>
> Nun stellt man fest, dass man eigentlich zwischen netto und brutto
> unterscheiden will, daher fügt man die Logik für die Mehrwertsteuer ein.
> Natürlich kann ich das in den Preis mit einbauen, aber dann muss ich
> sicher sein, dass alle Verwender das auch entsprchend berücksichtigen.
> Aber warum nicht einfach ein zweites berechnetes Attribute?
>
> public float getBruttoPreis()
> {
> return preis + (preis * 19 / 100); // hier fehlt noch ein Teil,
> um nicht zu runden...
> }
Mal ganz abgesehen davon, dass diese Berechnung der Mwst.
in der Klasse Ware gar nichts zu suchen hat. Hier merkt man
sich höchstens, zu welchem Mwst-Typ die jeweilige Ware gehört,
Stichwort Lebensmittel, Medikamente, Luxusgüter etc. Wobei das
auch über die Zugehörigkeit zu Warengruppen abgebildet werden
könnte. Die Berechnung selbst übernimmt ein passender Service
und _nur_ der kennt die aktuellen Prozente für die jeweilige
Warengruppe.
Alfred
Alfred
>
> Also ich habe bisher noch keine privaten Getter oder Setter gesehen. Ich
Dann hast du wohl noch nie über Hibernate read-only Klassen
implementiert. Dort sind die setter nämlich erforderlich aber
private genügt völlig, da Hibernate über Reflection und Accessible
geht. Es gelte der Grundsatz: So privat wie möglich und so öffentlich
wie nötig. Das gilt für Attribute und Methoden gleichermassen.
Alfred
Wolfgang Rostek
Ich kenne VisualStudio nicht. Hast Du einen Link mit
einem Screenshot?
In Eclipse Editor würde ich mir das ungefähr so vorstellen.
Im Code wird an der Stelle des Attributes eine Annotation
hinzugefügt
@property READ=public, WRITE=private
private boolean value = false;
// below invisible if properties are collapsed
private void setValue(boolean value) {
this.value = value;
}
public boolean getValue() {
return value;
}
Im package explorer würde ich dann ähnlich den fields
eine Sektion properties sehen. Mit dem Filter leicht
unsichtbar zu machen.
Deren setter/getter sollen dann aber +nicht+ nochmal
im Block der Methoden erscheinen. Dort stören sie mich.
Gruß
Wolfgang R.
Daniel Urban
> In Eclipse Editor würde ich mir das ungefähr so vorstellen.
>
> Im Code wird an der Stelle des Attributes eine Annotation
> hinzugefügt
>
> @property READ=public, WRITE=private
> private boolean value = false;
Ah, so hast Du das gemeint. Das geht in Eclipse und VS nicht. In Eclipse
wären es wirklich zwei ausklappbare Codestellen. In VS ist es dann sogar
noch etwas schlechter, da man beim Property nicht mehr erkennt, ob Getter
und Setter oder nur eins von beiden existiert.
[...]
> Deren setter/getter sollen dann aber +nicht+ nochmal
> im Block der Methoden erscheinen. Dort stören sie mich.
In VS mit C# ist dem so.
Gruß,
Daniel
Jochen Theodorou
[...]
> - Auch im Code w�rde mir max. eine Zeile mit
> den komprimiert dargestellten Eigenschaften
> der Properties reichen. Wenn ich die Implementierung
> Da ich oft Code auf Papier lese, w�rde selbst der
> Trick mit dem '+' nicht gehen.
denk immer daran: du programmierst in Java
Java ist eine Sprache die dich an der Hand nimmt und versucht dir
einzureden was du tun und lassen sollst. Java ist eine Sprache die dich
zwingt viel Rauchsen zu produzieren.
Und nicht wenige finden genau das toll!
> Kurzum, zuviel zu lesen f�r den Informationsgehalt.
deswegen habe viele Sprachen auch eine Art Propertysyntax, zum Beipsiel
kannst du in Groovy mit
class A {
String foo
}
ein property definieren, mit einem privaten Feld foo mit Typ String,
einen entsprechenden Getter und einen entsprechenden Setter. Daf�r
unterst�tzt Groovy keine Properties mit der Sichtbarkeit privaten,
protected oder "package private", aber daf�r kann man auf den alten Weg
aus Java dann zur�ckgreifen... und kombinieren kann man es auch...
Gruss theo
Thomas Thiele
> Java ist eine Sprache die dich an der Hand nimmt und versucht dir
> einzureden was du tun und lassen sollst. Java ist eine Sprache die dich
> zwingt viel Rauchsen zu produzieren.
> Und nicht wenige finden genau das toll!
Und einige andere finden *genau das* nicht toll!
Michael Paap
Nun, die m�ssen ja dann nicht Java verwenden. Warst du nicht einer von
denen, die verk�nden, dass man immer das richtige Werkzeug f�r eine
Aufgabe w�hlen m�ge? *g*
Gru�,
Michael
Thomas Thiele
> Nun, die müssen ja dann nicht Java verwenden. Warst du nicht einer von
> denen, die verkünden, dass man immer das richtige Werkzeug für eine
> Aufgabe wählen möge? *g*
In einer Hammerbude wird eben prinzipiell nur gehämmert und auch
die Kundschaft will nur zusammengehämmertes.
Dass Geschraubtes vielleicht besser wäre, interessiert doch
niemanden...;-)
Gruß Thomas, weiss wo der Hammer hängt
Wolfgang Rostek
> [...]
>
> > - Auch im Code würde mir max. eine Zeile mit
> > den komprimiert dargestellten Eigenschaften
> > der Properties reichen. Wenn ich die Implementierung
> > Da ich oft Code auf Papier lese, würde selbst der
> > Trick mit dem '+' nicht gehen.
>
> denk immer daran: du programmierst in Java
>
> Java ist eine Sprache die dich an der Hand nimmt und versucht dir
> einzureden was du tun und lassen sollst. Java ist eine Sprache die dich
> zwingt viel Rauchsen zu produzieren.
>
> Und nicht wenige finden genau das toll!
aus der Erfahrung Java vs. Groovie einen besseren Überblick.
Bestimmt bin ich schon zu tief drin, das ich dieses Rauschen
gar nicht mehr sehe.
Aber sowohl nach dem Lesen von 'Beyond Java' und auch nach Lesen
des Ruby Manuals habe ich für mich keine wesentlichen Schwächen
von Java gesehen. Wenn dann eher die fehlende Durchgängigkeit
von OO. Wie ich bei Ruby gesehen habe, die integer als Objekt zu
behandeln ist ganz nett. An einigen Stellen etwas mehr zu schreiben
stört mich üblicherweise nicht.
Wenn auch nicht die ultimative Sprache, so ist Java doch
durch vieles im Umfeld sehr produktiv. 'Rauschen' ordne ich
stark dem Begriff 'unproduktiv' zu. Das sehe ich nicht so.
Gruß
Wolfgang R.
Jochen Theodorou
Rauchsen... lol... ich sollte nicht mit jet lag schreiben ;)
Gruss theo
Jochen Theodorou
> On 2 Okt., 04:01, Jochen Theodorou <blackd...@gmx.org> wrote:
>> Wolfgang Rostek schrieb:
>> [...]
>>
>>> den komprimiert dargestellten Eigenschaften
>>> der Properties reichen. Wenn ich die Implementierung
>>> Da ich oft Code auf Papier lese, w�rde selbst der
>>> Trick mit dem '+' nicht gehen.
>> denk immer daran: du programmierst in Java
>>
>> Java ist eine Sprache die dich an der Hand nimmt und versucht dir
>> einzureden was du tun und lassen sollst. Java ist eine Sprache die dich
>> zwingt viel Rauchsen zu produzieren.
>>
>> Und nicht wenige finden genau das toll!
>
> aus der Erfahrung Java vs. Groovie einen besseren �berblick.
Groovy, nicht Groovie bitte ;)
> Bestimmt bin ich schon zu tief drin, das ich dieses Rauschen
> gar nicht mehr sehe.
Das menschliche Gehirn hat eine erstaunliche F�higkeit Dinge zu
ignorieren... ich glaube Terry Pratchet hat sowas mal gesagt.
> Aber sowohl nach dem Lesen von 'Beyond Java' und auch nach Lesen
> des Ruby Manuals habe ich f�r mich keine wesentlichen Schw�chen
> von Java gesehen. Wenn dann eher die fehlende Durchg�ngigkeit
> von OO. Wie ich bei Ruby gesehen habe, die integer als Objekt zu
> behandeln ist ganz nett. An einigen Stellen etwas mehr zu schreiben
> st�rt mich �blicherweise nicht.
es st�rt dich durchaus, wenn du ein Programm in einem Buch oder Artikel
lesen willst. Denn dann ist da keine IDE, die dir Sachen ausblendet und
wenn du st�ndig bl�ttern musst, funktioniert das mit dem ignorieren auch
nicht mehr so toll. Und wenn sich mein Code mal eben um 50% reduzieren,
dann, macht das beim bl�ttern durchaus einen grossen Unterschied. Und
damit meine ich nicht nur die LOCs, sondern teilweise auch die
Komplexit�t des Codes, wobei das ohne Metrik ein wenig schwer in Prozent
auszudr�cken ist. Von "mal kurz was anderes anschauen" wird man
�blicherweise nicht gleich �berzeugt, da muss man schon extreme
Beispiele bringen, wie zum Beispiel Scott Davis, der eine
30-Zeilen-Java-Programm zeigt, dass zu einer Zeile eingedampft wird und
dabei lesbar bleibt, bzw. sogar lesbarer. Das soll aber kein typisches
Beispiel sein, sondern eine Motivation mal ein bisschen mit der Sprache
zu arbeiten... zum "anfixen" so zu sagen ;) Denn wenn man mal damit
angefangen hat, dann wollen viele es nicht mehr missen. Viele sehen dann
erst wie "unn�tig" aufwendig Java �berhaupt ist.
Es geht auch nicht direkt um Schw�chen von Java in seinen Konzepten.
Aber die bisherige Weigerung zum Beispiel Typinferenz in Java
aufzunehmen in Kombination mit Generics halte ich f�r ein brauchbares
Beispiel. Man braucht 2 Seiten um etwas zu vergleichen, deswegen braucht
man den Typ bei der Variablendeklaration und den Typ des Konstruktes das
man dieser Variablen zuweist, sonst gibt es da nichts zu pr�fen. Naja
gut, wenn ich da an ML denke, dann tr�gt IMHO Typinferenz auch nicht
immer unbedingt zur Lesbarkeit bei.
> Wenn auch nicht die ultimative Sprache, so ist Java doch
> durch vieles im Umfeld sehr produktiv. 'Rauschen' ordne ich
> stark dem Begriff 'unproduktiv' zu. Das sehe ich nicht so.
ich schon ;) Allerdings wird der Produktivit�tsverlust durch die IDEs
meist wieder ausgeglichen. Daher sprechen viele auch von einer
IDE-getrieben Sprache, denn ohne IDE ist Java oft grausam anzusehen oder
zu schreiben.
Gruss theo
J. Stoever
> ich schon ;) Allerdings wird der Produktivit�tsverlust durch die IDEs
> meist wieder ausgeglichen. Daher sprechen viele auch von einer
> IDE-getrieben Sprache, denn ohne IDE ist Java oft grausam anzusehen oder
> zu schreiben.
HTML ist als Plaintext auch grausam anzusehen. Und ?
Wer im Jahre 2008 noch ohne IDE coded, ist imo entweder Totalamateur
oder so veraltet dass er vermutlich sowieso nur ANSI-C beherrscht. Oder
Assembler.
Gegen Java zu argumentieren, weil es ohne IDE grausig ist, ist wie zu
sagen "XML mag ich nicht, das sieht im Texteditor so komisch aus". Weder
XML noch Java sind fuer notepad.exe gedacht bzw. geeignet.
Ich erwarte jetzt auch nicht wirklich, dass eine IDE-Kriese aufkommt und
wir in 2009 wieder zum Texteditor wechseln muessen, also finde ich, der
Punkt "Java saugt ohne IDE" ist ziemlich theoretisch ;)
Wolfgang Rostek
Ich bin durchaus offen und würde mal gerne
ein Projekt mit z.B. Ruby machen. Ist
natürlich was anderes, als ein Buch darüber
zu lesen. Vielleicht rede ich nachher anders.
>
> > Wenn auch nicht die ultimative Sprache, so ist Java doch
> > durch vieles im Umfeld sehr produktiv. 'Rauschen' ordne ich
> > stark dem Begriff 'unproduktiv' zu. Das sehe ich nicht so.
>
> ich schon ;) Allerdings wird der Produktivitätsverlust durch die IDEs
> meist wieder ausgeglichen. Daher sprechen viele auch von einer
> IDE-getrieben Sprache, denn ohne IDE ist Java oft grausam anzusehen oder
> zu schreiben.
>
IDEs finde ich jetzt auch nicht mehr so schlimm,
wie vor zehn Jahren. Sie sind offen,
zwingen einem nicht allzu viel auf. Sind doch
in erster Linie ein schlauer Editor/Browser, der
die Sprache gut versteht. Ich möchte nicht
mehr mit vi und irgend einer Sprache arbeiten.
Wir benutzten aber z.B. weder Ant, noch die
Subversion Anbindung in Eclipse. Das
machen Zehnzeiler in Unix auch ganz gut.
Ja, lästig sind die Ausdrucke. Hier könnte
natürlich eine ausdrucksstärkere Sprache
helfen. Aber Klassen browsen?
Gruß
Wolfgang R.
Jochen Theodorou
> Jochen Theodorou wrote:
>> ich schon ;) Allerdings wird der Produktivit�tsverlust durch die IDEs
>> meist wieder ausgeglichen. Daher sprechen viele auch von einer
>> IDE-getrieben Sprache, denn ohne IDE ist Java oft grausam anzusehen
>> oder zu schreiben.
>
> HTML ist als Plaintext auch grausam anzusehen. Und ?
aber bei HTML ist nicht so sehr der Source als viel mehr das was im
Browser angezeigt wird wichtig. Ausserdem hat HTML alleine nicht
wirklich irgendwelche Konrollstrukturen... Kurzum es ist eine
beschreibungssprache und als solche etwas v�llig anderes als eine
allgemeine Programmiersprache. Ich sehe XML zum Beipsiel auch nicht als
etwas dass f�r den menschlichen Leser bestimmt ist, sondern ich
bezeichne das als "cross machine language", kurz XML eben ;) Zudem habe
ich bei HTML oft nur eine Datei, die ich betrachte.... bei Java hast du
nur selten eine Klasse.
> Wer im Jahre 2008 noch ohne IDE coded, ist imo entweder Totalamateur
> oder so veraltet dass er vermutlich sowieso nur ANSI-C beherrscht. Oder
> Assembler.Das heisst nicht das man in ruby weniger produktiv
ehm... finde ich jetzt nicht... man sollte sich eher fragen warum man
die IDE �berhaupt braucht und f�r was man die eigentlich braucht. Und
dann sollte man sich mal umschauen ob es nicht auch besser geht. Ich
behaupte ja nicht, dass man wenn man Ruby benutzt nicht auch irgendwann
eine IDE gut brauchen kann... Nur h�ngt das mit einer bestimmten Menge
an Code zusammen und die erreicht man bei Java schneller als bei zum
Beispiel Ruby. Schneller nicht im Sinne von Produktivit�t, sondern man
braucht einfach mehr Code um ein Problem zu l�sen. Und es ist eben nicht
so, dass man einfach alles "�berfl�ssige" ignorieren kann. Denn es ist
ja nicht wirklich �berfl�ssig. Wenn es das w�re hat es nichts in der
Sprache zu suchen... es sei denn man will Programmierer qu�len ;)
> Gegen Java zu argumentieren, weil es ohne IDE grausig ist, ist wie zu
> sagen "XML mag ich nicht, das sieht im Texteditor so komisch aus". Weder
> XML noch Java sind fuer notepad.exe gedacht bzw. geeignet.
es gibt Leute die Argumentieren f�r Smalltalk gerade wegen der IDE. Aber
da ist die IDE indirekt Teil der Sprache und in das System integriert.
Da bedeutet auch "seine" IDE zu benutzen, dass man von speziell
angepassten Code spricht... nunja, ich will das jetzt nicht auswalzen.
Ich habe auch nie behauptet dass ich Java nicht oder XML nicht mag. Es
kommt aber darauf an f�r welche Zielgruppe diese Sachen eigentlich
gedacht sind. Und XML ist eben ein generisches Datenaustauschformat,
nicht unbedingt etwas indem man ohne spezialisierten Editor arbeitet.
Ich habe Java als IDE-driven bezeichnet, weil es ohne IDE grausam ist.
Dass heisst nicht das ich Java deswegen nicht mag. Ich sehe es
allerdings f�r eine textbasierte Programmiersprache als Nachteil an,
wenn sie aufgrund der "Umst�ndlichkeit" der Sprache ohne IDE kaum
nutzbar ist. Bei auf Grafiken basierenden Sprachen kommt man ohne IDE ja
nicht aus... wenn man da �berhaupt von Sprache reden kann. Und ich sehe
es durchaus als Vorteil wenn ich eine Sprache auch ohne komplexe IDE
benutzen kann. Ich weiss Java f�r viele Dinge zu sch�tzen, aber wenn es
um Rauschen in der Sprache geht, kenne ich nur Ada das Java noch
schlagen kann. Aber auch der Grund f�r so viel Rauschen in Java ist mir
klar, denn damals wollte man keinen komplexen Parser haben. Man wollte
das andere einen Parser leicht schreiben k�nnen. Ruby ist zum Beispiel
ziemlich grausam, wenn du daf�r einen Parser schreiben willst. Aber bei
Ruby war nicht der Parser der Fokus, sondern der Programmierer. Und der
will oft Dinge die ein Mensch leicht versteht, ein Parser aber nicht.
> Ich erwarte jetzt auch nicht wirklich, dass eine IDE-Kriese aufkommt und
> wir in 2009 wieder zum Texteditor wechseln muessen, also finde ich, der
> Punkt "Java saugt ohne IDE" ist ziemlich theoretisch ;)
Die Krise ist schon l�ngst da, weil man solche Monster-IDEs �berhaupt
braucht. Man muss auch akzeptieren dass sich Java nicht sonderlich gut
f�r manche Dinge eignet... dazu geh�rt zum Beispiel
Multicoreprogrammierung (und ich meine mehr als 10 Kerne). Sicher... man
kann einen Weg finden. Er wird komplex sein und man wird das eigentliche
Programm nicht mehr erkennen k�nnen, aber man wird schon einen Weg
finden. Wenn ich dann daran denke was zum Beispiel die Leute bei
Fortress machen wollen, dann sind da Welten dazwischen. Java ist eben
nicht immer das richtige Tool... eine IDE kann versuchen diesen Umstand
zu verstecken, aber letztlich kann dass dann nur durch eine gewisse Art
von Anzeigesprache geschehen. Also eine Sprache, die in komprimierter
Form zeigt, was die unkomprimierte Form machen w�rde... Letztlich ist
das aber eine neue Sprache, auch wenn sie auf Java basiert und 1:1
umgesetzt werden kann.
Wenn man sich in "alternativen" Kreisen bewegt lernt man vor allem:
Nicht alle Programmierer werden deine Auffassung teilen, auch wenn deine
Argumente noch so stichhaltig sind. Und: Viele werden sich pers�nlich
oder ihre Lieblingssprache angegriffen sehen, dich als jemanden
bezeichnen der alles schlecht machen will (oder schlimmeres), auch wenn
es daf�r keinen objektiven Grund gibt.
Das ist keineswegs speziell f�r Java so. Fang mal in einer Rubygruppe
damit an wie toll du Java findest und ein flamewar ist praktisch garantiert.
Ich will auch nicht sagen X ist besser als Y. Insbesondere Groovy habe
ich nie als Sprache gesehen die Java abl�sen will, sondern die mit Java
zusammenarbeiten will. Allerdings sollte man auch in der Lage sein mal
zu versuchen logisch argumentierend zu Diskutieren und mal in Kauf
nehmen dass die Lieblingssprache Nachteile hat und dass es andere besser
k�nnen. Wenn Java perfekt w�re, dann br�uchte man die Sprache nicht mehr
weiterentwickeln und sowas �hnliches wie Closures hinzuf�gen... die
meisten JSRs w�ren dann unn�tig... nicht alle, weil manche sich auch mit
der JVM besch�ftigen. Das bei Java mehr als nur die API diskutiert wird,
d�rfte aber auf der Hand liegen, oder?
Gruss theo
Jochen Theodorou
> ...
> Ich bin durchaus offen und w�rde mal gerne
> ein Projekt mit z.B. Ruby machen. Ist
> zu lesen.
kann ich sehr empfehlen.
> Vielleicht rede ich nachher anders.
die Chancen stehen gut... allerdings muss ich dich auch warnen... wenn
man erst mal einen Blick daf�r bekommen hat wie es besser gehen k�nnte,
dann macht Java deutlich weniger Spa�.
>>> Wenn auch nicht die ultimative Sprache, so ist Java doch
>>> durch vieles im Umfeld sehr produktiv. 'Rauschen' ordne ich
>>> stark dem Begriff 'unproduktiv' zu. Das sehe ich nicht so.
>> ich schon ;) Allerdings wird der Produktivit�tsverlust durch die IDEs
>> meist wieder ausgeglichen. Daher sprechen viele auch von einer
>> IDE-getrieben Sprache, denn ohne IDE ist Java oft grausam anzusehen oder
>> zu schreiben.
>>
> IDEs finde ich jetzt auch nicht mehr so schlimm,
> wie vor zehn Jahren.
Nunja, was sich als IDE definiert hat sich ja auch weiterentwickelt.
Fr�her war eine IDE oft schon etwas dass dir Syntaxhighliting gab und
dir erlaubt Programme direkt aus dem Editor heraus auszuf�hren. Heute
geht ohne Klassenbrowser, integriertem Debugger, Refactoringtools, sowie
Codenavigation eigentlich nichts mehr.
> Sie sind offen,
NetBeans und Eclipse sind offen... IntelliJ IDEA zum Beispiel nicht.
> zwingen einem nicht allzu viel auf.
du redest nicht vom Speicherverbrauch nehme ich an ;)
> Sind doch
> in erster Linie ein schlauer Editor/Browser, der
> die Sprache gut versteht. Ich m�chte nicht
> mehr mit vi und irgend einer Sprache arbeiten.
f�r den xemacs gibt es auch einen Klassenbrowser, ich glaube auch einen
integrierten Debugger, wenn man so will. Refactoringtools fehlen glaube
ich, dass hindert es daran ein IDE f�r Java zu sein. Andererseits...
http://www.xref-tech.com/speller/main.html es geht also schon ;) Ok, wo
ist das VI-Lager? bitte mal was vergleichbares pr�sentieren! Ahem... ok,
lassen wir das lieber, ich habe schon genug Potential f�r einen flamewar
eingestreut ;)
> Wir benutzten aber z.B. weder Ant, noch die
> Subversion Anbindung in Eclipse. Das
> machen Zehnzeiler in Unix auch ganz gut.
ich benutze recht oft meld diff, weil ich mir dann meine �nderungen
nochmal anschauen kann und weil ich dann nicht auf die richtige
Funktionsweise des IDE Plugins angewiesen bin... die nicht immer gegeben
ist. Ant benutze ich privat selten. Allerdings macht es f�r einen
komplexeren build schon Sinn.. Groovy produziert zum Beipsiel mehrere
Jars, mit eingebetteten jars, mit einem compiler der zur Laufzeit
erstmal kompiliert werden muss, mit Manifesterweiterungen f�r OSGI usw...
> Ja, l�stig sind die Ausdrucke. Hier k�nnte
> nat�rlich eine ausdrucksst�rkere Sprache
> helfen. Aber Klassen browsen?
es kommt auch darauf an wie viele Klassen du brauchst und wie viel Logik
diese enthalten. Bei
class X {
String foo
int bar
}
sehe ich auf einen Blick, dass da praktisch keine Logik drin steckt,
sich also um ein POJO handelt.. und selbst wenn es 20 Properties werden
�ndert sich das nicht wesentlich. In Java hast du leicht 40 Methoden
zus�tzlich und 120 Zeilen code mehr
Gruss theo
J. Stoever
> J. Stoever schrieb:
>> HTML ist als Plaintext auch grausam anzusehen. Und ?
> aber bei HTML ist nicht so sehr der Source als viel mehr das was im
> Browser angezeigt wird wichtig. Ausserdem hat HTML alleine nicht
Und Java wird in der IDE angezeigt ;)
> wirklich irgendwelche Konrollstrukturen... Kurzum es ist eine
> beschreibungssprache und als solche etwas v�llig anderes als eine
> allgemeine Programmiersprache. Ich sehe XML zum Beipsiel auch nicht als
> etwas dass f�r den menschlichen Leser bestimmt ist, sondern ich
> bezeichne das als "cross machine language", kurz XML eben ;) Zudem habe
> ich bei HTML oft nur eine Datei, die ich betrachte.... bei Java hast du
> nur selten eine Klasse.
Klar, das sind ganz grundverschiedene Dinger. Ich wollte damit auch nur
den Punkt machen, dass es nicht viel Sinn macht, Sachen aus einer
unrealistischen Perspektive zu betrachten.
>> Wer im Jahre 2008 noch ohne IDE coded, ist imo entweder Totalamateur
>> oder so veraltet dass er vermutlich sowieso nur ANSI-C beherrscht.
>> Oder Assembler.Das heisst nicht das man in ruby weniger produktiv
> ehm... finde ich jetzt nicht... man sollte sich eher fragen warum man
> die IDE �berhaupt braucht und f�r was man die eigentlich braucht. Und
Warum ? Ich finde, eine interessantere Frage ist, warum man ueberhaupt
gegen eine IDE ist. Ich sehe jetzt so spontan keine Nachteile (*) die es
mir wuenschenswert zu erscheinen lassen, mich von IDEs zu distanzieren.
> dann sollte man sich mal umschauen ob es nicht auch besser geht. Ich
> behaupte ja nicht, dass man wenn man Ruby benutzt nicht auch irgendwann
> eine IDE gut brauchen kann... Nur h�ngt das mit einer bestimmten Menge
> an Code zusammen und die erreicht man bei Java schneller als bei zum
> Beispiel Ruby. Schneller nicht im Sinne von Produktivit�t, sondern man
Java ist ja nun auch generell fuer andere Probleme geeignet als andere
Sprachen. Wenn man ein schnelles kleines 5-Zeilen-Script basteln will,
braucht man natuerlich auch keine IDE, aber dann waer' es auch
normalerweise nicht sehr sinnvoll, Java dafuer einzusetzen. Ich wuerde
mal, ganz pauschal jetzt, und in diesem Zusammenhang, sagen, dass sich
Java eher fuer groessere Projekte eignet. Und fuer die ist dann eine IDE
sowieso angebracht, egal welche Sprache.
> es gibt Leute die Argumentieren f�r Smalltalk gerade wegen der IDE. Aber
> da ist die IDE indirekt Teil der Sprache und in das System integriert.
> Da bedeutet auch "seine" IDE zu benutzen, dass man von speziell
> angepassten Code spricht... nunja, ich will das jetzt nicht auswalzen.
Ja, natuerlich. Sprachen waren schon immer (naja, fast) eng mit den IDEs
verbunden. Man denke da nur an das alte Turbo Pascal mit der Borland
IDE, oder an die diversen Microsoft-Produkte. Das ist eben bei manchen
so, sehe ich jetzt aber nicht wirklich als problematisch.
> Ich habe auch nie behauptet dass ich Java nicht oder XML nicht mag.
Schon klar, das war eine rein rhetorische Aussage, um die Kritik zu
polarisieren.
> Ich habe Java als IDE-driven bezeichnet, weil es ohne IDE grausam ist.
> Dass heisst nicht das ich Java deswegen nicht mag. Ich sehe es
> allerdings f�r eine textbasierte Programmiersprache als Nachteil an,
> wenn sie aufgrund der "Umst�ndlichkeit" der Sprache ohne IDE kaum
> nutzbar ist. Bei auf Grafiken basierenden Sprachen kommt man ohne IDE ja
Warum ? Dafuer muesstest Du mir, wie gesagt, erklaeren, warum es Dir
wuenschenswert erscheint, Java ohne IDE zu nutzen.
> Die Krise ist schon l�ngst da, weil man solche Monster-IDEs �berhaupt
> braucht. Man muss auch akzeptieren dass sich Java nicht sonderlich gut
> f�r manche Dinge eignet... dazu geh�rt zum Beispiel
> Multicoreprogrammierung (und ich meine mehr als 10 Kerne). Sicher... man
Wirklich ? Wieso ? Ich kenn' mich mit solchen Groessenordnungen gar
nicht aus, wuerde mich aber trotzdem interessieren.
> Also eine Sprache, die in komprimierter
> Form zeigt, was die unkomprimierte Form machen w�rde... Letztlich ist
> das aber eine neue Sprache, auch wenn sie auf Java basiert und 1:1
> umgesetzt werden kann.
Waer' dann halt ein weiterer Abstraktionslevel.
> Wenn man sich in "alternativen" Kreisen bewegt lernt man vor allem:
> Nicht alle Programmierer werden deine Auffassung teilen, auch wenn deine
> Argumente noch so stichhaltig sind. Und: Viele werden sich pers�nlich
> oder ihre Lieblingssprache angegriffen sehen, dich als jemanden
> bezeichnen der alles schlecht machen will (oder schlimmeres), auch wenn
> es daf�r keinen objektiven Grund gibt.
Ja, natuerlich. Nichts koennen Programmierer besser, als sich ueber
Nichtigkeiten streiten, am besten jahrelang ;)
> Das ist keineswegs speziell f�r Java so. Fang mal in einer Rubygruppe
> damit an wie toll du Java findest und ein flamewar ist praktisch
> garantiert.
Meine Jugend hab' ich mit C vs Pascal und Windows vs DOS verschwendet ;)
> Ich will auch nicht sagen X ist besser als Y. Insbesondere Groovy habe
> ich nie als Sprache gesehen die Java abl�sen will, sondern die mit Java
> zusammenarbeiten will. Allerdings sollte man auch in der Lage sein mal
> zu versuchen logisch argumentierend zu Diskutieren und mal in Kauf
> nehmen dass die Lieblingssprache Nachteile hat und dass es andere besser
> k�nnen.
Das "Problem" ist ja nicht wirklich ein Java-Problem. Wie Du selber
sagst, da gibt es durchaus noch ein paar mehr Sprachen die aehnlich laut
Rauschen. Aber wie gesagt sehe ich noch nicht, dass dieses "Problem"
wirklich eins ist, und nicht einfach eine (neutrale) Eigenschaft.
*: Natuerlich gibt es Nachteile bei vielen IDEs, aber das sind alles
Sachen, die nicht inherent mit IDEs verbunden sind, sondern nur
spezifische Probleme, die man loesen koennte, ohne auf eine IDE zu
verzichten (z.B. Feature overload und aehnliches).
s.ra...@googlemail.com
> class X {
> String foo
> int bar
>
> }
>
> sehe ich auf einen Blick, dass da praktisch keine Logik drin steckt,
> sich also um ein POJO handelt
DTO oder VO, nicht POJO.
Jochen Theodorou
> Jochen Theodorou wrote:
>> J. Stoever schrieb:
>>> HTML ist als Plaintext auch grausam anzusehen. Und ?
>> aber bei HTML ist nicht so sehr der Source als viel mehr das was im
>> Browser angezeigt wird wichtig. Ausserdem hat HTML alleine nicht
>
> Und Java wird in der IDE angezeigt ;)
also stimmst du mir zu dass Java ohne IDE schlecht nutzbar ist?
>> wirklich irgendwelche Konrollstrukturen... Kurzum es ist eine
>> beschreibungssprache und als solche etwas v�llig anderes als eine
>> allgemeine Programmiersprache. Ich sehe XML zum Beipsiel auch nicht
>> als etwas dass f�r den menschlichen Leser bestimmt ist, sondern ich
>> bezeichne das als "cross machine language", kurz XML eben ;) Zudem
>> habe ich bei HTML oft nur eine Datei, die ich betrachte.... bei Java
>> hast du nur selten eine Klasse.
>
> Klar, das sind ganz grundverschiedene Dinger. Ich wollte damit auch nur
> den Punkt machen, dass es nicht viel Sinn macht, Sachen aus einer
> unrealistischen Perspektive zu betrachten.
das ist schon witzig finde ich... ich meine eine Sprache, die in einer
Zeit entworfen wurde in der es die heutigen IDEs noch nicht gab....
welche Perspektive hatten denn die Leute, die Java entworfen haben?
Najagut, das muss ja nicht unbedingt eine realistische sein. Aber gehe
ich recht in der Annahme dass du dann sagst, dass Java erst durch eine
IDE "richtig gut" wird?... also durch ein Element das weder Teil der
Sprache, noch der Laufzeitumgebung oder der API ist? Weisst fr�her hat
man von Sprache gesprochen und die Sprache gemeint, nicht die API, nicht
die IDE, es sei denn es war von Anfang an als komplettes Konstrukt gedacht.
>>> Wer im Jahre 2008 noch ohne IDE coded, ist imo entweder Totalamateur
>>> oder so veraltet dass er vermutlich sowieso nur ANSI-C beherrscht.
>>> Oder Assembler.Das heisst nicht das man in ruby weniger produktiv
>> ehm... finde ich jetzt nicht... man sollte sich eher fragen warum man
>> die IDE �berhaupt braucht und f�r was man die eigentlich braucht. Und
>
> Warum ?
Warum nicht? Nenne es Erforschung des Selbst ;)
> Ich finde, eine interessantere Frage ist, warum man ueberhaupt
> gegen eine IDE ist. Ich sehe jetzt so spontan keine Nachteile (*) die es
> mir wuenschenswert zu erscheinen lassen, mich von IDEs zu distanzieren.
ich ornde mal ein (*) hier ein, weil es bem Zitieren sonst so schwer wird:
> *: Natuerlich gibt es Nachteile bei vielen IDEs, aber das sind alles
> Sachen, die nicht inherent mit IDEs verbunden sind, sondern nur
> spezifische Probleme, die man loesen koennte, ohne auf eine IDE zu
> verzichten (z.B. Feature overload und aehnliches).
Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
sondern sich einfach auf Codecompletion verl�sst und dabei Hilfsklassen
vollkommen ignoriert, abgesehen davon dass man sich st�ndig
irgendwelchen Code generieren l�sst, abgesehen davon dass die meisten
IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter 2GB und was
weiss ich wie viel permgen) was Speicher und CPU-Last betrifft,
abgesehen davon dass die meisten IDEs v�llig �berladen sind mit
features, die niemand braucht, abgesehen davon dass ich ewig warten muss
bis die IDE hochgefahren ist wo ich doch nur eine Zeile kurz �ndern
wollte, abgesehen davon dass viele keine build skripte irgendeiner Art
machen, abgesehen davon dass die meisten IDEs in der Bedienung nicht
sonderlich einheitlich sind, abgesehen davon dass eine IDE ein
ausdrucksschwache Sprache auch nicht wirklich verbessern kann, abgesehen
davon dass fehlende Konzepte nciht einfach durch die IDE erg�nzt werden
k�nnen...
nein.. ich habe nicht wirklich etwas gegen IDEs, nur das man so gro�e
IDEs braucht um wirklich was mit der Sprache anfangen zu k�nnen... ja,
gegen diese Kombination habe ich etwas.
>> dann sollte man sich mal umschauen ob es nicht auch besser geht. Ich
>> behaupte ja nicht, dass man wenn man Ruby benutzt nicht auch
>> irgendwann eine IDE gut brauchen kann... Nur h�ngt das mit einer
>> bestimmten Menge an Code zusammen und die erreicht man bei Java
>> schneller als bei zum Beispiel Ruby. Schneller nicht im Sinne von
>> Produktivit�t, sondern man
>
> Java ist ja nun auch generell fuer andere Probleme geeignet als andere
> Sprachen.
Also das ist mir jetzt ein wenig zu allgemein.
> Wenn man ein schnelles kleines 5-Zeilen-Script basteln will,
> braucht man natuerlich auch keine IDE, aber dann waer' es auch
> normalerweise nicht sehr sinnvoll, Java dafuer einzusetzen.
Ach? passiert aber oft genug
> Ich wuerde
> mal, ganz pauschal jetzt, und in diesem Zusammenhang, sagen, dass sich
> Java eher fuer groessere Projekte eignet. Und fuer die ist dann eine IDE
> sowieso angebracht, egal welche Sprache.
wie gesagt, das orientiert sich IMHO an der Codegr�sse und in einer
ausdrucksst�rkeren Sprache kann man das gleiche in mit weniger Code
ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE in
Java fr�her als in zum Beispiel Ruby.
>> es gibt Leute die Argumentieren f�r Smalltalk gerade wegen der IDE.
>> Aber da ist die IDE indirekt Teil der Sprache und in das System
>> integriert. Da bedeutet auch "seine" IDE zu benutzen, dass man von
>> speziell angepassten Code spricht... nunja, ich will das jetzt nicht
>> auswalzen.
>
> Ja, natuerlich. Sprachen waren schon immer (naja, fast) eng mit den IDEs
> verbunden. Man denke da nur an das alte Turbo Pascal mit der Borland
> IDE, oder an die diversen Microsoft-Produkte. Das ist eben bei manchen
> so, sehe ich jetzt aber nicht wirklich als problematisch.
wenn dann die Sprache steht und f�llt mit der IDE sehe ich das durchaus
als problematisch....konsequenterweise m�sste man ja dann sagen, dass
Java f�r gr��ere Projekte nicht geeignet war in den ersten Jahren.
[...]
>> Ich habe Java als IDE-driven bezeichnet, weil es ohne IDE grausam ist.
>> Dass heisst nicht das ich Java deswegen nicht mag. Ich sehe es
>> allerdings f�r eine textbasierte Programmiersprache als Nachteil an,
>> wenn sie aufgrund der "Umst�ndlichkeit" der Sprache ohne IDE kaum
>> nutzbar ist. Bei auf Grafiken basierenden Sprachen kommt man ohne IDE ja
>
> Warum ? Dafuer muesstest Du mir, wie gesagt, erklaeren, warum es Dir
> wuenschenswert erscheint, Java ohne IDE zu nutzen.
vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
wurde? Es sind eben viele kleine Sache, die dazu beitragen, nicht eine
spezielle Sache. Ich finde es zum Beispiel durchaus nervig fast 5
Minuten warten zu m�ssen bis ich in meiner IDE eine Datei �ndern kann...
wenn ich die IDE denn �berhaupt hochfahren kann... mir ist vielleicht
gerade der Speicher ausgegangen. Sowas wie Gedit braucht nicht viel
Speicher und geht eigentlich immer
>> Die Krise ist schon l�ngst da, weil man solche Monster-IDEs �berhaupt
>> braucht. Man muss auch akzeptieren dass sich Java nicht sonderlich gut
>> f�r manche Dinge eignet... dazu geh�rt zum Beispiel
>> Multicoreprogrammierung (und ich meine mehr als 10 Kerne). Sicher... man
>
> Wirklich ? Wieso ? Ich kenn' mich mit solchen Groessenordnungen gar
> nicht aus, wuerde mich aber trotzdem interessieren.
nunja, �berlege dir mal eine Berechnung die sich gut aufteilen l�sst und
dann stell dir vor du wolltest das auf 10Threads verteilen.. wie machst
du das? Und dann �berlege dir mal eine Berechnung, die sich weniger gut
aufteilen l�sst und tr�ume mal davon wie sch�n es w�re wenn deine
Sprache das aufteilen f�r dich vollautomtisch erledigen w�rde.
>> Also eine Sprache, die in komprimierter Form zeigt, was die
>> unkomprimierte Form machen w�rde... Letztlich ist das aber eine neue
>> Sprache, auch wenn sie auf Java basiert und 1:1 umgesetzt werden kann.
>
> Waer' dann halt ein weiterer Abstraktionslevel.
Oder in anderen Worten ein Hochsprache zur Hochsprache ;) Nenn' es ruhig
Level, ich nenne es Sprache.... bzw. *neue* Sprache.. was impliziert
dass die alte nicht ausreichend ist in einem bestimmten Aspekt.
>> Wenn man sich in "alternativen" Kreisen bewegt lernt man vor allem:
>> Nicht alle Programmierer werden deine Auffassung teilen, auch wenn
>> deine Argumente noch so stichhaltig sind. Und: Viele werden sich
>> pers�nlich oder ihre Lieblingssprache angegriffen sehen, dich als
>> jemanden bezeichnen der alles schlecht machen will (oder schlimmeres),
>> auch wenn es daf�r keinen objektiven Grund gibt.
>
> Ja, natuerlich. Nichts koennen Programmierer besser, als sich ueber
> Nichtigkeiten streiten, am besten jahrelang ;)
stimmt
>> Das ist keineswegs speziell f�r Java so. Fang mal in einer Rubygruppe
>> damit an wie toll du Java findest und ein flamewar ist praktisch
>> garantiert.
>
> Meine Jugend hab' ich mit C vs Pascal und Windows vs DOS verschwendet ;)
Windows vs DOS? echt? Habe ich noch nie mitbekommen so eine Diskussion.
>> Ich will auch nicht sagen X ist besser als Y. Insbesondere Groovy habe
>> ich nie als Sprache gesehen die Java abl�sen will, sondern die mit
>> Java zusammenarbeiten will. Allerdings sollte man auch in der Lage
>> sein mal zu versuchen logisch argumentierend zu Diskutieren und mal in
>> Kauf nehmen dass die Lieblingssprache Nachteile hat und dass es andere
>> besser k�nnen.
>
> Das "Problem" ist ja nicht wirklich ein Java-Problem. Wie Du selber
> sagst, da gibt es durchaus noch ein paar mehr Sprachen die aehnlich laut
> Rauschen. Aber wie gesagt sehe ich noch nicht, dass dieses "Problem"
> wirklich eins ist, und nicht einfach eine (neutrale) Eigenschaft.
naja, wie neutral kann es denn sein, wenn manche Sprachen das Problem
haben und manche nicht? Oder wenn der Grad des Rauschen so
unterschiedlich ist? Das Rauschen selbst ist erstmal kein Problem. Wenn
du den Fernseher einschaltest und siehst wei�es Rauschen, dann ist das
auch erstmal kein Problem... wenn du allerdings ein Fernsehprogramm
anschauen wolltest und dich nicht vom Rauschen hypnotisieren lassen
wolltest, dann ist es ein Problem. Rauschen in der Programmiersprache
verdeckt den Blick auf das, was wirklich wichtig ist. Nicht wenige
fangen ein Programm an, indem sie erstmal all das "drum-herum"
schreiben. Zum Beispiel kenne ich jemanden, der Groovy benutzt hat um
einen Bildbearbeitungsalgorithmus zu entwickeln. Ziel war es dabei nicht
besonders schnell zu sein, sondern den Algorithmus leicht anpassen zu
k�nnen und sich nicht vom Rauschen ablenken zu lassen. Nachdem er mit
dem Ergebnis zufrieden war, hat er den Algorithmus nach Java portiert um
die notwendige Geschwindigkeit zu bekommen. Nach seinen Aussagen h�tte
er in Java wahrscheinlich doppelt so lange gebraucht.. was ich nat�rlich
nicht selbst beurteilen kann.
Ich will jetzt auch nicht behaupten, dass es sich lohnt ein grosses
existierendes Projekt von heute auf morgen nach Groovy um zu stellen...
andererseits muss das ja so auch nicht gemacht werden ;)
Gruss theo
Jochen Theodorou
ich hatte eine strengere Version als
http://de.wikipedia.org/wiki/Plain_Old_Java_Object im Sinn. Ich habe das
fr�her immer eine Datenklasse genannt. Ansonsten eher DTO als VO, aber
in der Javacommunity werden die ja gleich behandelt.
Gruss theo
Michael Paap
> das ist schon witzig finde ich... ich meine eine Sprache, die in
> einer Zeit entworfen wurde in der es die heutigen IDEs noch nicht
> gab.... welche Perspektive hatten denn die Leute, die Java entworfen
> haben? Najagut, das muss ja nicht unbedingt eine realistische sein.
Vielleicht hatten die ja die Perspektive, dass ihr Zeug ansonsten genug
Durchsetzungsverm�gen hat, so dass schon jemand gute IDEs entwickeln
wird, wenn der Bedarf entsteht. Hat geklappt. ;-)
> Aber gehe ich recht in der Annahme dass du dann sagst, dass Java erst
> durch eine IDE "richtig gut" wird?... also durch ein Element das
> weder Teil der Sprache, noch der Laufzeitumgebung oder der API ist?
Dieser Aussage wird heute wohl kaum noch jemand widersprechen.
Gegenfrage: Welche Perspektive haben denn Leute, die heute Sprachen
entwerfen, f�r die es derart m�chtige Werkzeuge *nicht* gibt? Die bindet
man dann an die Java-API an, gell? *g*
> Weisst fr�her hat man von Sprache gesprochen und die Sprache gemeint,
> nicht die API, nicht die IDE, es sei denn es war von Anfang an als
> komplettes Konstrukt gedacht.
Wann ist denn "fr�her"? Fr�her gab es z.B. Smalltalk. Von vornherein als
Sprache mit API und IDE und noch einigem mehr gedacht. Und ganz nebenbei
der Vorfahr des ganzen OO-Ged�nsens.
> Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
> sondern sich einfach auf Codecompletion verl�sst und dabei
> Hilfsklassen vollkommen ignoriert, abgesehen davon dass man sich
> st�ndig irgendwelchen Code generieren l�sst,
Das ist durch nichts belegte Greuelpropaganda, mehr nicht. Richtig ist,
dass jemand, der hinreichend stumpf drauf ist, es mit der IDE leichter
hat, trotzdem zu programmieren. Aber wer beim Programmieren denkt, der
wird auch durch die IDE nicht damit aufh�ren.
> abgesehen davon dass die
> meisten IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter
> 2GB und was weiss ich wie viel permgen)
Komisch... bei mir ist das so nicht. Ich hab gar keine 2 GB.
> abgesehen davon dass die meisten IDEs v�llig �berladen sind
> mit features, die niemand braucht,
... der nicht genug Erfahrungen mit der betreffenden IDE gesammelt hat.
> abgesehen davon dass ich ewig
> warten muss bis die IDE hochgefahren ist wo ich doch nur eine Zeile
> kurz �ndern wollte,
Die Realit�t professionellen Programmierens sieht meist ein bisschen
anders aus, oder? Und um mal eben eine Zeile zu �ndern, reicht auch bei
Java ein Texteditor. Oder hat sich das seit gestern ge�ndert, als ich
das zuletzt - mit vi - gemacht habe?
> abgesehen davon dass viele keine build skripte
> irgendeiner Art machen,
Verwende doch einfach eine IDE, die tut, was du brauchst. Es gibt ja
immerhin drei bis vier gro�e ausgewachsene und ein paar Hundert Plugins.
> nein.. ich habe nicht wirklich etwas gegen IDEs, nur das man so gro�e
> IDEs braucht um wirklich was mit der Sprache anfangen zu k�nnen...
> ja, gegen diese Kombination habe ich etwas.
Ich hab was gegen Propaganda von Fans wovon auch immer. Und dein Posting
liest sich leider sehr nach Fan-Tum.
> wie gesagt, das orientiert sich IMHO an der Codegr�sse und in einer
> ausdrucksst�rkeren Sprache kann man das gleiche in mit weniger Code
> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
> erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE
> in Java fr�her als in zum Beispiel Ruby.
Und? Wenn man aufh�rt, eine IDE (getrieben von der Tatsache, dass es f�r
die eigene Lieblingssprache nichts Vern�nftigess gibt) als Nachteil
betrachten zu wollen, ist das doch gar nicht schlimm.
> wenn dann die Sprache steht und f�llt mit der IDE sehe ich das
> durchaus als problematisch....konsequenterweise m�sste man ja dann
> sagen, dass Java f�r gr��ere Projekte nicht geeignet war in den
> ersten Jahren.
Das mag durchaus so sein, ja. Oder nur unter Schmerzen. Und? Wen
interessiert das denn noch?
> vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
> Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
> wurde?
Es gibt da ausgereifte Werkzeuge...
> Es sind eben viele kleine Sache, die dazu beitragen, nicht
> eine spezielle Sache. Ich finde es zum Beispiel durchaus nervig fast
> 5 Minuten warten zu m�ssen bis ich in meiner IDE eine Datei �ndern
> kann... wenn ich die IDE denn �berhaupt hochfahren kann... mir ist
> vielleicht gerade der Speicher ausgegangen. Sowas wie Gedit braucht
> nicht viel Speicher und geht eigentlich immer
Und kann bei Java problemlos verwendet werden, um deine st�ndig
beschworene eine Zeile zu �ndern. Aber ich z.B. starte die IDE einmal am
Tag.
> Ich will jetzt auch nicht behaupten, dass es sich lohnt ein grosses
> existierendes Projekt von heute auf morgen nach Groovy um zu
> stellen... andererseits muss das ja so auch nicht gemacht werden ;)
Was ich mich die ganze Zeit frage: Wenn Java *so* furchtbar ist - und
mir sind die Nachteile durchaus bewusst - warum wird dann eigentlich
ausgerechnet die Anbindung an Java und die Nutzung der Java-API immer so
sehr als Feature von Groovy herausgestellt?
Spielt wom�glich die vorhandene Java-API f�r Groovy die Rolle, welche
die Existenz guter IDEs f�r heutiges Java spielt? *g*
Gru�,
Michael
Michael Paap
> Allerdings sollte man auch in der Lage sein mal
> zu versuchen logisch argumentierend zu Diskutieren und mal in Kauf
> nehmen dass die Lieblingssprache Nachteile hat und dass es andere besser
> k�nnen.
Ja. Aber dazu geh�rt auch, sich auf die real existierenden Nachteile von
Java zu beschr�nken - von denen es nun wahrlich genug gibt - und nicht
welche an die Wand zu malen, die f�r 99% der professionellen Verwender
v�llig irrelevant sind.
Von "Lieblingssprachen" halte ich eh wenig, das riecht mir zu sehr nach
"Lieblingsband" und "Mein Fussballverein". Leute, die in diesen Bahnen
denken, sind Fans. Mit Fans zu diskutieren, ist meist ebenso anstrengend
wie sinnfrei.
> Wenn Java perfekt w�re, dann br�uchte man die Sprache nicht mehr
> weiterentwickeln und sowas �hnliches wie Closures hinzuf�gen...
Davon wird imho auch nichts besser werden, ganz im Gegenteil.
Gru�,
Michael
J. Stoever
> J. Stoever schrieb:
>> Jochen Theodorou wrote:
>>> J. Stoever schrieb:
>>>> HTML ist als Plaintext auch grausam anzusehen. Und ?
>>> aber bei HTML ist nicht so sehr der Source als viel mehr das was im
>>> Browser angezeigt wird wichtig. Ausserdem hat HTML alleine nicht
>> Und Java wird in der IDE angezeigt ;)
> also stimmst du mir zu dass Java ohne IDE schlecht nutzbar ist?
Ja, wie gesagt, genau so wie HTML. Das sehe ich aber nicht als Nachteil,
weil genau so wie man HTML eben mit einem Browser anguckt, guckt man
Java eben mit 'ner IDE an. Java mit Notepad zu oeffnen, ist imo genau so
unsinnig, wie das selbe mit HTML oder XML zu machen.
>> Klar, das sind ganz grundverschiedene Dinger. Ich wollte damit auch
>> nur den Punkt machen, dass es nicht viel Sinn macht, Sachen aus einer
>> unrealistischen Perspektive zu betrachten.
> das ist schon witzig finde ich... ich meine eine Sprache, die in einer
> Zeit entworfen wurde in der es die heutigen IDEs noch nicht gab....
> welche Perspektive hatten denn die Leute, die Java entworfen haben?
Das weiss ich auch nicht. Hat damals vermutlich keiner gross drueber
nachgedacht.
> Najagut, das muss ja nicht unbedingt eine realistische sein. Aber gehe
> ich recht in der Annahme dass du dann sagst, dass Java erst durch eine
> IDE "richtig gut" wird?... also durch ein Element das weder Teil der
> Sprache, noch der Laufzeitumgebung oder der API ist? Weisst fr�her hat
> man von Sprache gesprochen und die Sprache gemeint, nicht die API, nicht
> die IDE, es sei denn es war von Anfang an als komplettes Konstrukt gedacht.
Tja, ist halt nicht mehr alles wie damals vor'm Krieg :p
Stimmt, Java ist ohne IDE nicht besonders gut. Ohne API auch nicht. Ohne
JVM/JIT auch nicht. Sind das jetzt alles negative Sachen ?
>>> ehm... finde ich jetzt nicht... man sollte sich eher fragen warum man
>>> die IDE �berhaupt braucht und f�r was man die eigentlich braucht. Und
>> Warum ?
> Warum nicht? Nenne es Erforschung des Selbst ;)
Solange man dann nicht in nach Schema "1. Fragen warum man IDE braucht,
2. ????, 3. Prof^H^H^H^H^H IDEs sind doof!" denkt, ist das ja auch ok.
>> Ich finde, eine interessantere Frage ist, warum man ueberhaupt gegen
>> eine IDE ist. Ich sehe jetzt so spontan keine Nachteile (*) die es mir
>> wuenschenswert zu erscheinen lassen, mich von IDEs zu distanzieren.
>> *: Natuerlich gibt es Nachteile bei vielen IDEs, aber das sind alles
>> Sachen, die nicht inherent mit IDEs verbunden sind, sondern nur
>> spezifische Probleme, die man loesen koennte, ohne auf eine IDE zu
>> verzichten (z.B. Feature overload und aehnliches).
> Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
> sondern sich einfach auf Codecompletion verl�sst und dabei Hilfsklassen
> vollkommen ignoriert,
Kannst Du das naeher erlaeutern ? Ich verstehe nicht genau, was Du damit
meinst.
Das Grundprinzip ist natuerlich klar - Sachen, die einem das Leben
leichter machen, verbloeden auch. Mit der Logik musst Du aber Java ganz
loeschen und direkt in Maschinencode schreiben. Sonst lernst Du ja die
Opcodes nicht mehr, verlaesst Dich auf Stackmanagement und ignoriest
Taktzyklen ;)
Mit dem Argument kannst Du eigentlich praktisch jede Neuerung und jede
Automatisierung als negativ darstellen. Das ist aber Unsinn. Nur weil
einige Anfaenger zu faul sind, richtig zu lernen, sollte ich nicht
benachteiligt werden.
> abgesehen davon dass man sich st�ndig
> irgendwelchen Code generieren l�sst,
Ist doch super, wenn man nicht selber tippseln muss. Laesst mehr Zeit
zum nachdenken. Was ist daran genau negativ ?
> abgesehen davon dass die meisten
> IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter 2GB und was
> weiss ich wie viel permgen) was Speicher und CPU-Last betrifft,
Spezifisches Problem von spezifischen IDEs. Nicht alle sind
featureueberladene Monster. Ist also nicht ein Problem von IDEs, sondern
ein Problem von bestimmten Produkten. Gibt auch kleine, schlanke IDEs.
> abgesehen davon dass die meisten IDEs v�llig �berladen sind mit
> features, die niemand braucht, abgesehen davon dass ich ewig warten muss
> bis die IDE hochgefahren ist wo ich doch nur eine Zeile kurz �ndern
> wollte, abgesehen davon dass viele keine build skripte irgendeiner Art
> machen, abgesehen davon dass die meisten IDEs in der Bedienung nicht
> sonderlich einheitlich sind,
Alles wie oben. Immer wenn Du "bei einigen" oder "die meisten" sagst,
sprichst Du ueber Probleme in der tatsaechlichen Software, nicht ueber
generelle Probleme die IDEs nun mal haben.
> abgesehen davon dass eine IDE ein
> ausdrucksschwache Sprache auch nicht wirklich verbessern kann,
> abgesehen
> davon dass fehlende Konzepte nciht einfach durch die IDE erg�nzt werden
> k�nnen...
Verlangt ja auch keiner. Eine Tastatur kann eine ausdrucksschwache
Sprache auch nicht verbessern, oder Konzepte ersetzen. Sind Tastaturen
deshalb schlecht ?
> nein.. ich habe nicht wirklich etwas gegen IDEs, nur das man so gro�e
> IDEs braucht um wirklich was mit der Sprache anfangen zu k�nnen... ja,
> gegen diese Kombination habe ich etwas.
Braucht man ja nicht wirklich. IDEs sind generell so gross, weil
Programmierer viele verschiedene Sachen machen. Das ist eben Feature
creep. Gibt aber auch schlanke IDEs, bei denen das (noch) nicht der Fall
ist. Feature creep ist aber kein IDE-spezifisches Problem.
>> Java ist ja nun auch generell fuer andere Probleme geeignet als andere
>> Sprachen.
> Also das ist mir jetzt ein wenig zu allgemein.
Das sollte aber eigentlich voellig unbestritten sein, oder ?
>> Wenn man ein schnelles kleines 5-Zeilen-Script basteln will, braucht
>> man natuerlich auch keine IDE, aber dann waer' es auch normalerweise
>> nicht sehr sinnvoll, Java dafuer einzusetzen.
> Ach? passiert aber oft genug
Hauen auch genug Leute 'ne Schraube mit 'ner leeren Flasche in die Wand.
Das heisst jetzt aber nicht, das wir nur noch Getraenke in Kartons
verkaufen sollten.
> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
> erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE in
> Java fr�her als in zum Beispiel Ruby.
Dafuer hat Java laengere Fileendungen als Ruby!
Mein Punkt: Du sagst das so, als waere das was negatives. Ist es aber
(imo) nicht.
> wenn dann die Sprache steht und f�llt mit der IDE sehe ich das durchaus
> als problematisch....konsequenterweise m�sste man ja dann sagen, dass
> Java f�r gr��ere Projekte nicht geeignet war in den ersten Jahren.
Und da haette man vermutlich Recht mit gehabt. Andererseits wurden auch
schon grosse Programme in Zeiten ohne Source-Control,
Syntax-Highlighting und Garbage Collectors geschrieben. Ist halt alles
irgendwie moeglich.
>> Warum ? Dafuer muesstest Du mir, wie gesagt, erklaeren, warum es Dir
>> wuenschenswert erscheint, Java ohne IDE zu nutzen.
> vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
> Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
Wieso nicht mit einem Diff-Viewer and die entsprechende Stelle huepfen
und den alten und neuen Code direkt nebeneinander zu sehen ?
> wurde? Es sind eben viele kleine Sache, die dazu beitragen, nicht eine
> spezielle Sache. Ich finde es zum Beispiel durchaus nervig fast 5
> Minuten warten zu m�ssen bis ich in meiner IDE eine Datei �ndern kann...
> wenn ich die IDE denn �berhaupt hochfahren kann... mir ist vielleicht
> gerade der Speicher ausgegangen. Sowas wie Gedit braucht nicht viel
> Speicher und geht eigentlich immer
Vielleicht machst Du da auch was falsch. Mein Eclipse ist seit Montag
morgen offen, hat locker 35-40 ordentliche Projekte offen und frisst
grade, Moment, 198MB total. Und wie schon oben gesagt, Deine Beschwerden
richten sich an spezielle IDEs, nicht an IDEs im allgemeinen. Falsches
Benutzen, z.B. dauernd auf und zu machen, tut sein uebriges.
> nunja, �berlege dir mal eine Berechnung die sich gut aufteilen l�sst und
> dann stell dir vor du wolltest das auf 10Threads verteilen.. wie machst
> du das? Und dann �berlege dir mal eine Berechnung, die sich weniger gut
> aufteilen l�sst und tr�ume mal davon wie sch�n es w�re wenn deine
> Sprache das aufteilen f�r dich vollautomtisch erledigen w�rde.
Ja gut, verglichen mit Sprachen, die speziell dafuer geeignet sind,
klar. Ich dachte, Java waere jetzt speziell schlechter als andere
vergleichbare Sprachen wie, sagen wir mal, C# oder so.
> Oder in anderen Worten ein Hochsprache zur Hochsprache ;) Nenn' es ruhig
> Level, ich nenne es Sprache.... bzw. *neue* Sprache.. was impliziert
> dass die alte nicht ausreichend ist in einem bestimmten Aspekt.
Naja, mit dem Argument kannst Du dann ja sagen, alles unterhalb von UML
ist nicht ausreichend ;)
>> Meine Jugend hab' ich mit C vs Pascal und Windows vs DOS verschwendet ;)
> Windows vs DOS? echt? Habe ich noch nie mitbekommen so eine Diskussion.
Naja, damals schon, in Zeiten wo Windows noch optional war, und nur
Looser (sic) sich Windows installierten, waerend wir echten super pros
natuerlich jeden DOS-Befehl im Schlaf auswendig aufsagen konnten, und
alles auf unseren Systemen natuerlich viel schneller lief. Und mehr RAM
zur Verfuegung hatte! Weil wir naemlich, cool wie wir waren, naechtelang
an unseren config.sys'en herumgespielt hatten und exotische
memory-manager settings testeten ;)
>> Das "Problem" ist ja nicht wirklich ein Java-Problem. Wie Du selber
>> sagst, da gibt es durchaus noch ein paar mehr Sprachen die aehnlich
>> laut Rauschen. Aber wie gesagt sehe ich noch nicht, dass dieses
>> "Problem" wirklich eins ist, und nicht einfach eine (neutrale)
>> Eigenschaft.
> naja, wie neutral kann es denn sein, wenn manche Sprachen das Problem
> haben und manche nicht? Oder wenn der Grad des Rauschen so
> unterschiedlich ist? Das Rauschen selbst ist erstmal kein Problem. Wenn
> du den Fernseher einschaltest und siehst wei�es Rauschen, dann ist das
> auch erstmal kein Problem... wenn du allerdings ein Fernsehprogramm
> anschauen wolltest und dich nicht vom Rauschen hypnotisieren lassen
> wolltest, dann ist es ein Problem. Rauschen in der Programmiersprache
> verdeckt den Blick auf das, was wirklich wichtig ist. Nicht wenige
Dafuer haben wir die IDEs. Java rauscht ja nicht, weil es den Designern
langweilig war ohne Rauschen. Das Rauschen wird erst wirklich ein
Problem, wenn jemand aus irgend einem Grund ohne IDE arbeiten will. Und
genau so, wie jemand der Compiler nicht mag und lieber mit Hexeditor
direkt Maschinencode schreibt, kann man sich dann nicht beschweren, dass
es so viel Arbeit ist. Wenn man ein Tool nicht nutzt, und sich dann
beschwert, dass es so anstrengender ist, dann ist man selber schuld.
Genau dafuer ist das Tool ja da.
In anderen Worten: es ist ein Problem, das keins ist, ausser, man
schafft es sich selber, z.B. durch Verzicht auf IDE, Compiler, Tastatur
oder sonst was.
> fangen ein Programm an, indem sie erstmal all das "drum-herum"
> schreiben. Zum Beispiel kenne ich jemanden, der Groovy benutzt hat um
> einen Bildbearbeitungsalgorithmus zu entwickeln. Ziel war es dabei nicht
> besonders schnell zu sein, sondern den Algorithmus leicht anpassen zu
> k�nnen und sich nicht vom Rauschen ablenken zu lassen. Nachdem er mit
> dem Ergebnis zufrieden war, hat er den Algorithmus nach Java portiert um
> die notwendige Geschwindigkeit zu bekommen. Nach seinen Aussagen h�tte
> er in Java wahrscheinlich doppelt so lange gebraucht.. was ich nat�rlich
> nicht selbst beurteilen kann.
Die Geschichte hat ja nun so ziemlich einen Wert von Null ;) Du kennst
jemand, der hat mal ein Programm geschrieben, und der glaubt, das haette
vielleicht mit Java laenger gedauert. Ich hab da auch mal von jemand
gehoert, der hatte nen Freund, und dessen Tochter hat mal in Java einen
Taschenrechner programmiert. Die Tochter von dem Freund von dem Typ, von
dem ich gehoert hab', hat in ihr Tagebuch geschrieben, dass der
Taschenrechner in Fortran vermutlich sieben mal so lange wie in Java
gedauert haette. :p
> Ich will jetzt auch nicht behaupten, dass es sich lohnt ein grosses
> existierendes Projekt von heute auf morgen nach Groovy um zu stellen...
> andererseits muss das ja so auch nicht gemacht werden ;)
Naja, ich will ja auch nicht sagen, dass das alles wirklich so neutral
und egal ist. Ich widerspreche nur der stillschweigenden Akzeptanz von
einer bis dato ungeprueften Annahme (naemlich das IDEs boese/ein
noetiges Uebel sind). Sowas irritiert mich immer, genauso wie, zum
Beispiel, die stille Annahme dass Open Source "gut" und irgendwie eine
Art von Pluspunkt ist.
Wolfgang Rostek
> Bei
>
> class X {
> String foo
> int bar
>
> }
>
> sehe ich auf einen Blick, dass da praktisch keine Logik drin steckt,
> sich also um ein POJO handelt.. und selbst wenn es 20 Properties werden
> zusätzlich und 120 Zeilen code mehr
Dafür siehst Du aber auch nicht, was der setBar(int) so alles macht.
Neben Logging können dort durchaus Dinge implementiert sein, die
ich bei +Bedarf'+ sehen möchte. Natürlich sollte dies nicht über
die Grundlogik eines setters hinausgehen.
Gruß
Wolfgang R.
Thomas Thiele
> Warum ? Ich finde, eine interessantere Frage ist, warum man ueberhaupt
> gegen eine IDE ist. Ich sehe jetzt so spontan keine Nachteile (*) die es
> mir wuenschenswert zu erscheinen lassen, mich von IDEs zu distanzieren.
Eine IDE sollte ein *Hilfmittel* sein, keine Grundvorausetzung.
Aber nebenbei ich habe auch schon ganze Java-Projekte mit Ultraedit
gemacht.
> Java ist ja nun auch generell fuer andere Probleme geeignet als andere
> Sprachen.
Auf diese Beispiele bin ich gespannt.
Was - ausser einem eventuellen Bibliotheksvorhandensein - macht Java
für
irgendein Projekt geeigneter?
> Ich wuerde
> mal, ganz pauschal jetzt, und in diesem Zusammenhang, sagen, dass sich
> Java eher fuer groessere Projekte eignet.
Aber doch vorallem deshalb weil mit der Größe des Projektes die
Spracheigenschaften immer unwesentlicher werden.
> Ja, natuerlich. Sprachen waren schon immer (naja, fast) eng mit den IDEs
> verbunden.
vi?
> Man denke da nur an das alte Turbo Pascal mit der Borland
> IDE, oder an die diversen Microsoft-Produkte.
Ausser typische MS-Sprachen wie Cis und VB sehe ich da keinen
Zusammenhang.
Java ist mit den selben Argumenten auch Eclipse abhängig...
> Warum ? Dafuer muesstest Du mir, wie gesagt, erklaeren, warum es Dir
> wuenschenswert erscheint, Java ohne IDE zu nutzen.
Warum sollte es wünschenswert erscheinen eine IDE zu benutzen zu
müssen?
Wenn die IDE ein Benutzbarkeit herstellt, die in Sprachen wie Python
oder Ruby
schon von sich aus gegeben ist, dann ist diese Forderung überflüssig.
Wenn aber die Sprache Eigenschaften hat, die per entsprechender IDE,
geradezu
einen Programmierluxus herstellt, dann wäre es ok. Btw. Java hat z.T.
solche
Eigenschaften.
> > Form zeigt, was die unkomprimierte Form machen würde... Letztlich ist
> > das aber eine neue Sprache, auch wenn sie auf Java basiert und 1:1
> > umgesetzt werden kann.
> Waer' dann halt ein weiterer Abstraktionslevel.
Der aber den Zwischenschritt Java überflüssig machen würde.
> Ja, natuerlich. Nichts koennen Programmierer besser, als sich ueber
> Nichtigkeiten streiten, am besten jahrelang ;)
Das macht ja auch am meisten Spass...;-)
Jochen Theodorou
> Jochen Theodorou schrieb:
>
>> das ist schon witzig finde ich... ich meine eine Sprache, die in
>> einer Zeit entworfen wurde in der es die heutigen IDEs noch nicht
>> gab.... welche Perspektive hatten denn die Leute, die Java entworfen
>> haben? Najagut, das muss ja nicht unbedingt eine realistische sein.
>
> Vielleicht hatten die ja die Perspektive, dass ihr Zeug ansonsten genug
> Durchsetzungsverm�gen hat, so dass schon jemand gute IDEs entwickeln
> wird, wenn der Bedarf entsteht. Hat geklappt. ;-)
wer weiss, gut m�glich... oder man wollte sp�ter vielleicht sogar eine
IDE verkaufen!?
>> Aber gehe ich recht in der Annahme dass du dann sagst, dass Java erst
>> durch eine IDE "richtig gut" wird?... also durch ein Element das
>> weder Teil der Sprache, noch der Laufzeitumgebung oder der API ist?
>
> Dieser Aussage wird heute wohl kaum noch jemand widersprechen.
Man muss sich hlat vor Augen halten, dass es eigentlich keinen Sinn
macht von Java, der Sprache zu reden, sondern von Sprache+API+IDE, aber
die IDE ist nicht so sehr standardisiert wie die API oder gar die Sprache..
> Gegenfrage: Welche Perspektive haben denn Leute, die heute Sprachen
> entwerfen, f�r die es derart m�chtige Werkzeuge *nicht* gibt? Die bindet
> man dann an die Java-API an, gell? *g*
IntelliJ IDEA hat schon Refactoring Tools f�r Groovy. Netbeans weiss ich
nicht, Eclipse gibt es einfache Rafactorings, komplexere kommen noch.
Groovy ist allerdings nicht an die Java-API angebunden, wie ein
Anh�ngsel. Die Java-API und die Erg�nzungen zu dieser sind Teil der
Sprache wie bei Java eben auch.
>> Weisst fr�her hat man von Sprache gesprochen und die Sprache gemeint,
>> nicht die API, nicht die IDE, es sei denn es war von Anfang an als
>> komplettes Konstrukt gedacht.
>
> Wann ist denn "fr�her"? Fr�her gab es z.B. Smalltalk. Von vornherein als
> Sprache mit API und IDE und noch einigem mehr gedacht. Und ganz nebenbei
> der Vorfahr des ganzen OO-Ged�nsens.
Smalltalk war in vielen Dingen seiner Zeit vorraus. Ich denke da mehr so
an Pascal und C. Es gibt nicht viele Sprachen mit IDE und noch weniger
in denen man zur Laufzeit die IDE �ndern kann.
>> Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
>> sondern sich einfach auf Codecompletion verl�sst und dabei
>> Hilfsklassen vollkommen ignoriert, abgesehen davon dass man sich
>> st�ndig irgendwelchen Code generieren l�sst,
>
> Das ist durch nichts belegte Greuelpropaganda, mehr nicht.
ne... habe ich schon erlebt. Sogar bei mir selbst, weil ich damals
anstatt die API wirklich zu lernen gedacht hatte ich k�nne sie verstehen
und nutzen indem ich mir einfach nur die vorgeschlagenen Methoden
anschauen. S�nden der Jugend eben.
> Richtig ist,
> dass jemand, der hinreichend stumpf drauf ist, es mit der IDE leichter
> hat, trotzdem zu programmieren. Aber wer beim Programmieren denkt, der
> wird auch durch die IDE nicht damit aufh�ren.
denk daran, dass der Mensch zur Faulheit neigt.
>> abgesehen davon dass die
>> meisten IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter
>> 2GB und was weiss ich wie viel permgen)
>
> Komisch... bei mir ist das so nicht. Ich hab gar keine 2 GB.
tja.. was soll ich da sagen? Ich habe fr�her unter Eclipse auch mit
256MB gearbeitet, aber das war kein Eclipse 3.4 und die Projekte waren
kleiner.
>> abgesehen davon dass die meisten IDEs v�llig �berladen sind
>> mit features, die niemand braucht,
>
> ... der nicht genug Erfahrungen mit der betreffenden IDE gesammelt hat.
w�rde ich so nicht sagen... ich benutze Refactoringtools allgemein sehr
selten und bestimmte Dinge wie "erzeuge mir ein Interface aus dieser
Klasse" benutze ich garnicht.
>> abgesehen davon dass ich ewig
>> warten muss bis die IDE hochgefahren ist wo ich doch nur eine Zeile
>> kurz �ndern wollte,
>
> Die Realit�t professionellen Programmierens sieht meist ein bisschen
> anders aus, oder?
kommt darauf an w�rde ich sagen. Wenn du mit professionellen
Programmieren meinst, dass die IDE doch eh die ganze Zeit l�uft, dann
sicher ja. Ich erinnere mich aber ungern an eine Konferenz wo, ich mal
kurz jemanden was zeigen wollte auf meinen Linux-Laptop, auf dem ich
noch nie Eclipse benutzt hatte... Kurz gesagt das ging nicht, Eclipse
hat so sehr mit dem limitierten Speicher gek�mpft, dass jede Aktion
mehrere Minuten in Anspruch nahm.
> Und um mal eben eine Zeile zu �ndern, reicht auch bei
> Java ein Texteditor. Oder hat sich das seit gestern ge�ndert, als ich
> das zuletzt - mit vi - gemacht habe?
kommt darauf an ob du genau weisst wo diese Zeile ist ;)
>> abgesehen davon dass viele keine build skripte
>> irgendeiner Art machen,
>
> Verwende doch einfach eine IDE, die tut, was du brauchst. Es gibt ja
> immerhin drei bis vier gro�e ausgewachsene und ein paar Hundert Plugins.
Also von Eclipse, Netbeans und IntelliJ IDEA habe ich IntelliJ ein
halbes Jahr lang getestet und wurde damit nicht gr�n. Eclipse bin ich
halt gewohnt... Netbeans habe ich schon seit etlichen Jahren nicht mehr
probiert... keine Ahnung wie das im Moment so ist. Allerdings ist der
Punkt ja gerade der das wenn ich etwas schreibe, dass ich dann keine
Buildskripte brauche. Nur wenn andere was damit anfangen k�nnen sollen,
dann sieht das anders aus... was meinst du wie ich mich �ber bug reports
freue in denen ein Beispielprojekt enthalten ist f�r das ich dann eine
IDE brauche. F�r Sarkasmusresistente: Ich freue mich nicht sehr!
>> nein.. ich habe nicht wirklich etwas gegen IDEs, nur das man so gro�e
>> IDEs braucht um wirklich was mit der Sprache anfangen zu k�nnen...
>> ja, gegen diese Kombination habe ich etwas.
>
> Ich hab was gegen Propaganda von Fans wovon auch immer. Und dein Posting
> liest sich leider sehr nach Fan-Tum.
und von was w�re ich da der Fan? Von ausdruckst�rkeren Sprachen als
Java? Wenn du jetzt sagen w�rdest ich bin Java gegen�ber Voreingenommen
k�nnte ich eher damit leben ;) Aber deswegen bin ich nicht gleich Fan
von etwas bestimmten... wir sind ja hier nicht in einer 2-wertigen
Logik... oder wolltest du nur polarisieren?
>> wie gesagt, das orientiert sich IMHO an der Codegr�sse und in einer
>> ausdrucksst�rkeren Sprache kann man das gleiche in mit weniger Code
>> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
>> erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE
>> in Java fr�her als in zum Beispiel Ruby.
>
> Und? Wenn man aufh�rt, eine IDE (getrieben von der Tatsache, dass es f�r
> die eigene Lieblingssprache nichts Vern�nftigess gibt) als Nachteil
> betrachten zu wollen, ist das doch gar nicht schlimm.
wie gesagt, ich betrachte nicht die IDE ansich als schlecht, sonderen
dass man sie *braucht*.
[...]
>> vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
>> Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
>> wurde?
>
> Es gibt da ausgereifte Werkzeuge...
zum Beispiel?
[...]
>> Ich will jetzt auch nicht behaupten, dass es sich lohnt ein grosses
>> existierendes Projekt von heute auf morgen nach Groovy um zu
>> stellen... andererseits muss das ja so auch nicht gemacht werden ;)
>
> Was ich mich die ganze Zeit frage: Wenn Java *so* furchtbar ist - und
> mir sind die Nachteile durchaus bewusst - warum wird dann eigentlich
> ausgerechnet die Anbindung an Java und die Nutzung der Java-API immer so
> sehr als Feature von Groovy herausgestellt?
Wenn Assembler so furchtbar ist, warum wird es dann trotzdem benutzt? Es
gibt einfach gute Gr�nde daf�r. Groovy ist eine Sprache gemacht von
Leuten, die von Java frustriert waren. Das heisst aber nicht dass alles
in Java schlecht ist. Die Plattform und die API m�ssen ja nicht schlecht
sein, nur weil die Sprache.. naja lassen wir das. die Anbindung an Java
wird aus 2 Gr�nden so herausgestellt:
1) weil man dann Javabibliotheken wirklich in trivialer Weise nutzen
kann und weil es aus Sicht von Java dann fast immer keinen Unterschied
macht ob etwas in Groovy oder Java geschrieben ist. F�r etwas das als
Erg�nzung gedacht ist, ist sowas wichtig.
2) Weil Programmierer sich nicht gerne von etwas gelerntem l�sen und
einen Migrationspfad brauchen, auf dem sie sich St�ck f�r St�ck l�sen
k�nnen, anstatt das volle Programm vorgesetzt zu bekommen. So kann man
Groovy durchaus als Zwischenstation von Java zu Ruby benutzen, oder
anders herum... oder man bleibt bei Groovy. Und etwas gelerntes ist
nicht nur die Sprache, sondern auch die API... allerdings haben es da
Rubyleute schwerer mit Groovy als Javaleute.
> Spielt wom�glich die vorhandene Java-API f�r Groovy die Rolle, welche
> die Existenz guter IDEs f�r heutiges Java spielt? *g*
Hmm? Den Satz verstehe ich nicht.
Gruss theo
Michael Paap
>> Das ist durch nichts belegte Greuelpropaganda, mehr nicht.
>
> ne... habe ich schon erlebt. Sogar bei mir selbst, weil ich damals
> anstatt die API wirklich zu lernen gedacht hatte ich k�nne sie verstehen
> und nutzen indem ich mir einfach nur die vorgeschlagenen Methoden
> anschauen. S�nden der Jugend eben.
Du neigst ein wenig dazu, solche Erlebnisse zu verallgemeinern, glaube
ich. Ey, was ich nicht schon alles erlebt und gesehen hab... *g*
Aber derlei Erlebnis taugt als Beleg f�r eine Kausalit�t eher wenig.
> denk daran, dass der Mensch zur Faulheit neigt.
Faulheit ist legitim, Stumpfheit nicht. Und jemand, der keine API-Doku
liest, sondern das erste nimmt, was ihm die IDE vorschl�gt und was
halbwegs passend aussieht, ist nicht faul, sondern stumpf. Um mal
negativer klingende Adjektive zu vermeiden.
> w�rde ich so nicht sagen... ich benutze Refactoringtools allgemein sehr
> selten und bestimmte Dinge wie "erzeuge mir ein Interface aus dieser
> Klasse" benutze ich garnicht.
Warum denn nicht?
> kommt darauf an w�rde ich sagen. Wenn du mit professionellen
> Programmieren meinst, dass die IDE doch eh die ganze Zeit l�uft, dann
> sicher ja. Ich erinnere mich aber ungern an eine Konferenz wo, ich mal
> kurz jemanden was zeigen wollte auf meinen Linux-Laptop, auf dem ich
> noch nie Eclipse benutzt hatte... Kurz gesagt das ging nicht, Eclipse
> hat so sehr mit dem limitierten Speicher gek�mpft, dass jede Aktion
> mehrere Minuten in Anspruch nahm.
Ganz eindeutig mangelhafte Vorbereitung deinerseits, w�rde ich sagen. *g*
> kommt darauf an ob du genau weisst wo diese Zeile ist ;)
Ah, du willst also nicht nur mal eben eine Zeile �ndern, sondern eine
umfangreiche Problemanalyse durchziehen? *g*
> Nur wenn andere was damit anfangen k�nnen sollen,
> dann sieht das anders aus... was meinst du wie ich mich �ber bug reports
> freue in denen ein Beispielprojekt enthalten ist f�r das ich dann eine
> IDE brauche. F�r Sarkasmusresistente: Ich freue mich nicht sehr!
Hmm, ich verstehe nicht so ganz, was dich hindert, ein Ant-Skript zu
schreiben. Habe ich bei mehreren Projekten. Gab es da nicht sogar eine
M�glichkeit, das Build-Skript zu �bernehmen, welches Eclipse intern
verwendet? Verwendet habe ich das noch nicht.
> und von was w�re ich da der Fan? Von ausdruckst�rkeren Sprachen als
> Java? Wenn du jetzt sagen w�rdest ich bin Java gegen�ber Voreingenommen
> k�nnte ich eher damit leben ;) Aber deswegen bin ich nicht gleich Fan
> von etwas bestimmten... wir sind ja hier nicht in einer 2-wertigen
> Logik... oder wolltest du nur polarisieren?
Nein, das machst du ja die ganze Zeit schon, indem du v�llig unsauber
zwischen Einzelbeispielen und allgemeinen Aussagen hin und her
wechselst, bzw. teilweise aus Einzelbeispielen allgemeine Aussagen
ableitest, beispielsweise wenn du die Schw�chen einer IDe dem Konzept
IDE an sich anlastest.
> wie gesagt, ich betrachte nicht die IDE ansich als schlecht, sonderen
> dass man sie *braucht*.
Das kann ich schlicht nicht nachvollziehen. Genauso k�nnte ich mich
daran st�ren, dass mein Fahrrad Bremsen *braucht*.
>> Es gibt da ausgereifte Werkzeuge...
>
> zum Beispiel?
Zum einen ist auch in Eclipse erzeugter Java-Quellcode schlicht Text. Du
kannst jedes beliebige Diff-Tool deiner Wahl darauf ansetzen. Aber f�r
viele Zwecke reicht auch schon die in Eclipse eingebaute M�glichkeit,
verschiedene Versionen in einem entsprechenden View zu vergleichen.
>> Spielt wom�glich die vorhandene Java-API f�r Groovy die Rolle, welche
>> die Existenz guter IDEs f�r heutiges Java spielt? *g*
>
> Hmm? Den Satz verstehe ich nicht.
Na, du zeterst dar�ber, dass man in Java eine IDE *braucht*. Dass man in
Groovy Java *braucht*, st�rt dich hingegen nicht. Wo ist das Problem?
Wenn du ab einer gewissen Projektgr��e f�r Java eine IDE brauchst, dann
nimmst du halt eine. Wenn f�r ein Projekt Groovy geeigneter ist als
Java, dann nimmst du halt Groovy.
Gr�nde, von Java frustriert zu sein, gibt es sicher. Aber du wirst zur
Kenntnis nehmen m�ssen, dass viele Leute ihre IDE gerne benutzen und die
Tatsache, dass man f�r Groovy vielleicht bei einem bestimmten Projekt
keine IDE brauchen w�rde, f�r Java hingegen schon, f�r diese Leute wenig
z�hlt. Denn die Notwendigkeit einer IDE ist *nicht* das, was z.B. mich
an Java schmerzt. Und bei anderen interessanten Sprachen fehlt sie mir,
die IDE, auch wenn ich sie vielleicht nicht *so* sehr "brauchen" w�rde,
wie bei Java. Und mit IDE meine ich heute sowas wie Eclipse, nicht einen
besseren Editor mit SH.
Gru�,
Michael
Michael Paap
> Eine IDE sollte ein *Hilfmittel* sein, keine Grundvorausetzung.
Ooooh, ein Postulat. Da kann man nat�rlich kaum gegen argumentieren.
> Aber nebenbei ich habe auch schon ganze Java-Projekte mit Ultraedit
> gemacht.
Ah. Na also, dann ist dein Postulat - f�r dich - ja erf�llt.
Ansonsten halte ich den �bergang zwischen "Voraussetzung" und
"Hilfsmittel" f�r �berwiegend subjektiv und von den jeweiligen Umst�nden
abh�ngig. Unterhalte dich mal mit Leuten �ber die Frage, ob ihr Auto ein
Hilfsmittel zur Erreichung von Mobilit�t ist oder eine Voraussetzung.
Und dann mit Leuten, die gar kein Auto haben. Dann siehst du, wie
relativ das alles ist.
> Wenn die IDE ein Benutzbarkeit herstellt, die in Sprachen wie Python
> oder Ruby schon von sich aus gegeben ist, dann ist diese Forderung �berfl�ssig.
Wenn dem so w�re. Belege das bitte ggf. anhand von entsprechen gro�en in
Ruby mit vi gebauten Projekten.
> Das macht ja auch am meisten Spass...;-)
Auf *der* Ebene? M��ig... sehr m��ig.
Gru�,
Michael
Jochen Theodorou
> Jochen Theodorou wrote:
>> J. Stoever schrieb:
>>> Jochen Theodorou wrote:
>>>> J. Stoever schrieb:
>>>>> HTML ist als Plaintext auch grausam anzusehen. Und ?
>>>> aber bei HTML ist nicht so sehr der Source als viel mehr das was im
>>>> Browser angezeigt wird wichtig. Ausserdem hat HTML alleine nicht
>>> Und Java wird in der IDE angezeigt ;)
>> also stimmst du mir zu dass Java ohne IDE schlecht nutzbar ist?
>
> Ja, wie gesagt, genau so wie HTML. Das sehe ich aber nicht als Nachteil,
> weil genau so wie man HTML eben mit einem Browser anguckt, guckt man
> Java eben mit 'ner IDE an. Java mit Notepad zu oeffnen, ist imo genau so
> unsinnig, wie das selbe mit HTML oder XML zu machen.
aber man editiert HTML nicht mit dem Browser, daf�r brauchst du dann
nochmal eine "IDE"
[...]
> Stimmt, Java ist ohne IDE nicht besonders gut. Ohne API auch nicht. Ohne
> JVM/JIT auch nicht. Sind das jetzt alles negative Sachen ?
Java die Sprache ist nicht gleich Java die Plattform. Java die Sprache
ist eine Sprache f�r Java die Plattform, es gibt da noch dutzende
andere.. zum Beispiel Scala, Jython, JRuby, Groovy, Clojure, Kawa....
[...]
>>> Ich finde, eine interessantere Frage ist, warum man ueberhaupt gegen
>>> eine IDE ist. Ich sehe jetzt so spontan keine Nachteile (*) die es
>>> mir wuenschenswert zu erscheinen lassen, mich von IDEs zu distanzieren.
>
>>> *: Natuerlich gibt es Nachteile bei vielen IDEs, aber das sind alles
>>> Sachen, die nicht inherent mit IDEs verbunden sind, sondern nur
>>> spezifische Probleme, die man loesen koennte, ohne auf eine IDE zu
>>> verzichten (z.B. Feature overload und aehnliches).
>> Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
>> sondern sich einfach auf Codecompletion verl�sst und dabei
>> Hilfsklassen vollkommen ignoriert,
>
> Kannst Du das naeher erlaeutern ? Ich verstehe nicht genau, was Du damit
> meinst.
viel zitiertes und deswegen schlechtes Beispiel, weil das dann doch
wieder jeder weiss sind HilfsKlasse im JDK wie zum Beispiel Arrays, wo
man sortiermethoden finden kann usw. In Groovy w�re ein Beispiel
ClassHelper, dass ClassNode unterst�tzt... wird oft �bersehen, obwohl es
sogar im gleichen Package ist und in dem Package direkt nicht
sonderlich viele Klassen sind.
> Das Grundprinzip ist natuerlich klar - Sachen, die einem das Leben
> leichter machen, verbloeden auch. Mit der Logik musst Du aber Java ganz
> loeschen und direkt in Maschinencode schreiben. Sonst lernst Du ja die
> Opcodes nicht mehr, verlaesst Dich auf Stackmanagement und ignoriest
> Taktzyklen ;)
dem stimme ich nicht zu. Wenn es deine Ausdrucksf�higkeit erh�ht, dann
kann man abstrakter denken und verbloedet auch nicht. Die Frage ist ob
eine IDE das leistet. Wenn mir eine IDE Beispiel anzeigen w�rde nach
welchem pattern diese Klasse geschrieben wurde, dann w�rde ich da
Mehrwert und Abstraktion sehen. Im Zusammenklappen von Gettern und
Settern, sodass man nur noch den Methodenkopf sieht, sehe ich keinen
Mehrwert f�r die Abstraktion, "nur" eine bessere �bersichtlichkeit...
die nat�rlich auch nicht wertlos ist.
>> abgesehen davon dass man sich st�ndig
>> irgendwelchen Code generieren l�sst,
>
> Ist doch super, wenn man nicht selber tippseln muss. Laesst mehr Zeit
> zum nachdenken. Was ist daran genau negativ ?
das es notwendig ist, wenn man produktiv sein will.
>> abgesehen davon dass die meisten
>> IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter 2GB und was
>> weiss ich wie viel permgen) was Speicher und CPU-Last betrifft,
>
> Spezifisches Problem von spezifischen IDEs.
ja, aber du kannst nicht irgendeine, nicht existierende Pseudeo-IDE ein
das Tripplet Sprache+API+IDE aufnehmen und dabei die anderen beiden
konkret halten. Ich kann dann auch mit einer idealen Sprache kommen, die
einfach tut was ich will ohne das ich APIs lernen muss ;)
> Nicht alle sind
> featureueberladene Monster. Ist also nicht ein Problem von IDEs, sondern
> ein Problem von bestimmten Produkten. Gibt auch kleine, schlanke IDEs.
welche IDE ist denn schlank und qualifiziert sich noch als IDE in dem
Sinne, dass es auch Refaktoringsupport, Codenavigation, Klassenbrowser
und Highliting gibt?
[...]
>> abgesehen davon dass eine IDE ein
>> ausdrucksschwache Sprache auch nicht wirklich verbessern kann,
>> abgesehen
>> davon dass fehlende Konzepte nciht einfach durch die IDE erg�nzt
>> werden k�nnen...
>
> Verlangt ja auch keiner. Eine Tastatur kann eine ausdrucksschwache
> Sprache auch nicht verbessern, oder Konzepte ersetzen. Sind Tastaturen
> deshalb schlecht ?
Die Tastatur nimmt ja auch nicht f�r sich in Anspruch die Sprache erst
gut zu machen. Ausserdem sage ich ja nicht das IDEs schlecht sind,
sondern das deren Notwendigkeit f�r Java schlecht ist.
[...]
>>> Java ist ja nun auch generell fuer andere Probleme geeignet als
>>> andere Sprachen.
>> Also das ist mir jetzt ein wenig zu allgemein.
>
> Das sollte aber eigentlich voellig unbestritten sein, oder ?
die Aussage klingt so als gebe aus eine bestimmte Klasse von Problemen
f�r die java am besten geeignet ist und dass das die einzigen Probleme
sind, die man in Java l�st. Das Java aber eine "general purpose"-Sprache
ist, ist das sicher nicht der Fall. Ausserdem ist nicht nur das Problem
wichtig, sondern auch die Konzepte zur L�sung des Problems. oder viel
mehr geht es darum wie einfach es die Sprache einem Programmierer macht
ein Problem zu l�sen, wobei bestimmte Konzepte helfen k�nnen. Threads
sind zum Beipsiel sowas, oder Klassen. F�r welche Probleme ist denn die
Sprache Java besser geeignet als andere Sprachen? Und was bedeutet
"besser"?naja, du sprachst ja nicht wirklich von besser, sondern von
"generell f�r andere Probleme geeignet als andere Sprachen".. was man
auch so verstehen k�nnte dass es Probleme gibt die man nur in Java l�sen
kann... das vage ich aber sehr zu bezweifeln. Von v�llig unbestritten
kann hier also keine Rede sein, denn ich was ja noch nicht mal was du
eigentlich meinst.
[...]
>> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
>> erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE in
>> Java fr�her als in zum Beispiel Ruby.
>
> Dafuer hat Java laengere Fileendungen als Ruby!
lol... .groovy ist noch l�nger ;)
> Mein Punkt: Du sagst das so, als waere das was negatives. Ist es aber
> (imo) nicht.
Es ist also nicht negativ, dass man in Java mit 1000 Zeilen Code weniger
machen kann als in Ruby?
>> wenn dann die Sprache steht und f�llt mit der IDE sehe ich das
>> durchaus als problematisch....konsequenterweise m�sste man ja dann
>> sagen, dass Java f�r gr��ere Projekte nicht geeignet war in den ersten
>> Jahren.
>
> Und da haette man vermutlich Recht mit gehabt.
gutgut, ich wollte das best�tigt haben ;)
> Andererseits wurden auch
> schon grosse Programme in Zeiten ohne Source-Control,
> Syntax-Highlighting und Garbage Collectors geschrieben. Ist halt alles
> irgendwie moeglich.
sicher... Mammuts hat man auch irgendwie erlegt - wahrscheinlich
>>> Warum ? Dafuer muesstest Du mir, wie gesagt, erklaeren, warum es Dir
>>> wuenschenswert erscheint, Java ohne IDE zu nutzen.
>> vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
>> Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
>
> Wieso nicht mit einem Diff-Viewer and die entsprechende Stelle huepfen
> und den alten und neuen Code direkt nebeneinander zu sehen ?
weil das schon hunderte von Zeilen sind und man nat�rlich umherspringen
kann, aber allein der Codeumfang erschl�gt einen schon.
>> wurde? Es sind eben viele kleine Sache, die dazu beitragen, nicht eine
>> spezielle Sache. Ich finde es zum Beispiel durchaus nervig fast 5
>> Minuten warten zu m�ssen bis ich in meiner IDE eine Datei �ndern
>> kann... wenn ich die IDE denn �berhaupt hochfahren kann... mir ist
>> vielleicht gerade der Speicher ausgegangen. Sowas wie Gedit braucht
>> nicht viel Speicher und geht eigentlich immer
>
> Vielleicht machst Du da auch was falsch. Mein Eclipse ist seit Montag
> morgen offen, hat locker 35-40 ordentliche Projekte offen und frisst
> grade, Moment, 198MB total.
inzwischen ist das f�r mich unm�glich, weil ich unter Linux mit 64bit
arbeite. Wenn ich da den permgen nicht auf knapp 100MB erh�he fliegt mir
die IDE um die Ohren... nach 5 Minuten Arbeit wohl gemerkt, und mit
einem Projekt, das nichtmal besonders gro� ist.
[...]
>> nunja, �berlege dir mal eine Berechnung die sich gut aufteilen l�sst
>> und dann stell dir vor du wolltest das auf 10Threads verteilen.. wie
>> machst du das? Und dann �berlege dir mal eine Berechnung, die sich
>> weniger gut aufteilen l�sst und tr�ume mal davon wie sch�n es w�re
>> wenn deine Sprache das aufteilen f�r dich vollautomtisch erledigen w�rde.
>
> Ja gut, verglichen mit Sprachen, die speziell dafuer geeignet sind,
> klar. Ich dachte, Java waere jetzt speziell schlechter als andere
> vergleichbare Sprachen wie, sagen wir mal, C# oder so.
Nunja, in Groovy arbeite ich an sowas demn�chst... und da wird es keine
syntaktischen Sprach�nderungen geben deswegen
>> Oder in anderen Worten ein Hochsprache zur Hochsprache ;) Nenn' es
>> ruhig Level, ich nenne es Sprache.... bzw. *neue* Sprache.. was
>> impliziert dass die alte nicht ausreichend ist in einem bestimmten
>> Aspekt.
>
> Naja, mit dem Argument kannst Du dann ja sagen, alles unterhalb von UML
> ist nicht ausreichend ;)
f�r welchen Algorithmus ist bitte UML geeignet?
[...]
>>> Das "Problem" ist ja nicht wirklich ein Java-Problem. Wie Du selber
>>> sagst, da gibt es durchaus noch ein paar mehr Sprachen die aehnlich
>>> laut Rauschen. Aber wie gesagt sehe ich noch nicht, dass dieses
>>> "Problem" wirklich eins ist, und nicht einfach eine (neutrale)
>>> Eigenschaft.
>> naja, wie neutral kann es denn sein, wenn manche Sprachen das Problem
>> haben und manche nicht? Oder wenn der Grad des Rauschen so
>> unterschiedlich ist? Das Rauschen selbst ist erstmal kein Problem.
>> Wenn du den Fernseher einschaltest und siehst wei�es Rauschen, dann
>> ist das auch erstmal kein Problem... wenn du allerdings ein
>> Fernsehprogramm anschauen wolltest und dich nicht vom Rauschen
>> hypnotisieren lassen wolltest, dann ist es ein Problem. Rauschen in
>> der Programmiersprache verdeckt den Blick auf das, was wirklich
>> wichtig ist. Nicht wenige
>
> Dafuer haben wir die IDEs.
die haben aber auch nur beschr�nkte F�higkeiten. Wenn ich zum Beispiel
code vergleiche den ich mittels dem Swingbuilder geschrieben habe und
wie der Code in Java aussehen w�rde, dann kann die IDE nur eines machen,
mir das ganze Ding graphisch darstellen und mit komischen Grafiken
versuchen sowas wie Binding hinzubekommen... nicht zu vergessen dass man
dann user code auch noch irgendwo unterbringen muss.... zu dumm dass man
sowas dann aber nicht mehr in einem Buch abdrucken kann... aber B�cher
liest ja wahrscheinlich auch niemand mehr.
> Java rauscht ja nicht, weil es den Designern
> langweilig war ohne Rauschen. Das Rauschen wird erst wirklich ein
> Problem, wenn jemand aus irgend einem Grund ohne IDE arbeiten will. Und
> genau so, wie jemand der Compiler nicht mag und lieber mit Hexeditor
> direkt Maschinencode schreibt, kann man sich dann nicht beschweren, dass
> es so viel Arbeit ist. Wenn man ein Tool nicht nutzt, und sich dann
> beschwert, dass es so anstrengender ist, dann ist man selber schuld.
> Genau dafuer ist das Tool ja da.
Ein Tool zu haben heisst nicht dass es gut wird. Sicher, es ist besser
einen Hammer zu benutzen um einen Nagel in ein Brett zu schlagen, besser
als mit einer Flasche... aber wenn es viele N�gel sind, geht es mit der
Nagelpistole vielleicht noch besser. Und eine andere Sprache sehe ich
durchaus auch als Tool an. Gem�� deiner Aussage oben ist dann jeder
selbst Schuld, der nicht die geeignetere Sprache f�r das Problem
einsetzt. nunja, du teilst diese Auffassung vielleicht nicht mit mir,
aber das ist genau so wie wir Groovy sehen wollen, als Tool.
[...]
>> fangen ein Programm an, indem sie erstmal all das "drum-herum"
>> schreiben. Zum Beispiel kenne ich jemanden, der Groovy benutzt hat um
>> einen Bildbearbeitungsalgorithmus zu entwickeln. Ziel war es dabei
>> nicht besonders schnell zu sein, sondern den Algorithmus leicht
>> anpassen zu k�nnen und sich nicht vom Rauschen ablenken zu lassen.
>> Nachdem er mit dem Ergebnis zufrieden war, hat er den Algorithmus nach
>> Java portiert um die notwendige Geschwindigkeit zu bekommen. Nach
>> seinen Aussagen h�tte er in Java wahrscheinlich doppelt so lange
>> gebraucht.. was ich nat�rlich nicht selbst beurteilen kann.
>
> Die Geschichte hat ja nun so ziemlich einen Wert von Null ;) Du kennst
> jemand, der hat mal ein Programm geschrieben, und der glaubt, das haette
> vielleicht mit Java laenger gedauert.
nun er hatte Erfahrung in dem Bereich... aber da er diesen Algorithmus
nun schon fertig hat, kann man das nicht mehr mit java vergleichen...
dazu h�tte er sich Zweiteilen m�ssen, oder einen vergleichbaren Partner,
der das in Java macht.
[...]
>> Ich will jetzt auch nicht behaupten, dass es sich lohnt ein grosses
>> existierendes Projekt von heute auf morgen nach Groovy um zu
>> stellen... andererseits muss das ja so auch nicht gemacht werden ;)
>
> Naja, ich will ja auch nicht sagen, dass das alles wirklich so neutral
> und egal ist. Ich widerspreche nur der stillschweigenden Akzeptanz von
> einer bis dato ungeprueften Annahme (naemlich das IDEs boese/ein
> noetiges Uebel sind).
b�se ansich nein, besonders nicht wenn wir von einem abstrakten idealen
Konstrukt reden ;) Das sie �berhaupt notwendig sind, ist ein Ausdruck
der Schw�che der Sprache.
Gruss theo
Jochen Theodorou
> Jochen Theodorou schrieb:
>
>> Allerdings sollte man auch in der Lage sein mal
>> zu versuchen logisch argumentierend zu Diskutieren und mal in Kauf
>> nehmen dass die Lieblingssprache Nachteile hat und dass es andere besser
>> k�nnen.
>
> Ja. Aber dazu geh�rt auch, sich auf die real existierenden Nachteile von
> Java zu beschr�nken - von denen es nun wahrlich genug gibt - und nicht
> welche an die Wand zu malen, die f�r 99% der professionellen Verwender
> v�llig irrelevant sind.
Closures sind f�r 100% der Javaanwender irrelevant, weil es sie in Java
nicht gibt oder �ber innere klasse irgendwie simuliert werden. Trotzdem
sehe ich deren Fehlen als Nachteil an.
> Von "Lieblingssprachen" halte ich eh wenig, das riecht mir zu sehr nach
> "Lieblingsband" und "Mein Fussballverein". Leute, die in diesen Bahnen
> denken, sind Fans. Mit Fans zu diskutieren, ist meist ebenso anstrengend
> wie sinnfrei.
Ich wollte ja auch nur etwas zuspitzen ;)
>> Wenn Java perfekt w�re, dann br�uchte man die Sprache nicht mehr
>> weiterentwickeln und sowas �hnliches wie Closures hinzuf�gen...
>
> Davon wird imho auch nichts besser werden, ganz im Gegenteil.
wieso? Findest du Closures ansich schlecht, oder nur deren Umsetzung f�r
Java? Von anderen Sprachen kenne ich Bl�cke/Lambdas/richtige Closures,
als recht m�chtiges Werkzeug. ich habe die jetzt einfach mal
zusammengefasst, da sie zwar nicht gleich sind, aber doch �hnlich genug
Gruss theo
J. Stoever
> On 2 Okt., 15:25, "J. Stoever" <thetwis...@gmx.de> wrote:
>> Warum ? Ich finde, eine interessantere Frage ist, warum man ueberhaupt
>> gegen eine IDE ist. Ich sehe jetzt so spontan keine Nachteile (*) die es
>> mir wuenschenswert zu erscheinen lassen, mich von IDEs zu distanzieren.
> Eine IDE sollte ein *Hilfmittel* sein, keine Grundvorausetzung.
Ja. Warum ? Das sagst Du jetzt so. Gibt es dafuer auch objektive
Gruende, oder muessen wir das einfach glauben ?
> Aber nebenbei ich habe auch schon ganze Java-Projekte mit Ultraedit
> gemacht.
Nichts gegen Dich, aber da wuerde ich sagen - schoen bescheuert.
Andererseits habe ich aber auch mal ein Starscroller in Assembler
geschrieben (19 Byte!).
>> Java ist ja nun auch generell fuer andere Probleme geeignet als andere
>> Sprachen.
> Auf diese Beispiele bin ich gespannt.
> Was - ausser einem eventuellen Bibliotheksvorhandensein - macht Java
> f�r irgendein Projekt geeigneter?
Ok. Grosses Projekt, sagen wir wir mal, Office. Java ist dafuer
geeigneter, als, z.B., QuickBasic. Oder ein anderes Projekt - ein CMS
Server. Java ist hier geeigneter als, z.B., Assembler. Oder ein lang
laufendes, kompliziertes System. Java ist hier geeigneter als, z.B., C
(dank des GC).
Genug ?
>> Ich wuerde
>> mal, ganz pauschal jetzt, und in diesem Zusammenhang, sagen, dass sich
>> Java eher fuer groessere Projekte eignet.
> Aber doch vorallem deshalb weil mit der Gr��e des Projektes die
> Spracheigenschaften immer unwesentlicher werden.
Nein, weil Java eine relativ "hohe" Sprache mit nuetzlichen Sachen wie
GC ist. Das ist fuer ein grosses Projekt ziemlich toll, fuer ein
5-Zeilen-Batchscript aber relativ egal.
>> Ja, natuerlich. Sprachen waren schon immer (naja, fast) eng mit den IDEs
>> verbunden.
> vi?
Ja, vi-script ist ziemlich eng mit vi verbunden. Oder was wolltest Du
jetzt damit sagen ?
>> Man denke da nur an das alte Turbo Pascal mit der Borland
>> IDE, oder an die diversen Microsoft-Produkte.
> Ausser typische MS-Sprachen wie Cis und VB sehe ich da keinen
> Zusammenhang.
> Java ist mit den selben Argumenten auch Eclipse abh�ngig...
Ja, und ? Wie gesagt, so ist das eben. Wo genau wird das negativ ?
>> Warum ? Dafuer muesstest Du mir, wie gesagt, erklaeren, warum es Dir
>> wuenschenswert erscheint, Java ohne IDE zu nutzen.
> Warum sollte es w�nschenswert erscheinen eine IDE zu benutzen zu
> m�ssen?
Warum nicht ?
> Wenn die IDE ein Benutzbarkeit herstellt, die in Sprachen wie Python
> oder Ruby
> schon von sich aus gegeben ist, dann ist diese Forderung �berfl�ssig.
Nein, ist sie nicht. Wie in einem anderen Post erwaehnt, weder mein
Fahrrad noch meine Bremsen sind boese, nur weil ein Fahrrad bremsen
braucht. Und nur weil mein Dreirad keine Bremsen hat, macht das weder
mein Fahrrad noch meine Bremsen irgendwie boese oder negativ.
>>> Form zeigt, was die unkomprimierte Form machen w�rde... Letztlich ist
>>> das aber eine neue Sprache, auch wenn sie auf Java basiert und 1:1
>>> umgesetzt werden kann.
>> Waer' dann halt ein weiterer Abstraktionslevel.
> Der aber den Zwischenschritt Java �berfl�ssig machen w�rde.
Ja, so wie Java Bytecode ueberfluessig und Bytecode Maschinencode
ueberfluessig macht.
>> Ja, natuerlich. Nichts koennen Programmierer besser, als sich ueber
>> Nichtigkeiten streiten, am besten jahrelang ;)
> Das macht ja auch am meisten Spass...;-)
Machen wir ja auch grade.
J. Stoever
> J. Stoever schrieb:
>> Nachteil, weil genau so wie man HTML eben mit einem Browser anguckt,
>> guckt man Java eben mit 'ner IDE an. Java mit Notepad zu oeffnen, ist
>> imo genau so unsinnig, wie das selbe mit HTML oder XML zu machen.
> aber man editiert HTML nicht mit dem Browser, daf�r brauchst du dann
> nochmal eine "IDE"
Stimmt zwar, ist aber wirklich egal, da dass ja nicht der Punkt ist.
HTML editiert man uebrigens auch normalerweise nicht mit Texteditor,
auch wenn das manchmal noetig ist. Und bitte erzaehl' mir jetzt nicht
von Deiner Homepage, die Du nur mit copy con > homepage.html geschrieben
hast ;)
>> Ist doch super, wenn man nicht selber tippseln muss. Laesst mehr Zeit
>> zum nachdenken. Was ist daran genau negativ ?
> das es notwendig ist, wenn man produktiv sein will.
Das ist eine null-aussage. Klar, alles was die Produktivitaet steigert,
ist notwendig, wenn man produktiv(er) sein will. Eine Tastatur, im
vergleich zu einer Bildschirmtastatur, ist auch notwendig, wenn Du
produktiv sein willst. Ist die jetzt auch boese ?
>>> abgesehen davon dass die meisten
>>> IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter 2GB und was
>>> weiss ich wie viel permgen) was Speicher und CPU-Last betrifft,
>> Spezifisches Problem von spezifischen IDEs.
> ja, aber du kannst nicht irgendeine, nicht existierende Pseudeo-IDE ein
> das Tripplet Sprache+API+IDE aufnehmen und dabei die anderen beiden
> konkret halten. Ich kann dann auch mit einer idealen Sprache kommen, die
> einfach tut was ich will ohne das ich APIs lernen muss ;)
Und wenn ich jetzt argumentieren wuerde, dass APIs schlecht sind, weil
man sie braucht, dann haettest Du damit auch voellig recht (wenn wir
jetzt mal das voellig sinnfreie dabei ausser acht lassen).
>> Nicht alle sind featureueberladene Monster. Ist also nicht ein Problem
>> von IDEs, sondern ein Problem von bestimmten Produkten. Gibt auch
>> kleine, schlanke IDEs.
> welche IDE ist denn schlank und qualifiziert sich noch als IDE in dem
> Sinne, dass es auch Refaktoringsupport, Codenavigation, Klassenbrowser
> und Highliting gibt?
Keine Ahnung, ich brauche kein Schlank. Wenn da Bedarf fuer ist, wird's
die aber sicher geben.
>> Verlangt ja auch keiner. Eine Tastatur kann eine ausdrucksschwache
>> Sprache auch nicht verbessern, oder Konzepte ersetzen. Sind Tastaturen
>> deshalb schlecht ?
> Die Tastatur nimmt ja auch nicht f�r sich in Anspruch die Sprache erst
> gut zu machen. Ausserdem sage ich ja nicht das IDEs schlecht sind,
> sondern das deren Notwendigkeit f�r Java schlecht ist.
Aber erklaert warum hast Du das immer noch nicht.
>>>> Java ist ja nun auch generell fuer andere Probleme geeignet als
>>>> andere Sprachen.
>>> Also das ist mir jetzt ein wenig zu allgemein.
>> Das sollte aber eigentlich voellig unbestritten sein, oder ?
> die Aussage klingt so als gebe aus eine bestimmte Klasse von Problemen
> f�r die java am besten geeignet ist und dass das die einzigen Probleme
> sind, die man in Java l�st.
Das war weder so gemeint noch geschrieben. Hab' ich ja in einem anderen
Post erlaeutert.
>> Mein Punkt: Du sagst das so, als waere das was negatives. Ist es aber
>> (imo) nicht.
> Es ist also nicht negativ, dass man in Java mit 1000 Zeilen Code weniger
> machen kann als in Ruby?
Das ist negativ, wenn man seinen Code ausdrucken muss und Baeume mag.
Oder wenn man sich den Code mit Notepad anguckt. Oder wenn die
Festplatte fast voll ist. Wenn man hingegen eine vernuenftige IDE
benutzt, ist es voellig egal, ob's nun 500 oder 1000 Zeilen sind, und
Java's Rauschen ist ja nicht voellig sinnfrei. Das hat eben Vor- und
Nachteile, und die IDE kuemmert sich um die Nachteile.
>>> vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
>>> Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
>> Wieso nicht mit einem Diff-Viewer and die entsprechende Stelle huepfen
>> und den alten und neuen Code direkt nebeneinander zu sehen ?
> weil das schon hunderte von Zeilen sind und man nat�rlich umherspringen
> kann, aber allein der Codeumfang erschl�gt einen schon.
Kann man ja alles wegfolden. Wenn man ne tolle IDE hat. Klar, wer das in
der Textkonsole mit diff.exe anguckt, ist am Arsch. Aber das ist dann ja
die eigene Schuld.
>> Vielleicht machst Du da auch was falsch. Mein Eclipse ist seit Montag
>> morgen offen, hat locker 35-40 ordentliche Projekte offen und frisst
>> grade, Moment, 198MB total.
> inzwischen ist das f�r mich unm�glich, weil ich unter Linux mit 64bit
> arbeite. Wenn ich da den permgen nicht auf knapp 100MB erh�he fliegt mir
> die IDE um die Ohren... nach 5 Minuten Arbeit wohl gemerkt, und mit
> einem Projekt, das nichtmal besonders gro� ist.
Installier Dir halt was vernuenftiges, so wie Vista *duck*
> zu dumm dass man
> sowas dann aber nicht mehr in einem Buch abdrucken kann... aber B�cher
> liest ja wahrscheinlich auch niemand mehr.
Richtig. Buecher im Codingbereich sind ein voelliger Anachronismus. Da
funktioniert ja nicht mal Ctrl+F.
Jochen Theodorou
> Jochen Theodorou schrieb:
>
>>> Das ist durch nichts belegte Greuelpropaganda, mehr nicht.
>> ne... habe ich schon erlebt. Sogar bei mir selbst, weil ich damals
>> anstatt die API wirklich zu lernen gedacht hatte ich k�nne sie verstehen
>> und nutzen indem ich mir einfach nur die vorgeschlagenen Methoden
>> anschauen. S�nden der Jugend eben.
>
> Du neigst ein wenig dazu, solche Erlebnisse zu verallgemeinern, glaube
> ich. Ey, was ich nicht schon alles erlebt und gesehen hab... *g*
> Aber derlei Erlebnis taugt als Beleg f�r eine Kausalit�t eher wenig.
nunja, war eben nicht nur ein pers�nliches Erlebnis.
>> denk daran, dass der Mensch zur Faulheit neigt.
>
> Faulheit ist legitim, Stumpfheit nicht. Und jemand, der keine API-Doku
> liest, sondern das erste nimmt, was ihm die IDE vorschl�gt und was
> halbwegs passend aussieht, ist nicht faul, sondern stumpf. Um mal
> negativer klingende Adjektive zu vermeiden.
dann habe ich schon sehr viele stumpfe Menschen gesehen, die dann
meistens auch noch Faul waren ;)
>> w�rde ich so nicht sagen... ich benutze Refactoringtools allgemein sehr
>> selten und bestimmte Dinge wie "erzeuge mir ein Interface aus dieser
>> Klasse" benutze ich garnicht.
>
> Warum denn nicht?
Ich habe es halt noch nie gebraucht, bzw. habe erst daran gedacht, dass
es das vielleicht gibt, nachdem ich das von Hand gemacht hatte
>> kommt darauf an w�rde ich sagen. Wenn du mit professionellen
>> Programmieren meinst, dass die IDE doch eh die ganze Zeit l�uft, dann
>> sicher ja. Ich erinnere mich aber ungern an eine Konferenz wo, ich mal
>> kurz jemanden was zeigen wollte auf meinen Linux-Laptop, auf dem ich
>> noch nie Eclipse benutzt hatte... Kurz gesagt das ging nicht, Eclipse
>> hat so sehr mit dem limitierten Speicher gek�mpft, dass jede Aktion
>> mehrere Minuten in Anspruch nahm.
>
> Ganz eindeutig mangelhafte Vorbereitung deinerseits, w�rde ich sagen. *g*
das mag zwar stimmen, dennoch h�tte Vorbereitung nur dazu gef�hrt dass
ich schon vorher gewusst h�tte dass das nicht geht.
>> kommt darauf an ob du genau weisst wo diese Zeile ist ;)
>
> Ah, du willst also nicht nur mal eben eine Zeile �ndern, sondern eine
> umfangreiche Problemanalyse durchziehen? *g*
ne, aber wenn ich einem Code von 200 Zeilen erstmal alle Zeilen
durchgehen muss um diese bestimmte Stelle zu finden...
>> Nur wenn andere was damit anfangen k�nnen sollen,
>> dann sieht das anders aus... was meinst du wie ich mich �ber bug reports
>> freue in denen ein Beispielprojekt enthalten ist f�r das ich dann eine
>> IDE brauche. F�r Sarkasmusresistente: Ich freue mich nicht sehr!
>
> Hmm, ich verstehe nicht so ganz, was dich hindert, ein Ant-Skript zu
> schreiben.
Mich hindert nichts daran... relevant wird es erst in Zusammenarbeit mit
anderen... und eigentlich habe ich besseres zu tun als f�r andere ein
ant script zu schreiben, dass sie dann vielleicht nichtmal �bernehmen
> Habe ich bei mehreren Projekten. Gab es da nicht sogar eine
> M�glichkeit, das Build-Skript zu �bernehmen, welches Eclipse intern
> verwendet? Verwendet habe ich das noch nicht.
Um mal eine IDE zu loben... naja teilweise... IntelliJ hat eine sehr
gute Integration mit ant... allerdings muss man da auch oft auf ant
zur�ckgreifen. Ich glaube Netbeans ist ein besseres Beispiel, weil da
geh�rt das zum regul�ren Build dazu glaube ich.
>> und von was w�re ich da der Fan? Von ausdruckst�rkeren Sprachen als
>> Java? Wenn du jetzt sagen w�rdest ich bin Java gegen�ber Voreingenommen
>> k�nnte ich eher damit leben ;) Aber deswegen bin ich nicht gleich Fan
>> von etwas bestimmten... wir sind ja hier nicht in einer 2-wertigen
>> Logik... oder wolltest du nur polarisieren?
>
> Nein, das machst du ja die ganze Zeit schon, indem du v�llig unsauber
> zwischen Einzelbeispielen und allgemeinen Aussagen hin und her
> wechselst, bzw. teilweise aus Einzelbeispielen allgemeine Aussagen
> ableitest, beispielsweise wenn du die Schw�chen einer IDe dem Konzept
> IDE an sich anlastest.
Es geht um eine konkrete Sprache, um eine konkrete API und dann darf ich
keine konkrete IDE nehmen? Sondern? Eine API oder Sprache ist ja auch
kein Konzept in dem Sinne wie du es hier von der IDE erwartest. Ich
h�tte es halt schon gerne etwas konkreter als ein "sprachunterst�tzendes
Werkzeug", denn das ist meine bash auch. Wenn wir schon von
konzeptionelle Dingen sprechen, dann m�sste ich auch die Sprache
abstrahieren.... Mir geht es aber nicht um irgendeine Sprache, sondern
konkret um Java.
>> wie gesagt, ich betrachte nicht die IDE ansich als schlecht, sonderen
>> dass man sie *braucht*.
>
> Das kann ich schlicht nicht nachvollziehen. Genauso k�nnte ich mich
> daran st�ren, dass mein Fahrrad Bremsen *braucht*.
dein Fahrrad braucht keine Bremsen, du brauchst sie. Aber st�ren kann
man sich durchaus daran wenn man unbedingt will. Ich hindere niemanden
daran. Allerdings brauche ich die bremse der Sicherheit wegen, nicht
damit ich �berhaupt fahren kann. Dann m�sste man sich schon eher an den
Pedalen oder Kette oder den R�dern st�ren... aber aus welchem Grund?
Damit man Fahrrad fahren kann? Ich st�re mich ja nicht an der IDE weil
ich die IDE benutzen will. Beim Fahrradbeispiel w�rde man alternativ
halt zu Fuss gehen, oder mit etwas motorisierten oder reiten... was auch
immer. Was ist die Alternative zur IDE? Ich denke da stimmt was mit dem
Abstraktionsgrad dieses Beispieles nicht... in anderen Worten der
Vergleich hinkt.
>>> Es gibt da ausgereifte Werkzeuge...
>> zum Beispiel?
>
> Zum einen ist auch in Eclipse erzeugter Java-Quellcode schlicht Text.
den ich ja nicht direkt lesen oder bearbeiten will, weil sonst br�uchte
ich ja keine IDE
> Du
> kannst jedes beliebige Diff-Tool deiner Wahl darauf ansetzen. Aber f�r
> viele Zwecke reicht auch schon die in Eclipse eingebaute M�glichkeit,
> verschiedene Versionen in einem entsprechenden View zu vergleichen.
Wenn du ein diff hast, dass etliche Klassen und mehrere hundert Zeilen
code umfasst, dann bringt mir das in der Regel wenig. ein diff wo nur
eine Klasse/Method oder noch besser, nur eine Zeile ge�ndert wird... das
ist brauchbar, ja.
>>> Spielt wom�glich die vorhandene Java-API f�r Groovy die Rolle, welche
>>> die Existenz guter IDEs f�r heutiges Java spielt? *g*
>> Hmm? Den Satz verstehe ich nicht.
>
> Na, du zeterst dar�ber, dass man in Java eine IDE *braucht*. Dass man in
> Groovy Java *braucht*, st�rt dich hingegen nicht.
Das sind doch auch v�llig verschiedene Dinge. Das w�re ja ungef�hr so
als beschwere ich mit unter Linux dar�ber wenn ich die libc brauche.
Eine IDE ein optionales Tool. Java ist f�r Groovy nicht optional. Es ist
viel mehr die Basis. Ich verstehe den Vergleich nicht.
> Wo ist das Problem?
> Wenn du ab einer gewissen Projektgr��e f�r Java eine IDE brauchst, dann
> nimmst du halt eine. Wenn f�r ein Projekt Groovy geeigneter ist als
> Java, dann nimmst du halt Groovy.
ich sage ja nicht dass ich damit ein Problem habe, nur dass es in Java
mehr rauschen gibt ;) Ich habe nichts gegen das "Konzept" einer IDE als
Tool das mich bei der Softwareentwicklung unterst�tzt
> Gr�nde, von Java frustriert zu sein, gibt es sicher. Aber du wirst zur
> Kenntnis nehmen m�ssen, dass viele Leute ihre IDE gerne benutzen und die
> Tatsache, dass man f�r Groovy vielleicht bei einem bestimmten Projekt
> keine IDE brauchen w�rde, f�r Java hingegen schon, f�r diese Leute wenig
> z�hlt.
das nehme ich nicht nur zur Kenntnis, das weiss ich sogar. Ich m�chte
jetzt hier auch garnicht behaupten dass Groovy oder Ruby bessere
Sprachen w�ren als Java. Aber die IDE braucht man trotzdem nicht so
schnell ;) Ich habe auch nichts dagegen, wenn jemand gerne eine IDE
bennutzt... wenn man quasi gezwungen ist sie zu benutzen....
Gruss theo
Michael Paap
> wieso? Findest du Closures ansich schlecht, oder nur deren Umsetzung f�r
> Java? Von anderen Sprachen kenne ich Bl�cke/Lambdas/richtige Closures,
> als recht m�chtiges Werkzeug. ich habe die jetzt einfach mal
> zusammengefasst, da sie zwar nicht gleich sind, aber doch �hnlich genug
Ich habe mich noch nicht weiter damit besch�ftigt, wie die Pl�ne
aussehen, Closures in Java umzusetzen. Aber es sollte mich sehr wundern,
wenn es auf eine Weise geschieht, die Java - die Sprache - sch�ner,
einfacher oder konzeptionell stimmiger macht. Schlie�lich muss ja alles
abw�rtskompatibel bleiben...
Prinzipiell hab ich garnichts gegen schicke Sprachfeatures. Aber wenn
immer drangestrickt wird, dann wird das Ganze immer inkonsistenter und
es gibt immer neue Ausnahmeregeln.
Nehmen wir Autoboxing. Schlimm genug, dass es Primitivtypen gibt, aber
das wird sich bei Java wohl nicht mehr �ndern. Nun gut... also
Autoboxing. Sieht ja einfach genug aus. Aber neulich hatte ich das
Vergn�gen, mir anzusehen, wie die Aufl�sung von �berladung aussieht,
wenn nicht nur Parameter von Primitivtypen und Referenztypen vorkommen,
sondern auch noch Autoboxing eine Rolle spielt. Da kriegst du graue
Haare, das kannst und willst du keinem Anf�nger erkl�ren. Genau
Letzteres ist mein Job.
Dasselbe mit parametrischer Polymorphie. Prinzipiell fein, aber die
Umsetzung in Java mit Typ-Erasure... krieschischplack.
Gru�,
Michael
Daniel Urban
Kannst Du das mal f�r mich abgrenzen?
Data Transfer Object und Value Object waren bisher f�r mich das Gleiche.
Klassen ohne Logik, die Daten (zum Transfer) halten. Beides - dachte ich -
sind auch POJOs. POJOs k�nnen auch Logik enthalten und dienen somit nicht
nur zum Transfer. Aber ist Logik oder Nicht-Transfer eine notwendige
Bedingung f�r den Bergriff POJO? Oder kann etwas kein POJO sein, was bereits
einen anderen Begriff hat?
Gru�,
Daniel
Michael Paap
> dann habe ich schon sehr viele stumpfe Menschen gesehen, die dann
> meistens auch noch Faul waren ;)
Ja, davon gibt es genug. Und zugegeben: Viele davon verwenden Java. Weil
sie das halt mal eingepr�gelt bekommen haben.
> das mag zwar stimmen, dennoch h�tte Vorbereitung nur dazu gef�hrt dass
> ich schon vorher gewusst h�tte dass das nicht geht.
Sorry, aber ich kenne etliche Leute, die Eclipse auf einem Linux-Laptop
verwenden, und zwar nicht auf irgendeinem nagelneuen Boliden. Und wenn
es nur darum ging, "mal eben jemandem was zu zeigen", dann w�sste ich
nicht, wo das Problem sein sollte, au�er du hantierst mit einem 486/100. ;-)
> ne, aber wenn ich einem Code von 200 Zeilen erstmal alle Zeilen
> durchgehen muss um diese bestimmte Stelle zu finden...
Das muss ich dank existierender Suchfunktion, Call-Hierachie-View usw.
eigentlich nie.
> Mich hindert nichts daran... relevant wird es erst in Zusammenarbeit mit
> anderen... und eigentlich habe ich besseres zu tun als f�r andere ein
> ant script zu schreiben, dass sie dann vielleicht nichtmal �bernehmen
Ich verstehe irgendwie das Problem nicht so ganz... du findest, dass es
ein Vorteil ist, wenn man Ant-Skripte benutzen *muss*?
> Um mal eine IDE zu loben... naja teilweise... IntelliJ hat eine sehr
> gute Integration mit ant... allerdings muss man da auch oft auf ant
> zur�ckgreifen. Ich glaube Netbeans ist ein besseres Beispiel, weil da
> geh�rt das zum regul�ren Build dazu glaube ich.
Bei Eclipse doch imho auch.
> Es geht um eine konkrete Sprache, um eine konkrete API und dann darf ich
> keine konkrete IDE nehmen?
Nat�rlich nicht, wenn du daraus Aussagen �ber IDEs im allgmeinen ableitest.
> Sondern? Eine API oder Sprache ist ja auch
> kein Konzept in dem Sinne wie du es hier von der IDE erwartest.
Wir reden aber von *einer* Sprache, und nicht vom Konzept
Programmiersprache. Du hingegen redest vom Konzept IDE.
> dein Fahrrad braucht keine Bremsen, du brauchst sie. Aber st�ren kann
> man sich durchaus daran wenn man unbedingt will.
Genau das ist mein Eindruck: Du willst dich unbedingt an IDEs st�ren.
Mach das halt. Aber es �berzeugt mich kein bisschen.
> Allerdings brauche ich die bremse der Sicherheit wegen, nicht
> damit ich �berhaupt fahren kann.
Definitionssache.
> Damit man Fahrrad fahren kann? Ich st�re mich ja nicht an der IDE weil
> ich die IDE benutzen will. Beim Fahrradbeispiel w�rde man alternativ
> halt zu Fuss gehen, oder mit etwas motorisierten oder reiten... was auch
> immer. Was ist die Alternative zur IDE?
Na, vi oder was wei� ich. Ist halt unbequemer. So wie zu Fu� zu gehen.
>> Zum einen ist auch in Eclipse erzeugter Java-Quellcode schlicht Text.
>
> den ich ja nicht direkt lesen oder bearbeiten will, weil sonst br�uchte
> ich ja keine IDE
Wenn man nicht v�llig borniert ist, w�ste ich nicht, warum ich nicht
zus�tzlich zu einer IDE weitere Werkzeuge einsetzen sollte, z.B. Diff,
da wo es sinnvoll ist. Ich kann dir echt nicht folgen.
> Das sind doch auch v�llig verschiedene Dinge. Das w�re ja ungef�hr so
> als beschwere ich mit unter Linux dar�ber wenn ich die libc brauche.
> Eine IDE ein optionales Tool. Java ist f�r Groovy nicht optional. Es ist
> viel mehr die Basis. Ich verstehe den Vergleich nicht.
Wir hatten doch ziemlich �bereinstimmend festgestellt, dass eine IDE
heute f�r Java eben kein optionales Tool ist, wenn es um professionelle
Entwicklung geht. Genau dar�ber lamentierst du doch. St�rt dich, dass
die IDE nicht fest verdrahtet ist, sondern du sie dir aussuchen kannst
oder was?
> ich sage ja nicht dass ich damit ein Problem habe, nur dass es in Java
> mehr rauschen gibt ;) Ich habe nichts gegen das "Konzept" einer IDE als
> Tool das mich bei der Softwareentwicklung unterst�tzt
Dann ist doch alles gut. *g*
> das nehme ich nicht nur zur Kenntnis, das weiss ich sogar. Ich m�chte
> jetzt hier auch garnicht behaupten dass Groovy oder Ruby bessere
> Sprachen w�ren als Java.
Nun, wenn es um die *Sprache* alleine geht, geh�rt da ja nicht viel
dazu. Auch C# ist eine bessere Sprache.
> Aber die IDE braucht man trotzdem nicht so
> schnell ;) Ich habe auch nichts dagegen, wenn jemand gerne eine IDE
> bennutzt... wenn man quasi gezwungen ist sie zu benutzen....
Sie geh�rt heute einfach dazu und fertig. Mach Spa� und tut nicht weh.
Mir. *g*
Gru�,
Michael
Michael Paap
> Installier Dir halt was vernuenftiges, so wie Vista *duck*
Weil dann der Speicherbedarf der IDE zwanglos unauff�llig im
Speicherbedarfs des Betriebssystems untergeht und die IDE-Startzeiten
nicht mehr ins Gewicht fallen, weil ein aktueller Rechner mit Vista zum
Booten eh drei mal so lange braucht wie mein 1800-MHz-Rechner mit XP? *g*
Gru�,
Michael
Daniel Urban
[...]
> Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
> sondern sich einfach auf Codecompletion verl�sst und dabei Hilfsklassen
> vollkommen ignoriert,
Ich glaube nicht, dass das einen gro�en Unterschied macht. Wenn es die
Codecompletion nicht geben w�rde, w�rde man eben in der Doku suchen und
genauso wahrscheinlich Fehler machen.
> abgesehen davon dass man sich st�ndig irgendwelchen Code generieren
> l�sst,
Seltsamerweise kenne ich nur wenige Leute, die diese generierten
Code-Schnipsel verwenden. Ich verwende die Dinge zum Beispiel auch nicht.
Ich kann nicht einmal sagen, warum ich das nicht mache. Vielleicht weil ich
jedes Mal nach der Abk�rzung suchen m�sste und in der selben Zeit den Code
schon selber geschrieben habe.
> abgesehen davon dass die meisten IDEs ware Monster sind (Eclipse l�uft bei
> mir nicht unter 2GB und was weiss ich wie viel permgen) was Speicher und
> CPU-Last betrifft,
Auch wenn ich die 2 GB nicht nachvollziehen kann, gebe ich Dir grunds�tzlich
recht. Die IDEs sollten wirklich mal eine Di�t machen.
> abgesehen davon dass die meisten IDEs v�llig �berladen sind mit features,
> die niemand braucht,
Meine vollste Zustimmung. Ich finde, die Dinger sind teilweise so �berladen,
dass sie einen ergonomischen Supergau darstellen. Aber Emacs und Vi mit
zahlreichen Tastenkombinationen sind auch ein ergonomischer Supergau.
> abgesehen davon dass ich ewig warten muss bis die IDE hochgefahren ist wo
> ich doch nur eine Zeile kurz �ndern wollte,
Auch hier hast Du meine Zustimmung. Allerdings w�rde ich f�r eine Zeile Code
die IDE nicht hochfahren. Solche Arbeiten werden dann bis zum n�chsten
regul�ren IDE-Start verschoben.
> abgesehen davon dass viele keine build skripte irgendeiner Art machen,
Ich gebe Dir Recht, dass es �rgerlich ist, wenn sich die Ausf�hrung zwischen
IDE und Standalone unterscheidet. So k�nnen gerne auch mal Fehler �bersehen
werden, weil zum Beispiel andere Bibliotheken verwendet werden. Aber Eclipse
soll doch dort zumindest eine L�sung anbieten. Auch wenn ich nur wenige
Personen kenne, die damit umgehen k�nnen. Ich kann es nicht. Solche
elementaren Dinge sind teilweise einfach zu kompliziert gel�st.
> abgesehen davon dass die meisten IDEs in der Bedienung nicht sonderlich
> einheitlich sind,
Untereinander oder innerhalb einer IDE? Letzteres ist mir noch nicht
aufgefallen. Vielleicht hast Du ein Beispiel?
> abgesehen davon dass eine IDE ein ausdrucksschwache Sprache auch nicht
> wirklich verbessern kann,
Das ist aber wohl auch nicht wirklich das Ziel gewesen.
> abgesehen davon dass fehlende Konzepte nciht einfach durch die IDE erg�nzt
> werden k�nnen...
Was wohl auch nicht das Ziel gewesen ist.
> nein.. ich habe nicht wirklich etwas gegen IDEs, nur das man so gro�e IDEs
> braucht um wirklich was mit der Sprache anfangen zu k�nnen... ja, gegen
> diese Kombination habe ich etwas.
Ich habe nicht dein Eindruck, dass die Sprache das Problem ist. F�r Java
braucht man grunds�tzlich keine IDE. Aber je gr��er ein Projekt wird, desto
mehr ben�tigt man eine IDE. Dies ist meiner Erfarhung nach unabh�ngig von
der Sprache.
>> Wenn man ein schnelles kleines 5-Zeilen-Script basteln will, braucht man
>> natuerlich auch keine IDE, aber dann waer' es auch normalerweise nicht
>> sehr sinnvoll, Java dafuer einzusetzen.
>
> Ach? passiert aber oft genug
Aber nur von Leuten, die nur Java k�nnen/installiert haben und daher den
bequemsten Weg w�hlen. Normalerweise sollte man die geeigneste Sprache
w�hlen, sofern die Kosten nicht unverh�ltnism��ig sind.
[...]
> wie gesagt, das orientiert sich IMHO an der Codegr�sse und in einer
> ausdrucksst�rkeren Sprache kann man das gleiche in mit weniger Code
> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht erst
> ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE in Java
> fr�her als in zum Beispiel Ruby.
Das mag sein, aber die Schwelle ist vermutlich so niedrig, dass es in der
Praxis unabh�ngig von der Sprache kaum professionelle Programme geben wird,
die ohne IDE geschrieben wurden. IMHO
Gru�,
Daniel
Jochen Theodorou
> ...
>> Bei
>>
>> class X {
>> String foo
>> int bar
>>
>> }
>>
>> sehe ich auf einen Blick, dass da praktisch keine Logik drin steckt,
>> sich also um ein POJO handelt.. und selbst wenn es 20 Properties werden
>> zus�tzlich und 120 Zeilen code mehr
>
> Daf�r siehst Du aber auch nicht, was der setBar(int) so alles macht.
muss ich ja nicht, denn das ist in der Sprache definiert. Wenn da was
anderes passiert, dann gibt es eine entsprechend sichtbare Methode.
Gruss theo
Daniel Urban
Das nenne ich doch einmal eine gute L�sung. Allerdings w�re eine Annotation
bez�glich der Modifier Public, Procted usw. getrennt f�r Setter und Getter
w�nschenswert.
Gru�,
Daniel
Michael Paap
> Mal im Ernst, ich bin so froh dass schon wieder ein neues Windows in der
> Roehre ist, mit ein bisschen Glueck kann ich dann von XP direkt auf's
> neue umsteigen, und Vista kommt in die gleiche Schublade wie ME bei mir.
Ich bin da wohl ziemlich konservativ... der Umstieg von Windows 2000 auf
XP liegt bei mir gerade mal 7 Monate zur�ck. Aber ich k�nnte mir
durchaus vorstellen, von XP auf das Windows nach Vista zu wechseln, wenn
das etwa 5 Jahre abgehangen ist. ;-)
Gru�,
Michael
J. Stoever
Ne, weil Aero so schoen bunt ist, dass Du gerne einfach drauf schaust
und nichts tust.
Jochen Theodorou
[...]
> Sorry, aber ich kenne etliche Leute, die Eclipse auf einem Linux-Laptop
> verwenden, und zwar nicht auf irgendeinem nagelneuen Boliden. Und wenn
> es nur darum ging, "mal eben jemandem was zu zeigen", dann w�sste ich
> nicht, wo das Problem sein sollte, au�er du hantierst mit einem 486/100. ;-)
tja also, das war ein ganz normales Eclipse von vor 12 Monaten und ein
Laptop 1GHz mit 256MB ram. Es ist sicher genug Rechenleistung, der
Speicher hat Eclipse aber nicht gereicht. vielleicht bin auch dem
�blichen bug zum Opfer gefallen.
>> ne, aber wenn ich einem Code von 200 Zeilen erstmal alle Zeilen
>> durchgehen muss um diese bestimmte Stelle zu finden...
>
> Das muss ich dank existierender Suchfunktion, Call-Hierachie-View usw.
> eigentlich nie.
dann geht es aber ohne IDE nicht
>> Mich hindert nichts daran... relevant wird es erst in Zusammenarbeit mit
>> anderen... und eigentlich habe ich besseres zu tun als f�r andere ein
>> ant script zu schreiben, dass sie dann vielleicht nichtmal �bernehmen
>
> Ich verstehe irgendwie das Problem nicht so ganz... du findest, dass es
> ein Vorteil ist, wenn man Ant-Skripte benutzen *muss*?
lieber ein ant skript als garnichts.
>> Um mal eine IDE zu loben... naja teilweise... IntelliJ hat eine sehr
>> gute Integration mit ant... allerdings muss man da auch oft auf ant
>> zur�ckgreifen. Ich glaube Netbeans ist ein besseres Beispiel, weil da
>> geh�rt das zum regul�ren Build dazu glaube ich.
>
> Bei Eclipse doch imho auch.
ehem... die ant integration in Eclipse ist ja wohl ein Witz... es sei
denn ich habe da was �bersehen.. Aber bei mir sind ant un der interne
Compiler separat, ant ist als externes Tool in einer eigenen runtime
configuration definiert, sogar fullbuilds in eclipse ignorieren ant.
Integration ist f�r mich was anderes... und nur weil eclipse mir da
einen Knopf bietet, damit ich auf der Kommandozeile kein "ant compile"
eingeben muss?
Ich f�nde es super wenn ich Eclipse sagen k�nnte dass es f�r dieses
Projekt bei full builds doch bitte dieses und jenes ant target benutzen
soll. Wenn jemand weiss ob Eclipse das kann, dann bitte nicht
zur�ckhalten und es hier kund tun.
>> Es geht um eine konkrete Sprache, um eine konkrete API und dann darf ich
>> keine konkrete IDE nehmen?
>
> Nat�rlich nicht, wenn du daraus Aussagen �ber IDEs im allgmeinen ableitest.
will ich ja nicht. Was interessiert mich zum Beispiel VisualStudio oder
KDevelop. Wenn es um IDEs f�r Java geht sind eh nur Eclipse, Netbeans
und IntelliJ IDEA relevant. Und in meinen Punkten unterscheiden die sich
nicht wesentlich.
>> Sondern? Eine API oder Sprache ist ja auch
>> kein Konzept in dem Sinne wie du es hier von der IDE erwartest.
>
> Wir reden aber von *einer* Sprache,
von einer bestimmten, ja, Java
> und nicht vom Konzept
> Programmiersprache. Du hingegen redest vom Konzept IDE.
Neh... ich mache es vielleicht nicht deutlich genug, aber ich rede von
den f�r Java verf�gbaren und gebr�uchlichen IDEs. Wenn man Von IDE im
Zusammenhang mit Java spricht, dann meint man doch eine von diesen IDEs,
oder nicht? Ich jedenfalls meine das.
[...]
>> Allerdings brauche ich die bremse der Sicherheit wegen, nicht
>> damit ich �berhaupt fahren kann.
>
> Definitionssache.
ich muss bremsen k�nnen um mich bewegen zu k�nnen? Macht physikalisch
gesehen nicht viel Sinn.
[...]
>>> Zum einen ist auch in Eclipse erzeugter Java-Quellcode schlicht Text.
>> den ich ja nicht direkt lesen oder bearbeiten will, weil sonst br�uchte
>> ich ja keine IDE
[...]
> Ich kann dir echt nicht folgen.
Du sagst Quelltext ist schlicht Text, ich sage dass das sicherlich so
ist, dass du den aber ohne IDE ja offensichtlich nicht editieren oder
gar schreiben willst. Und das will man nicht, weil es sonst zu
umst�ndlich ist. Dass es so umst�ndlich ist h�ngt aber auch von der
Sprache ab.
>> Das sind doch auch v�llig verschiedene Dinge. Das w�re ja ungef�hr so
>> als beschwere ich mit unter Linux dar�ber wenn ich die libc brauche.
>> Eine IDE ein optionales Tool. Java ist f�r Groovy nicht optional. Es ist
>> viel mehr die Basis. Ich verstehe den Vergleich nicht.
>
> Wir hatten doch ziemlich �bereinstimmend festgestellt, dass eine IDE
> heute f�r Java eben kein optionales Tool ist, wenn es um professionelle
> Entwicklung geht. Genau dar�ber lamentierst du doch. St�rt dich, dass
> die IDE nicht fest verdrahtet ist, sondern du sie dir aussuchen kannst
> oder was?
optional in dem Sinne das ich notfalls und ineffizient Javatext auch in
einem simplen Editor ohne IDE editieren kann, Groovy aber funktioniert
ohne Javaklassen nicht, genauso wie jede andere Sprache auf der JVM. In
Falle von Groovy ist die Integration halt noch ein bischen
tiefgreifender, aber Javaklassen werden da immer irgendwo gebraucht...
das ist in der JVM fest verdrahtet. Java die Sprache braucht man in
Groovy nicht unbedingt, Java die Plattform schon.
Professionelle Entwicklung braucht nat�rlich immer irgendwelche
Werkzeuge, aber schon der Hobbyentwickler kommt ja ohne die nicht aus.
Gruss theo
Bernd Eckenfels
> ehem... die ant integration in Eclipse ist ja wohl ein Witz... es sei
> configuration definiert, sogar fullbuilds in eclipse ignorieren ant.
Das is aber einfach, man packt "precompile" und "postcompile" targets von
ant als Builder ins Projekt. Oder man macht sich dafï¿œr eben ein ANT Target
das man manuell aufruft. Damit kann man dann die meisten jaxb oder xdoclet
Generator Scenarien einigermassen erschlagen.
Das eigentliche Problem ist ja ANT, das kein vernuenftiges dependency
checking macht.
> Ich fï¿œnde es super wenn ich Eclipse sagen kï¿œnnte dass es fï¿œr dieses
> Projekt bei full builds doch bitte dieses und jenes ant target benutzen
> soll. Wenn jemand weiss ob Eclipse das kann, dann bitte nicht
> zurï¿œckhalten und es hier kund tun.
ANT als builder hinzufuegen.
Gruss
Bernd
Jochen Theodorou
> Jochen Theodorou wrote:
>> J. Stoever schrieb:
>>> Ja, wie gesagt, genau so wie HTML. Das sehe ich aber nicht als
>>> Nachteil, weil genau so wie man HTML eben mit einem Browser anguckt,
>>> guckt man Java eben mit 'ner IDE an. Java mit Notepad zu oeffnen, ist
>>> imo genau so unsinnig, wie das selbe mit HTML oder XML zu machen.
>> aber man editiert HTML nicht mit dem Browser, daf�r brauchst du dann
>> nochmal eine "IDE"
>
> Stimmt zwar, ist aber wirklich egal, da dass ja nicht der Punkt ist.
> HTML editiert man uebrigens auch normalerweise nicht mit Texteditor,
> auch wenn das manchmal noetig ist. Und bitte erzaehl' mir jetzt nicht
> von Deiner Homepage, die Du nur mit copy con > homepage.html geschrieben
> hast ;)
no, daf�r nehme ich einen Texteditor ;) Ne mal ehrlich... bisher habe
ich HTML immer im Texteditor geschrieben, weil die meisten HTML-Editoren
mit GUI-Unterst�tzung recht komische Sachen mit dem HTML anstellen und
meistens benutze ich auch Templatesysteme... ich meine wer benutzt heute
noch �berwiegend statische Seiten?
>>> Ist doch super, wenn man nicht selber tippseln muss. Laesst mehr Zeit
>>> zum nachdenken. Was ist daran genau negativ ?
>> das es notwendig ist, wenn man produktiv sein will.
>
> Das ist eine null-aussage. Klar, alles was die Produktivitaet steigert,
> ist notwendig, wenn man produktiv(er) sein will. Eine Tastatur, im
> vergleich zu einer Bildschirmtastatur, ist auch notwendig, wenn Du
> produktiv sein willst. Ist die jetzt auch boese ?
nicht produktiver, sondern einfach nur irgendwie produktiv.
>>>> abgesehen davon dass die meisten
>>>> IDEs ware Monster sind (Eclipse l�uft bei mir nicht unter 2GB und
>>>> was weiss ich wie viel permgen) was Speicher und CPU-Last betrifft,
>>> Spezifisches Problem von spezifischen IDEs.
>> ja, aber du kannst nicht irgendeine, nicht existierende Pseudeo-IDE
>> ein das Tripplet Sprache+API+IDE aufnehmen und dabei die anderen
>> beiden konkret halten. Ich kann dann auch mit einer idealen Sprache
>> kommen, die einfach tut was ich will ohne das ich APIs lernen muss ;)
>
> Und wenn ich jetzt argumentieren wuerde, dass APIs schlecht sind, weil
> man sie braucht, dann haettest Du damit auch voellig recht (wenn wir
> jetzt mal das voellig sinnfreie dabei ausser acht lassen).
ehm.. warum soll ich das sinnfreie dabei ausseracht lassen? Gibt es
�berhaupt eine Sprache bei der man ohne API-Zugriff ein Hello World
ausgeben kann? Naja, gibt es bestimmt ;)
>>> Nicht alle sind featureueberladene Monster. Ist also nicht ein
>>> Problem von IDEs, sondern ein Problem von bestimmten Produkten. Gibt
>>> auch kleine, schlanke IDEs.
>> welche IDE ist denn schlank und qualifiziert sich noch als IDE in dem
>> Sinne, dass es auch Refaktoringsupport, Codenavigation, Klassenbrowser
>> und Highliting gibt?
>
> Keine Ahnung, ich brauche kein Schlank. Wenn da Bedarf fuer ist, wird's
> die aber sicher geben.
es klang aber so als g�be es solch eine IDE... niemand scheint sie zu
kennen.
[...]
>>> Mein Punkt: Du sagst das so, als waere das was negatives. Ist es aber
>>> (imo) nicht.
>> Es ist also nicht negativ, dass man in Java mit 1000 Zeilen Code
>> weniger machen kann als in Ruby?
>
> Das ist negativ, wenn man seinen Code ausdrucken muss und Baeume mag.
> Oder wenn man sich den Code mit Notepad anguckt. Oder wenn die
> Festplatte fast voll ist. Wenn man hingegen eine vernuenftige IDE
> benutzt, ist es voellig egal, ob's nun 500 oder 1000 Zeilen sind, und
nett... bisher brauchten wir nur eine IDE, jetzt brauchen wir eine
vern�nftige IDE ;) Die Anforderungen steigen?
> Java's Rauschen ist ja nicht voellig sinnfrei. Das hat eben Vor- und
> Nachteile, und die IDE kuemmert sich um die Nachteile.
die IDEs haben sich also darum gek�mmert dass vor java5 ein
for (Itertor it=collection.iterator(); it.hasNext();) {
X element = (X) it.next()
...
}
irgendwie kompakter dargestellt wird? Das habe ich noch niergends
gesehen... statt dessen hat man
for (X element : collection) {
...
}
in Java5 eingef�hrt um es dem Programmierer leichter zu machen... W�re
die IDEs so toll wie ihr alle tut, dann w�re diese �nderung �berfl�ssig
gewesen, oder nicht? Es waren aber wohl ausreichend Leute der Meinung,
dass es nicht �berfl�ssig ist, also waren zumindest die in diesem Fall
mit ihrer IDE nicht zufrieden.
>>>> vielleicht weil ich ein diff lesen k�nnen m�chte ohne hunderte von
>>>> Zeilen lesen zu m�ssen obwohl nur ein kleines Feature implementiert
>>> Wieso nicht mit einem Diff-Viewer and die entsprechende Stelle
>>> huepfen und den alten und neuen Code direkt nebeneinander zu sehen ?
>> weil das schon hunderte von Zeilen sind und man nat�rlich
>> umherspringen kann, aber allein der Codeumfang erschl�gt einen schon.
>
> Kann man ja alles wegfolden. Wenn man ne tolle IDE hat. Klar, wer das in
> der Textkonsole mit diff.exe anguckt, ist am Arsch. Aber das ist dann ja
> die eigene Schuld.
ich kenne kein diff, weder in IntelliJ IDEA, noch in Eclipse noch meld
diff noch sonst irgendein diff wo man irgendwas "wegfolden" kann.
Gruss theo
Michael Paap
> tja also, das war ein ganz normales Eclipse von vor 12 Monaten und ein
> Laptop 1GHz mit 256MB ram. Es ist sicher genug Rechenleistung, der
> Speicher hat Eclipse aber nicht gereicht.
Naja, 256 MB ist heutzutage wirklich etwas mager.
> dann geht es aber ohne IDE nicht
Ja, herrje! Kapier doch endlich: Nein, geht es nicht. Macht aber nichts,
es gibt die Dinger schlie�lich. ;-)
>> Ich verstehe irgendwie das Problem nicht so ganz... du findest, dass es
>> ein Vorteil ist, wenn man Ant-Skripte benutzen *muss*?
>
> lieber ein ant skript als garnichts.
Seltsam. Du lastest der IDE/Java an, dass man die benutzen *muss* und
wirfst ihr gleichzeitig vor, dass sie dich nicht zwingt, Skripte zu
benutzen?
> Ich f�nde es super wenn ich Eclipse sagen k�nnte dass es f�r dieses
> Projekt bei full builds doch bitte dieses und jenes ant target benutzen
> soll. Wenn jemand weiss ob Eclipse das kann, dann bitte nicht
> zur�ckhalten und es hier kund tun.
Meines Wissens kannst du ein Ant-Buildfile dem Projekt deiner Wahl als
"Builder" hinzuf�gen und dann passiert genau das, was du m�chtest. Wobei
ich das noch nicht gemacht habe... aber wenn du mal suchst, findest du
bestimmt entsprechende Informationen.
> will ich ja nicht. Was interessiert mich zum Beispiel VisualStudio oder
> KDevelop. Wenn es um IDEs f�r Java geht sind eh nur Eclipse, Netbeans
> und IntelliJ IDEA relevant. Und in meinen Punkten unterscheiden die sich
> nicht wesentlich.
Aehm... na gut, wenn du das so siehst.
> Neh... ich mache es vielleicht nicht deutlich genug, aber ich rede von
> den f�r Java verf�gbaren und gebr�uchlichen IDEs. Wenn man Von IDE im
> Zusammenhang mit Java spricht, dann meint man doch eine von diesen IDEs,
> oder nicht? Ich jedenfalls meine das.
Ja. Aber das sind immerhin drei doch einigerma�en verschiedene. Von
denen ich gerade mal eine halbwegs kenne. Und du offenbar auch keine gut
genug. :-)
> ich muss bremsen k�nnen um mich bewegen zu k�nnen? Macht physikalisch
> gesehen nicht viel Sinn.
Physikalisch nicht, aber unter dem Aspekt der Verkehrssicherheit und der
Gesundheit. Ich finde, das wird gerade etwas gar zu albern.
> Du sagst Quelltext ist schlicht Text, ich sage dass das sicherlich so
> ist, dass du den aber ohne IDE ja offensichtlich nicht editieren oder
> gar schreiben willst.
Richtig. Aber das muss mich doch nicht hindern, ihn n�tigenfalls als das
zu bearbeiten, was er ist, n�mlich Text. Wenn es denn Sinn ergibt, mit
einem entsprechenden Werkzeug.
>> Wir hatten doch ziemlich �bereinstimmend festgestellt, dass eine IDE
>> heute f�r Java eben kein optionales Tool ist, wenn es um professionelle
>> Entwicklung geht. Genau dar�ber lamentierst du doch. St�rt dich, dass
>> die IDE nicht fest verdrahtet ist, sondern du sie dir aussuchen kannst
>> oder was?
>
> optional in dem Sinne das ich notfalls und ineffizient Javatext auch in
> einem simplen Editor ohne IDE editieren kann
Sorry, aber entweder du hast mittlerweile v�llig vergessen, was du
eigentlich beweisen willst oder du betreibst Rabulistik und Vernebelung
der ganz wilden Sorte. Wie auch immer... mir ist f�r diese Sorte
Diskussion meine Zeit zu schade. Die hat dann doch zu wenig mit meinen
Erfahrungen und damit zu tun, was *ich* an Java problematisch finde.
In diesem Sinne... nichts f�r ungut, aber f�r mich ist der Thread beendet.
Gru�,
Michael
Jochen Theodorou
> "Jochen Theodorou"
> [...]
>> Nachteile von IDEs. Nun mal abgesehen dass man APIs nicht mehr lernt,
>> sondern sich einfach auf Codecompletion verl�sst und dabei
>> Hilfsklassen vollkommen ignoriert,
>
> Ich glaube nicht, dass das einen gro�en Unterschied macht. Wenn es die
> Codecompletion nicht geben w�rde, w�rde man eben in der Doku suchen und
> genauso wahrscheinlich Fehler machen.
nicht wenn in der Doku die Hilfsklasse genannt ist.
>> abgesehen davon dass man sich st�ndig irgendwelchen Code generieren
>> l�sst,
>
> Seltsamerweise kenne ich nur wenige Leute, die diese generierten
> Code-Schnipsel verwenden. Ich verwende die Dinge zum Beispiel auch
> nicht. Ich kann nicht einmal sagen, warum ich das nicht mache.
> Vielleicht weil ich jedes Mal nach der Abk�rzung suchen m�sste und in
> der selben Zeit den Code schon selber geschrieben habe.
ich mag es nicht, weil ich dann immer die Methode suchen muss ;)
>> abgesehen davon dass die meisten IDEs ware Monster sind (Eclipse l�uft
>> bei mir nicht unter 2GB und was weiss ich wie viel permgen) was
>> Speicher und CPU-Last betrifft,
>
> Auch wenn ich die 2 GB nicht nachvollziehen kann, gebe ich Dir
> grunds�tzlich recht. Die IDEs sollten wirklich mal eine Di�t machen.
unter 64bit ist es wirklich schlimm... weder IntelliJ IDEA noch Eclipse
Ganymed laufen da bei mir mit den Standardeinstellungen in brauchbarer
Weise.
>> abgesehen davon dass die meisten IDEs v�llig �berladen sind mit
>> features, die niemand braucht,
>
> Meine vollste Zustimmung. Ich finde, die Dinger sind teilweise so
> �berladen, dass sie einen ergonomischen Supergau darstellen. Aber Emacs
> und Vi mit zahlreichen Tastenkombinationen sind auch ein ergonomischer
> Supergau.
ja... Ich finde da IntelliJ IDEA sogar noch ein bischen schlimmer. Bei
Eclipse kann man ja in der Regel sich durch die Men�s hangeln um etwas
zu finden. Bei IDEA scheint es manchmal nur die Tastenkombination zu
geben und nirgends eine Referenz ausser in der Hilfe... Da muss man aber
auch erstmal wissen,dass das existiert. Ich weiss nicht wie oft ich zum
Beispiel suchen musste wie die Tastenkombination war um den Sourcecode
zu formatieren. Und nat�rlich kann ich mir da meine eigene
Tastenkombination definieren, aber dann unterhalte dich mal mit jemanden
anderen, der diese IDE einsetzt und pl�tzlich fragt dieser entsetzt ob
du wirklich die Tastenbelegung umdefiniert hast.
>> abgesehen davon dass ich ewig warten muss bis die IDE hochgefahren ist
>> wo ich doch nur eine Zeile kurz �ndern wollte,
>
> Auch hier hast Du meine Zustimmung. Allerdings w�rde ich f�r eine Zeile
> Code die IDE nicht hochfahren. Solche Arbeiten werden dann bis zum
> n�chsten regul�ren IDE-Start verschoben.
bin ich leider zu zerstreut f�r.
>> abgesehen davon dass viele keine build skripte irgendeiner Art machen,
>
> Ich gebe Dir Recht, dass es �rgerlich ist, wenn sich die Ausf�hrung
> zwischen IDE und Standalone unterscheidet. So k�nnen gerne auch mal
> Fehler �bersehen werden, weil zum Beispiel andere Bibliotheken verwendet
> werden. Aber Eclipse soll doch dort zumindest eine L�sung anbieten.
das ist aber nicht wirklich integriert.
> Auch
> wenn ich nur wenige Personen kenne, die damit umgehen k�nnen. Ich kann
> es nicht. Solche elementaren Dinge sind teilweise einfach zu kompliziert
> gel�st.
yupp
>> abgesehen davon dass die meisten IDEs in der Bedienung nicht
>> sonderlich einheitlich sind,
>
> Untereinander oder innerhalb einer IDE? Letzteres ist mir noch nicht
> aufgefallen. Vielleicht hast Du ein Beispiel?
unereinander meinte ich. Wenn du mal eine IDE wechseln musst, dann ist
das echt schmerzhaft... jedenfalls war das halbe Jahr mit IntelliJ IDEA
so bei mir. Ich glaube mit Netbeans und Eclipse ist das nicht so
schlimm, weil die Bedienkonzepte vergleichbarer sind.
>> abgesehen davon dass eine IDE ein ausdrucksschwache Sprache auch nicht
>> wirklich verbessern kann,
>
> Das ist aber wohl auch nicht wirklich das Ziel gewesen.
nunja, manche hier scheinen aber so zu tun.
>> abgesehen davon dass fehlende Konzepte nicht einfach durch die IDE
>> erg�nzt werden k�nnen...
>
> Was wohl auch nicht das Ziel gewesen ist.
W�re aber zum Teil w�nschenswert
>> nein.. ich habe nicht wirklich etwas gegen IDEs, nur das man so gro�e
>> IDEs braucht um wirklich was mit der Sprache anfangen zu k�nnen... ja,
>> gegen diese Kombination habe ich etwas.
>
> Ich habe nicht dein Eindruck, dass die Sprache das Problem ist. F�r Java
> braucht man grunds�tzlich keine IDE. Aber je gr��er ein Projekt wird,
> desto mehr ben�tigt man eine IDE. Dies ist meiner Erfarhung nach
> unabh�ngig von der Sprache.
die Codegr��e ab der das notwendig ist, ist aber sehr wohl von der
Sprache abh�ngig.
>>> Wenn man ein schnelles kleines 5-Zeilen-Script basteln will, braucht
>>> man natuerlich auch keine IDE, aber dann waer' es auch normalerweise
>>> nicht sehr sinnvoll, Java dafuer einzusetzen.
>>
>> Ach? passiert aber oft genug
>
> Aber nur von Leuten, die nur Java k�nnen/installiert haben und daher den
> bequemsten Weg w�hlen. Normalerweise sollte man die geeigneste Sprache
> w�hlen, sofern die Kosten nicht unverh�ltnism��ig sind.
ok, einfaches Beispiel... kopiere eine Datei von A nach B. Ist es nur
dass, dann bist du mit einem einfachen Kommandozeilenbefehl gut
beraten... brauchst du das innerhalb deines Programmes sieht es schon
wieder anders aus. Auch 5-Zeiler wachsen schnell... Ich habe mir zum
Beispiel ein Shell script geschrieben, damit ich mir bei einem merge die
Pfade nicht immer merken muss. und kurz danach habe ich es erweitert
damit man die Revision einfacher eingeben kann und dann habe ich es
ge�ndert dass bei einem Problem mit dem merge automatisch abgebrochen
wird, dann habe ich hinzugef�gt, dass der text des changesets angezeigt
wird usw...
[...]
>> wie gesagt, das orientiert sich IMHO an der Codegr�sse und in einer
>> ausdrucksst�rkeren Sprache kann man das gleiche in mit weniger Code
>> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
>> erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE in
>> Java fr�her als in zum Beispiel Ruby.
>
> Das mag sein, aber die Schwelle ist vermutlich so niedrig, dass es in
> der Praxis unabh�ngig von der Sprache kaum professionelle Programme
> geben wird, die ohne IDE geschrieben wurden. IMHO
Nunja, ich weiss von Leuten die 40k Zeilen Groovycode einsetzen und
daf�r hatten sie nur Synaxhighliting. Damals konnte das plugin noch
nicht mehr.
Gruss theo
Jochen Theodorou
> Jochen Theodorou schrieb:
>
>> wieso? Findest du Closures ansich schlecht, oder nur deren Umsetzung f�r
>> Java? Von anderen Sprachen kenne ich Bl�cke/Lambdas/richtige Closures,
>> als recht m�chtiges Werkzeug. ich habe die jetzt einfach mal
>> zusammengefasst, da sie zwar nicht gleich sind, aber doch �hnlich genug
>
> Ich habe mich noch nicht weiter damit besch�ftigt, wie die Pl�ne
> aussehen, Closures in Java umzusetzen. Aber es sollte mich sehr wundern,
> wenn es auf eine Weise geschieht, die Java - die Sprache - sch�ner,
> einfacher oder konzeptionell stimmiger macht. Schlie�lich muss ja alles
> abw�rtskompatibel bleiben...
stimmt, ja
> Prinzipiell hab ich garnichts gegen schicke Sprachfeatures. Aber wenn
> immer drangestrickt wird, dann wird das Ganze immer inkonsistenter und
> es gibt immer neue Ausnahmeregeln.
auch das stimmt. Wobei ich das Proposal von Gafter durchaus f�r
brauchbar halte...die Typdeklarationen st�ren allerdings sehr.
> Nehmen wir Autoboxing. Schlimm genug, dass es Primitivtypen gibt, aber
> das wird sich bei Java wohl nicht mehr �ndern. Nun gut... also
> Autoboxing. Sieht ja einfach genug aus. Aber neulich hatte ich das
> Vergn�gen, mir anzusehen, wie die Aufl�sung von �berladung aussieht,
> wenn nicht nur Parameter von Primitivtypen und Referenztypen vorkommen,
> sondern auch noch Autoboxing eine Rolle spielt. Da kriegst du graue
> Haare, das kannst und willst du keinem Anf�nger erkl�ren. Genau
> Letzteres ist mein Job.
hehe, ja, habe ich mich auch mal mit besch�ftigt. In so einem Fall ist
eine IDE wirklich Gold wert, weil dann kannst du sehen welche Methode
aufgerufen wird... Andererseits ist es traurig, dass man f�r sowas eine
IDE braucht.
> Dasselbe mit parametrischer Polymorphie. Prinzipiell fein, aber die
> Umsetzung in Java mit Typ-Erasure... krieschischplack.
wieder Zustimmung meinerseits.
Gruss theo
Jochen Theodorou
> <s.ra...@googlemail.com>
>> On 2 Okt., 15:23, Jochen Theodorou <blackd...@gmx.org> wrote:
>>
>> > class X {
>> > String foo
>> > int bar
>> >
>> > }
>> >
>> > sehe ich auf einen Blick, dass da praktisch keine Logik drin steckt,
>> > sich also um ein POJO handelt
>>
>> DTO oder VO, nicht POJO.
>
>
> Data Transfer Object und Value Object waren bisher f�r mich das Gleiche.
Also ich versuche mich da mal, allerdings erhebe ich keinen Anspruch auf
Richtigkeit.
VO = Value Object
Kapselung eines einzelnen Wertes in einer Klasse, vielleicht sogar ohne
setter, eventuell immutable. Integer w�re da ein Beispiel f�r
DTO = Data Transfer Object
Kapselung mehrere Werte in einer Klasse. DTO undVO wird oft zusammengeworfen
POJO = Plain Old Java Object
hatte ich immer als ein einfaches Bean ohne jede Logik verstanden, aber
es scheint wohl eher darauf anzukommen, dass keinerlei Annnotationen
verwendet werden.. auch keinerlei Interfaces und Klassen aus
irgendwelchen Frameworks. Also so zu sagen "framework free". Was da
gemacht wird scheint eher unwichtig zu sein. Damit kann ein VO auch ein
POJO sein. Ebenso f�r DTO
Gruss theo
Jochen Theodorou
nunja, das ist meistens f�r Beans gedacht. Da hat man meistens beides
und meistens in gleicher Sichtbarkeit, die �blicherweise public ist. F�r
den Fall ist es also perfekt. Wenn du etwas anderes willst, dann musst
du selbst daf�r sorgen.
class X {
final String foo
int bar
private int getBar() { return bar}
}
hier h�tte man zum Beipsiel einen getter f�r foo, aber keinen setter.
der getter f�r bar w�re private. Wir hatten fr�her eine Annotation
@Property, aber die empfanden die meisten als h��lich... h�tte dann so
ausgesehen:
class X {
@Property String foo
@Property int bar
}
Griuss theo
Daniel Urban
> Daniel Urban schrieb:
>> Ich glaube nicht, dass das einen gro�en Unterschied macht. Wenn es die
>> Codecompletion nicht geben w�rde, w�rde man eben in der Doku suchen und
>> genauso wahrscheinlich Fehler machen.
>
> nicht wenn in der Doku die Hilfsklasse genannt ist.
Nun gut, miene Codecompletion gibt mir die M�glichkeit die Doku zu lesen.
Und meistens steht dort die Hilfklasse wohl eher nicht drin. Aber egal...
>>> abgesehen davon dass man sich st�ndig irgendwelchen Code generieren
>>> l�sst,
>>
>> Seltsamerweise kenne ich nur wenige Leute, die diese generierten
>> Code-Schnipsel verwenden. Ich verwende die Dinge zum Beispiel auch nicht.
>> Ich kann nicht einmal sagen, warum ich das nicht mache. Vielleicht weil
>> ich jedes Mal nach der Abk�rzung suchen m�sste und in der selben Zeit den
>> Code schon selber geschrieben habe.
>
> ich mag es nicht, weil ich dann immer die Methode suchen muss ;)
Mmm... ich dachte wir reden �ber for, main usw. Da muss man eigentlich
nichts suchen. Au�erdem schrieb ich, dass ich nicht genau wei�, warum ich
sie nicht anwende. Aber grunds�tzlich mag ich keine K�rzel oder
Tastenkombinationen auswendig lernen. Das ist besonders schwierig, wenn jede
IDE unterschiedliche hat.
>> Untereinander oder innerhalb einer IDE? Letzteres ist mir noch nicht
>> aufgefallen. Vielleicht hast Du ein Beispiel?
>
> unereinander meinte ich. Wenn du mal eine IDE wechseln musst, dann ist das
> echt schmerzhaft... jedenfalls war das halbe Jahr mit IntelliJ IDEA so bei
> mir. Ich glaube mit Netbeans und Eclipse ist das nicht so schlimm, weil
> die Bedienkonzepte vergleichbarer sind.
Keine Frage, wie ich oben schon schrieb. Ich kann mir keine Shortcuts
merken, weil ich mit VS C# programmiere und in Eclipse Java. Deswegen muss
alles �ber Men� und Kontextmen� funktionieren.
> [...]
>>> wie gesagt, das orientiert sich IMHO an der Codegr�sse und in einer
>>> ausdrucksst�rkeren Sprache kann man das gleiche in mit weniger Code
>>> ausdr�cken. Was also ein grosses Projekt in Java ist, ist vielleicht
>>> erst ein mittleres in Ruby. Anders ausgedr�ckt, man braucht die IDE in
>>> Java fr�her als in zum Beispiel Ruby.
>>
>> Das mag sein, aber die Schwelle ist vermutlich so niedrig, dass es in der
>> Praxis unabh�ngig von der Sprache kaum professionelle Programme geben
>> wird, die ohne IDE geschrieben wurden. IMHO
>
> Nunja, ich weiss von Leuten die 40k Zeilen Groovycode einsetzen und daf�r
> hatten sie nur Synaxhighliting. Damals konnte das plugin noch nicht mehr.
Solche Leute kennt wohl jeder, aber dass sind dann zumeist wirklich sehr
spezielle Personen. Ich denke, dass man das nicht auf alle Entwickler
anwenden sollte. Die Folgen w�ren vermutlich dramatisch.
Gru�,
Daniel
Jochen Theodorou
> "Jochen Theodorou"
>> Daniel Urban schrieb:
>>> Seltsamerweise kenne ich nur wenige Leute, die diese generierten
>>> Code-Schnipsel verwenden. Ich verwende die Dinge zum Beispiel auch
>>> nicht. Ich kann nicht einmal sagen, warum ich das nicht mache.
>>> Vielleicht weil ich jedes Mal nach der Abk�rzung suchen m�sste und in
>>> der selben Zeit den Code schon selber geschrieben habe.
>>
>> ich mag es nicht, weil ich dann immer die Methode suchen muss ;)
>
> Mmm... ich dachte wir reden �ber for, main usw. Da muss man eigentlich
> nichts suchen.
ich dachte da jetzt an das automatische generieren von Gettern und Settern
> Au�erdem schrieb ich, dass ich nicht genau wei�, warum
> ich sie nicht anwende. Aber grunds�tzlich mag ich keine K�rzel oder
> Tastenkombinationen auswendig lernen. Das ist besonders schwierig, wenn
> jede IDE unterschiedliche hat.
das stimmt nat�rlich
Gruss theo
Jochen Theodorou
> Jochen Theodorou <blac...@gmx.org> wrote:
>> ehem... die ant integration in Eclipse ist ja wohl ein Witz... es sei
>> denn ich habe da was ï¿œbersehen.. Aber bei mir sind ant un der interne
>> Compiler separat, ant ist als externes Tool in einer eigenen runtime
>> configuration definiert, sogar fullbuilds in eclipse ignorieren ant.
>
> Das is aber einfach, man packt "precompile" und "postcompile" targets von
> ant als Builder ins Projekt. Oder man macht sich dafï¿œr eben ein ANT Target
> das man manuell aufruft. Damit kann man dann die meisten jaxb oder xdoclet
> Generator Scenarien einigermassen erschlagen.
ich kann das als builder ins Projekt packen? Oh... geschafft... war sehr
einfach... Oh ja, das ist echt toll ;) Danke Bernd.
> Das eigentliche Problem ist ja ANT, das kein vernuenftiges dependency
> checking macht.
du meinst bei den targets? Ja, das stimmt schon, aber in meinem Fall ist
das nicht so wild
Gruss theo
Thomas Thiele
>> Eine IDE sollte ein *Hilfmittel* sein, keine Grundvorausetzung.
> Ooooh, ein Postulat.
Eine schlichte Anforderung an ein Werkzeug.
Eine Metawerkzeug muss eben nicht sein.
> Ah. Na also, dann ist dein Postulat - f�r dich - ja erf�llt.
Ja. Ich habe ja nie behauptet, dass Java nur mit IDE beherrschbar w�re.
> Wenn dem so w�re. Belege das bitte ggf. anhand von entsprechen gro�en in
> Ruby mit vi gebauten Projekten.
Also erstens benutze ich Ruby nicht, sondern Python.
Zweitens finde ich Ultraedit besser als vi.
Auf den Python-Seiten findest du bestimmt gro�e Projekt die mit Python
gemacht wurden. Ich selber habe schon eine komplexe
Client-Server-Anwendung geschrieben.
Inklusive GUI.
Das in Java gegossen h�tte bestimmt die 3fache Gr��e.
Zu belegen ist im �brigen *nicht*, dass es mehr gro�e Java-Projekte
*gibt*, als Python/Ruby-Projekte, sondern das Java prinzipiell f�r
gr��ere Projekte Vorteile bietet.
Thomas Thiele
>> Eine IDE sollte ein *Hilfmittel* sein, keine Grundvorausetzung.
> Ja. Warum ? Das sagst Du jetzt so. Gibt es dafuer auch objektive
> Gruende, oder muessen wir das einfach glauben ?
- Wenn ein Problem mit einem Werkzeug bearbeitet wird welches wiederum
nur mit einem Metawerkzeug beherrschbar ist, dann ist das eine
Indirektion mehr enthalten. Praktisch ist dies eine Fehlerquelle oder
Einschr�nkend. Man hat auch eine Abh�ngikeit mehr.
- Man kann vermuten, dass ein Werkzeug welches ohne Metawerkzeug
beherrschbar ist stabilier und sicherer ist.
- Ein zus�tzliches Metawerkzeug wird ebenso dann zu *noch mehr*
Effektivit�t f�hren k�nnen. Wenn man davon ausgeht dass diese
Metawerkzeuge das Werkzeug effektiver handhabarer machen.
- Erfahrungsgem�� sind Softwareprojekte die IDE-unabh�ngig sind besser.
(plattformunabh�nginger, umgebungsunabh�ngiger, robuster,
wartungsfreundlicher usw.)
Da muss nicht zwingend eine Kausalit�t zur IDE bestehen. Aber es ist
dieselbe Denkweise "was bei *mir* l�uft, hat �berall zu laufen,
ansonsten machen die anderen was falsch". Leider korriliert das.
>> Aber nebenbei ich habe auch schon ganze Java-Projekte mit Ultraedit
>> gemacht.
> Nichts gegen Dich, aber da wuerde ich sagen - schoen bescheuert.
Wieso?
Es gibt keine Nachteil. Java ist keine Sprache die zwingend eine IDE
braucht. Auch wenn neue Techniken und Frameworks und eventuelle neu
Sprachfeatures das versuchen zu �ndern.
Umkehrschlu�: wenn du es nicht schaffst ein Projekt gleich welcher
Sprache mit Editor und Kommondazeile zu bauen, verf�gst du
m�glicherweise gar nicht �ber die wirklichen Kenntnisse. Du bist
IDE-abh�ngig.
Ich war es btw auch. Zwar nicht mit Java, sondern mit Borland C++.
Ich weiss also wovon ich rede. Meine Kenntnisse in C stiegen enorm
als ich gezwungen war C(++) zu Fu� zu programmieren und makefiles
per Hand getippt habe. (war btw. im Praktikum in einer Firma)
> Ok. Grosses Projekt, sagen wir wir mal, Office.
Was meinst du mit "Office"?
Zu unkonkret.
Java ist dafuer
> geeigneter, als, z.B., QuickBasic. Oder ein anderes Projekt - ein CMS
> Server. Java ist hier geeigneter als, z.B., Assembler.
a) Behauptungen
b) vergleich mit Assembler ist l�cherlich
> z.B., C (dank des GC).
a) Wer nicht mit Speicher umgehen kann, verdient keinen!
Wer Fehler bei der Speicherverwaltung baut, baut h�chstwahrscheinlich
auch fachlicher Fehler in �hnlicher H�he.
b) Da die Ressourcenfreigabe in Java fast immer explzit erfolgen muss,
eben weil kein Destructor beim Verlassen des Scopes bei einer
Auto-Variable aufgerufen werden muss, ist das die h�ufigste Fehlerquelle.
Ich hatte verh�ltnism�ssig mehr versteckte Ressorucenprobleme (nicht
freigegebene connections, memory leaks) in Java als Speicherproblem in
C(++). Das ist einfach so. Empirische Erfahrung.
> Genug ?
Nein. Denn du nanntest bisher nur �bliche Vorurteile.
Also ob der GC die Wunderwaffe w�re...
> Nein, weil Java eine relativ "hohe" Sprache mit nuetzlichen Sachen wie
> GC ist. Das ist fuer ein grosses Projekt ziemlich toll, fuer ein
> 5-Zeilen-Batchscript aber relativ egal.
Das bietet Python (und um den Vergleich geht es ja) auch und zwar besser
(just-in-time-destructor).
Und in C++ kannst du dir das f�r dein Framework selber zimmern.
Der Witz ist, dass man den GC in C++ gar nicht braucht!
Denn Speicherverwaltung ist sehr selten das Problem in normalen Projekten.
Nat�rlich *gibt* es diese Problem. Ich habe derzeit selber eins in C++.
Ein richtigen fiesen Bug bei dem bei einer WIN-API Funktion mir alles um
die Ohren fliegt ohne das ich dem Problem n�her komme.
(gibt in der anderen NG schon l�nger her)
Nur hinkt der Vergleich. Denn sowas w�rde man mit Java gar nicht machen
und zweitens *ist* "schmutzige" C-Pointer-Memory-Verwaltung involviert.
Was man bei einem C++-Office-Projekt nicht machen w�rde.
> Ja, vi-script ist ziemlich eng mit vi verbunden.
Aha...
> Ja, und ? Wie gesagt, so ist das eben. Wo genau wird das negativ ?
Die Abh�ngigkeit existiert gar nicht!
Sie wird herbeigeredet.
Eclipse macht viele Sachen toll und einfach, aber es ginge auch mit
Ultraedit oder vi.
>> Warum sollte es w�nschenswert erscheinen eine IDE zu benutzen zu
>> m�ssen?
> Warum nicht ?
Zwang!
Nochmal: ich bin nicht gegen IDEs, ich bin gegen den Zwang eine benutzen
zu m�ssen. Und auch nochmal, ich sehe bei Java diesen Zwang den du
versuchst herbeizureden gar nicht.
> Ja, so wie Java Bytecode ueberfluessig und Bytecode Maschinencode
> ueberfluessig macht.
Genaugenommen ja. Alles �ber einer Turingmaschine ist �berfl�ssiger Luxus...
Ernsthafter: man braucht nur zwei(!) Sprachen. Eine die tats�chlich
abl�uft (Befehle f�r CPU, bzw. VM) und eine wo der Mensch in stark
abstrahierter Form die Logik schreibt.
Paul Ebermann
> J. Stoever schrieb:
> > Und wenn ich jetzt argumentieren wuerde, dass APIs schlecht sind, weil
> > man sie braucht, dann haettest Du damit auch voellig recht (wenn wir
> > jetzt mal das voellig sinnfreie dabei ausser acht lassen).
>
> ehm.. warum soll ich das sinnfreie dabei ausseracht lassen? Gibt es
> �berhaupt eine Sprache bei der man ohne API-Zugriff ein Hello World
> ausgeben kann? Naja, gibt es bestimmt ;)
Hmm, haengt ein bisschen davon ab, wo du die Grenze zwischen
API und Sprache ziehst.
In Lisp wird das Ergebnis eines Ausdruckes erst
einmal ausgegeben, wenn man in der normalen
Read-Eval-Print-Loop ist. Damit wuerde also ein
Hello World so aussehen:
"Hello World"
In Unlambda sieht so ein Programm so aus:
`r```````````.H.e.l.l.o. .w.o.r.l.di
Dabei sind wohl `, r, i als Sprachelemente
und die .H etc. als API-Zugriff aufzufassen -
oder alternativ ist nur ` ein Sprachelement
und alles andere API, oder alles Sprachelemente.
Nicht ganz eindeutig.
Paul
--
Nun ludigxas: : ()
Daniel Urban
> J. Stoever schrieb:
[...]
> - Wenn ein Problem mit einem Werkzeug bearbeitet wird welches wiederum
> nur mit einem Metawerkzeug beherrschbar ist, dann ist das eine Indirektion
> mehr enthalten. Praktisch ist dies eine Fehlerquelle oder Einschr�nkend.
> Man hat auch eine Abh�ngikeit mehr.
Das muss nicht so sein, ist aber vermutlich oft so. Aber Du vergisst den
wesentlichen Vorteile: die Reduzierung der Komplexit�t und die im konkreten
Fall besser Ergonomie.
Beispiel: Assembler -> Java, auch wenn Java kein Metatool ist, aber die
Indirektion bietet deutliche Vorteile, wenn auch Einschr�nkungen.
> - Man kann vermuten, dass ein Werkzeug welches ohne Metawerkzeug
> beherrschbar ist stabilier und sicherer ist.
Du kannst vieles vermuten, es muss aber nicht korrekt sein. Kannst Du das
auch begr�nden?
> - Ein zus�tzliches Metawerkzeug wird ebenso dann zu *noch mehr*
> Effektivit�t f�hren k�nnen. Wenn man davon ausgeht dass diese
> Metawerkzeuge das Werkzeug effektiver handhabarer machen.
Verstehe ich nicht. Kannst Du das mal umformulieren, so dass ich es
vielleicht besser verstehe?
> - Erfahrungsgem�� sind Softwareprojekte die IDE-unabh�ngig sind besser.
Deine Erfahrung.
> (plattformunabh�nginger, umgebungsunabh�ngiger, robuster,
> wartungsfreundlicher usw.)
Mal abgesehen, dass ich plattformunabh�ngig und umgebungsunabh�ngig nicht
f�r Qualit�tsmerkmale halte, w�re hier eine Abgrenzung hilfreich. Au�erdem
solltest Du noch einmal erkl�ren, ob Du das "besser" auf das Endprodukt
(Programm) oder auf den Prozes (Softwareprojekt) beziehst.
Wie ein Softwareprojekt robuster sein kann, musst Du mir wohl auch mal
erkl�ren. Wenn Du meinst, dass die Software robuster ist, kann ich den
Zusammenhang zur IDE nicht entdecken. Der Code wird immer noch vom
Entwickler geschrieben und sollte sich in beiden F�llen nicht gro�artig
unterscheiden.
Und das es wartungsfreudlicher ist, w�rde ich bestreiten. Eine IDE bietet
hierf�r viel zu viel Komfort.
> Da muss nicht zwingend eine Kausalit�t zur IDE bestehen. Aber es ist
> dieselbe Denkweise "was bei *mir* l�uft, hat �berall zu laufen, ansonsten
> machen die anderen was falsch". Leider korriliert das.
Das h�ngt doch von der Organisation des Softwareprojektes ab. In meinen
Projekten ist vorgeschrieben, dass jeder Entwickler die gleiche IDE mit der
gleichen Konfiguration benutzt. Die IDE wird hier sogar in der
Versionsverwaltung gepflegt.
[...]
> Es gibt keine Nachteil. Java ist keine Sprache die zwingend eine IDE
> braucht.
Ich brauche auch kein Auto um mich fortzubewegen, aber mit Auto bin ich
m�glicherweise schneller als zu Fu�.
> Auch wenn neue Techniken und Frameworks und eventuelle neu
> Sprachfeatures das versuchen zu �ndern.
Beispiele?
> Umkehrschlu�: wenn du es nicht schaffst ein Projekt gleich welcher Sprache
> mit Editor und Kommondazeile zu bauen, verf�gst du m�glicherweise gar
> nicht �ber die wirklichen Kenntnisse. Du bist IDE-abh�ngig.
Du musst irgend eine Zauber-IDE verwenden. Ich sehe nicht, was eine IDE zur
Zeit leistet, was nicht transparent w�re und somit dem Nutzer Kenntnisse
�ber Java (die Sprache) erspart.
Nebenbei: Auch mit einem Texteditor und Google kann ich Copy & Paste
Programmierung betreiben.
Gru�,
Daniel
Daniel Urban
> J. Stoever schrieb:
>
> a) Wer nicht mit Speicher umgehen kann, verdient keinen!
> Wer Fehler bei der Speicherverwaltung baut, baut h�chstwahrscheinlich auch
> fachlicher Fehler in �hnlicher H�he.
B�st Du Masochist? Warum sollte ich Hilfsmittel generell ablehnen, wenn sie
mir die Arbeit erleichtern? Ob ein Entwickler mit Speicher umgehen kann,
h�ngt nicht davon ab, ob er eine Sprache verwendet, die einen GC verwendet.
Es gibt auch Entwickler, die keinen GC verwenden und trotzdem nicht mit
Speicher umgehen k�nnen.
Die Frage ist doch nur, ob es mit einem GC einfacher ist, mit Speicher
umzugehen. Wenn dem so ist, dann sollte man ihn auch einsetzen. Ich kann das
bejahen und anscheinend werden das auch immer mehr.
> b) Da die Ressourcenfreigabe in Java fast immer explzit erfolgen muss,
> eben weil kein Destructor beim Verlassen des Scopes bei einer
> Auto-Variable aufgerufen werden muss, ist das die h�ufigste Fehlerquelle.
>
> Ich hatte verh�ltnism�ssig mehr versteckte Ressorucenprobleme (nicht
> freigegebene connections, memory leaks) in Java als Speicherproblem in
> C(++). Das ist einfach so. Empirische Erfahrung.
Deine Erfahrung!
Das ist doch eine Frage der individuellen Erfahrung. Ein Anf�nger in C(++)
wird viele Speicherfehler machen. Ein Fortgeschrittener in Java wird wenige
Speicherfehler machen. Das bezieht sich sowohl auf die Erfahung generell in
der Software-Entwicklung als auch in der konkreten Sprache.
Gru�,
Daniel