Dynamische Sprachen

Was macht ihr eigentlich mit diesem ganzen dynamischen Möglichkeiten die man mit Python hat? Bitte keine Links zu irgendwelchen theortischen Sachen, sondern das was ihr wirklich macht aufzählen.

.filmor

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

.filmor schrieb:

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

Also eigentlich nur für Hacks.

kantaki

malhören schrieb:

.filmor schrieb:

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

Also eigentlich nur für Hacks.

Es gibt viele größere Projekte in Python: Siehe
Youtube
Google
Reddit
Sourceforge
...

(natürlich nicht komplett in python)

Mechanics

kantaki schrieb:

malhören schrieb:

.filmor schrieb:

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

Also eigentlich nur für Hacks.

Es gibt viele größere Projekte in Python: Siehe
Youtube
Google
Reddit
Sourceforge
...

(natürlich nicht komplett in python)

Das sind Webanwendungen. Das ist ein bisschen was anderes und da musst du auch schauen, was die alternativen sind. Natürlich ist eine Scriptsprache wie PHP oder Python für eine Webanwendung wesentlich besser geeignet, als C++. Und wenn man PHP und Python vergleicht, würde ich Python bevorzugen. Als Sprache gefällt mir Ruby besser, aber ich habe damit bisher keine Erfahrungen in einem größeren Projekt sammeln können.
Alternativen für Webanwendungen wären ASP.NET und Java EE. Tendenziell würde ich bei komplexeren Anwendungen fürs Backend auf jeden Fall Java EE bevorzugen. In dem Umfeld haben aber auch Scriptsprachen nach wie vor ihre Vorteile, auch wenn für mich wie schon mehrfach betont die Nachteile deutlich überwiegen.

Dravere

Shade Of Mine schrieb:

C# hat zB extra dynamische typisierung eingebaut - weil dynamische typisierung super ist.

Ehm ... Nein.
dynamic wurde in erster Linie eingeführt für die einfachere Interoperabilität mit dynamischen Sprachen oder Bibliotheken mit ähnlichem Verhalten bei Typen:
http://msdn.microsoft.com/en-us/library/dd264741.aspx

The dynamic type simplifies access to COM APIs such as the Office Automation APIs, and also to dynamic APIs such as IronPython libraries, and to the HTML Document Object Model (DOM).

dynamic kam übrigens mit der Dynamic Language Runtime (DLR), welche mit IronPython und IronRuby eingesetzt wird. Dient also dazu die .Net Welt in dynamisch typisierte Sprachen zu bringen.

Wenn man es genau nimmt, hat dynamic somit weniger damit zu tun, dass dynamische Typisierung so toll ist, sondern eher dass Microsoft der Meinung ist, dass die .Net Welt so toll ist und überall verwendet werden soll

Was ich bisher in C# gesehen habe, ist im allgemeinen auch eher, dass dynamic nur sehr begrenzt oder gezielt eingesetzt wird. Meistens für die Interoperabilität, zum Teil auch für die De-/Serialisierung von Daten.

@Topic,
An dynamischen Sprachen stört mich persönlich auch, dass sich viele Fehler erst zur Laufzeit zeigen. Ich setze sie daher meistens nur für Tools und dergleichen ein. Zum Teil auch als eingebundene Skriptsprachen.

Grüssli

kantaki schrieb:

malhören schrieb:

.filmor schrieb:

Sich kompliziertere Polymorphieansätze sparen. Ist halt für Prototypen wahnsinnig praktisch, wenn du nicht ständig irgendwelche Zeiger oder Schlauzeiger rumreichen musst oder auch mal schnell an einer einzigen Stelle im Programm den Typ einer Variable ändern kannst ohne dass dir der Rest um die Ohren fliegt.

Also eigentlich nur für Hacks.

Es gibt viele größere Projekte in Python: Siehe
Youtube
Google
Reddit
Sourceforge
...

(natürlich nicht komplett in python)

Vielleicht solltest du mal meine Frage lesen und die war nicht, wo Python verwendet wird. Übrigens ist wohl der größte Teil der Google Suchmaschine doch in C++ geschrieben.

Shade Of Mine

Dravere schrieb:

Ehm ... Nein.
dynamic wurde in erster Linie eingeführt für die einfachere Interoperabilität mit dynamischen Sprachen oder Bibliotheken mit ähnlichem Verhalten bei Typen:
http://msdn.microsoft.com/en-us/library/dd264741.aspx

The dynamic type simplifies access to COM APIs such as the Office Automation APIs, and also to dynamic APIs such as IronPython libraries, and to the HTML Document Object Model (DOM).

Klar ist das auch ein Grund. Aber dynamic hilft ungemein wenn du Data Driven Code hast. zB Data Driven WPF Binding, etc.

Gerade mit LINQ gibts da viele Anwendungsgebiete. Es auf IronPython zu reduzieren ist etwas kurzsichtig. In Effective C# gibts einige nette XML Parser Beispiele mit dynamic.

PS:
In Java wird zB oefters Reflection eingesetzt um dynamic zu emulieren.

Dravere

Shade Of Mine schrieb:

Aber dynamic hilft ungemein wenn du Data Driven Code hast. zB Data Driven WPF Binding, etc.

Gerade mit LINQ gibts da viele Anwendungsgebiete. Es auf IronPython zu reduzieren ist etwas kurzsichtig. In Effective C# gibts einige nette XML Parser Beispiele mit dynamic.

Sprichst du da aus persönlicher Erfahrung oder rein theoretischer Sicht? Meine persönlichen Erfahrungen laufen dem nämlich etwas entgegen. Umso mehr dynamic man einsetzt, desto mehr kommt es dazu, dass man Fehler viel später bemerkt.

Zudem habe ich es nicht nur auf IronPython reduziert, sondern auf die Interoperabilität mit dynamischen Sprachen oder entsprechenden Bibliotheken. Und so wie ich die Entwicklung von dynamic mitbekommen habe, war das definitiv eines der Hauptmotive. Andere Einsatzzwecke scheinen mir zum Teil recht umstritten zu sein.

Ich sage ja nicht, dass man dynamic nicht auch für anderes einsetzen kann. Ich sprach in meinem letzten Beitrag auch von gezieltem Einsatz. Wogegen ich hauptsächlich sprach, ist deine Argumentation, wieso dynamic in C# eingeführt wurde. Die ist meiner Meinung nach völlig neben der Realität durchgegriffen. Da kamen nicht irgendwelche Fanboys von dynamischer Typisierung und haben dynamic eingebaut, weil sie dieses Konzept einfach so wahnsinnig toll fanden

Grüssli

Shade Of Mine

Dravere schrieb:

Shade Of Mine schrieb:

Aber dynamic hilft ungemein wenn du Data Driven Code hast. zB Data Driven WPF Binding, etc.

Gerade mit LINQ gibts da viele Anwendungsgebiete. Es auf IronPython zu reduzieren ist etwas kurzsichtig. In Effective C# gibts einige nette XML Parser Beispiele mit dynamic.

Sprichst du da aus persönlicher Erfahrung oder rein theoretischer Sicht? Meine persönlichen Erfahrungen laufen dem nämlich etwas entgegen. Umso mehr dynamic man einsetzt, desto mehr kommt es dazu, dass man Fehler viel später bemerkt.

Ja das ist der Sinn von dynamic
Schau dir ein x beliebiges größeres Java oder C# Projekt an - du hast recht schnell irgendwo Reflection oder generisches Object im Einsatz. Beides sind Situationen wo dynamic besser ist.

Alles was ich sage ist, dynamic hat reelle Vorteile in C# Code und ist nicht rein aus interop Gründen da...

Dravere

Shade Of Mine schrieb:

Schau dir ein x beliebiges größeres Java oder C# Projekt an - du hast recht schnell irgendwo Reflection oder generisches Object im Einsatz. Beides sind Situationen wo dynamic besser ist.

Also sowas pauschal zu behaupten ist ja Unsinn mit Sahne oben drauf. Nach dieser Aussage kann man Reflection durch dynamic ersetzen. Dann hast du keine Ahnung was man mit Reflection alles machen kann. Da kann dynamic gleich einpacken.

Du übertreibst hier masslos. Und ich wiederhole mich nochmals, nein dynamic ist nicht nur aus Interop Gründen da, aber das war eines der Hauptmotive für die Einführung. Es kann auch noch an anderen Stellen gezielt eingesetzt werden. Ich komme mir langsam vor wie ein Papagei.

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

Shade Of Mine

Ich sage ja nichts dagegen dass es sicher ein Grund ist, dass man System.Dynamic ja für IronPython und Co gebraucht hat. Aber wozu dann soweit gehen und das Keyword dynamic einführen. System.Dynamic bietet ja alles was notwendig ist...

Und ich sage lediglich dass dynamic gewisse Vorteile bietet. Nicht mehr und nicht weniger.

Dravere

Shade Of Mine schrieb:

Aber wozu dann soweit gehen und das Keyword dynamic einführen. System.Dynamic bietet ja alles was notwendig ist...

dynamic arbeitet mit System.Dynamic zusammen, aber das eine ersetzt nicht das andere. dynamic erleichtert die Arbeit mit System.Dynamic erheblich.

Das Ziel war ja eine Erleichterung der Arbeit. System.Dynamic bietet dazu nur das Grundgerüst. dynamic , bzw. was dann die CLR mit dynamic und den Typen aus System.Dynamic macht, führen dann zu dieser Erleichterung. Genau genommen ist dynamic einfach nur Syntax-Sugar für System.Dynamic .

Shade Of Mine schrieb:

Und ich sage lediglich dass dynamic gewisse Vorteile bietet. Nicht mehr und nicht weniger.

Nein, du pauschalisiert masslos. Ich muss sagen, dass ich froh bin, dass du den vorherigen Inhalt deines letzten Beitrages hier rauseditiert hast. Das wäre nämlich die nächste Pauschalisierung gewesen mit einem leichten Rückzieher.

Grüssli

Shade Of Mine

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?

cooky451

buchstaben schrieb:

erzwungene Einrückung ist doch sinnvoll, weil es Redundanz vermeidet. Eingerückt wird ja sowieso, auch in Sprachen mit { ..... } oder BEGIN ... END, wo es eigentlich gar nicht nötig wäre.

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

VS

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

VS

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

buchstaben schrieb:

80 Zeichen/Zeile reichen bei 4er Tab für Einrücktiefen bis 19, das dürfte selbst für üblen Spaghetticode ausreichen.

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

buchstaben schrieb:

ad Flüchtigkeitsfehler: es kann doch ganz heilsam sein, wenn man beim Programmieren mit dynamischen Sprachen gezwungen wird, sich bei jedem Bezeichner zu überlegen, ob er korrekt hingeschrieben wurde, ob die Klasse den betreffenden Methodenaufruf auch unterstützt usw ... und sich nicht drauf zu verlassen "der Compiler findet die Flüchtigkeitsfehler ja eh".

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? Damit sich der Programmierer keine Gedanken mehr über solche Kleinigkeiten machen muss, und sich ganz auf das eigentliche Programm konzentrieren kann? Ist das nicht eigentlich sogar das Argument, das von vielen Python Nutzern gebracht wird?

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.