Re: Neue Attribute einem Objekt hinzufügen

Hi,

Jochen Theodorou wrote:
Schrieb ich doch schon mehrfach: Ich meine mehreres: Fehler bei Aufruf von Methoden, die es nicht gibt, Code-Completion und Refactoring. Und natürlich "Eclipse-F3"-mäßige Navigation im Code.

andererseits aber macht eine Sprache wie Java es auch erforderlich eine IDE zu benutzen, findest du nicht?

Völlig richtig! Andererseits denke ich, dass man in allen anderen Sprachen auch - wenn man dort denn größere Projekte bearbeitet - eine IDE braucht, um produktiv zu sein. Oder?

Gib' doch mal ein Beispiel, wo dich der Compiler behindert! (Von type-erasure-Tücken mal abgesehen, weil wir uns da ja einig sind, dass Java da Probleme hat (was aber kein generelles Problem von statischer Typisierung ist).)

ok.. sagen wir mal wir haben eine Art Taskmanager geschrieben, der auf Runnables operriert und diese der Reihe nach abarbeitet.

class TaskManager {
public void addTask(Runnable r) {..}
public void execute(){...}
}

Plötzlich wird es nötig eine Dateioperation in einem dieser Tasks zu machen und es stellt sich die Frage wie denn die IOException behandelt werden soll. Das ist ein ganz schöner Mist, denn wie soll amn das so fixen, that einerseits das Produkt noch mit der letzten Version kompatibel ist und andererseits diesen Fall korrekt behandelt?
...

Alles, was Du hier beschreibst, lässt sich auf ein einziges Problem zurückführen - nämlich, dass IOException eine checked Exception ist, und dein TaskManager dieses nicht berücksichtigt.

Letztendlich geht es also um checked/unchecked Exceptions. Darüber ließe sich trefflich streiten (ich habe da auch eine gespaltene Meinung!), aber das ist eine ganz andere Baustelle!

Kannst Du mal ein *richtiges* Beispiel geben, wo das statische Typsystem Dich behindert?

Mich würde wirklich mal interessieren wie andere das Problem lösen.

Entweder die IOException in eine RuntimeException verpacken, oder - wenn ich denn selbst der Entwickler der nötigen Schnittstellen bin, gleich sagen: "Wenn ich - in diesem Beispiel - diverse 'Tasks' habe, die gänzlich unterschiedliche Dinge machen, bei denen viel schief gehen kann, was ich niemals vorhersehen kann, ja mein Gott, dann steht da natürlich in der Methoden-Signatur auch ein 'throws Exception' drinnen". (Leider bin ich nicht der Entwickler des Interfaces java.lang.Runnable ;-)

Und natürlich wäre ein redesign im Javafall einfacher hier, das zeigt dann auch warum die ganzen Refactoring notwendig sind. In einer dynamischen Sprache wäre das eventuell garnicht notwendig.

Nun, die meisten Refactorings sind IMHO notwendig, weil sich die fachlichen Anforderungen ändern (sonst muss ich an das Programm ja gar nicht mehr 'ran' gehen). Aber gut, manche Refactorings sind vielleicht wirklich darauf zurück zu führen, insofern erkenne ich deinen Punkt an.

Ich spreche wie gesagt nicht nur vom Compiler, sondern speziell von der IDE mit Code-Completion und Refactoring. Sowas spart *enorm* Zeit - nicht nur bei der Entwicklung, sondern speziell auch bei der Wartung von Software.


ach du meinst dann so Dinge wie das Neuschreiben von sortieralgorithmen, weil jemand die Bibliothek dafür nicht kennt?


Nein, das meinte ich nicht. Wie kommst Du darauf? Ich meinte das, was ich schrieb.


weil sort nunmal keine Methode eines Array ist in Java,

Für's Protokoll: Von Arrays schrieb ich gar nichts! :-)

> auch wenn es
eine Methode zum Sortieren in der API gibt.

Ja, Arrays sind in Java nicht 100%ig schön in die Sprache intergriert (wobei das IMHO überbewertet (*) wird). Genau wie die nativen Typen nicht 100%ig schön integriert sind (was IMHO aber auch überbewertet (*') wird, zumal es dank der Krücke Autoboxing besser geworden ist). Dass bei Generics auch Verbesserungen möglich wären, sind wir uns auch einig. Aber all diese Probleme sind nicht auf ein statisches Typsystem zurückzuführen.

(*) Mit "überbewertet" meine ich: Man muss zwar nicht aufwändig ein Beispiel konstruieren, um zu zeigen, wie häßlich das manchmal ist - in jedem größeren Projekt kommt so ein häßlicher Code vor. Aber in der Regel belaufen sich diese Sellen auf vielleicht 0.1% des Codes.

> Ich will sagen
Code-Completion hilft die Methoden auf diesem Objekt zu finden, aber nicht die API zu verstehen.

Full ACK. Die API zu verstehen, erfordert viel mehr.

> Und andererseits wenn ich die API verstehe,
dann brauche ich Code-Completion weit weniger oft. Code-Completion erhält die Illusion aufrecht mit einem gesunden Halbwissen im Code pfuschen zu können.

Seh ich anders: Wer die API nicht verstanden hat, kann auch nicht im Code rumpfuschen.

Code-Completion ermöglicht es (unter anderem), sprechende Klassen-, Methoden- und Variablen-Namen zu verwenden, ohne zu viel zu tippen zu müssen!

List<Map<String,String>> maps=new ArrayList<Map<String,String>>();

in wie fern nimmt mir die IDE das lesen ab?

Als dass ich nur den ersten Teil schreiben muss.

schon, aber ich muss trotzdem die ganze Zeile lesen, wenn ich Code warten muss.

Oh, sorry, da hab' ich mich verlesen! ;-)

Stimmt, das Lesen nimmt die IDE mir nicht ab (der Newsreader auch nicht - obwohl der Name das nahelegt ;-).

Aber es ist doch so: Normalerweise reicht es, wenn ich die Deklaration (linke Hälfte) überfliege, damit ich Bescheid weiss. Die "Initialisierung" (rechte Hälfte) enthält zwar auch wichtige Informationen ("ArrayList oder LinkedList?"), aber die interessieren vor allem beim Schreiben, nicht beim Lesen. Bzw. dann, wenn ich wirklich tiefer in den Algorithmus einsteigen will (z.B. noch Performance-Betrachtungen machen möchte).

Überhaupt: Dauert das Lesen dieser Zeile (bzw. das 'überspringen' der zweiten Hälfte) wirklich so lange? (Denn Du wolltest ja eigentlich ein Beispiel bringen, wo dich das Typ-System aufhält.)

Und mal ehrlich: Wie viele Sekunden brauchst Du, um selbst obiges (mit einer IDE) zu schreiben, im Vergleich zu dem Rest, der zur Software-Entwicklung gehört!?

zu lange ;)

Heisst konkret? ;-)

dass

def maps = []

eben schneller getippt ist und weniger Leseaufwand bedeutet. Mir also nicht so sehr den Blick auf den Code versperrt wie der ganze Typenkram da oben.

Dafür gehen aber auch (IMHO wichtige) Informationen nicht mehr aus dieser Zeile hervor. Diese Informationen muss ich mir erst anderweitig herleiten. Da dauert es doch im Endeffekt viel länger, den Code zu verstehen!

> Wenn Java wenigstens Typinferenz hätte, sodass man nicht alles
deklarieren muss, wäre schon viel gewonnen...

Du meinst das schon lange diskutierte

var maps=new ArrayList<Map<String,String>>();

? Könnte ich gut mit leben. (Wobei auch das IMHO nur eine Detail-Veränderung wäre, und am Prinzip der statischen Typisierung nicht viel ändern würde.)

Ciao,
Ingo

.

Relevant Pages

  • Re: Neue Attribute einem Objekt =?ISO-8859-1?Q?hinzuf=FCgen?=
    ... andererseits aber macht eine Sprache wie Java es auch erforderlich eine IDE zu benutzen, ... Plötzlich wird es nötig eine Dateioperation in einem dieser Tasks zu machen und es stellt sich die Frage wie denn die IOException behandelt werden soll. ... An diversen Stellen hat man code der Art "info".equalsstehen, wobei str der besagte String ist und natürlich nicht an jeder Stelle "info" als Vergleichswert herangezogen wird. ... Ein einfaches Refactoring kann man da aber vergessen. ...
    (de.comp.lang.java)
  • Re: Java and .NET (no Flames Pls)
    ... I stand corrected on the refactoring, but I had it with some third party ... problems with Java IDEs in other areas. ... from Visual Studio .NET 2003, which is already a great IDE overall. ...
    (microsoft.public.dotnet.framework)
  • Re: Neue Attribute einem Objekt =?ISO-8859-1?Q?hinzuf=FCgen?=
    ... ich praktsich nie als Fehler, selbst als ich noch Java ohne IDE programmiert habe oder in einer IDE, in der Autovervollständigung darin besteht, einfach alle bisher genutzten Methodennamen anzuzeigen. ... von Methoden, die es nicht gibt, Code-Completion und Refactoring. ...
    (de.comp.lang.java)
  • Re: Highspeed parsen - aber wie?
    ... Mit diesem Code in der Grammatik, ist der Unterschied im Aufwand dann nicht mehr so erheblich und - und darauf wollte ich eigentlich hinaus - bei mir kannst eben genau das machen, was du bei deiner Grammatik vermisst hast: Du kannst es mit voller IDE Unterstützung direkt in Java programmieren. ... Alles ist Java und ich kann die Vorteile der IDE ausnutzen. ...
    (de.comp.lang.java)
  • Re: Java-Rauschen (war: Re: Getter & Setter)
    ... also stimmst du mir zu dass Java ohne IDE schlecht nutzbar ist? ... Nun mal abgesehen dass man APIs nicht mehr lernt, sondern sich einfach auf Codecompletion verlässt und dabei Hilfsklassen vollkommen ignoriert, ... Oder wenn der Grad des Rauschen so unterschiedlich ist? ...
    (de.comp.lang.java)