Dynamische Sprachen

Mechanics

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.

Dobi

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?

Shade Of Mine

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.

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