Können statische und dynamisch typisierte Sprachen als unterschiedliche Werkzeuge für verschiedene Arten von Jobs angesehen werden?

9

Ja, ähnliche Fragen wurden gestellt, aber immer mit dem Ziel herauszufinden, welches besser ist.

Ich frage, weil ich als Entwickler hauptsächlich in JavaScript aufgewachsen bin und keine wirklich umfangreiche Erfahrung im Schreiben in statisch typisierten Sprachen habe.

Trotzdem sehe ich definitiv Wert darin, C zu lernen, um anspruchsvolle Operationen auf niedrigeren Codeebenen zu handhaben (was meiner Meinung nach viel mit statischer und dynamischer Arbeit auf Compilerebene zu tun hat), aber was ich versuche, meinen Kopf herumzureißen ist, ob es bestimmte Projektkontexte gibt (möglicherweise bestimmte Arten von dynamischen datenintensiven Vorgängen?), die andere Dinge als die Leistung betreffen, bei denen es viel sinnvoller ist, Java oder C # im Vergleich zu Python zu verwenden.

dynamic-typing static-typing Erik Reppen
quelle
5
Die Antwort ist ja". Jeder Sprachtyp - in der Tat jede Sprache - hat seine Stärken und Schwächen und eignet sich daher besser für einige Aufgaben als für andere.
ChrisF
Es ist interessant, dass Sie C als Beispiel verwenden, da es sich um die am schwächsten typisierte Sprache handelt, die Sie verstehen und dennoch als statisch typisiert bezeichnen können. C ist aufgrund des Typsystems nicht schnell. Typüberprüfungen finden zur Kompilierungszeit statt. C ist schnell, da es nur wenige oder keine Sicherheitsmaßnahmen und Überprüfungen gibt, die verhindern, dass Sie sich in den Fuß schießen. und weil es zu nativen Binärdateien kompiliert wird.
Sara

Antworten:

10

Ja auf jeden Fall.
Dynamisches Schreiben hat bestimmte Vorteile in Fällen, in denen Sie alles als einen einzigen Typ behandeln möchten. Serialisierung / Deserialisierung ist eines der klassischen Beispiele. Aus diesem Grund wird so viel Webprogrammierung in dynamisch typisierten Skriptsprachen durchgeführt: Sie eignen sich gut für eine Aufgabe, bei der alle Arten von Daten in und aus Zeichenfolgen konvertiert werden müssen.

Für die Anwendungsprogrammierung hingegen funktionieren statische Sprachen viel besser, da der Versuch, alles als einen einzigen Typ zu behandeln, nicht häufig erforderlich ist. Sie möchten häufig effiziente Datenstrukturen mit Daten, die als solche dargestellt werden, und nicht sehr häufig in andere Typen konvertiert werden. Dies macht die Funktionen der dynamischen Eingabe zu einem Nachteil anstelle eines Vorteils, weshalb Anwendungen fast ausschließlich in statisch typisierten Sprachen geschrieben werden.

Mason Wheeler
quelle
3
@Erik: Ich bin mir nicht sicher, ob ich das überhaupt sagen würde. Dinge ändern sich während der Entwicklung. Anforderungen können sich ändern, oder Sie stellen fest, dass Sie eine Anforderung nicht korrekt implementieren, und der Code muss aktualisiert werden. Die Möglichkeit , eine Sache , und verwenden Sie die resultierenden Compiler - Fehler zu ändern , um Sie zu zeigen , wo alles anderes zu finden , dass Bedürfnisse einen geändert werden großen Schub Bequemlichkeit und Geschwindigkeit der Entwicklung , dass Sie in Sprachen verlieren , wenn diese Technik nicht zur Verfügung. Dies ist einer der Gründe, warum Sie keine komplizierten Apps sehen, die in dynamischen Sprachen entwickelt wurden.
Mason Wheeler
9
@ Mason Wheeler: Sehr gute Antwort. + 1 Ich möchte hinzufügen, dass die statische Typprüfung auch dazu beiträgt, Fehler früher zu finden, indem der Compiler die Typkorrektheit überprüft. ZB habe ich gestern ein Ruby-Programm mit 200 Zeilen getestet und es gab zwei typbezogene Fehler, die ich nur durch Ausführen des Programms erkennen konnte. Ich möchte nicht darüber nachdenken, was in einem Projekt mit 100000 Zeilen passiert. Dynamische Eingabe bietet Ihnen also mehr Flexibilität, was in den von Ihnen beschriebenen Kontexten gut ist, zu dem Preis, dass Sie bestimmte Fehler beim Kompilieren nicht finden können. Statisch typisiert hängt also nicht nur von der Effizienz ab, sondern auch von der Korrektheit.
Giorgio
1
@MasonWheeler Zwei Jahre und viel mehr C # und Java als ich später erwartet hatte, würde ich jetzt ein paar Dingen nicht zustimmen. Komplexe Web-Apps werden vollständig mit dynamischen Sprachen erstellt. Kompilieren vs. Laufzeit ist bedeutungslos, wenn Sie Änderungen vornehmen können, die sofort sichtbar sind. Und ich habe die Meinung entwickelt, dass all die Aufregung um Typen in einer prozeduralen Sprache viel sinnvoller ist als in einer Sprache, die von OOP gesteuert werden soll, in der Daten nicht ständig den Besitzer wechseln sollten.
Erik Reppen
1
@Erik: * zusammenzuck * Zunächst einmal ist das Beurteilen der statischen Eingabe als Konzept von Java wie das Beurteilen von Autos als Konzept des Pinto. Und zweitens ist alles, wo Änderungen "sofort sichtbar" sein können, per Definition kein sehr komplexes Programm, da selbst mit moderner Hardware komplexe Programme ziemlich viel Zeit benötigen, um den Code vorzubereiten, egal ob es sich um einen Compiler oder einen Interpreter handelt ( oder ein JIT-Compiler), der die Vorbereitung durchführt. Selbst die beeindruckendsten Webanwendungen sind in der Regel sehr einfache Programme, die von sehr komplexen Datenbanken unterstützt werden, was eine ganz andere Sache ist.
Mason Wheeler
1
Die Fähigkeit, komplexe Abstraktionen zu erstellen, ist orthogonal zu einem statischen oder dynamischen System und auch orthogonal zur Geschwindigkeit. Es gibt statische Systeme, die unglaublich mächtige (wenn auch manchmal arkane) Abstraktionen ermöglichen. Änderungen, die sofort angezeigt werden, sind auch unabhängig vom Typsystem: Sie können sicherlich Interpreter für statisch typisierte Sprachen erstellen.
Rufflewind
4

Wenn Sie auf natürliche Weise in einer statisch typisierten Sprache arbeiten können, ist statische Typisierung der richtige Weg. Im Allgemeinen besteht der Zweck eines Typsystems darin, zu verhindern, dass Sie Operationen mit undefinierter Semantik ausführen (string) "hello" + (bool) true. Das zusätzliche Sicherheitsniveau, das Sie daran hindert, diese Vorgänge auszuführen, kann eine gute Möglichkeit sein, Fehler in Ihrem Code zu verhindern, auch ohne umfangreiche Komponententests. Das heißt, die Typensicherheit bietet ein weiteres Maß an Vertrauen in die semantische Korrektheit Ihres Codes.

Typsysteme sind jedoch sehr schwer zu finden. Ich glaube nicht , es ist eine perfekte Art System in der Natur zum Zeitpunkt des Schreibens dieses Artikels. (Mit "perfektes Typsystem" meine ich ein striktes Typsystem, das keine ausführlichen Code-Annotationen erfordert, keine falsch positiven Typfehler erzeugt und dessen Typfehler für den Programmierer leicht zu verstehen sind.) Außerdem kann es Es ist schwierig, die wirklich guten Typsysteme zu verstehen, die es gibt. Als ich Haskell lernte, kann ich Ihnen nicht sagen, wie viele obskure Typfehler ich beim Versuch hatte, etwas zu schreiben, das (für mich) wie korrekter Code aussah. Normalerweise war der Code nicht richtig (was ein Punkt zugunsten des Typsystems ist), aber es hat viel gedauertvon Arbeit, um die Fehlermeldungen vom Compiler zu verstehen, damit ich die zugrunde liegenden Probleme beheben konnte. In OO - Sprachen, können Sie schließlich finden sich denken : „Dieses Argument sollte kontra mit dem Eingabetyp, nicht covariant!“, Oder (wahrscheinlicher) Rückkehr zu Umwandlungen von den Grenzen des Typs System zu entkommen. Typsysteme können viel schwieriger werden, als Sie denken.

Ich verstehe, dass die Schwierigkeit, gute Typsysteme zu entwickeln, Teil der Motivation von Gilad Bracha ist , die Unterstützung für steckbare Typsysteme in Newspeak aufzunehmen.

Aidan Cully
quelle
WRT-Unit-Tests stimme ich voll und ganz zu. Sie sehen immer Leute, die sagen: "Wenn Sie gute Komponententests haben, können sie die Typkorrektheit für Sie überprüfen." Das hat mich immer daran erinnert, wie Paul Graham (der fest davon überzeugt ist, dass dynamisches Tippen immer eine gute Sache ist) sagt, dass eine Sprache, mit der Sie die Arbeit des Compilers manuell erledigen, eine fehlerhafte Sprache ist. Sorta lässt Sie innehalten und nachdenken ...
Mason Wheeler
Ich denke, viele der Bedenken hinsichtlich der "Gefahren" dynamisch getippter Sprachen berücksichtigen nicht, wie wir dieses Zeug schreiben. Ein Großteil von Python und JS kann im Konsolenstil geschrieben werden. Schraubenkompilierung vs. Laufzeit, ich kann es jetzt ausprobieren und sehen, was passiert. Ich denke, Sie sind jedoch auf einem sehr guten Punkt. Nichts macht mich in der clientseitigen Webentwicklung verrückter, als wenn alle vermeintlich guten Browser-Anbieter einen verwirrenden Pass für schrecklichen Code geben, während IE6 oder 7 das Unerwartete tun. typischer saugen.
Erik Reppen
@ mason-wheeler Mismatch-Typen sind Trival-Fehler, und es ist nicht so, dass dynamische Sprachen die Typen nicht überprüfen, sondern nur zur Laufzeit. Ich habe die Erfahrung gemacht, dass die meisten statischen Sprachen den gleichen Grad an Abdeckung für Komponententests haben, dass sie keine Tests verlieren, wenn der Compiler ihre Typen vorab überprüft, und dass dynamische Sprachen keine spezifischen Tests hinzufügen müssen, um Typen zu überprüfen Das Laufzeitsystem überprüft Ihre Typen. Wenn Ihr Komponententest Ihre Methode abdeckt, werden sie abgefangen.
jbtule
4

Es sind verschiedene Werkzeuge, aber es hängt nicht von der Leistung ab. Es geht nur um Komplexität .

Dynamische Sprachen zielen normalerweise auf maximale Flexibilität ab und bringen mangelnde Validierung und eine Art Garantie mit sich. Dann ist es in kleinen Programmen sehr leistungsfähig, aber es wird fast unmöglich, große Programme zu verwalten (Komplexität).

Statische Sprachen zielen normalerweise auf eine maximale Validierung ab. Ihr erstes Ziel ist es normalerweise, Fehler (oder Bugs) so früh wie möglich zu erkennen. Für die Validierung werden viele Garantien gegeben. Dann ist es schwieriger zu lernen und zu starten, aber wenn Programme größer werden, bietet es eine bessere Programmvalidierung bei weitaus geringeren Kosten (Codierungsaufwand).

Daher eignen sich dynamische Sprachen normalerweise für kleine (ich meine sehr kleine) Programme wie dynamische Webseiten, Webbrowser-DSL (nicht für Browseranwendungen!) Oder Shell-Skripte. Statische Sprachen eignen sich besser für Systemprogrammierungen oder andere Dinge.

Die obigen Beschreibungen beziehen sich auf sehr rein dynamische oder statische Sprachen. Die meisten realen Sprachen befinden sich dazwischen und weisen verschiedene Merkmale auf.

Weitere Informationen finden Sie hier: https://softwareengineering.stackexchange.com/a/105417/17428

Eonil
quelle
1
"Dynamische Sprachen passen normalerweise für kleine (ich meine sehr kleine) Programme": Nach meiner Erfahrung können Sie dynamische Sprachen auch für mittelgroße Anwendungen verwenden (und natürlich gibt es Leute, die sie erfolgreich für große Anwendungen verwenden). Ich bin damit einverstanden, dass Sie von statischen Überprüfungen durch statische Sprachen umso mehr profitieren können, je größer die Codebasis wird.
Giorgio
2
@Giorgio Nun, das liegt vielleicht daran, dass ich süchtig nach statischen Validierungen bin. Es ist so süß zu mir und ich kann buchstäblich nicht ohne sie leben, auch nicht im kleinen Maßstab: p
Eonil
Ich sehe die Vorteile statischer Sprachen (und ich habe Ihre Antwort positiv bewertet). Vor kurzem habe ich Python und Common Lisp verwendet und ich gebe zu, dass Sie in der Praxis gute Ergebnisse erzielen, wenn Sie ein sauberes Design verwenden und insbesondere in Python, wenn Sie genügend Tests schreiben. Diese Sprachen können sehr effektiv sein, um einen Prototyp zu erstellen, der dann einfach in Ihren Produktionscode umgewandelt werden kann. Aber ja, für die komplexeren Projekte hätte ich gerne so viel Hilfe wie möglich, deshalb bevorzuge ich eine statische Sprache.
Giorgio
1

Ich programmiere derzeit in statischen Sprachen (C # und F #), aber ich programmiere gerne in dynamischen Sprachen (Smalltalk, Ruby). Es gibt viele Vor- und Nachteile, die Menschen mit einem Typ gegenüber einem anderen assoziieren, bei denen es mehr um die Sprache geht als beim Erzwingen von Typen. Beispielsweise haben dynamische Sprachen normalerweise eine sauberere, präzisere Syntax, jedoch haben F # und OCaml mit ihrem Typinferenzsystem eine ebenso saubere Syntax wie jede dynamische Sprache. Und mit statischer Typisierung haben Sie echte automatische Refactorings und Autocomplete, aber Smalltalk mit seinem gesamten Quellcode in einer Datenbank und jeder Methode, die separat kompiliert wurde, war die erste Sprache, die wirklich ernsthafte automatisierte Refactorings hatte, und es hat großartig funktioniert. Letztendlich sind moderne dynamische und statische Sprachen heutzutage typsicher, was der wichtigste Aspekt Ihres Typsystems ist.

jbtule
quelle
Ich habe manchmal vermutet, dass statische Typisierung nur ein kleiner Teil der Gleichung ist, die eine Sprache mehr oder weniger flexibel macht. Ich denke, ich beginne auch zu begreifen, dass viele Entwickler einen bequemen Satz Schienen bevorzugen, um sie zu führen, anstatt freie Hand zu haben, um absurd gefährliche Dinge wie das Überladen von Bedienern zu tun. VS bringt mich dazu, manchmal Welpen treten zu wollen, aber ich war definitiv neugierig auf F # und was Sie darüber gesagt haben, hat mich noch neugieriger gemacht. Ich gehe davon aus, dass dies mehr als nur das C # -Ding ist, bei dem Sie implizit in einen umfassenderen Typ umwandeln können.
Erik Reppen
@erik, Oh ja, mehr als implizite Eingabe und var: F # Typinferenz
jbtule
-1

Es ist jetzt 2015, was dem Gespräch einige interessante Ausschnitte hinzufügt:

  1. Wichtige Teile der Backend- Welt für Unternehmen erwägen oder beginnen, Python (dynamisch) anstelle von Java (streng statisch) zu verwenden.
  2. In der Enterprise- Frontend- Welt gibt es Dinge wie AngularJS v2, die auf TypeScipt basieren: eine typisierte Erweiterung von Javascript.

Die Backend-Leute haben also die unnötige Zwangsjacke des strengen Tippens satt, während die Frontend-Jungs das Chaos des dynamischen Tippens satt haben.

Ganz ironisch: Ich frage mich, ob sie sich in der Mitte treffen oder mit dem Überschallknall einer Frist aneinander vorbeirasen ...? ;)

Cornel Masson
quelle
Wenn Sie keinen Beweis liefern, würde ich behaupten, dass die Backend-Welt im schlimmsten Fall auf Go übergeht, aber Gott verbietet jegliches dynamisches Scripty-Zeug. Der Mythos, dass eine statische Programmiersprache immer viel Zeremonie hat, wurde lange Zeit mit leistungsfähigeren Inferenzsystemen und soliden REPL-Implementierungen entlarvt
Den
Es gibt viele dynamisch getippte Backends, die in großen Maßstäben verwendet werden. Insbesondere Django ist im Journalismus sehr beliebt und leitet die Backends für die NYT, den Guardian und die Washington Post. Walmart läuft auf Node. Der einzige Mythos ist die Idee, dass man ohne statische Typen nicht für die Skalierung schreiben kann. Und nachdem ich einige Zeit über einige Katastrophen mit Java-Legacy-Code nachgedacht habe, denke ich, dass Leute, die sich damit wohl fühlen, besser dran sind, egal ob sie mit statischen oder dynamischen arbeiten.
Erik Reppen
In der Tat hätte ich lieber ein kompetentes Python-Team für mein großes Unternehmensprojekt als ein schlechtes Java-Team. Nur um meine Position zu verdeutlichen: Ich habe die obige Antwort als Bewertung von
Cornel Masson
In der Tat hätte ich lieber ein erfahrenes Python-Team für mein großes Unternehmensprojekt als ein schlechtes Java-Team. Nur zur Klarstellung: Ich habe die obige Antwort als Beobachtung der Trends veröffentlicht, die ich in meinem Kundenstamm, meinem Branchennetzwerk und meiner allgemeinen Forschung sehe. Traditionell strenges Backend umfasst weniger Strenge, traditionell lockereres Frontend, mehr. Es ist nicht einmal eine Meinung, die "richtig" ist (wenn überhaupt) - nicht sicher, warum ich abgelehnt wurde. Vielleicht ist die Ironie verloren ...
Cornel Masson