Warum wird soviel in Java/C# entwickelt?



  • operator void schrieb:

    Selbst wenn man aus beiden Beispielen ganz stumpf templates macht, die alles annehmen, hat man nur in seltenen Fällen Fehler, die über die Compilezeit hinausgehen... das ist jetzt IMHO wirklich Kleinkram 🙂

    Je früher ein Fehler erkannt wird, desto besser, oder? Eine Java-IDE kann dir den Fehler hier schon dann anzeigen, wenn du die Zeile zuende getippt hast. Also weit vor dem Kompiliervorgang. 🙂 Wobei dieses Sprachfeature von Java eigentlich schon vor der Vermeidung von Fehlern interessant wird. Java bietet hier die Möglichkeit, eine bestimmte Art von Informationen formal in der Schnittstelle bekannt zu geben: Die Anforderungen an den Typ. In anderen Sprachen muss man diesbezüglich in der Dokumentation nachsehen oder nichtsprachliche Vereinbarungen, wie zum Beispiel eine bestimmte Namensgebung, einhalten und sich darauf verlassen.



  • Gregor schrieb:

    Eine Java-IDE kann dir den Fehler hier schon dann anzeigen, wenn du die Zeile zuende getippt hast. Also weit vor dem Kompiliervorgang.

    Er kompiliert jedesmal wärend ich was eintippe. Anders kann ich es mir nicht erklären.



  • Nein, das würde zu lange dauern. Er beschränkt sich dabei bestenfalls auf die aktuelle Übersetzungseinheit und wird keinesfalls Abhängigkeiten zu anderen Klassen testen.
    Ist mir aber nicht ganz klar, was das mit Java direkt zu tun hat. Theoretisch könnte man sowas auch für C++ realisieren (evtl. nur die aktuelle Funktion als Übersetzungsrahmen nehmen). Aber die meisten C++ IDEs sucken einfach hart, lediglich Visual Assist für VS hat mich echt mal zwischenzeitlich begeistert.

    Das muss einfach an der Komplexität der Sprache liegen. Was Java IDEs heute können, ist unglaublich. Man hat manchmal echt das Gefühl, die wissen genau, was du vorhast.



  • Optimizer schrieb:

    Nein, das würde zu lange dauern. Er beschränkt sich dabei bestenfalls auf die aktuelle Übersetzungseinheit und wird keinesfalls Abhängigkeiten zu anderen Klassen testen.
    Ist mir aber nicht ganz klar, was das mit Java direkt zu tun hat. Theoretisch könnte man sowas auch für C++ realisieren (evtl. nur die aktuelle Funktion als Übersetzungsrahmen nehmen). Aber die meisten C++ IDEs sucken einfach hart, lediglich Visual Assist für VS hat mich echt mal zwischenzeitlich begeistert.

    Das muss einfach an der Komplexität der Sprache liegen. Was Java IDEs heute können, ist unglaublich. Man hat manchmal echt das Gefühl, die wissen genau, was du vorhast.

    als c++ progger hat man eher manchmal das gefühl die pfuschen im code rum
    konnt mich noch ned dran gewöhnen



  • Rumpfuschen ist eine Sache. Ich rede von abartig intelligenten Hilfen ("Sie haben FooBar in BlubberBar umbennant. Foo scheint ein Namensbestandteil in ihrer Klassenhierarchie zu sein, möchten Sie alle Klassen dieser Hierarchie entsprechend umbenennen?") und Refactoring-Möglichkeiten.
    Ich möchte behaupten, für Java gibt es die besten IDEs.



  • C++ ist viel zu schwierig zu parsen. 🕶



  • Rumpfuschen ist eine Sache. Ich rede von abartig intelligenten Hilfen ("Sie haben FooBar in BlubberBar umbennant. Foo scheint ein Namensbestandteil in ihrer Klassenhierarchie zu sein, möchten Sie alle Klassen dieser Hierarchie entsprechend umbenennen?") und Refactoring-Möglichkeiten.
    Ich möchte behaupten, für Java gibt es die besten IDEs.

    Refactoring-Möglichkeiten haben die von SmallTalk-IDEs übernommen. Da ist sowas schon Ewigkeiten Standard.

    Entweder versteh ich Interfaces nicht oder Interfaces sind einfach nur abstrakte Klassen.

    Naja, man betriebt aber eine komplett andere Art von Objektorientierung. Wenn man von Klassen ausgeht, ist es so dass es meistens "ist-ein" Beziehungen sind. Bei Interfaces geht von eher von "ist" bezehungen aus (Foo ist serialisierbar, ...).



  • Interfaces sind aber auch definitiv nicht abstrakte C++ - Klassen, ich glaube aber, dass das der Vergleich sein sollte (wir haben ja über C++ geredet).
    Siehe folgenden Code:

    class Blubb : public Interface1, Interface2   // beide Klassen spezifizieren void foo();
    {
        // *grml*
    }
    
    ...
    
    myBlubb.foo();   //  *grml*
    

    Man kann es drehen und wenden wie man will: C++ hat IMHO keinen Support für Interfaces.
    btw. Ich denke, dass Interface sowohl 'ist' als auch 'ist ein' bedeuten kann. java.util.List ist ein Interface, eine ArrayList ist eine List. 🙂



  • Optimizer schrieb:

    Nein, das würde zu lange dauern. Er beschränkt sich dabei bestenfalls auf die aktuelle Übersetzungseinheit und wird keinesfalls Abhängigkeiten zu anderen Klassen testen.
    Ist mir aber nicht ganz klar, was das mit Java direkt zu tun hat. Theoretisch könnte man sowas auch für C++ realisieren (evtl. nur die aktuelle Funktion als Übersetzungsrahmen nehmen).

    Wenn solche Anforderungen direkt aus der Schnittstelle ersichtlich sind, dann sind diesbezügliche Checks eben deutlich schneller durchzuführen, als wenn man erst die dahinterliegende Methode oder Klasse übersetzen muss. Es muss halt nur überprüft werden, ob die Nutzung mit der Schnittstelle übereinstimmt.



  • Ach, darauf wolltest du hinaus. Ich Depp. Klar, templates on-the-fly zu übersetzen könnte aufwändig sein.


Anmelden zum Antworten