3. Dynamische Sprachen

Dynamische Sprachen

  • Z

    Also bis jetzt bin ich ganz zufrieden mit dem Refactoring von dynamischen Code. xD http://imageshack.us/f/444/58708825.png/

    0
  • ?

    hustbaer schrieb:

    Ich finde statische Typisierung und die darans resultierenden Fehlermeldungen des Compilers klasse.

    in der Tat verleiht es ein Gefühl von Macht, wenn man mit einem einzigen falschen Tastendruck im Quellcode eine 2 Bildschirmseiten lange Fehlermeldung provozieren kann. g++ mit stl zum Beispiel kann bei Fehlermeldungen recht erzählfreudig sein. In dynamischen Sprachen sehe ich selten mehr als eine oder ein paar Zeilen pro Fehler, oft ist die genaue Fehlerstelle sogar markiert, das nimmt einem jeden Spaß an der Fehlerjagd.

    hustbaer schrieb:

    Und zwar unter anderem zum Refactoren.

    nur damit ich's richtig verstehe: du refactorst, indem du dich von den Typfehler-Meldungen des compilers leiten läßt? (ist nicht böse gemeint, vielleicht meinst du ja was anderes)

    hustbaer schrieb:

    Nur leider sind automatisierte Tests in der Realität etwas, was lange nicht jedes Projekt hat.

    dafür kann eine dynamische Sprache ja nix. Es gibt frameworks wie SUnit.

    0
  • C

    buchstaben schrieb:

    oft ist die genaue Fehlerstelle sogar markiert

    Ou, was ein Luxus. 😃 👍

    0
  • M

    buchstaben schrieb:

    hustbaer schrieb:

    Ich finde statische Typisierung und die darans resultierenden Fehlermeldungen des Compilers klasse.

    in der Tat verleiht es ein Gefühl von Macht, wenn man mit einem einzigen falschen Tastendruck im Quellcode eine 2 Bildschirmseiten lange Fehlermeldung provozieren kann. g++ mit stl zum Beispiel kann bei Fehlermeldungen recht erzählfreudig sein. In dynamischen Sprachen sehe ich selten mehr als eine oder ein paar Zeilen pro Fehler, oft ist die genaue Fehlerstelle sogar markiert, das nimmt einem jeden Spaß an der Fehlerjagd.

    Das ist aber eine "Eigenheit" von C++. In anderen stark typisierten Sprachen, wie C#, Java, Delphi oder was auch immer hast du mindestens genauso klare und übersichtliche Fehlerausgaben.

    buchstaben schrieb:

    hustbaer schrieb:

    Und zwar unter anderem zum Refactoren.

    nur damit ich's richtig verstehe: du refactorst, indem du dich von den Typfehler-Meldungen des compilers leiten läßt? (ist nicht böse gemeint, vielleicht meinst du ja was anderes)

    Nein, ich glaube du hast ihn richtig verstanden. Das ist durchaus eine gute Hilfe beim Refactoren, mache ich auch so, vor allem früher in C#. Wenn ich was umbauen will, einfach die entsprechenden Stellen umbauen und kompilieren lassen, dann seh ich sofort alle Stellen, wo ich was ändern muss. Sehr hilfreich, unterschätz das nicht. Keine Chance bei dynamischen Sprachen.
    Natürlich hilft es nicht, wenn ich verborgene Änderungen mache, z.B. die Signatur einer Methode lassen, aber die Bedeutung ändern. Aber sowas ist sowieso sehr böse und dann muss man an der Stelle schon genau wissen, wo das alles benutzt wird. Hat jetzt aber nichts mit der Sprache zu tun.

    0
  • M

    cooky451 schrieb:

    buchstaben schrieb:

    oft ist die genaue Fehlerstelle sogar markiert

    Ou, was ein Luxus. 😃 👍

    Nun ja... Wenn mir der C++ Compiler sowas sagt, glaube ich ihm das nicht 😉 Ich hab neulich auch 2 Minuten eine Fehlermeldung angestarrt und mir gedacht, WTF??? Dabei stand dabei, fehlt evtl. ein Komma? oder sowas... Das hab ich komplett ignoriert, kann ja nicht sein, dass es sowas einfaches ist. Tatsächlich hat in der Zeile davor ein Komma gefehlt.

    0
  • Z

    Ob dynamische Sprachen von statischen Analysen ausgeschlossen seien....

    http://paulbiggar.com/research/wip-optimizer.pdf 7. Conclusion schrieb:

    Scripting languages have become some of the most widely used programming languages, particularly for web development. The dynamic features of scripting languages make static analysis very challenging, particularly for PHP which has no documented semantics outside the source code of its reference implementation. However, we have extensively documented PHP’s run-time behaviour, how it affect program analysis, and in particular its difficult-toanalyse features, for the first time.
    We have developed a static analysis model for PHP that can deal with dynamic language features such duck-typing, dynamic and weak typing, overloading of simple operations, implicit object and array creation and run-time aliasing. The main focus of our work is alias analysis, but we show how type inference and constant propagation must be used to perform the analysis effectively

    0

  • buchstaben schrieb:

    hustbaer schrieb:

    Und zwar unter anderem zum Refactoren.

    nur damit ich's richtig verstehe: du refactorst, indem du dich von den Typfehler-Meldungen des compilers leiten läßt? (ist nicht böse gemeint, vielleicht meinst du ja was anderes)

    Ich refactore indem ich ne Methode oder Klasse markiere, Ctrl+R drücke und den neuen Namen reinschreibe.
    Das Refactoring-Tool kann dann sämtliche Bezeichner im ganzen Programm bzw. Programmpaket anpassen, die genau diese Methode in genau dieser Klasse benennen. Weil eben alles statisch typisiert ist.

    OK, kleine Ausnahme: statisches Duck-Typing mit Templates.
    In dem Fall drückt mal 1x auf "build all", und bekommt "Method not found" Fehler an den Stellen wo die Methode über statisches Duck-Typing aufgerufen wurde. Theoretisch gibt es Sonderfälle wo man keinen Fehler bekommt, weil eine andere Methode mit dem alten Namen gefunden wird. In der Praxis kommt das aber nicht bzw. kaum vor.

    Bzw. ich refactore indem ich mir denke "die Methode braucht sicher keine Sau mehr, die ist bloss ein Übrigbleibsel", und sie einfach weglösche. 1x "build all", wenn keine Fehler kommen hatte ich Recht.

    Mach das mal in einer dynamischen Sprache wenn du keine Unit-Tests mit 100% Coverage hast.

    buchstaben schrieb:

    hustbaer schrieb:

    Nur leider sind automatisierte Tests in der Realität etwas, was lange nicht jedes Projekt hat.

    dafür kann eine dynamische Sprache ja nix. Es gibt frameworks wie SUnit.

    Und?
    Was hat das mit meiner Aussage zu tun?
    Meinst du im Ernst dass es für 100% aller Projekte eine realistische Option wäre automatisierte Tests mit 100% Coverage zu schreiben?
    Dann muss ich dir leider mitteilen dass du träumst.
    Und wenn ich von vornherein weiss, dass ich keine bzw. zu wenig automatisierte Tests werde schreiben können, weil die Zeit dafür einfach nicht da ist, dann nehm' ich lieber was statisch typisiertes, weil damit unterm Strich dann weniger Fehler passieren.
    Was ist daran so schwer zu verstehen?

    Die "man könnte ja" Argumentation finde ich sowas von sinnlos, wenn man darüber diskutiert was eine Sache in der Realität für Vor- bzw. Nachteile hat, und das "man könnte ja" ein theoretisches "man könnte ja" ist, aber ein praktisches "man kann eben nicht" (bzw. nicht in allen Fälken).

    0

  • Zeus schrieb:

    Also bis jetzt bin ich ganz zufrieden mit dem Refactoring von dynamischen Code. xD http://imageshack.us/f/444/58708825.png/

    Ist das jetzt ein Scherz? Ich spreche offensichtlich davon Klassen und Member umzubenennen.
    Und wie soll das bitte gehen, wenn irgendwo

    var v = Foo();
v.MachWas();

    steht, und ich MachWas() umbenennen möchte?
    Aber nur ein MachWas() einer bestimmten Klasse (bzw. eines bestimmten Prototypes).
    Weil der Name an anderen Stellen durchaus OK ist, an einer aber einfach irreführend.

    Wenn das Refactoring-Tools nicht entscheiden kann was "v" an der Stelle für einen Typ hat, und bei dynamisch typisierten Sprachen kann es das Refactoring-Tool halt in vielen Fällen nicht können, ...

    0

  • Zeus schrieb:

    Ob dynamische Sprachen von statischen Analysen ausgeschlossen seien....

    http://paulbiggar.com/research/wip-optimizer.pdf 7. Conclusion schrieb:

    Scripting languages have become some of the most widely used programming languages, particularly for web development. The dynamic features of scripting languages make static analysis very challenging, particularly for PHP which has no documented semantics outside the source code of its reference implementation. However, we have extensively documented PHP’s run-time behaviour, how it affect program analysis, and in particular its difficult-toanalyse features, for the first time.
    We have developed a static analysis model for PHP that can deal with dynamic language features such duck-typing, dynamic and weak typing, overloading of simple operations, implicit object and array creation and run-time aliasing. The main focus of our work is alias analysis, but we show how type inference and constant propagation must be used to perform the analysis effectively

    1. Wo ist das real existierende Refactoring-Werkzeug das das in die Praxis umsetzt?
    2. Was ist mit den Fällen wo die statische Analyse ausspuckt "könnte an der Stelle einer von 10 Typen sein"?
    3. Was ist mit den Fällen wo die statische Analyse ausspuckt "ich hab verflixtnochmal keinen Schimmer was das an der Stelle für ein Typ sein könnte"?
    0
  • Z

    Du meinst sowas?

    http://img534.imageshack.us/img534/6845/49340447.png

    0

  • Zeus schrieb:

    Du meinst sowas?

    http://img534.imageshack.us/img534/6845/49340447.png

    Ja, sowas.
    In Programmen mit ernstzunehmender Komplexität und Grösse.

    0
Anmelden zum Antworten