Was ist der vermeintliche Produktivitätsgewinn beim dynamischen Tippen? [geschlossen]

82

Ich habe oft die Behauptung gehört, dass dynamisch getippte Sprachen produktiver sind als statisch getippte Sprachen. Was sind die Gründe für diesen Anspruch? Arbeiten Sie nicht einfach mit modernen Konzepten wie Konvention statt Konfiguration, der Verwendung von funktionaler Programmierung, fortschrittlichen Programmiermodellen und der Verwendung konsistenter Abstraktionen? Zugegeben, es gibt weniger Unordnung, da die (beispielsweise in Java) häufig redundanten Typdeklarationen nicht benötigt werden. Sie können jedoch auch die meisten Typdeklarationen in statisch typisierten Sprachen, die Typinferenz verwenden, weglassen, ohne die anderen Vorteile der statischen Typisierung zu verlieren. Und all dies ist auch für moderne statisch typisierte Sprachen wie Scala verfügbar.

Also: Was kann man für die Produktivität mit dynamischer Eingabe sagen, was wirklich ein Vorteil des Typmodells selbst ist?

Klarstellung: Ich interessiere mich mehr für große / mittlere Projekte als für schnelle Hacks. :-)

Hans-Peter Störr
quelle
10
Würden Sie erwarten, dass das "statische Duo" schneller oder produktiver ist als das "dynamische Duo"?
Steve314
Was meinst du mit Duo? Wie auch immer: Ich kann mir eine Reihe von Gründen vorstellen, warum statisches Schreiben produktiver ist als dynamisches Schreiben: Mehr Compiler-Überprüfungen auf Fehler, Code-Vervollständigung, mehr Informationen über die Absicht des Programmierers im Code. Deshalb frage ich nach dem Gegenteil.
Hans-Peter Störr
11
Es war ein Witz mit einem Punkt. Das "dynamische Duo" heißt Batman und Robin. Sie würden der kriminellen Unterwelt von Gotham City nicht annähernd so viel Angst einjagen, wenn sie als "statisches Duo" bezeichnet würden. Da Entwickler Menschen sind, können oberflächliche Dinge einen Unterschied machen, unabhängig davon, was die Begriffe bedeuten.
Steve314
Meine erste Frage ist, ob ich weiß, was ich tue oder nicht. Wenn ich das tue, kann ich Dinge im Voraus entwerfen und statisches Tippen ist sinnvoll. Wenn nicht, muss ich viele Dinge im laufenden Betrieb ändern, und dynamisches Tippen wird einfacher. Common Lisp ist die beste Sprache, die ich gefunden habe, wenn ich nicht weiß, was ich tue. (Vorsichtsmaßnahme: Ich habe nur Haskell gekratzt und daher kein gutes Gefühl für die gefolgerte statische Typisierung.)
David Thornley
2
Ich bin mit John Skeet völlig einverstanden. Msmvps.com/blogs/jon_skeet/archive/2009/11/17/…
user

Antworten:

99

Ich denke eigentlich, dass es ein ziemlich enger Anruf ist. Sowohl die dynamische als auch die statische Eingabe haben ihre Vorteile.

Gründe für eine produktivere dynamische Eingabe:

  • Es ist prägnanter - Eine Menge von fremdem Code kann entfernt werden, wenn alles dynamisch getippt wird - Typdeklarationen, Typumwandlungslogik usw. Wenn alle anderen Dinge gleich sind, lässt sich kürzerer Code geringfügig schneller schreiben, vor allem aber schneller lesen und verarbeiten pflegen (da Sie nicht durch viele Seiten Code waten müssen, um einen Überblick über das Geschehen zu bekommen)
  • Einfachere "Hack" -Techniken wie das Tippen von Enten und das Patchen von Affen können sehr schnell zu Ergebnissen führen (obwohl sie Sie später verwirren könnten ...)
  • Interaktiver - Dynamisches Tippen eignet sich wahrscheinlich besser für interaktive, REPL-ähnliche Programmierung für Rapid Prototyping, Echtzeit-Debugging laufender Programminstanzen oder sogar für Live-Codierung.
  • Testfälle können die Laufzeitfehler abfangen - vorausgesetzt, Sie verwenden TDD oder haben zumindest eine gute Testsuite, sollte dies Tippprobleme in Ihrem Code beheben .
  • Besserer Polymorphismus - Dynamische Sprachen fördern möglicherweise eher die Erstellung polymorpher Funktionen und Abstraktionen, wodurch die Produktivität und die Wiederverwendung von Code gesteigert werden können. Clojure beispielsweise nutzt den dynamischen Polymorphismus in seinen vielen Abstraktionen .
  • Prototypen - Prototypbasierte Daten- / Objektmodelle sind aus meiner Sicht leistungsfähiger und flexibler als statisch typisierte Erbschaften. Dynamische Sprachen ermöglichen oder fördern eher einen prototypbasierten Ansatz, wobei Javascript ein gutes Beispiel ist.

Gründe für eine produktivere statische Typisierung:

  • Besseres Design - Wenn Sie gezwungen sind, über die Arten von Werten in Ihrer Software nachzudenken, können Sie zu saubereren, logischeren Lösungen gelangen. (Ich sage kann - es ist immer noch möglich, wirklich schlechten Code zu entwerfen ...)
  • Bessere Überprüfung der Kompilierungszeit - Durch statische Typisierung können zur Kompilierungszeit mehr Fehler abgefangen werden. Dies ist ein enormer Vorteil und wohl das Beste an statisch typisierten Sprachen insgesamt.
  • Auto-Vervollständigung - Durch statische Typisierung kann die IDE auch mehr Informationen erhalten, so dass die automatische Vervollständigung der Code- oder Dokumentationssuche effektiver ist.
  • Entmutigt Hacks - Sie müssen die Typdisziplin in Ihrem Code einhalten, was wahrscheinlich ein Vorteil für die langfristige Wartbarkeit ist.
  • Typinferenz - In einigen Sprachen (z. B. Scala) können Sie viele der Vorteile dynamischer Sprachen nutzen, um die Typdisziplin beizubehalten.

Im Durchschnitt bin ich (nach vielen Jahren Erfahrung auf beiden Seiten des Zauns) zu dem Schluss gekommen, dass dynamisches Tippen kurzfristig produktiver sein kann, aber letztendlich schwierig zu warten ist, wenn Sie nicht über sehr gute Testsuiten und Testdisziplinen verfügen.

Auf der anderen Seite bevorzuge ich statisch typisierte Ansätze insgesamt, weil ich denke, dass die Vorteile der Korrektheit und der Toolunterstützung langfristig zu einer besseren Produktivität führen.

mikera
quelle
14
+1, sehr ausführliche Antwort. Der Wert des Punktes "Bessere Überprüfung der Kompilierungszeit" kann nicht genug betont werden.
NoChance
8
Neben Type Inference gibt es auch Haskell-artiges Überladen, C ++ - Vorlagen, Generika und möglicherweise einige andere Sprachfunktionen, die einige der Vorteile des Duck-Typing in einem statischen Typing-Framework bieten - sofern das Objekt die erforderliche Schnittstelle (it) bereitstellt "Quacksalber wie eine Ente") können Sie es verwenden, fast unabhängig von der Art des Objekts. Das "fast" liegt daran, dass einige Ansätze eine Art "Quacksalber dieser Art" wie die entsprechende Entenartdeklaration erfordern - z. B. die "Klassen" -Deklaration in Haskell.
Steve314
45
Ich muss Ihrer Behauptung, dass "kürzerer Code ... schneller zu lesen und zu warten ist", nachdrücklich widersprechen. Es gibt einen Zwischenschritt, den Code zu verstehen. Ich musste den Code anderer Leute sowohl in Delphi als auch in JavaScript beibehalten, und der Delphi-Code ist weitaus einfacher zu verstehen, da er ausführlicher ist. Und vor allem, weil der Delphi-Code Typdeklarationen enthält und das JavaScript nicht. Wenn Sie sich mit etwas Komplexerem als Primitiven befassen, ist es aufgrund von Typdeklarationen trivial, zu sehen, was Ihre Variablen sind und was sie können. Dies ist ein wesentliches Wissen für Wartungsarbeiten.
Mason Wheeler
21
Ich bin mit den meisten hier genannten Gründen nicht einverstanden. Nehmen wir Haskell, das wahrscheinlich das strengste Typensystem auf dem Markt hat. Es hat eine REPL (eigentlich mindestens zwei), einen sehr starken Polymorphismus durch Pattern-Matching auf Konstruktoren und ist so prägnant, wie man es sich erhoffen kann - viel mehr als Javascript oder Python. Ich schätze, einige der Gründe, die Sie erwähnen, sind eher zufällig als typisch für lose geschriebene Sprachen.
Andrea
15
Ich würde "Testfällen" nicht zu viel Vertrauen schenken. Man kann sie nicht mit einem guten Typensystem vergleichen. Ein Typensystem liefert den Beweis, dass Ihre Funktion bereits mit mindestens typenrichtigen Parametern aufgerufen wird, während Testfälle nur empirische Beweise liefern können. Doch selbst diese Beweise stammen aus einer künstlichen Umgebung.
Ingo
56

Mit dynamischen Sprachen können Sie beschissenen Code schneller schreiben als mit einer getippten Sprache.

Sobald Sie schnell einen riesigen Stapel dynamischer Elemente erstellt haben, können Sie problemlos zu einem anderen Projekt wechseln, ohne sich um die langfristige Wartung kümmern zu müssen.

Das ist Produktivitätsgewinn :)

Ich mache Witze, aber nachdem ich in ein Projekt mit "dynamischer Sprache" involviert war, hatte ich Angst vor der Menge unnötiger Tests, Dokumentationen und Konventionen, mit denen Sie sich auseinandersetzen müssen, wenn Sie ein funktionierendes Produkt wünschen.
Und mit der Freude an vielen Laufzeitfehlern, die beim Kompilieren hätten auftreten können.
Oh, ich habe auch vergessen, mich über all die Hacks und Voodoos zu lustig zu machen, mit denen Sie Meta-Programmierung in Ihren Code einführen können!

Der Produktivitätsgewinn könnte also ein Mythos für ein mittelgroßes / großes Projekt während seiner gesamten Lebensdauer sein.

Guillaume
quelle
11
Ja, meine Erfahrung ist die gleiche. Ein 100-Zeilen-Perl-Skript ist in Ordnung, und ohne solch großartige Tools wären wir verloren gegangen. Aber ein 100k-Line-Perl-Projekt wird höchstwahrscheinlich ein Albtraum sein.
Ingo
3
... und dann haben Sie JavaScript (nicht nur dynamisch, sondern auch schwach getippt).
Den
16

Auch für dieses Problem gibt es eine theoretische Sichtweise: Ein statisches Typensystem ist im Wesentlichen ein spezialisierter Theorembeweiser, der das Programm nur dann akzeptiert, wenn es die Typkorrektheit beweisen kann. Alle statischen Typsysteme lehnen einige gültige Programme ab, da kein entscheidbares statisches Typsystem leistungsfähig genug ist, um alle möglichen typkorrekten Programme zu beweisen.

Man könnte argumentieren, dass diese Programme, die nicht durch einen statischen Typechecker nachweisbar sind, Hacks und / oder einen schlechten Stil darstellen, aber wenn Sie bereits ein gültiges Programm haben und der Typechecker es nicht akzeptiert, beeinträchtigt dies Ihre Produktivität auf kurze Sicht.

Einige Fälle, in denen Sie möglicherweise bemerken, dass die Typprüfung im Weg steht, sind generische Container und Co- / Contravarianz in Argumenten und Rückgabetypen.

Patrick
quelle
18
Umgekehrt, wenn Sie versehentlich ein falsches Programm eingegeben haben, teilt der Compiler dies sofort mit und hebt die fehlerhafte Zeile hervor. Dies verbessert Ihre Produktivität im Vergleich zum Erkennen eines fehlgeschlagenen Testlaufs und zum Debuggen, um den Fehler zu finden.
MarkJ
5
Generische Container und explizite Co- / Contravarianz sollen "in die Quere kommen", wenn Sie es falsch machen. Was ist der Vorteil des Kompilierens von Code, der zur Laufzeit fehlschlägt?
M. Stramm,
Normalerweise wird der Auftrag als zu 0% erledigt betrachtet, bis alle Tests erfolgreich ausgeführt wurden. Nur dann kann Ihr Fortschritt mehr als nichts berücksichtigt werden. Aus diesem Grund denke ich nicht, dass es sich lohnt, Ihre Produktivität an etwas zu messen, das noch nicht fertig ist.
Pijusn
-1 Befasst sich nicht mit der eigentlichen Frage ("Produktivitätszuwächse", erinnerst du dich?). Wahrscheinlich möchtest du auch nicht die "gültigen Programme schreiben, die das Typsystem ablehnt". Nur weil Sie können, heißt das nicht, dass Sie sollten. Und warum hätten Sie überhaupt ein "gültiges Programm", das der Typechecker ablehnt? Was, haben Sie ein Javascript-Programm programmiert und plötzlich versucht, es in Java kompilieren zu lassen?
Andres F.
Diese gültigen Programme, die das Typsystem ablehnt, können dazu beitragen, Ihren Code zu verkürzen, was zu weniger Fehlern führt, die das Typsystem nicht herausfinden kann (weniger Code = weniger Fehler). Der Compiler / die IDE, der / die die Zeile hervorhebt, kann in dynamischen Sprachen mit Testwerten (dh REPL-gesteuerter Entwicklung) ausgeführt werden, sodass Sie die Zwischenwerte sehen und Fehler auffinden können, die Ihr Typsystem nicht kann, sowie Typfehler. Sie können auch statische Typinferenz verwenden, um Ihnen Typwarnungen zu geben.
aoeu256
15

Ein Vorteil, den ich bei den meisten dynamischen Sprachen festgestellt habe, ist, dass sie das Schreiben von generischem Code erleichtern. Es ist viel einfacher, auf einer höheren Abstraktionsebene zu schreiben, wenn Sie nicht mit dem Typensystem kämpfen müssen, um dies zu tun.

Sie müssen nicht so viel darüber nachdenken - das Schreiben von Code, der mit einem Objekt in Java etwas nicht Triviales bewirkt, ist schwierig und erfordert wahrscheinlich eine Reflexion, die im Grunde genommen dynamisch getippt wird. Mit so etwas wie JavaScript ist es selbstverständlich, eine Funktion zu schreiben, die für alle Objekte etwas Interessantes bewirkt. Ein perfektes Beispiel wäre eine Funktion, die ich kürzlich geschrieben habe und die ein Objekt nimmt und alle Methoden durch Methoden ersetzt, die dasselbe tun, aber auch ein Ereignis auslösen. Ich habe keine Ahnung, wie ich so etwas in Java angehen soll. Ich bin mir jedoch nicht sicher, wie viel davon auf die Typsysteme zurückzuführen ist und wie viel auf andere Sprachunterschiede.

Ich habe jedoch vor kurzem begonnen, Haskell zu verwenden. Mit Haskell kann ich abstrakten, generischen Code so einfach schreiben wie jede dynamisch getippte Sprache, die ich verwendet habe. Mein obiges Java / JavaScript-Beispiel macht in Haskell keinen Sinn, da es keine Objekte, Methoden, Ereignisse oder sogar viel Mutation enthält, aber andere Arten von generischem Code sind wirklich einfach zu schreiben.

Tatsächlich kann Haskell einen generischen Code schreiben, den dynamisch getippte Sprachen nicht können. Ein perfektes Beispiel ist die readFunktion, die im Grunde das Gegenteil von ist toString. Sie können einen Intoder einen Doubleoder einen beliebigen Typ abrufen (sofern er zu einer bestimmten Typklasse gehört). Sie können sogar polymorphe haben Konstanten , so maxBoundkann das Maximum sein Int, Double, Char... etc., Die alle je nachdem , welche Art es angenommen hat , sein.

Meine Theorie ist nun, dass der Produktivitätsgewinn durch die Verwendung einer dynamischen Sprache immer im Vergleich zu Sprachen wie Java mit weniger fähigen, ausführlicheren und weniger flexiblen Typsystemen ist.

Jedoch hat selbst das Typensystem von Haskell einige lästige Probleme, die Sie in einer dynamisch getippten Sprache nicht hätten. Das größte Problem, über das ich mich geärgert habe, ist der Umgang mit Zahlen. Sie müssen beispielsweise mit dem Typensystem herumspielen, um length(von einer Liste) als Double zu verwenden, was Sie ohne ein Typensystem problemlos hätten. Eine andere ärgerliche Sache, die ich getroffen habe, ist die Arbeit mit Word8(einem nicht signierten Int-Typ) und Funktionen, die es erwarten Int.

Das Fehlen eines Typensystems erleichtert es letztendlich, allgemeinen Code zu schreiben, ohne zu viel darüber nachzudenken, und vermeidet außerdem lästige Fallstricke von Typensystemen. Sie müssen das Typensystem nie in einer dynamischen Sprache bekämpfen, können sich aber auch nicht darauf verlassen.

Tikhon Jelvis
quelle
1
Ja, aus irgendeinem Grund sind Zahlensysteme schwer zu finden. In Scala ist es auch ein Chaos. Ich denke, dynamische Schriftsysteme gewinnen zweifellos gegenüber einfachen statischen Schriftsystemen in Bezug auf die Benutzerfreundlichkeit, verlieren jedoch gegenüber den fortgeschritteneren (wie Scala, Haskell, ML usw., die alle Varianten von System-F verwenden ).
Edgar Klerks
3
Ihre Antwort ist gut gemeint, hat aber Fehler. Erstens ist es nicht wahr, dass dynamische Sprachen "kein Typsystem" haben, und das kann nicht der Grund sein, warum sie "das Schreiben von generischem Code erleichtern". Sie machen es nicht einfacher, wie Ihr eigenes Gegenbeispiel mit Haskell zeigt (Sie widerlegen Ihre eigene Behauptung!). "Sie müssen das Typensystem nie bekämpfen" ist falsch: Sie bekämpfen es jedes Mal, wenn Sie einen Fehler beheben müssen, der durch nicht genügend statische Typenkontrolle verursacht wurde. Schließlich ist das explizite Erzwingen der IntRückgabe durch eine Liste trivial. Beispiel:, 1.0 + fromIntegral (length myList)dh nur verwenden fromIntegral.
Andres F.
2
Schließlich: "Code schnell schreiben"! = "Produktiver sein". Ihr Code muss funktionieren! Wenn Sie fehlerhafte Software schreiben, für die Sie später Zeit zum Debuggen und Reparieren aufwenden müssen, sind Sie nicht produktiv.
Andres F.
"ohne zu viel nachzudenken" rote Fahne für das, was die meisten Leute meinen, wenn sie über dynamisch getippte Sprachen sprechen, die "produktiver" sind
Ataraxia
Wenn Typsysteme die Produktivität wirklich verbessert haben, wo sind dann alle nützlichen Anwendungen in Haskell oder Idris? Ich denke, Dinge wie das einfache Verstehen des Typfehlers, die "Patchfähigkeit" (die Fähigkeit, Ihre Anwendung auf unvorhersehbare Weise zu bearbeiten) und die 90% ige Fehlerprüfung von Doctests und Typinferenz könnten wichtiger sein.
aoeu256
7

F: Ich habe oft die Behauptung gehört, dass dynamisch getippte Sprachen produktiver sind als statisch getippte Sprachen. Was sind die Gründe für diesen Anspruch? "

Das hat historische Gründe. In den letzten Jahrzehnten waren dynamische Sprachen unbestreitbar weitaus produktiver als statische Sprachen (wenn auch deutlich langsamer). Perl ist deutlich produktiver als C, wenn Sie beide kennen und die jeweilige Aufgabe dies zulässt. Im Laufe der Zeit haben sich die Sprachen jedoch stark voneinander geliehen, und neuere Sprachen verringern die Kluft (sowohl in Bezug auf Produktivität als auch in Bezug auf Leistung).

Hier sind einige Punkte zu beachten:

Müllabfuhr : Müllabfuhr ist ein enormer Produktivitätsschub. Ich glaube, Java war die erste statische Standardsprache mit GC. Davor bedeutete statisch im Wesentlichen manuelle Speicherverwaltung. (Hinweis: Hier und im Folgenden werde ich nur die Hauptsprachen betrachten. Es gibt viele experimentelle und Nischensprachen, die Gegenbeispiele zu jedem Punkt liefern, den ich mache.)

Speichersicherheit : Dies ist eine Produktivitätsverbesserung, bei der Sie sich keine Sorgen machen müssen, wenn Sie sich in den Fuß schießen. Vor "verwalteten" statischen Sprachen wie Java bedeutete statisch normalerweise direkten Speicherzugriff. Das Debuggen ist auch ein Teil der Produktivität, und ein unsicherer Speicherzugriff kann zu wirklich undurchsichtigen Fehlern führen.

Umständliche Systeme. Vor der Einführung parametrisierter Typen (wie Vorlagen oder Generika) in statischen Sprachen waren die Einschränkungen der Systeme für statische Typen häufig eine Belastung. In Java mussten Sie beispielsweise jedes Mal, wenn Sie einen Artikel aus einer Sammlung auswählten, explizit einen Downcast ausführen. Sie haben also den syntaktischen Aufwand einer Besetzung und keine Typensicherheit. Angesichts der Tatsache, wie allgegenwärtig Sammlungen in der Programmierung sind, war dies ein großer Nachteil.
Das Deklarieren des Typs von allem ist eine Menge redundanter Typisierung, aber mit moderner Typisierung kann dies erheblich reduziert werden.

Große Standardbibliothek. Python wurde wegen der großen Standardbibliothek berühmt als "inklusive Batterien" beworben. Dies ist im Vergleich zu C, die eine sehr minimalistische Standardbibliothek haben. Aber mit Plattformen wie Java und .net wird eine riesige Standardbibliothek zum Standard, und neuere Sprachen wie Scala und F # erben dies "kostenlos".

Erstklassige Datenstrukturen. Dynamische Sprachen wie Perl und Python verfügen über erstklassige Datenstrukturen wie Listen und Maps mit praktischen syntaktischen Verknüpfungen für allgemeine Operationen. Im Vergleich dazu verfügt C über keine integrierten Sammlungen mit Ausnahme von Arrays mit fester Größe.

Closures und Lambda-Syntax - dynamische Sprachen hatten dies normalerweise von Anfang an, aber statische Sprachen haben dies übernommen, zuletzt Java.

REPL die Fähigkeit , schnell Schnipsel Code zu testen , ist interaktiv ein großer Segen. Obwohl IDE-Tools, wie das "unmittelbare" Fenster in Visual Studio, statische Sprachen in gewissem Maße emulieren können.

Erweitertes Tooling - Zusätzlich zu den oben genannten Punkten, in denen statische Sprachen dem Komfort dynamischer Sprachen immer näher kommen, nutzen moderne Editoren die statische Analyse so, dass dynamische Sprachen nur schwer miteinander übereinstimmen können. Zum Beispiel können Redakteure sichere automatische Refactorings bereitstellen, was in einer dynamischen Sprache streng genommen unmöglich ist.

Fazit: Historisch gesehen stimmte das, aber heute ist die Antwort weniger eindeutig.


F: Also, was kann man für die Produktivität beim dynamischen Tippen sagen, was wirklich ein Vorteil des Typmodells selbst ist?

Es ist etwas schwierig, das dynamische Typisierungsmodell von dynamischen Sprachen zu trennen, aber als Beispiel hat C # im Laufe der Zeit mehr und dynamischere Funktionen übernommen, obwohl es als Kern eine statische Sprache ist. Dies ist ein echter Beweis für den Nutzen des dynamischen Typmodells. Beispiele:

Reflexion Reflexion ist im Grunde eine dynamische Schreibfunktion. Sie überprüfen die Objekttypen zur Laufzeit nach der Kompilierungszeit. Als es eingeführt wurde, war es ein bisschen verpönt, aber in C # wird die Verwendung von Reflektion immer allgegenwärtiger, zum Beispiel verwendet ASP.Net MVC stark Reflektion.

Attribute Attribute sind ein Beispiel für die dynamische Typisierung. Sie können einer Klasse zur Kompilierungszeit beliebige Attribute hinzufügen und dann zur Laufzeit (durch Reflektion) inspizieren und darauf basierende Objekte bearbeiten. So etwas wie MEP ist im Grunde ein Erweiterungsframework, das auf einem dynamischen Typmodell basiert.

Linq to SQL, EF mv. Die verschiedenen Linq-Transformer prüfen Abfragen als Laufzeitobjekte und generieren SQL-Code im laufenden Betrieb. Es wird nicht dynamischer als das Untersuchen von Code zur Laufzeit. CodeDom ist die andere Seite der Medaille, auf der Code zur Laufzeit generiert werden kann

Roslyn Roslyn implementiert im Grunde genommen das eval, was einst als bestimmendes Merkmal einer wirklich dynamischen Sprache galt.

Dynamisch Der dynamic-Typ ist die explizit dynamischste Funktion in C # und wird verwendet, um die Interaktion mit externen Objekten und Sprachen einfacher und produktiver zu gestalten. Es wird jedoch auch in Asp.net MVC verwendet.

Der Nutzen aller oben genannten Merkmale zeigt, dass das dynamische Modell selbst in einer statischen Sprache mit parametrisierten Typen, strukturellen Typen und Typinferenz deutliche Vorteile hat .

JacquesB
quelle
Diese Antwort gefällt mir wirklich nicht, weil fast alle Punkte nicht die Kernfrage ansprechen: "Was ist der vermeintliche Produktivitätsgewinn des dynamischen Tippens ?" keine dynamischen Sprachen .
Kindermädchen
@nanny Könnten Sie Ihren wahrgenommenen Unterschied zwischen dynamischen Schriftsprachen und dynamischen Sprachen erläutern? (Es ist eines dieser unscharfen Dinge). Könnten Sie ein Beispiel für eine dynamisch geschriebene Sprache nennen, die keine dynamische Sprache ist, zusammen mit eindeutigen Definitionen für jede Sprache?
@nanny: Bei der Frage geht es eigentlich um "dynamisch getippte Sprachen", nicht nur um "dynamisches Tippen".
JacquesB
@ Michael Tut mir leid, ich war nicht klar. Die dynamische Eingabe ist ein Aspekt aller dynamischen Sprachen. In dieser Antwort geht es um einen anderen Aspekt, mit dem in der Vergangenheit dynamische Sprachen in der Regel einhergehen, ohne den dynamischen Typisierungsteil tatsächlich anzusprechen.
Kindermädchen
1
@nanny: Grundsätzlich antworte ich: "Ich habe oft die Behauptung gehört, dass dynamisch getippte Sprachen produktiver sind als statisch getippte Sprachen. Was sind die Gründe für diese Behauptung?" - Ich glaube, die Gründe für diese Behauptung sind historisch und hängen nicht nur mit der dynamischen Typisierung zusammen, sondern auch mit anderen produktivitätssteigernden Merkmalen dynamischer Sprachen.
JacquesB
6

Alle modernen Sprachfunktionen sind so umfangreich, dass statische und dynamische Eingaben allein nicht viel Gewicht haben.

Die Regel lautet: Je besser Ihre Sprachfunktionen sind, desto kürzer ist Ihr Code. Das ist ganz einfach. Java zeigt, wie sehr statische Eingaben schief gehen können, was den Gegnern viel zu bieten hat. Schlecht gestaltete Sprachfunktionen sind in der Regel mit Kosten verbunden, und die statische Eingabe in Java ist erstens eine obligatorische Funktion (andernfalls würden die meisten Benutzer sie wahrscheinlich nicht einmal verwenden) und zweitens wird sie schlecht ausgeführt.
Dies ist der Grund, warum im Vergleich die meisten dynamischen Sprachen glänzen, obwohl ich behaupten würde, dass PHP Ihr Leben in der Gesamtsumme (zumindest bis vor kurzem) nicht wirklich verbessert, weil es viele andere Macken gibt, die nichts mit Typsystemen zu tun haben.

Auf der anderen Seite gibt es viele Sprachen mit expressiven Schriftsystemen, die sich nicht in die Quere kommen und die nicht einmal obligatorisch sind. Einige von ihnen erlauben sogar das Einbetten von untypisiertem Code, wann immer Sie dem Typsystem entkommen müssen.

Persönlich benutze ich haXe, eine Sprache mit Typinferenz, sowohl nominaler als auch struktureller Subtypisierung, optionalem untypisiertem Code, erstklassigen Funktionstypen, algebraischen Datentypen und (nicht ganz ausgereiften, aber äußerst leistungsfähigen) lexikalischen Makros, wobei die arkane Syntax vermieden wird. Nachdem ich haXe nun seit ungefähr 3 Jahren benutze, bin ich zu einem einfachen Schluss gekommen:

Das Programmieren wird viel einfacher, wenn Ihre Sprache Sie nicht an religiöse Entscheidungen über Paradigmen bindet, sondern nur versucht, ein gutes Werkzeug zu sein. Es gibt eine Reihe von statischen und dynamischen Sprachen und gemischten Sprachen, die das schaffen. Einige von ihnen sind leicht zu erlernen und am schwersten zu meistern.
Ihre Stärke ergibt sich aus der Art und Weise, in der ihre einzelnen Merkmale so zusammengesetzt werden können, dass auf einfache Weise einfache Lösungen für komplexe Probleme erstellt werden können. Dies schließt eine gewisse Orthogonalität aus, die nur durch ein ausgewogenes Verhältnis von Einbeziehung oder Auslassung aller bisher untersuchten Sprachmerkmale erreicht werden kann. Wenn Sie versuchen würden, Ruby mit statischer Typisierung zu versehen, würden Sie es lähmen. Wenn Sie versuchen würden, es Haskell zu entziehen, würden Sie es lähmen. Im Gegensatz dazu: Wenn Sie es von C wegnehmen würden, würden die Leute es kaum bemerken, und wenn Sie es von Java wegnehmen würden, könnten einige es Ihnen danken.

Aus meiner persönlichen Erfahrung kann ich Ihnen Folgendes sagen: Ich mag Ruby. Es hat meinen Horizont erweitert und die Art, wie ich Systeme entwerfe. IMHO sollte es verwendet werden, um Menschen die Programmierung in erster Linie zu lehren. Es ist unauffällig, kraftvoll, prägnant und macht Spaß. Ich verstehe, warum jemand, der aus einer orthodoxen Sprache kommt, es genießen wird.
Auf lange Sicht ermöglicht es die statische Typisierung jedoch, die Arbeit auf den statischen Analysator zu verschieben, und bei einer Typinferenz ist dies im Grunde genommen kostenlos. Das Ergebnis ist Code, der einfacher zu warten ist und häufig schneller ausgeführt wird.

Aber auch hier kann statisches Tippen allein nichts bewirken. Es ist eine Frage der Kombination. Ich denke irgendwo zwischen F #, Scala, Nemerle, OCaml oder haXe kann man sein eigenes Optimum finden. Aber das hängt letztendlich von Ihnen ab, denn die Sprache sollte es Ihnen ermöglichen, Ihre Gedanken mühelos einzubetten, anstatt Sie zu zwingen, sie herumzubiegen. Und nichts bringt mehr Produktivitätsgewinn, als wenn Programmieren Spaß macht.

back2dos
quelle
"Die Regel lautet: Je besser Ihre Sprachfunktionen sind, desto kürzer ist Ihr Code." Dies mag in gewisser Hinsicht auf die Meinung zurückzuführen sein, aber ich halte diese Aussage nicht für richtig. Kürzerer Code bietet nicht allzu viele Vorteile für sich allein, außer dass beim Schreiben weniger getippt wird und möglicherweise weniger Speicherplatz belegt wird (was bei kompilierten Sprachen sowieso kein Faktor ist). Ich denke, die Note einer guten Sprache vermittelt so viele Informationen darüber, was sie tut, auf möglichst kurze Weise. Dynamische Typisierung ist nicht sehr selbstdokumentierend und verliert daher die Wartbarkeit
Ataraxia
Sie können dynamischen getippten Code mit Informationen wie Standardwerten / Schlüsselwortargumenten, Typen, die aus Typinferenz oder dynamischer Typinferenz von einem JIT-Compiler stammen, ergänzen oder einfach alle Funktionen protokollieren Version der Funktion, die ihre Argumente / Ergebnisse protokolliert). Dann können Sie das Protokoll der vorherigen Läufe einer Funktion anzeigen. Eine andere Idee ist, Code abzulehnen, der weder Typanmerkungen, Laufzeitverträge noch Beispiel-REPL-Sitzungstests enthält, sondern dem Entwickler die Möglichkeit bietet, eine der drei Optionen auszuwählen.
aoeu256
3

Persönlich ist der einzige Grund, warum dynamisches Tippen hilfreich ist, wenn Sie ein sehr langsamer Typist sind oder riesige Funktionen / Methoden / was auch immer erstellen, die schwer zu navigieren sind. Sie müssen sich auch mit dem gesamten Unit-Testing befassen. Dynamische Typen erfordern (es sei denn, Sie schreiben gerne gebrochenen Code) intensive Komponententests (um sicherzustellen, dass Ihre dynamischen Typen nicht unerwartet in die Luft jagen (dh die Variable ist meistens enttäuscht, manchmal jedoch versehentlich)). Statik wird sich viel mehr bemühen, dies zu verhindern (und ja, Sie können das Argument für strenge Komponententests vorbringen)

Paul
quelle
0

Ich denke, zuerst muss man "Produktivität" definieren. Was bedeutet und beinhaltet "Produktivität"?

Wenn Sie mit "produktiver" weniger Codezeilen schreiben, um dieselbe Funktion zu implementieren, dann sind dynamische Programmiersprachen "produktiver" als statische.

Berücksichtigt man jedoch auch die Zeit, die für das Debuggen und Beheben von Fehlern aufgewendet wird, sind Sprachen mit dynamischer Typisierung möglicherweise nicht so produktiv, da Sprachen mit dynamischer Typisierung dazu neigen, die Fehlerprüfung auf die Laufzeit zu verlagern, während Sprachen mit statischer Typisierung im Gegensatz dazu ausgeführt werden kann in der Kompilierungszeit einige Fehlerprüfungen durchführen. Es wird allgemein angenommen, dass die Behebung dieses Fehlers umso teurer ist, je später ein Fehler gefunden wird. Aus diesem Grund kann der Code für die dynamische Eingabe im Allgemeinen die gleiche oder sogar eine geringere Produktivität als der Code für die statische Eingabe aufweisen.

yaobin
quelle
Im Allgemeinen stimmt es nicht, dass Sie mit einer dynamischen Sprache ein Feature in weniger Zeilen schreiben können. Welche Sprachen vergleichen Sie überhaupt?
Andres F.
@AndresF. Oh, ich benutze hauptsächlich Python und C ++.
Yaobin
1
Ok, aber wenn Sie Python und C ++ tatsächlich vergleichen, können Sie nicht dynamisch oder statisch verallgemeinern. C ++ ist kein besonders repräsentatives Beispiel für eine Sprache mit statischer Typisierung. Es gibt äußerst präzise statisch typisierte Sprachen, mit denen Sie mehr oder weniger Programme schreiben können, die so kurz sind wie mit Python. Im Allgemeinen ist Ihre Behauptung also falsch.
Andres F.
Ja, aber was ist, wenn Sie Ihr Programm bearbeiten, während es noch läuft? Alle Laufzeitprobleme werden einfach auftreten und Sie können sie direkt dort beheben. Wenn in Lisp eine Fehlermeldung angezeigt wird, können Sie Ihr Programm einfach reparieren und dann weiter ausführen. Ja, für komplexere Pfade sind Typanmerkungen hilfreich (möglicherweise können Sie schrittweise Eingaben wie mypy & lisp verwenden), aber für komplexere Pfade Es kann auch vorkommen, dass Fehler vom Typ "non-type" auftreten. Daher ist es möglicherweise eine gute Idee, komplexe Pfade in einer beliebigen Sprache zu vermeiden.
aoeu256
-1

Der große Vorteil des dynamischen Tippens ist die Produktivität.

Python, Ruby usw. bieten neben der dynamischen Typisierung (Standardparameter, Wörterbücher usw.) noch viele weitere Produktivitätssteigerungen. Die kumulative Auswirkung auf die Programmiererproduktivität ist beeindruckend.

Die Nachteile in Bezug auf Geschwindigkeit (oder Mangel an!) Und Ressourcenverbrauch sind nicht so schlimm wie erwartet und werden in den meisten Fällen durch Entwicklungsgeschwindigkeit und Flexibilität mehr als ausgeglichen.

Zu diesem Thema gibt es eine (sehr alte!) Zeitung . Es ist eine der wenigen ordnungsgemäß durchgeführten Studien zur Produktivität von Programmierern, und viele der Schlussfolgerungen sind noch gültig.

Was wäre (wahrscheinlich) anders, wenn die Studie heute durchgeführt würde:

  1. Java-JVMs wurden bis zur Unkenntlichkeit verbessert.
  2. Moderne IDEs hätten die Produktivität der C ++ - und Java-Codierer verbessert, die Skriptsprachen jedoch kaum verändert.
  3. C # wäre enthalten und wahrscheinlich im selben Ballpark wie Java, aber etwas besser.

Die Botschaft ist also, dass dynamische Sprachen Ihre Produktivität steigern, es sei denn, die Leistung ist ein wirklich ernstes Problem.

James Anderson
quelle
2
Meine Unklarheit ist, was genau dynamisches Tippen bewirkt, um Ihre Produktivität zu steigern. Das Papier ist interessant, es handelt sich jedoch um ein sehr kleines Programm, und ich bin nicht sicher, wie sich dies auf die vielen tausend Codezeilen in den meisten Programmen überträgt.
Hans-Peter Störr
5
Diese Studie verwendet nur C, C ++ und Java als Beispiele für statische Sprachen und versucht dann, die Schlussfolgerungen auf traditionelle Programmiersprachen im Allgemeinen anzuwenden. Alle drei Sprachen haben dieselbe grundlegende Syntax mit denselben inhärenten, die Produktivität verringernden Fehlern, wodurch der Vergleich ungültig wird. Es ist nicht so, dass statische Sprachen unproduktiv sind, sondern dass die C-Familie unproduktiv ist. Hätten sie einen Pascal-Dialekt in ihre Tests einbezogen, wären sie höchstwahrscheinlich zu unterschiedlichen Ergebnissen gekommen.
Mason Wheeler
@mason - auf diesem Gebiet gibt es nur sehr wenige tatsächliche objektive Studien. Dies ist eine der wenigen echten Studien mit tatsächlichen Zahlen usw. Das "Beispiel" -Programm ist nicht trivial! Es kombiniert Elemente des Dictionary-Handlings, komplexe Algorithmen und große Datenmengen. Der hohe Prozentsatz fehlgeschlagener und abstürzender Versuche bestätigt die Nicht-Trivialität der Aufgabe.
James Anderson
2
-1 Sie sagen nicht viel darüber, was dynamische Schriftsprachen produktiver macht. Standardparameter und Wörterbücher können in statisch typisierten Sprachen wie zB Scala gefunden werden.
Jonas
1
@JamesAnderson Schlimmer noch, das Papier, mit dem Sie verlinkt haben, unterstützt nicht einmal Ihren Standpunkt. Es vergleicht "Skriptsprachen" (oft dynamisch) mit " konventionellen Sprachen" (oft statisch). Nun sag mir, was genau sind "konventionelle" Sprachen? Denken Sie, es ist dasselbe wie die Sprachgruppe mit statischer Typisierung? Schlimmer noch, das Papier ist nicht so alt. Bis zum Jahr 2000 gab es bereits viele großartige Sprachen mit statischer Typisierung, die wahrscheinlich produktiver waren als dynamische Sprachen.
Andres F.