Was reizt die Menschen an dynamischen Sprachen? [geschlossen]

Es scheint, dass in letzter Zeit jeder auf den dynamischen, nicht kompilierten Zug springt. Ich habe meistens nur in kompilierten, statisch typisierten Sprachen (C, Java, .Net) gearbeitet. Die Erfahrung, die ich mit dynamischen Sprachen habe, ist ASP (Vb Script), JavaScript und PHP. Die Verwendung dieser Technologien hat einen schlechten Geschmack in meinem Mund hinterlassen, wenn ich über dynamische Sprachen nachdenke. Dinge, die normalerweise vom Compiler abgefangen wurden, wie falsch geschriebene Variablennamen und das Zuweisen eines Werts vom falschen Typ zu einer Variablen, treten erst zur Laufzeit auf. Und selbst dann bemerken Sie möglicherweise keinen Fehler, da nur eine neue Variable erstellt und ein Standardwert zugewiesen wird. Ich habe auch noch nie gesehen, dass Intellisense in einer dynamischen Sprache gut funktioniert, da Variablen keinen expliziten Typ haben.

Was ich wissen möchte ist, was die Leute an dynamischen Sprachen so attraktiv finden? Was sind die Hauptvorteile in Bezug auf Dinge, die dynamische Sprachen Ihnen ermöglichen, die nicht oder nur schwer in kompilierten Sprachen möglich sind? Es scheint mir, dass wir vor langer Zeit entschieden haben, dass Dinge wie nicht kompilierte Asp-Seiten, die Laufzeitausnahmen auslösen, eine schlechte Idee waren. Warum gibt es eine Wiederbelebung dieser Art von Code? Und warum scheint es mir zumindest so, als ob Ruby on Rails nicht wirklich so aussieht, wie Sie es vor 10 Jahren mit ASP nicht hätten tun können?

Ich denke, der Grund dafür ist, dass Menschen an statisch typisierte Sprachen gewöhnt sind, die sehr begrenzte und nicht ausdrucksstarke Typsysteme haben. Dies sind Sprachen wie Java, C ++, Pascal usw. Anstatt in Richtung ausdrucksstärkerer Typsysteme und besserer Typinferenz zu gehen (wie zum Beispiel in Haskell und in gewissem Maße sogar in SQL), möchten manche Leute einfach nur behalten alle "Typ" -Informationen in ihrem Kopf (und in ihren Tests) und beseitigen die statische Typprüfung insgesamt.

Was Ihnen das am Ende bringt, ist unklar. Es gibt viele falsche Vorstellungen über Typchecking. Die beiden, auf die ich am häufigsten stoße, sind diese beiden.

Irrtum: Dynamische Sprachen sind weniger ausführlich. Das Missverständnis ist, dass Typinformationen gleich Typanmerkungen sind. Das ist völlig falsch. Wir alle wissen, dass Typanmerkungen ärgerlich sind. Die Maschine sollte in der Lage sein, das herauszufinden. Und tatsächlich in modernen Compilern. Hier ist eine statisch typisierte QuickSort in zwei Zeilen von Haskell (von haskell.org ):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Und hier ist ein dynamisch typisierter QuickSort in LISP (von swisspig.net ):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Das Haskell-Beispiel verfälscht die Hypothese, die statisch typisiert und daher ausführlich ist . Das LISP-Beispiel verfälscht die Hypothese ausführlich und daher statisch typisiert . Es gibt keine Implikation zwischen Tippen und Ausführlichkeit in beide Richtungen. Sie können das sicher aus Ihrem Kopf verdrängen.

Irrtum: Statisch typisierte Sprachen müssen kompiliert und nicht interpretiert werden. Wieder nicht wahr. Viele statisch typisierte Sprachen haben Dolmetscher. Es gibt den Scala-Interpreter, die GHCi- und Hugs-Interpreter für Haskell, und natürlich wurde SQL länger als ich am Leben statisch typisiert und interpretiert.

Weißt du, vielleicht möchte die dynamische Menge nur, dass die Freiheit nicht so sorgfältig darüber nachdenken muss, was sie tut. Die Software ist möglicherweise nicht korrekt oder robust, muss es aber möglicherweise nicht sein.

Persönlich denke ich, dass diejenigen, die die Typensicherheit aufgeben würden, um ein wenig vorübergehende Freiheit zu erwerben, weder Freiheit noch Typensicherheit verdienen.

Vergessen Sie nicht, dass Sie in Komponententests eine 10-fache Codeabdeckung schreiben müssen, um die Funktionen Ihres Compilers zu ersetzen: D.

Ich war dort, habe das mit dynamischen Sprachen gemacht und sehe absolut keinen Vorteil.

Beim Lesen der Antworten anderer scheint es mehr oder weniger drei Argumente für dynamische Sprachen zu geben:

1) Der Code ist weniger ausführlich. Ich finde das nicht gültig. Einige dynamische Sprachen sind weniger ausführlich als einige statische. Aber F # ist statisch typisiert, aber die statische Typisierung dort fügt nicht viel, wenn überhaupt, Code hinzu. Es ist zwar implizit typisiert, aber das ist etwas anderes.

2) "Meine bevorzugte dynamische Sprache X hat mein bevorzugtes Funktionsmerkmal Y, daher ist Dynamik besser". Verwechseln Sie nicht funktional und dynamisch (ich kann nicht verstehen, warum dies gesagt werden muss).

3) In dynamischen Sprachen können Sie Ihre Ergebnisse sofort sehen. News: Sie können dies auch mit C # in Visual Studio (seit 2005) tun. Setzen Sie einfach einen Haltepunkt, führen Sie das Programm im Debugger aus und ändern Sie das Programm während des Debuggens. Ich mache das die ganze Zeit und es funktioniert perfekt.

Ich selbst bin ein starker Befürworter der statischen Typisierung, und zwar aus einem Hauptgrund: der Wartbarkeit. Ich habe ein System mit ein paar 10k-Zeilen JavaScript, und jedes Refactoring, das ich durchführen möchte, dauert etwa einen halben Tag, da der (nicht vorhandene) Compiler mir nicht sagt, was diese Umbenennung der Variablen durcheinander gebracht hat. Und das ist Code, den ich selbst geschrieben habe, IMO auch gut strukturiert. Ich möchte nicht die Aufgabe haben, die Verantwortung für ein gleichwertiges dynamisches System zu übernehmen, das jemand anderes geschrieben hat.

Ich denke, ich werde dafür massiv herabgestimmt, aber ich werde das Risiko eingehen.

VBScript ist zum Kotzen, es sei denn, Sie vergleichen es mit einer anderen VB-Variante. PHP ist in Ordnung, solange Sie bedenken, dass es sich um eine überwucherte Vorlagensprache handelt. Modernes Javascript ist großartig. Ja wirklich. Sehr viel Spaß. Halten Sie sich einfach von Skripten fern, die mit "DHTML" gekennzeichnet sind.

Ich habe noch nie eine Sprache verwendet, die keine Laufzeitfehler zulässt. IMHO, das ist größtenteils ein roter Hering: Compiler fangen nicht alle Tippfehler ab und bestätigen auch nicht die Absicht. Explizites Tippen ist großartig, wenn Sie explizite Typen benötigen, aber meistens nicht. Suchen Sie hier nach den Fragen genericsoder nach der Frage, ob die Verwendung von vorzeichenlosen Typen eine gute Wahl für Indexvariablen war oder nicht - in den meisten Fällen stört dieses Zeug nur und gibt den Leuten die Möglichkeit, sich zu drehen, wenn sie Zeit haben .

Aber ich habe deine Frage nicht wirklich beantwortet. Warum sind dynamische Sprachen attraktiv? Denn nach einer Weile wird das Schreiben von Code langweilig und Sie möchten nur noch den Algorithmus implementieren. Sie haben bereits alles mit einem Stift ausgearbeitet und mögliche Problemszenarien grafisch dargestellt und als lösbar erwiesen. Sie müssen nur noch die zwanzig Implementierungszeilen codieren ... und zweihundert Zeilen Boilerplate, um sie kompilieren zu können . Dann stellen Sie fest, dass das Typsystem, mit dem Sie arbeiten, nicht das widerspiegelt, was Sie tatsächlich tun, sondern die ultra-abstrakte Vorstellung eines anderen, was Sie möglicherweise tun, und Sie haben die Programmierung längst aufgegeben, um ein Leben lang so zu arbeiten obsessiv-zwanghaft, dass es sogar den fiktiven Detektiv Adrian Monk beschämen würde.

Dann werden Sie sich ernsthaft mit dynamischen Sprachen beschäftigen.

Ich bin ein Vollzeit-.Net-Programmierer, der sich voll und ganz mit statisch typisiertem C # beschäftigt. Ich liebe jedoch modernes JavaScript.

Generell denke ich, dass dynamische Sprachen es Ihnen ermöglichen, Ihre Absicht prägnanter auszudrücken als statisch typisierte Sprachen, da Sie weniger Zeit und Raum damit verbringen, die Bausteine ​​für das zu definieren, was Sie auszudrücken versuchen, wenn sie in vielen Fällen selbstverständlich sind.

Ich denke, es gibt auch mehrere Klassen dynamischer Sprachen. Ich habe keine Lust, wieder klassische ASP-Seiten in VBScript zu schreiben. Um nützlich zu sein, muss eine dynamische Sprache im Kern eine Art Sammlung, Liste oder assoziatives Konstrukt unterstützen, damit Objekte (oder was für Objekte passieren) ausgedrückt werden können und Sie komplexere Konstrukte erstellen können. (Vielleicht sollten wir alle nur in LISP codieren ... es ist ein Witz ...)

Ich denke, in .Net-Kreisen bekommen dynamische Sprachen einen schlechten Ruf, weil sie mit VBScript und / oder JavaScript verbunden sind. VBScript wird aus vielen Gründen, die Kibbee angegeben hat, nur als Albtraum bezeichnet. Jeder kann sich daran erinnern, den Typ in VBScript mit CLng erzwungen zu haben, um sicherzustellen, dass Sie genug Bits für eine 32-Bit-Ganzzahl haben. Ich denke auch, dass JavaScript immer noch als Browsersprache für Dropdown-Menüs angesehen wird, die für alle Browser anders geschrieben ist. In diesem Fall geht es nicht um die Sprache, sondern um die verschiedenen Browserobjektmodelle. Interessant ist, dass je mehr C # reift, desto dynamischer es aussieht. Ich liebe Lambda-Ausdrücke, anonyme Objekte und Typinferenz. Es fühlt sich jeden Tag eher wie JavaScript an.

Hier ist eine statisch typisierte QuickSort in zwei Zeilen von Haskell (von haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Und hier ist ein dynamisch typisierter QuickSort in LISP (von swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

Ich denke, Sie beeinflussen die Dinge mit Ihrer Wahl der Sprache hier. Lisp ist notorisch parenlastig. Ein näheres Äquivalent zu Haskell wäre Python.

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Python-Code von hier

Für mich ist der Vorteil dynamischer Sprachen, wie viel lesbarer der Code wird, weil weniger Code und Funktionstechniken wie Rubys Block und Pythons Listenverständnis vorhanden sind.

Aber dann vermisse ich irgendwie die Überprüfung der Kompilierungszeit (Tippfehler passiert) und die automatische Vervollständigung der IDE. Insgesamt zahlt sich die geringere Menge an Code und Lesbarkeit für mich aus.

Ein weiterer Vorteil ist die normalerweise interpretierte / nicht kompilierte Natur der Sprache. Ändern Sie einen Code und sehen Sie das Ergebnis sofort. Es ist wirklich eine Zeitersparnis während der Entwicklung.

Last but not least gefällt mir die Tatsache, dass Sie eine Konsole starten und etwas ausprobieren können, bei dem Sie sich nicht sicher sind, z. B. eine Klasse oder Methode, die Sie noch nie zuvor verwendet haben, und sehen können, wie sie sich verhält. Es gibt viele Verwendungsmöglichkeiten für die Konsole, und ich überlasse es Ihnen, dies herauszufinden.

Ihre Argumente gegen dynamische Sprachen sind absolut gültig. Beachten Sie jedoch Folgendes:

1. Dynamische Sprachen müssen nicht kompiliert werden. Führen Sie sie einfach aus. In den meisten Fällen können Sie die Dateien sogar zur Laufzeit neu laden, ohne die Anwendung neu zu starten.
2. Dynamische Sprachen sind im Allgemeinen weniger ausführlich und besser lesbar : Haben Sie sich jemals einen bestimmten Algorithmus oder ein bestimmtes Programm angesehen, das in einer statischen Sprache implementiert ist, und ihn dann mit dem Ruby- oder Python-Äquivalent verglichen? Im Allgemeinen sehen Sie eine Reduzierung der Codezeilen um den Faktor 3. In dynamischen Sprachen ist viel Gerüstcode nicht erforderlich. Das bedeutet, dass das Endergebnis besser lesbar ist und sich mehr auf das eigentliche Problem konzentriert.
3. Machen Sie sich keine Sorgen über Tippprobleme : Der allgemeine Ansatz beim Programmieren in dynamischen Sprachen besteht darin, sich keine Gedanken über das Tippen zu machen: In den meisten Fällen wird die richtige Art von Argument an Ihre Methoden übergeben. Und hin und wieder kann jemand ein anderes Argument verwenden, das zufällig auch funktioniert. Wenn etwas schief geht, wird Ihr Programm möglicherweise gestoppt. Dies geschieht jedoch selten, wenn Sie einige Tests durchgeführt haben.

Auch ich fand es etwas beängstigend, mich zunächst von der sicheren Welt des statischen Schreibens zu entfernen, aber für mich überwiegen die Vorteile bei weitem die Nachteile, und ich habe nie zurückgeschaut.

Ich glaube, dass die "neu gefundene Liebe" zu dynamisch typisierten Sprachen weniger damit zu tun hat, ob statisch typisierte Sprachen im absoluten Sinne besser oder schlechter sind als die zunehmende Beliebtheit bestimmter dynamischer Sprachen. Ruby on Rails war offensichtlich ein großes Phänomen, das das Wiederaufleben dynamischer Sprachen verursachte. Das, was Schienen so beliebt machte und so viele Konvertiten aus dem statischen Lager hervorbrachte, war hauptsächlich: sehr knapper und trockener Code und Konfiguration. Dies gilt insbesondere im Vergleich zu Java-Webframeworks, für die eine Vielzahl von XML-Konfigurationen erforderlich waren. Viele Java-Programmierer - auch kluge - haben konvertiert und einige haben sogar Ruby und andere dynamische Sprachen evangelisiert. Für mich ermöglichen drei unterschiedliche Funktionen, dass dynamische Sprachen wie Ruby oder Python knapper werden:

1. Minimalistische Syntax - die große ist, dass keine Typanmerkungen erforderlich sind, aber auch der Sprachdesigner hat die Sprache von Anfang an so gestaltet, dass sie knapp ist
2. Inline-Funktionssyntax (oder das Lambda) - Die Fähigkeit, Inline-Funktionen zu schreiben und als Variablen weiterzugeben, macht viele Arten von Code kürzer. Dies gilt insbesondere für Listen- / Array-Operationen. Die Wurzeln dieser Ideen waren offensichtlich - LISP.
3. Metaprogrammierung - Metaprogrammierung ist ein großer Teil dessen, was Schienen zum Ticken bringt. Es entstand eine neue Art der Umgestaltung von Code, die es dem Client-Code Ihrer Bibliothek ermöglichte, viel prägnanter zu sein. Dies stammt auch von LISP.

Alle drei Funktionen sind nicht nur für dynamische Sprachen verfügbar, aber sie sind in den gängigen statischen Sprachen von heute sicherlich nicht vorhanden: Java und C #. Sie könnten argumentieren, dass C # bei Delegierten die Nummer 2 hat, aber ich würde argumentieren, dass es überhaupt nicht weit verbreitet ist - beispielsweise bei Listenoperationen.

Was fortgeschrittenere statische Sprachen betrifft ... Haskell ist eine wunderbare Sprache, es hat # 1 und # 2, und obwohl es nicht # 3 hat, ist das Typsystem so flexibel, dass Sie wahrscheinlich keinen Mangel an Meta finden werden einschränkend sein. Ich glaube, Sie können zur Kompilierungszeit Metaprogrammierung in OCaml mit einer Spracherweiterung durchführen. Scala ist eine sehr neue Ergänzung und sehr vielversprechend. F # für das .NET-Camp. Benutzer dieser Sprachen sind jedoch in der Minderheit und haben daher nicht wirklich zu dieser Änderung in der Programmiersprachenlandschaft beigetragen. Tatsächlich glaube ich sehr, dass die Popularität von Ruby die Popularität von Sprachen wie Haskell, OCaml, Scala und F # zusätzlich zu den anderen dynamischen Sprachen positiv beeinflusst hat.

Persönlich denke ich, dass die meisten der "dynamischen" Sprachen, die Sie verwendet haben, nur schlechte Beispiele für Sprachen im Allgemeinen sind.

Ich bin Weise produktiver in Python als in C oder Java, und zwar nicht nur , weil Sie den Edit-Compile-Link-Run - Tanz zu tun haben. Ich werde in Objective-C produktiver, aber das liegt wahrscheinlich eher am Framework.

Unnötig zu erwähnen, dass ich in jeder dieser Sprachen produktiver bin als PHP. Zur Hölle, ich würde lieber in Schema oder Prolog als in PHP codieren. (Aber in letzter Zeit habe ich tatsächlich mehr Prolog gemacht als alles andere, also nimm das mit einem Körnchen Salz!)

Meine Wertschätzung für dynamische Sprachen hängt sehr davon ab, wie funktional sie sind. Pythons Listenverständnis, Rubys Verschlüsse und die prototypisierten Objekte von JavaScript sind allesamt sehr ansprechende Facetten dieser Sprachen. Alle bieten auch erstklassige Funktionen - etwas, ohne das ich nie wieder leben kann.

Ich würde PHP und VB (Skript) nicht auf die gleiche Weise kategorisieren. Für mich sind dies meistens zwingende Sprachen mit all den von Ihnen vorgeschlagenen Nachteilen bei der dynamischen Typisierung.

Sicher, Sie erhalten nicht die gleiche Anzahl von Überprüfungen zur Kompilierungszeit (da es keine Kompilierungszeit gibt), aber ich würde erwarten, dass sich statische Tools zur Syntaxprüfung im Laufe der Zeit weiterentwickeln, um dieses Problem zumindest teilweise zu beheben.

Einer der Vorteile dynamischer Sprachen besteht darin, dass Sie nur den Code ändern und weiter ausführen können. Keine Neukompilierung erforderlich. In VS.Net 2008 können Sie beim Debuggen den Code tatsächlich ändern und ohne Neukompilierung weiter ausführen. Mit den Fortschritten bei Compilern und IDEs ist es möglich, dass dieser und andere Vorteile der Verwendung dynamischer Sprachen wegfallen.

Ah, ich habe dieses Thema nicht gesehen, als ich eine ähnliche Frage gestellt habe

Abgesehen von den guten Eigenschaften, die der Rest der hier erwähnten Leute über dynamische Sprachen hat, denke ich, dass jeder eine vergisst, die grundlegendste Sache: die Metaprogrammierung.

Programmieren des Programms.

In kompilierten Sprachen ist es im Allgemeinen ziemlich schwierig, zum Beispiel .Net. Damit es funktioniert, müssen Sie alle Arten von Mambo-Jumbo erstellen. Normalerweise endet es mit Code, der etwa 100-mal langsamer läuft.

Die meisten dynamischen Sprachen haben eine Möglichkeit, Metaprogrammierung durchzuführen, und das hält mich auf dem Laufenden - die Fähigkeit, jede Art von Code im Speicher zu erstellen und ihn perfekt in meine Anwendung zu integrieren.

Um zum Beispiel einen Taschenrechner in Lua zu erstellen, muss ich nur Folgendes tun:

print( loadstring( "return " .. io.read() )() )

Versuchen Sie dies jetzt in .Net.

Mein Hauptgrund für die Vorliebe für dynamische (getippte, da dies der Schwerpunkt des Threads zu sein scheint) Sprachen ist, dass diejenigen, die ich (in einer Arbeitsumgebung) verwendet habe, den nicht dynamischen Sprachen, die ich verwendet habe, weit überlegen sind. C, C ++, Java usw. ... das sind alles schreckliche Sprachen, um die eigentliche Arbeit zu erledigen. Ich würde gerne eine implizit typisierte Sprache sehen, die so natürlich ist, dass sie in so vielen dynamisch typisierten Sprachen programmiert werden kann.

Davon abgesehen gibt es bestimmte Konstrukte, die in dynamisch typisierten Sprachen einfach erstaunlich sind. Zum Beispiel in Tcl

 lindex $mylist end-2

Die Tatsache, dass Sie "end-2" übergeben, um den gewünschten Index anzugeben, ist für den Leser unglaublich präzise und offensichtlich. Ich habe noch keine statisch typisierte Sprache gesehen, die dies erreicht.

Ich denke, diese Art von Argument ist ein bisschen dumm: "Dinge, die normalerweise vom Compiler abgefangen worden wären, wie falsch geschriebene Variablennamen und das Zuweisen eines Werts vom falschen Typ zu einer Variablen, treten erst zur Laufzeit auf." Ja, das ist richtig als PHP-Entwickler Ich sehe Dinge wie falsch eingegebene Variablen erst zur Laufzeit, ABER die Laufzeit ist für mich Schritt 2, in C ++ (die einzige kompilierte Sprache, die ich Erfahrung habe) ist es Schritt 3 nach dem Verknüpfen und Kompilieren.

Ganz zu schweigen davon, dass es einige Sekunden dauert, nachdem ich auf Speichern geklickt habe, bis mein Code zur Ausführung bereit ist, im Gegensatz zu kompilierten Sprachen, in denen es buchstäblich Stunden dauern kann. Es tut mir leid, wenn das ein bisschen wütend klingt, aber ich bin es leid, dass Leute mich als zweitklassigen Programmierer behandeln, weil ich meinen Code nicht kompilieren muss.

Das Argument ist komplexer als dieses (lesen Sie Yegges Artikel "Is Weak Typing Strong Enough" für einen interessanten Überblick).

Dynamische Sprachen müssen auch nicht unbedingt fehlerfrei sein - die Typinferenz von C # ist möglicherweise ein Beispiel. Auf die gleiche Weise haben C und C ++ schreckliche Kompilierungsprüfungen und sie sind statisch typisiert.

Die Hauptvorteile dynamischer Sprachen sind a) Fähigkeiten (die nicht unbedingt ständig verwendet werden müssen) und b) Boyds Iterationsgesetz .

Der letztere Grund ist massiv.

Obwohl ich noch kein großer Fan von Ruby bin, finde ich dynamische Sprachen wirklich wunderbare und mächtige Werkzeuge.

Die Idee, dass es keine Typprüfung und Variablendeklaration gibt, ist eigentlich kein allzu großes Problem. Zugegeben, Sie können diese Fehler erst zur Laufzeit abfangen, aber für erfahrene Entwickler ist dies kein wirkliches Problem, und wenn Sie Fehler machen, können sie normalerweise leicht behoben werden.

Es zwingt auch Anfänger, das, was sie schreiben, genauer zu lesen. Ich weiß, dass ich durch das Erlernen von PHP aufmerksamer auf das eingegangen bin, was ich tatsächlich geschrieben habe, was meine Programmierung selbst in kompilierten Sprachen verbessert hat.

Gute IDEs bieten genügend Intelligenz, damit Sie wissen, ob eine Variable "deklariert" wurde, und sie versuchen auch, eine Typinferenz für Sie durchzuführen, damit Sie erkennen können, was eine Variable ist.

Die Kraft dessen, was mit dynamischen Sprachen gemacht werden kann, macht meiner Meinung nach wirklich so viel Spaß, mit ihnen zu arbeiten. Sicher, Sie könnten die gleichen Dinge in einer kompilierten Sprache tun, aber es würde mehr Code erfordern. Mit Sprachen wie Python und PHP können Sie sich in kürzerer Zeit entwickeln und die meiste Zeit schneller eine funktionierende Codebasis erhalten.

Ich bin ein Vollzeit-.NET-Entwickler und ich liebe kompilierte Sprachen. In meiner Freizeit benutze ich nur dynamische Sprachen, um mehr über sie zu lernen und mich als Entwickler zu verbessern.

Ich denke, wir brauchen die verschiedenen Arten von Sprachen, je nachdem, was wir erreichen oder mit ihnen lösen wollen. Wenn wir eine Anwendung wünschen, die Datensätze über das Internet aus der Datenbank erstellt, abruft, aktualisiert und löscht, ist es besser, dies mit einer Zeile ROR-Code (unter Verwendung des Gerüsts) zu tun, als sie in einer statisch typisierten Sprache von Grund auf neu zu schreiben. Die Verwendung dynamischer Sprachen befreit den Geist von Fragen

• Welche Variable hat welchen Typ?
• wie man einen String nach Bedarf dynamisch vergrößert
• Wie schreibe ich Code, damit ich, wenn ich den Typ einer Variablen ändere, nicht alle Funktionen, die mit ihr interagieren, neu schreiben muss?

zu Problemen, die näher an geschäftlichen Anforderungen liegen, wie

• Daten werden in der Datenbank gespeichert / aktualisiert usw. Wie verwende ich sie, um den Datenverkehr auf meine Website zu lenken?

Ein Vorteil von lose getippten Sprachen ist jedenfalls, dass es uns egal ist, um welchen Typ es sich handelt, wenn er sich so verhält, wie er soll. Das ist der Grund, warum wir Enten in dynamisch typisierten Sprachen tippen. Es ist eine großartige Funktion und ich kann die gleichen Variablennamen verwenden, um bei Bedarf verschiedene Datentypen zu speichern. Statisch typisierte Sprachen zwingen Sie außerdem dazu, wie eine Maschine zu denken (wie interagiert der Compiler mit Ihrem Code usw. usw.), während dynamisch typisierte Sprachen, insbesondere Ruby / Ror, die Maschine dazu zwingen, wie ein Mensch zu denken.

Dies sind einige der Argumente, mit denen ich meinen Job und meine Erfahrung in dynamischen Sprachen rechtfertige!

Ich denke, beide Stile haben ihre Stärken. Meiner Meinung nach lähmt dieses Entweder-Oder-Denken unsere Community. Ich habe in Architekturen gearbeitet, die von oben nach unten statisch typisiert waren, und es war in Ordnung. Meine Lieblingsarchitektur ist die dynamische Typisierung auf UI-Ebene und die statische Typisierung auf Funktionsebene. Dies fördert auch eine Sprachbarriere, die die Trennung von Benutzeroberfläche und Funktion erzwingt.

Um ein Zyniker zu sein, kann es einfach sein, dass dynamische Sprachen es dem Entwickler ermöglichen, fauler zu sein und Dinge zu erledigen, die weniger über die Grundlagen des Rechnens wissen. Ob dies eine gute oder eine schlechte Sache ist, liegt beim Leser :)

FWIW, das Kompilieren auf den meisten Anwendungen sollte nicht Stunden dauern. Ich habe mit Anwendungen gearbeitet, die zwischen 200 und 500.000 Zeilen umfassen und deren Kompilierung Minuten dauert. Sicher nicht Stunden.

Ich bevorzuge selbst kompilierte Sprachen. Ich habe das Gefühl, dass die Debugging-Tools (meiner Erfahrung nach, die möglicherweise nicht für alle zutreffen) besser und die IDE-Tools besser sind.

Ich mag es, mein Visual Studio an einen laufenden Prozess anhängen zu können. Können andere IDEs das tun? Vielleicht, aber ich weiß nichts über sie. Ich habe in letzter Zeit einige PHP-Entwicklungsarbeiten durchgeführt und um ehrlich zu sein, ist es gar nicht so schlecht. Ich bevorzuge jedoch C # und die VS IDE. Ich habe das Gefühl, schneller zu arbeiten und Probleme schneller zu beheben.

Vielleicht ist es für mich eher ein Toolset als das Problem der dynamischen / statischen Sprache?

Ein letzter Kommentar ... Wenn Sie mit einem lokalen Server entwickeln, ist das Speichern schneller als das Kompilieren, aber oft habe ich nicht Zugriff auf alles auf meinem lokalen Computer. Datenbanken und Fileshares leben anderswo. Es ist einfacher, FTP an den Webserver zu senden und dann meinen PHP-Code auszuführen, um den Fehler zu finden und das FTP zu beheben und erneut zu starten.

Produktivität in einem bestimmten Kontext. Aber das ist nur eine Umgebung, die ich kenne, im Vergleich zu einigen anderen, die ich kenne oder die ich gesehen habe.

Smalltalk auf Squeak / Pharo mit Seaside ist eine viel effektivere und effizientere Webplattform als ASP.Net (/ MVC), RoR oder Wicket für komplexe Anwendungen. Bis Sie mit etwas kommunizieren müssen, das Bibliotheken in einem dieser, aber nicht Smalltalk hat.

Falsch geschriebene Variablennamen sind in der IDE rot, IntelliSense funktioniert, ist aber nicht so spezifisch. Laufzeitfehler auf Webseiten sind kein Problem, sondern eine Funktion. Ein Klick, um den Debugger aufzurufen, ein Klick auf meine IDE, Behebung des Fehlers im Debugger, Speichern, Fortfahren. Bei einfachen Fehlern beträgt die Umlaufzeit für diesen Zyklus weniger als 20 Sekunden.

Dynamische Sprachen schlagen zurück

http://www.youtube.com/watch?v=tz-Bb-D6teE

Ein Vortrag über dynamische Sprachen, was einige der positiven Aspekte sind und wie viele der negativen Aspekte nicht wirklich zutreffen.

Weil ich es für dumm halte, den Typ der Box deklarieren zu müssen. Der Typ bleibt bei der Entität, nicht beim Container. Statische Typisierung hatte einen Sinn, wenn der Typ der Box einen direkten Einfluss darauf hatte, wie die Bits im Speicher interpretiert wurden.

Wenn Sie sich die Entwurfsmuster in der GoF ansehen, werden Sie feststellen, dass ein großer Teil davon nur dazu da ist, mit der statischen Natur der Sprache zu kämpfen, und dass sie überhaupt keinen Grund haben, in einer dynamischen Sprache zu existieren.

Außerdem bin ich es leid, Dinge wie MyFancyObjectInterface f = new MyFancyObject () schreiben zu müssen. Trockenprinzip jemand?

Stellen Sie sich an die Stelle eines brandneuen Programmierers, der zunächst eine Sprache auswählt, der sich nicht für Dynamik versus Staic versus Lambdas versus dies versus das usw.; Welche Sprache würdest DU wählen?

C #

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

Lua:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)

Dies alles hängt teilweise davon ab, was für die jeweiligen Ziele angemessen ist und was eine gemeinsame persönliche Präferenz ist. (EG Wird dies eine riesige Codebasis sein, die von mehr Personen gepflegt wird, als eine vernünftige Besprechung zusammen durchführen kann? Sie möchten eine Typprüfung.)

Der persönliche Teil besteht darin, einige Überprüfungen und andere Schritte für die Entwicklungs- und Testgeschwindigkeit abzuwägen (während wahrscheinlich die CPU-Leistung aufgegeben wird). Es gibt einige Leute, für die dies befreiend und leistungssteigernd ist, und es gibt einige, für die dies genau das Gegenteil ist, und ja, es hängt irgendwie auch vom besonderen Geschmack Ihrer Sprache ab. Ich meine, niemand hier sagt, Java rockt für eine schnelle, knappe Entwicklung oder dass PHP eine solide Sprache ist, in der Sie selten einen schwer zu erkennenden Tippfehler machen werden.

Ich liebe sowohl statische als auch dynamische Sprachen. Jedes Projekt, an dem ich seit ungefähr 2002 beteiligt war, war eine C / C ++ - Anwendung mit einer eingebetteten Python-Interpretation. Das gibt mir das Beste aus beiden Welten:

1. Die Komponenten und Frameworks, aus denen die Anwendung besteht, sind für eine bestimmte Version einer Anwendung unveränderlich. Sie müssen außerdem sehr stabil und daher gut getestet sein. Eine statisch typisierte Sprache ist die richtige Wahl, um diese Teile zu erstellen.
2. Die Verkabelung von Komponenten, das Laden von Komponenten-DLLs, Grafiken, der größte Teil der GUI usw. kann sehr unterschiedlich sein (z. B. um die Anwendung für einen Client anzupassen), ohne dass Framework- oder Komponentencode geändert werden müssen. Eine dynamische Sprache ist dafür perfekt.

Ich finde, dass die Mischung aus einer statisch typisierten Sprache zum Aufbau des Systems und einer dynamisch typisierten Sprache zur Konfiguration mir Flexibilität, Stabilität und Produktivität gibt.

Um die Frage zu beantworten: "Was ist mit der Liebe zu dynamischen Sprachen?" Für mich ist es die Möglichkeit, ein System zur Laufzeit auf jede erdenkliche Weise komplett neu zu verkabeln. Ich sehe die Skriptsprache als "Ausführen der Show", daher kann die ausführende Anwendung alles tun, was Sie wünschen.

Ich habe nicht viel Erfahrung mit dynamischen Sprachen im Allgemeinen, aber die eine dynamische Sprache, die ich kenne, JavaScript (auch bekannt als ECMAScript), liebe ich absolut.

Warten Sie, was ist die Diskussion hier? Dynamische Kompilierung? Oder dynamisches Tippen? JavaScript deckt beide Grundlagen ab, also werde ich wohl über beide sprechen:

Dynamische Kompilierung :

Um zu beginnen, dynamische Sprachen werden zusammengestellt, wird die Kompilierung einfach auf später vertröstet. Und Java und .NET werden wirklich zweimal kompiliert. Einmal zu ihren jeweiligen Zwischensprachen und wieder dynamisch zu Maschinencode.

Wenn die Kompilierung jedoch verschoben wird, können Sie die Ergebnisse schneller sehen. Das ist ein Vorteil. Es macht mir Spaß, die Datei einfach zu speichern und mein Programm ziemlich schnell in Aktion zu sehen.

Ein weiterer Vorteil ist, dass Sie zur Laufzeit Code schreiben und kompilieren können . Ob dies in statisch kompiliertem Code möglich ist, weiß ich nicht. Ich stelle mir das vor, denn was auch immer JavaScript kompiliert, ist letztendlich Maschinencode und statisch kompiliert. In einer dynamischen Sprache ist dies jedoch eine triviale Aufgabe. Code kann sich selbst schreiben und ausführen. (Und ich bin mir ziemlich sicher, dass .NET dies kann, aber die CIL, zu der .NET kompiliert wird, wird sowieso dynamisch im laufenden Betrieb kompiliert, und in C # ist es nicht so trivial.)

Dynamische Eingabe :

Ich denke, dynamisches Tippen ist ausdrucksvoller als statisches Tippen. Beachten Sie, dass ich den Begriff expressiv informell verwende, um zu sagen, dass dynamisches Tippen mit weniger mehr sagen kann. Hier ist ein JavaScript-Code:

var Person = {};

Weißt du was Person jetzt ist? Es ist ein allgemeines Wörterbuch. Ich kann dies tun:

Person ["Vorname"] = "John";
Person ["Nachname"] = "Smith";

Es ist aber auch ein Objekt. Ich könnte auf jeden dieser "Schlüssel" wie folgt verweisen:

Person.First_Name

Und fügen Sie alle Methoden hinzu, die ich für notwendig halte:

Person.changeFirstName = Funktion (neuer Name) {
  this.First_Name = newName;
};

Sicher, es kann Probleme geben, wenn newName keine Zeichenfolge ist. Es wird nicht sofort gefangen, wenn überhaupt, aber Sie können es selbst überprüfen. Es geht darum, Ausdruckskraft und Flexibilität gegen Sicherheit einzutauschen. Es macht mir nichts aus, Code hinzuzufügen, um Typen usw. selbst zu überprüfen, und ich bin noch nicht auf einen Typfehler gestoßen, der mir viel Kummer bereitete (und ich weiß, dass das nicht viel aussagt. Es könnte eine Frage der Zeit sein: )). Ich genieße jedoch sehr diese Fähigkeit, mich im laufenden Betrieb anzupassen.

Schöner Blog-Beitrag zum gleichen Thema: Python macht mich nervös

Methodensignaturen sind in Python praktisch nutzlos. In Java macht statische Typisierung die Methodensignatur zu einem Rezept: Es ist alles, was Sie brauchen, um diese Methode zum Laufen zu bringen. Nicht so in Python. Hier sagt Ihnen eine Methodensignatur nur eines: wie viele Argumente Sie benötigen, damit es funktioniert. Manchmal wird es das nicht einmal tun, wenn Sie anfangen, mit ** kwargs herum zu ficken.

Weil es Spaß macht, Spaß macht. Zum einen macht es Spaß, sich keine Gedanken über die Speicherzuweisung zu machen. Es macht Spaß, nicht auf die Zusammenstellung zu warten. etc etc etc.

Schwach typisierte Sprachen ermöglichen eine flexible Verwaltung Ihrer Daten.

Ich habe VHDL im letzten Frühjahr für mehrere Klassen verwendet, und ich mag ihre Methode zur Darstellung von Bits / Bytes und wie der Compiler Fehler abfängt, wenn Sie versuchen, einem 9-Bit-Bus einen 6-Bit-Bus zuzuweisen. Ich habe versucht, es in C ++ neu zu erstellen, und ich habe ein ziemliches Problem damit, dass die Eingabe mit vorhandenen Typen reibungslos funktioniert. Steve Yegge beschreibt die Probleme, die mit starken Typsystemen verbunden sind, sehr gut, denke ich.

In Bezug auf die Ausführlichkeit: Ich finde, dass Java und C # im Großen ziemlich ausführlich sind (lassen Sie uns keine kleinen Algorithmen auswählen, um einen Punkt zu "beweisen"). Und ja, ich habe in beiden geschrieben. C ++ kämpft auch im selben Bereich; VHDL erliegt hier.

Sparsamkeit scheint eine Tugend der dynamischen Sprachen im Allgemeinen zu sein (ich präsentiere Perl und F # als Beispiele).