Dynamische Sprachen

[Mechanics]

kantaki schrieb:

Gibt es eine IDE die solche Fehler erkennt ?

Schwierig, weil die Sprache eben dynamisch ist. Die Funktion könnte von sonst woher kommen. Du kannst auch dynamisch Funktionen definieren und hinzufügen. Aber wenn die IDE gute Unterstützung für die Programmiersprache bietet, sollten sich solche Fehler in Grenzen halten lassen. Probier mal Eclipse, bin mir nicht sicher, obs was bessser gibt.
Das ist eben das Problem, das ist angesprochen habe. Viele Fehler, die der Compiler zur Kompilierzeit erkennen könnte, fallen erst irgendwann zur Laufzeit auf. Und es gibt noch viel vertracktere Fehler, als das.

[kantaki]

Mechanics schrieb:

kantaki schrieb:

Gibt es eine IDE die solche Fehler erkennt ?

Schwierig, weil die Sprache eben dynamisch ist. Die Funktion könnte von sonst woher kommen. Du kannst auch dynamisch Funktionen definieren und hinzufügen. Aber wenn die IDE gute Unterstützung für die Programmiersprache bietet, sollten sich solche Fehler in Grenzen halten lassen. Probier mal Eclipse, bin mir nicht sicher, obs was bessser gibt.
Das ist eben das Problem, das ist angesprochen habe. Viele Fehler, die der Compiler zur Kompilierzeit erkennen könnte, fallen erst irgendwann zur Laufzeit auf. Und es gibt noch viel vertracktere Fehler, als das.

Ich denke ich werde pycharm benutzen, da ich sowieso in Richtung Webdevlopment gehen möchte.

http://www.jetbrains.com/pycharm/features/index.html

Sieht sehr sehr gut aus. Kostet allerdings auch 28€, sollte ich aber verkraften

[Mechanics]

Ich kenne PyCharm nicht, aber ich finde, Jetbrains macht gute Software.

[cooky451]

Ich muss sagen die Fehlerfindung zur Laufzeit hat mich in Python auch sehr genervt. In C++ setze ich alles daran viel zur Compilezeit abzufangen, und Python geht genau den anderen Weg. Das einzige "Größere" (war immernoch total klein, 2 Leute halt) das ich gezwungenermaßen mit Python machen musste, hat mich total genervt. Das geht schon los mit so Kleinigkeiten wie

blubb = xyz
#...
def foo():
  blubb = 4
  #...

Wurde dann zu

blubba = xyz
#...
def foo():
  blubb = 4
  #...

Aber das gibt natürlich keinen Compilerfehler, weil hier einfach eine neue Variable angelegt wird. Bis ich den ganzen Kram wieder raus hatte. Argh. Und geht weiter mit irgendwelchen total kryptischen Fehlern, die alle nur aus Flüchtigkeitsfehlern resultierten, die ein statisches Typsystem sofort aufgefangen hätte. Vielleicht hab ich die Sprache einfach nie ordentlich gelernt, aber mich hat sie nur genervt sobald man 200+ Zeilen hatte.

(Von dem Quatsch mit der erzwungenen Einrückung fang ich gar nicht erst an.)

[buchstaben]

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.

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

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". Abgesehen davon findet der Bytecode-compiler ja auch Fehler, ist ja nicht so, daß man beliebigen Quatsch compilieren könnte. Typfehler zur Laufzeit sind natürlich ein Thema.

[malhören]

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.

[malhören]

.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

[malhören]

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?