Dynamische Sprachen

cooky451

Dobi schrieb:

und der Backslash bringt mich auch nicht um.

Ich find's immernoch verdammt hässlich, aber das was du da angesprochen hast ist schon eher Nebenpunkt.

buchstaben schrieb:

cooky451 schrieb:

Finde ich nicht. Also wirklich überhaupt nicht. Sollte es nicht Aufgabe und Ziel einer Sprache sein, gerade solche Fehler frühzeitig und effizient zu finden?

doch. Wenn man sich aber allzusehr darauf verläßt, daß der Compiler jeden Tippfehler und jeden verwechselten Bezeichner finden wird, wird die Sache nachteilig, vor allem, wenn mal was in einer dynamischen Sprache gemacht werden muß. Vielleicht sollte der Compiler eine Option haben, mit der er zufallsgesteuert jeden hundertsten compile time Fehler übersieht, um den Programmierer wachsam zu halten.

Er hat grundsätzlich schon irgendwie recht, dass die Leute sich voll auf den Übersetzer verlassen, ist mir schon öfter negativ eingefallen, auf die Idee, einfach zufallsgesteuert mal Fehler durchrutschen zu lassen, bin ich aber noch nicht gekommen.
Dafür zu Argumentieren stellt sich für mich jetzt etwas schwer dar, da es hier schon auf Nuancen ankommt und ich meine ursprüngliche Motivation vergessen habe.

Grundsätzlich ging es mir, glaube ich, darum, dass die Leute in solchen Fällen zum Teil wirklich faul werden und sich nach dem Spruch Hey! It compiles! Ship it! richten, was man auch schön an unserer Informatik-Klasse sieht. Das Problem daran ist eben, dass der Code dann nur genau so lange angepasst wird, bis er fehlerfrei übersetzt wird (und vielleicht das Programm startet), aber nicht darüber nachgedacht wird, ob es möglicherweise irgendwelche Randfälle gibt, die sie nicht beachtet haben. Das gibt dann später mehr Fehler.
(Ja, es ist verlockend, aber ich maße mir an, das wenigstens nicht dauernd zu tun. Ich wäre aber auch nicht auf die Idee gekommen, einen Konstruktor mit 27 (sic!) Parametern zu schreiben … –.–)

Mechanics

Fast2_unreg schrieb:

Grundsätzlich ging es mir, glaube ich, darum, dass die Leute in solchen Fällen zum Teil wirklich faul werden und sich nach dem Spruch Hey! It compiles! Ship it! richten, was man auch schön an unserer Informatik-Klasse sieht.

Das ist doch Quatsch. Sieht man vielleicht wirklich mal in irgendwelchen Informatik Klassen, hat aber nichts mit professioneller Softwareentwicklung zu tun. Wenn schon jemand hauptberuflich als Softwareentwickler arbeitet, wird er so eine Einstellung nicht drauf haben, hab ich noch nie gesehen und kanns mir auch nicht vorstellen. Vor allem in C++ wissen die meisten Leute ziemlich genau, was sie tun. Ausnahmen sind vielleicht Pseudo C++ Entwickler in irgendwelchen Java Firmen, wo sie die einzigen sind, die ein bissschen C++ können und deswegen eine alten C++ Software pflegen, ohne wirklich durchzublicken. Aber selbst die werden irgendwann gemerkt haben, dass eine Software die kompiliert, noch lange nicht richtig funktioniert.

Mechanics schrieb:

Wenn schon jemand hauptberuflich als Softwareentwickler arbeitet, wird er so eine Einstellung nicht drauf haben, hab ich noch nie gesehen und kanns mir auch nicht vorstellen. Vor allem in C++ wissen die meisten Leute ziemlich genau, was sie tun. Ausnahmen sind vielleicht Pseudo C++ Entwickler in irgendwelchen Java Firmen, wo sie die einzigen sind, die ein bissschen C++ können und deswegen eine alten C++ Software pflegen, ohne wirklich durchzublicken. Aber selbst die werden irgendwann gemerkt haben, dass eine Software die kompiliert, noch lange nicht richtig funktioniert.

Das hat doch nichts mit der Sprache zu tun! Oo
Glaubst du in Java fliegen keine Exceptions? Selbst wenn keine fliegen, kann die Software etwas anderes tun als erwartet. Das ist sprachenunabhängig...

Immer diese Java-Basher...

Mechanics

Steffo schrieb:

Mechanics schrieb:

Wenn schon jemand hauptberuflich als Softwareentwickler arbeitet, wird er so eine Einstellung nicht drauf haben, hab ich noch nie gesehen und kanns mir auch nicht vorstellen. Vor allem in C++ wissen die meisten Leute ziemlich genau, was sie tun. Ausnahmen sind vielleicht Pseudo C++ Entwickler in irgendwelchen Java Firmen, wo sie die einzigen sind, die ein bissschen C++ können und deswegen eine alten C++ Software pflegen, ohne wirklich durchzublicken. Aber selbst die werden irgendwann gemerkt haben, dass eine Software die kompiliert, noch lange nicht richtig funktioniert.

Das hat doch nichts mit der Sprache zu tun! Oo
Glaubst du in Java fliegen keine Exceptions? Selbst wenn keine fliegen, kann die Software etwas anderes tun als erwartet. Das ist sprachenunabhängig...

Immer diese Java-Basher...

Natürlich hat das nichts mit der Sprache zu tun. Und ich bin kein Java Basher, ich programmiere auch Java und habe kein Problem damit, auch wenn ich hauptberuflich im Moment C++ programmiere. Worauf ich hinauswollte, und das habe ich glaub ich deutlich genug gesagt, sind die Leute, die eigentlich nur Java (oder eine andere ähnliche Sprache können), und nebenbei nur ein bisschen C++ machen, ohne das richtig gelernt zu haben. Da kenne ich persönlich genug. Das kann nicht funktionieren. Nichts anderes wollte ich sagen.

cooky451

Mechanics schrieb:

Fast2_unreg schrieb:

Grundsätzlich ging es mir, glaube ich, darum, dass die Leute in solchen Fällen zum Teil wirklich faul werden und sich nach dem Spruch Hey! It compiles! Ship it! richten, was man auch schön an unserer Informatik-Klasse sieht.

Das ist doch Quatsch.

Aber wirklich sehr guter Quatsch. Ernsthaft, so eine Einstellung haben vielleicht totale Anfänger die nicht mal die Syntax für Pointer oder Templates verstanden haben. Deren größter Feind ist in der Tat der Compiler. Aber mit Leuten die nur etwas fortgeschrittener sind hat das nichts zu tun. Wobei ich die Argumentation auch lustig finde. Ja, wir nehmen die Sprache die mehr Fehler durchlässt, damit sich die Leute besser konzentrieren. Vielleicht solltet ihr da mal Linus fragen, der hat bei dem Thema sicher ein offenes Ohr.

Kellerautomat

Linus Torvalds ist so ziemlich das Gegenteil von nem Experten, wenns um Programmiersprachen geht. Seine "Argumente"... göttlich

if (file.read_binary(header.blubb1) == sizeof header.blubb1
  && file.read_binary(header.blubb2) == sizeof header.blubb2
  && file.read_binary(header.blubb3) == sizeof header.blubb3
  && file.read_binary(header.blubb4) == sizeof header.blubb4
  && file.read_binary(header.blubb5) == sizeof header.blubb5)
{
  ..
}

==

headers = [
    header.blubb1, header.blubb2, header.blubb3, header.blubb4, header.blubb5
]
if all(file.read_binary(h) == sizeof(h) for h in headers):
    ...

von hier: http://www.python-forum.de/viewtopic.php?f=1&t=29592

Dann doch lieber Zwangseinrückung und dafür einen übersichtlichen und ordentlichen Syntax.

-lowbyte- 0

Kellerautomat schrieb:

Linus Torvalds ist so ziemlich das Gegenteil von nem Experten, wenns um Programmiersprachen geht. Seine "Argumente"... göttlich

Der weis schon von was er spricht, keine Angst! Für die Faulen müsste man ganz andere Programmiersprachen entwickeln...

Bashar

cooky451 schrieb:

Mechanics schrieb:

Fast2_unreg schrieb:

Grundsätzlich ging es mir, glaube ich, darum, dass die Leute in solchen Fällen zum Teil wirklich faul werden und sich nach dem Spruch Hey! It compiles! Ship it! richten, was man auch schön an unserer Informatik-Klasse sieht.

Das ist doch Quatsch.

Aber wirklich sehr guter Quatsch. Ernsthaft, so eine Einstellung haben vielleicht totale Anfänger die nicht mal die Syntax für Pointer oder Templates verstanden haben. Deren größter Feind ist in der Tat der Compiler. Aber mit Leuten die nur etwas fortgeschrittener sind hat das nichts zu tun.

Du bist Schüler oder so, richtig? Deine Wunschvorstellungen teile ich zwar, aber die Realität sieht leider ein bisschen anders aus.

hustbaer

Ich finde statische Typisierung und die darans resultierenden Fehlermeldungen des Compilers klasse.
Und zwar unter anderem zum Refactoren.

Wie soll z.B. Refactor-Rename in einer dynamisch typisierten Sprache gehen? Einfach *alles* umbenennen was so heisst? Das kanns ja wohl auch nicht sein, das wäre ja kaum besser als "Find & Replace in Files".

Bzw. wie soll ich auf die Schnelle rausbekommen ob eine Funktion noch irgendwo aufgerufen wird?
OK, dabei könnten einem Unit-Tests (bzw. allgemein automatisierte Tests) helfen.

Nur leider sind automatisierte Tests in der Realität etwas, was lange nicht jedes Projekt hat. Und kaum irgendein Projekt ausreichend viele/gute davon hat, um auch nur halbwegs sicher sein zu können dass alles OK ist.

Und nochwas: "keine automatisierten Tests" heisst nicht automatisch "if it compiles, ship it". Man kann auch testen ohne dass dabei alles automatisiert wäre.

Zeus

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

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.

cooky451

buchstaben schrieb:

oft ist die genaue Fehlerstelle sogar markiert

Ou, was ein Luxus.

Mechanics

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.

Mechanics

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.

Zeus

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 difﬁcult-toanalyse features, for the ﬁrst 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

hustbaer

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).

hustbaer

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, ...

hustbaer

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 difﬁcult-toanalyse features, for the ﬁrst 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

Wo ist das real existierende Refactoring-Werkzeug das das in die Praxis umsetzt?
Was ist mit den Fällen wo die statische Analyse ausspuckt "könnte an der Stelle einer von 10 Typen sein"?
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"?