Verdienen dynamische typisierte Sprachen die ganze Kritik? [abgeschlossen

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/16

Frage

Ich habe ein paar Artikel im Internet über die Auswahl der Programmiersprache im Unternehmen gelesen. In letzter Zeit waren viele dynamische typisierte Sprachen beliebt, dh Ruby, Python, PHP und Erlang. Aber viele Unternehmen bleiben immer noch bei statischen, typisierten Sprachen wie C, C ++, C# und Java.

Und ja, einer der Vorteile von statischen typisierten Sprachen besteht darin, dass Programmierfehler früher zur Kompilierungszeit und nicht zur Laufzeit erfasst werden. Es gibt aber auch Vorteile mit dynamischen typisierten Sprachen. (Mehr über Wikipedia)

Der Hauptgrund, warum Unternehmen nicht anfangen, Sprachen wie Erlang, Ruby und Python zu verwenden, scheinen die Tatsache zu sein, dass sie dynamisch getippt sind. Das scheint auch der Hauptgrund zu sein, warum Menschen auf Stackoverflow gegen Erlang entscheiden. Sehen Warum hast du dich gegen "Erlang" entschieden?.

Es scheint jedoch eine starke Kritik gegen dynamisches Tippen in den Unternehmen zu geben, aber ich verstehe es nicht wirklich, warum es ist das stark.

Wirklich, warum gibt es in den Unternehmen so viel Kritik gegen dynamisches Typen? Beeinflusst es wirklich die Kosten von Projekten so viel oder was? Aber vielleicht irre ich mich.

War es hilfreich?

Lösung

Ja, ich glaube, dass sie es tun.

Es gibt einige Gründe, die bei der Auswahl einer Sprache für ein neues Projekt berücksichtigt werden müssen:

  • Laufzeitgeschwindigkeit. Im Vergleich zu C/C ++/FORTRAN sind Perl und Python so langsam, dass es lustig ist.
  • Initialisierungsgeschwindigkeit. Im Vergleich zu den oben genannten schnellen Sprachen, Java fällt um und weint, während der JVM weiter lädt und lädt und ...while(1)....
  • Prototyp-Fähigkeit. Die für C ++ oder Java erforderliche Erklärung/Definitionsarbeit erhöht die LOC, nämlich die für C ++ oder Java erforderliche Arbeit. nur Bekannte Metrik, die zuverlässig mit Bugcounts korreliert. Es dauert auch viel Zeit. Es erfordert auch ein bisschen mehr über Typen und Verbindungen nachdenkt.
  • Interne Fummelfähigkeit. Das dynamische Verlegen mit Ihren Interna ist großartig, bis Sie anfangen, Ihre zu debuggen selbstmodifizierender Code. (Python, Lisp, Perl)
  • Korrektheitsprüfung. Ein Compiler kann einen schnellen einmaligen Durchgang der Halbkorrigität Ihres Codes in C ++ liefern, und dies kann sein Ja wirklich Hübsch.
  • Statische Analysedetails. C und Java haben eine ziemlich gute statische Analyse. Perl ist bei a nicht vollständig statisch analyzbar theoretisch Level (möglicherweise auch Python). Ich bin mir einigermaßen sicher, dass Lisp nicht nicht ist.
  • Seltsame Plattformen nehmen im Allgemeinen nur C ein.
  • Unterstützungskette. Wenn Sie einen Vertrag haben können, den Sie Wille Holen Sie sich Ihre Bugs aus und arbeiten Sie daran, das ist riesig.

Wenn Sie davon ausgehen können, dass die Organisation, mit der Sie zusammenarbeiten Gewohnheit Entscheiden Sie sich nur zufällig, nicht an der Software zu arbeiten, und dann haben Sie einen viel besseren Fall für die Verwendung der Software. Da gibt es kein großes Geschäft Verkauf (Implikat, die Verantwortung für die Aufrechterhaltung des Python/Perl/$ Dynamic_Language zu übernehmen, verringert es das Risiko erheblich.

Nach meiner Erfahrung haben Open Source -Betreuer häufig ein Problem damit, die Verantwortung für Fehler für Fehler zu übernehmen und Updates zu veröffentlichen. "Es ist kostenlos, du arbeitest daran!" ist nicht Eine Antwort, die für die meisten Unternehmen akzeptabel ist (nicht für ihre Kernkompetenzen).

Natürlich spreche ich nicht über die WebApp/Startup sehr Offen für den Aufenthalt am schaumigen Tech.

Andere Tipps

Sie geben den Entscheidungsträgern der Unternehmen viel zu viel technisch zu. Es gibt ein altes Sprichwort: "Niemand wurde wegen Kaufs von IBM gefeuert." Wenn Sie einen anderen Weg gehen und die Dinge felsig werden (sie tun es immer), möchte niemand riskieren, Schuld zu machen. Halten Sie sich an die Standards und beschuldigen Sie jemand anderem.

Es gibt viele jüngere Unternehmen, die letztendlich die Unternehmen von morgen werden und diese Sprachen verwenden werden.

Und vergessen wir nicht die in VBA geschriebenen Codezeilen!

Der Grund, warum Unternehmen C, C ++, C# und Java verwenden, liegt nicht daran, dass sie statisch typisiert werden (zumindest nicht direkt). Enterprise -Entscheidungsträger treffen diese Art von Entscheidungen nicht auf der Grundlage eines objektiven Vergleichs von Typsystemen, ich versichere Ihnen.

Unternehmen tun Wert darauf legen:

  • Langzeitwartungskosten: Können Sie vernünftigerweise erwarten, dass die Dinge in 10 Jahren weiterhin gut funktionieren? Es ist eigentlich eine gute Sache, wenn die Sprachentwicklung konservativ und rückwärtskompatibel ist (wie bei Java). Das statische Tippen ist hier hilfreich, da es zur Kompilierung Zeit eine große Art von Fehlern fängt, bevor sie in Ihre Produktionssysteme einsteigen .....
  • Verfügbarkeit von Talenten - Können Sie Entwickler finden, die Ihr glänzendes neues System aufrechterhalten? Was ist, wenn der ursprüngliche Entwickler geht, wird alle anderen den Code verstehen? Dies stellt eine hohe Hürde auf die Einführung einer "neuen" Sprache (insbesondere wenn sie auch neue Anforderungen an die Bereitstellung, Bausysteme, operative Unterstützung usw. erzeugt). Dies bietet den weit verbreiteten Sprachen massive Vorteile (C, C ++, C# und Java)
  • Integrationskosten: Ist es einfach, sich mit anderen Technologien zu verbinden / zu integrieren, die Sie bereits vorhanden haben oder wahrscheinlich erwerben? Wenn Sie bereits einen Stapel Legacy -J2EE -Systeme haben, müssen Sie sich in sie integrieren. Eine neue Java -EE -Lösung dürfte dafür viel praktischer sein als z. B. Python.
  • Voraussetzbarkeit / geringes Risiko: Ist die Plattform / Sprache bewiesen, und kann ich sicher sein, dass sie funktionieren wird? Dies ist normalerweise mehr Wichtig als einfache Produktivität. Es ist für einen Manager viel einfacher, seinen Chef zu überreden, ihm ein großes Budget für Arbeitskräfte zu geben, um ein neues System aufzubauen, als dass er später zurückgeht und sagt, dass es nicht funktioniert hat .....
  • Enterprise -Unterstützung / -unterstützung - Sind große internationale Organisationen für die Unterstützung der Sprache und Plattform verpflichtet? Werden sie einen Vertrag unterschreiben, um mich zu unterstützen, damit ich jemanden anrufen kann, wenn etwas schief geht?
  • Anbieterneutralität / Plattformunabhängigkeit - Werde ich mich an einen einzelnen Lieferanten eingeschlossen? Oder habe ich eine breite Palette zukünftiger Lieferantenoptionen / Übergangswege zur Verfügung? Sie möchten nicht in einem architektonischen Sackgassen stecken und können keine Fortschritte machen, während Ihre Konkurrenten Ihr Mittagessen essen. Wenn Sie Ihren Job als Enterprise-Architekt ordnungsgemäß erledigen, müssen Sie dieses Zeug über mindestens 5-10 Jahre nachdenken.

Ich persönlich denke, wenn Sie dynamische Sprachen im Unternehmen verwenden möchten, besteht die bei weitem beste Chance darin, etwas zu verwenden, das Piggy-Backs auf einem vorhandenen Unternehmensökosystem. Am bemerkenswertesten sind die neuen dynamischen JVM -Sprachen: zB Jruby, Groovy, Clojure. Was das IT -Management betrifft, so sind diese "sichere" dynamische Sprachentscheidungen, da sie innerhalb des Restes des Java Enterprise -Ökosystems in innerhalb des Java Enterprise arbeiten.

Der Hauptgrund, warum Unternehmen nicht anfangen, Sprachen wie Erlang, Ruby und Python zu verwenden, scheinen die Tatsache zu sein, dass sie dynamisch getippt sind.

Ich denke, das ist nur ihre Hauptentschuldigung. Der wahre Grund ist, dass Unternehmen sie nicht wirklich so ernst nehmen und das Gefühl haben, dass sie vielleicht ein bisschen zu Amateur sind. Java und .NET sind „große Unternehmensnamen“, haben ein gutes kommerzielles Marketing, kommerzielle Kundenunterstützung und sind daher in der Tat sehr ernst genommen.

Es ist bedauerlich, dass es praktisch keine statisch-typische Sprache gibt, die nahe an nahezu beliebt ist wie die großen Geschäftsnamen. Warum werden Open-Source-/Free-Software-Programmierumgebungen fast immer dynamisch getippt? Dies könnte darauf hinweisen, dass eine statisch typische Sprache eigentlich nicht so einfach zu machen ist, und dass dynamisches Tippen ein „fauler Mannhack“ ist. Wenn dies der Fall ist, haben die Unternehmen, die sich gegen dynamisch typische Sprachen entscheiden, tatsächlich einen Punkt.

  • Dynamisch typisierte Sprachen sind in der Regel langsamer als ihre statisch typisierten Cousins.
  • Fehler sind schwerer zu fangen und können schwerer zu debuggen sein
  • Der Compiler/Dolmetscher ist in der Regel viel weniger anspruchsvoll, was Sie können und was nicht. dh, Sie fangen in der Kompilierungsphase so gut wie nur Syntaxfehler auf
  • Wenn Sie mit dem Design einer dynamisch getippten Sprache nicht sehr vorsichtig sind, haben Sie JavaScript, was ist das Sprache der Code-Mells

BEARBEITEN: Ich sollte erwähnen, dass meine wichtigste Programmiersprache im Moment Python ist, das dynamisch getippt wird. Persönlich liebe ich die Freiheit, die damit verbunden ist, Variablen nicht vor der Deklare vorzugehen, sondern manchmal, es möchten Seien Sie nett, zu spezifizieren (zum Beispiel), welche Art von Parametern eine Funktion nimmt, um Fehler frühzeitig und nicht spät zu fangen.

Dynamisch getippte Sprachen werden (von einigen Programmierern/Bossen) wahrgenommen, um Code zu erzeugen, die nicht auch funktionieren. Die Tatsache, dass ein dynamisch getipptes Programm kompiliert wird, sagt Ihnen sehr wenig über seine Richtigkeit. Die Tatsache, dass eine staatlich eingetragene Sprache kompiliert wird, sagt Ihnen viel mehr. (Andererseits gibt es immer noch einen langen Weg zwischen Kompiles und tut das Richtige, so dass dies weniger bedeutungsvoll sein könnte als es scheint)

Dynamisch getippte Sprachen werden als Skriptsprachen wahrgenommen. Sie würden niemals eine Anwendung in Bash oder eine Stapeldatei schreiben. Alle dynamisch typisierten Sprachen werden in der Regel (unfair) in diese Kategorie geschoben.

Dynamisch getippte Sprachen sind langsamer als statisch getippte Sprachen. (Aber wir werden sehen, wie gut es an JIT funktioniert, das verändert das)

Hinweis: Dies ist größtenteils subjektiv und basiert auf meinen Erfahrungen und Eindrücken.

Dynamisch getippte Sprachen unterscheiden sich stark von statisch getippten Sprachen. Diese Unterschiede werden wahrscheinlich wichtiger in der Unternehmens -Unternehmenssoftware als in den meisten anderen Anwendungen.

Statisch getypte Sprachen sind in der Regel sehr präskriptiv. Eine Methode nimmt nur Eingaben an, die genau der Signatur übereinstimmen. Die Zugangsniveaus sind in der Regel sehr wichtig und Schnittstellen werden explizit definiert, mit ausführlichen, aber eindeutigen Einschränkungen, um diese Definitionen durchzusetzen.

Dynamisch getippte Sprachen hingegen sind sehr pragmatisch. Typ -Conversions treten häufig implizit auf. Funktionen können sogar mitspielen, wenn Sie die falsche Eingabeart bereitstellen, solange sie sich ausreichend verhalten. In Sprachen wie Python basiert sogar Zugangsniveaus eher auf Vertrag als auf technischen Beschränkungen (dh es ist nur private Weil Sie gesagt haben, dass Sie es nicht verwenden sollen und es einen lustigen Namen hat).

Viele Programmierer bevorzugen dynamische Sprachen, weil sie (wohl) ein schnelles Prototyping ermöglichen. Der Code endet oft kürzer (wenn auch nur aufgrund des Mangels an Typdeklarationen) und wenn Sie ein ordnungsgemäßes Protokoll verletzen möchten, da Sie eine schnelle und schmutzige Lösung benötigen oder etwas testen möchten, ist dies leicht möglich.

Der Grund, warum "unternehmerische" Unternehmen häufig statisch typisierte Sprachen bevorzugen, ist genau, dass sie in Bezug auf diese Einschränkungen restriktiver und expliziterer sind. Obwohl in der Praxis sogar statisch getippte Code von Idioten mit einem Compiler unterbrochen werden kann, werden viele Probleme viel früher in diesem Prozess (dh vor der Laufzeit) viel besser sichtbar sein. Dies bedeutet, dass selbst wenn die Codebasis groß, monolithisch und komplex ist, viele Fehler leicht erfasst werden können, ohne den Code ausführen oder an die QA -Abteilung senden zu müssen.

Der Grund, warum der Nutzen die Nachteile für viele Programmierer außerhalb dieser Umgebung nicht überwiegen, ist, dass dies Fehler sind, die oft leicht durch eine gründliche Inspektion des Codes oder sogar durch Versuch, ihn zu betreiben, leicht zu erfassen sind. Insbesondere bei der Befolgung einer testgetriebenen Methodik werden diese Fehler häufig trivial zu fangen und leicht zu reparieren. Da viele solcher Unternehmen einen viel kürzeren Freisetzungszyklus haben, ist die Produktivität oft wichtiger als die Starrheit und viele (grundlegende) Tests werden von den Entwicklern selbst durchgeführt.

Der andere Grund, warum Unternehmensunternehmen nicht dynamisch typisierte Sprachen verwenden, ist der Legacy -Code. So albern es auch für US-Nerds auch sein mag, große Unternehmen halten sich oft an Lösungen, die funktionieren, auch wenn sie weit über ihre Haltbarkeit hinausgehen. Aus diesem Grund setzen so viele große Unternehmen Internet Explorer 6 durch und sind so langsam, ihre OSS aufzurüsten. Dies ist auch der Grund, warum sie oft neuen Code in "alten" Sprachen (z. B. alte Versionen von Java) schreiben Sprache.

tl; dr: Statische Sprachen fühlen sich eher wie Bürokratie an, daher mögen sie unternehmungslustige Manager besser.

Nein, ich glaube nicht, dass dynamisch getippte Sprachen die ganze Kritik verdienen. (Oder wenn Sie es bevorzugen, verdienen sie so viel Kritik wie statisch typisierte Sprachen.)

Nach meiner Erfahrung (und ich mache keinen Versuch, diese Aussage zu verallgemeinern) haben die Programmierer, die dynamische Sprachen kritisieren, nicht verwendet. Das Gespräch lautet normalerweise "aber mit statischer Eingabe des Compilers fängt das Compiler so viele Fehler auf!" Und ich sage "Nun, das ist meiner Erfahrung nach kein Problem." (Normalerweise der andere Programmierer aus einem Java, Delphi oder einem ähnlichen Hintergrund; ich kenne keine Haskell- oder ML -Programmierer.)

Das einzige, was mich wirklich erfasst, ist, wenn jemand behauptet, dass die Technik foo nicht kann möglicherweise in einer dynamisch typisierten Sprache erledigt werden (oder sehr schwer zu tun sein) ... wenn diese Technik in, von und für eine dynamisch typisierte Sprache erfunden wurde. Ides? Smalltalk. Automatisches Refactoring? Smalltalk. Anrufer von/Implementieren von? Smalltalk.

Unternehmen nehmen einfach nicht schnell genug neue Sprachen und Tools an und es gibt gute Gründe dafür. Wenn jedoch eines der Mainstream -Tools wie C# einige dieser Funktionen implementieren, werden es in die Mainstream -Unternehmen eindringen ....

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top