Dynamische Sprachen

Dravere schrieb:

Da du anscheinend nicht auf andere Argumente vernünftig eingehen willst und lieber mit irgendwelchen aus der Luft gegriffenen übertriebenen Aussagen daher kommst, sehe ich den weiteren Zweck dieser Diskussion nicht und ziehe mich daher zurück.

Grüssli

ist ziemlich sinnlos mit shade zu "diskutieren", er hat einen Haufen Bücherwissen und Sturheit, mehr nicht.

Dravere

Shade Of Mine schrieb:

http://stackoverflow.com/questions/2255982/c-sharp-4-real-world-example-of-dynamic-types

Eine simple Frage: denkst du, dass abseits von Interop mit dynamischen Sprachen, dynamic nichts bringt?

Hab ich das gesagt? Nein! Ich sage es dir zum weiss nicht wievieltem Male, dass ich das nie gesagt habe und dies auch nicht mein Kritikpunkt ist. Aber das scheint dir so lang wie breit zu sein. Du liest nur das, was dir in den Kram passt.

Übrigens, dein Link ist ziemlich genial! Hast du das mal genau inklusive der Kommentare durchgelesen? Ist ziemlich ironisch.

Die Frage ist nach "Real-World Example of Dynamic Types". Und dann kommt diese aktzeptierte riesen lange Antwort und wenn du die Kommentare dazu liest, dann findest du diesen Diamanten:

@DanM: to get these hypothetical examples to work, you'll obviously have to implement the hypothetical APIs first, i.e. you have to actually write XmlDocument and XmlBuilder classes that support this API. The latter should be pretty obvious, I think.

Ich möchte darauf hinweisen, dass der Kommentar vom Autoren der Antwort selbst kommt! Der Fragesteller fragt nach Beispielen aus der realen Welt und bekommt hypothetische Beispiele. Einfach genial ...

Übrigens, such mal im C# Forum nach DynamicJson. Moment, ich mach das mal für dich:
http://www.c-plusplus.net/forum/p2190455#2190455

Uh, ich habe eine Bibliothek für De-/Serialisierung mit dynamic verlinkt. Oh, moment, was hatte ich weiter vorne mal geschrieben?

Dravere schrieb:

..., zum Teil auch für die De-/Serialisierung von Daten.

Und ich hatte weiter vorne auch aus der MSDN zitiert. Wovon war dort als Bibliothek ebenfalls die Rede? Vom "HTML Document Object Model (DOM)" also etwas ähnlichem wie dem XML Document Object Model, was genau auch in deinem Link als Beispiel herangezogen wird. Wie erstaunlich! Halleluja!

Ich kann nicht anders und muss nun einfach das hier verlinken:
http://www.alphabetisierung.de/

Grüssli

cooky451 schrieb:

Es wird eingerückt, aber ist es eben nicht immer genau gleich sinnvoll. z.B.

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

was beweist dieses code sample zum Thema erzwungene Einrückung, außer daß ctrl-c ctrl-v eine feine Sache ist ?

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.

cooky451 schrieb:

Das heißt bei dir stehen in einer Zeile maximal 80 - 4 * 19 = 4 Zeichen in einer Zeile? Interessant.

wieso, ich brauche ja keine 19 Schachtelungstiefen. Meine Methoden passen in der Regel in 5-10 Zeilen.

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.

Mechanics

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

So ein Schwachsinn. Es gibt genug Laufzeitfehler, je mehr der Compiler abfangen kann, desto besser. Ist in C++ eines der Grundsätze, dass Compile time Fehler besser sind als Runtime Fehler. Deswegen gibt es auch solche "Kleinigkeiten" wie const correctness, an die ich mich spontan in keiner anderen Programmiersprache erinnern kann (ein bisschen in Delphi, aber nicht durchgezogen).

Dynamic in .NET ist so eine Sache... Theoretisch ist es ja nicht schlecht. 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. Der Punkt ist aber, dass man an der Stelle keine andere Wahl hat. 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. Naja, könnte man, soviel ich weiß gibt es keine entsprechende Implementierung. Aber sonst seh ich eigentlich keine real life Anwendungsfälle für dynamic. Hab mir schon paar mal überlegt, das zu benutzen, bin aber doch jedesmal bei konventionelleren Methoden geblieben, weil die einfach immer besser gepasst haben.

cooky451

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.

Zeus

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.

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.