Dynamische Sprachen
-
buchstaben schrieb:
nein, im Ernst: ließe sich das nicht auch einen Tick eleganter formulieren? Und dann könnte man es in python sicherlich auch ganz hübsch hinschreiben.
Vielleicht. Aber das ist nicht der Punkt. Das System ist nur nervig und hat keine Vorteile.
buchstaben schrieb:
wieso, ich brauche ja keine 19 Schachtelungstiefen. Meine Methoden passen in der Regel in 5-10 Zeilen.
Eben meintest du doch es passt für 19 Ebenen. Wollte nur zeigen, dass das nicht der Fall ist. Aber 19 sind natürlich unrealistisch.
buchstaben schrieb:
doch. Wenn man sich aber allzusehr darauf verläßt, daß der Compiler jeden Tippfehler und jeden verwechselten Bezeichner finden wird, wird die Sache nachteilig,
Ich finde das eigentlich ziemlich angenehm. Du willst nicht, dass der Compiler frühzeitig viele Fehler findet?
buchstaben schrieb:
vor allem, wenn mal was in einer dynamischen Sprache gemacht werden muß.
Muss ja nicht.
buchstaben schrieb:
Vielleicht sollte der Compiler eine Option haben, mit der er zufallsgesteuert jeden hundertsten compile time Fehler übersieht, um den Programmierer wachsam zu halten.
Sicher.
-
Grml!
Mechanics schrieb:
Dynamic in .NET ist so eine Sache... Theoretisch ist es ja nicht schlecht.
Nicht umsonst hat Microsoft ein Paper mit dem Sinn geschrieben, Grundsätzlich statisch, wenn gebraucht dynamisch (find ich greade blos nicht), d.h. Dynamic ist praktisch gut, dort wo der Einsatz ein Sinn machen würde, sollte man es einsätzen. Dazu muss du aber die Gesamtheit berücksichtigten.
Mechanics schrieb:
Wenn es keine andere Wahl gibt, ist es natürlich besser als andere Lösungen, wie Reflection. Also, wenn man ein IDispatch an der Hand hat und dann mühsam über Reflection irgendwas aufrufen müsste, ist es natürlich schon wesentlich eleganter, das über dynamic zu machen.
Irgendwer sollte mich mal aufklären, was an C#/CLR Reflection unelegant ist. In Java hab ich mal über Template Pattern Callback-Aufrufe von der Basisklassen auf die Subklassen delegiert. Wegen eine Einschränkung ging dies nur mit Reflection. Besonders Teuer war es auch nicht, weil ich brauchte nur das Class-Objekt um das Callback-Objekt zuzuordnen. Es war flexible und elegent. Ich hab wohl ein anderes Verstädnis.
Mechanics schrieb:
Auch bei XML wärs nicht verkehrt, dynamic zu benutzen. XML Daten sind nunmal "dynamisch", d.h. man muss so oder so über Strings darauf zugreifen und es gibt erstmal keinen Compiler der erzwingt, dass man nichts falsches macht. Von dem her kann man sich auch etwas Boilerplate sparen und dynamic benutzen.
Die Ursache von Boilercode sind mangelende Ausdrucksstärke und/oder schlechtest Design. Dynamic würde vielleicht abhilfe schaffen, würde aber nicht die Ursache bekämpfen.
-
Zeus schrieb:
Irgendwer sollte mich mal aufklären, was an C#/CLR Reflection unelegant ist.
Gar nichts. Ich hab kein Problem damit, habs auch schon oft benutzt. Wollte nur sagen, dass in einigen Fällen (z.B. eben COM Interop) dynamic einfach etwas angenehmer/eleganter ist. Es ist ja kein Ersatz für Reflection, nur eine Abkürzung in einigen Fällen.
-
Sorry, ich weiß, es ist offtopic, aber mich interessierts.
cooky451 schrieb:
buchstaben schrieb:
nein, im Ernst: ließe sich das nicht auch einen Tick eleganter formulieren? Und dann könnte man es in python sicherlich auch ganz hübsch hinschreiben.
Vielleicht. Aber das ist nicht der Punkt. Das System ist nur nervig und hat keine Vorteile.
Python:
if condition1: if condition2: if condition3: statement
C++:
if (condition1) { if (condition2) { if (condition3) { statement; } } }
Python:
if condition1 and condition2 and condition3: statement
C++:
if (condition1 && condition2 && condition3) { statement; }
Python:
if condition1 and\ condition2 and\ condition3: statement
C++:
if (condition1 && condition2 && condition3) { statement; }
Ich mache zwar geschätzt drei mal so viel mit C++ wie Python, aber in Python fand' ich das trotzdem nie nervig. Ist halt einfach nur anders. Klammern gibts halt keine, das Einrücken bin ich von C++ (auch wenn man da natürlich nicht musst) eh gewöhnt, und der Backslash bringt mich auch nicht um. Oder meintest du was anderes?
-
Dravere schrieb:
Hab ich das gesagt? Nein!
Dann verstehe ich dein Problem nicht.
Denn ich betone jedesmal dass alles was ich sage, lediglich ist, dass dynamic Vorteile abseits des Interops mit dynamischen Sprachen bringt.
-
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 … –.–)
-
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...
-
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.
-
buchstaben schrieb:
oft ist die genaue Fehlerstelle sogar markiert
Ou, was ein Luxus.
-
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.