Unter welchen Umständen sind dynamische Sprachen nicht geeignet?

Question

Welche Faktoren deuten darauf hin, dass die Lösung eines Projekts nicht in einer dynamischen Sprache codiert werden sollte?

Answer 1

Geschwindigkeit ist normalerweise die primäre Antwort. Obwohl dies heutzutage weniger ein Problem ist.

Answer 2

wenn Geschwindigkeit entscheidend ist. Dynamische Sprachen werden zwar schneller, sind aber immer noch nicht so leistungsfähig wie eine kompilierte Sprache.

Answer 3

Vertrautheit und Bereitschaft der Programmierer, mit der Sprache zu arbeiten.

Ihre dynamische Sprache ist wahrscheinlich meine statische Sprache.

Answer 4

Die Entwicklung auf Systemebene ist eine Schlüsselgruppe von Software, die normalerweise nicht in dynamischen Sprachen enthalten sein sollte. (Treiber, Kernel-Level-Zeug, usw.).

Im Grunde sollte alles, was jede Unze von Leistung oder niedrigen Hardwarezugriff haben muss, in einer niedrigeren Sprache sein.

Ein weiterer Indikator ist, wenn es in hohem Maße Zahlen knirscht, wie wissenschaftliche Datenzahl Knirschen. Das heißt, wenn es schnell laufen und Zahlen knirschen muss.

Ich denke, ein gemeinsames Thema ist prozessorintensive Probleme ... in diesem Fall werden Sie leicht die Leistungsunterschiede sehen, und Sie werden feststellen, dass die dynamische Sprache Ihnen nicht die Macht geben kann, die Hardware effektiv zu verwenden.

Das heißt, wenn Sie Prozessor-intensive Arbeit machen und es Ihnen nichts ausmacht, die Leistung zu schlagen, dann könnten Sie immer noch potenziell eine dynamische Sprache verwenden.

---

Update:

Beachten Sie, dass für Zahlenverarbeitung, ich meine wirklich lange Reihe läuft in der wissenschaftlichen Arena Knirschen, wo der Prozess für Stunden oder Tage läuft ... in diesem Fall ein 2x Leistungsgewinn ist GINORMOUS ... wenn es in einem viel kleineren Maßstab ist, könnten dynamische Sprachen immer noch nützlich sein.

Answer 5

Wie wäre es mit Interop? Ist es möglich, eine COM-Komponente von Ruby oder Python aufzurufen?

Answer 6

Interop ist mit dynamischen Sprachen absolut möglich. (Erinnern Sie sich an klassisches Visual Basic, das "Lazy Binding" hat?) Es erfordert jedoch, dass die COM-Komponente mit einigen Extras kompiliert wird, um ihren Anrufern zu helfen, namentlich zu telefonieren.

Ich denke nicht, dass Zahlenverarbeitung statisch kompiliert werden muss, meistens ist es eine Frage, wie Sie lösen. Matlab ist ein gutes Beispiel für Zahlenverarbeitung und hat eine nicht kompilierte Sprache. Matlab hat jedoch eine sehr spezifische Laufzeit für Zahlen und Matrizen.

Answer 7

Ich glaube, Sie sollten immer für statisch typisierte Sprache wählen, wo immer möglich. Ich sage nicht, dass C# oder Java gute statische Systeme haben, aber C# nähert sich. Gute type inference ist der Schlüssel, weil es Ihnen Vorteile in dynamischen Sprachen bietet, während Sie immer noch Sicherheit und Funktionen von statisch getippten geben. Problem gelöst - keine Flamme mehr.

Answer 8

Code auf Systemebene für eingebettete Systeme. Ein mögliches Problem besteht darin, dass dynamische Sprachen manchmal die Performance-Implikationen einer einzelnen leicht aussehenden Aussage verbergen.

Wie sagt diese Aussage Perl:

@contents = <FILE>; 

Wenn FILE ein paar Megabyte ist, dann ist das eine ressourcenintensive Aussage - Sie könnten Ihren Haufen erschöpfen, oder ein Watchdog-Timeout verursachen, oder generell verlangsamen die Antwort des eingebetteten Systems.

Wenn Sie "näher am Metall programmieren" möchten, möchten Sie wahrscheinlich eine statisch typisierte und "mittlere" Sprache verwenden.

Answer 9

Grafikkarte Gerätetreiber

Answer 10

Zu einem großen Teil ist Programmiersprache eine Art Wahl. Verwenden Sie die Sprache, die Sie verwenden möchten, und Sie werden maximal produktiv und glücklich sein. Wenn das aus irgendeinem Grund nicht möglich ist, dann wird Ihre endgültige Entscheidung hoffentlich auf etwas Sinnvollem basieren, wie eine Plattform, gegen die Sie antreten müssen, oder echte, empirische Leistungszahlen, und nicht die willkürliche Stilwahl eines anderen.