Warum werden bei der Entwicklung eines Produkts oder einer Software mehrere Programmiersprachen verwendet?

Ich bin ein neuer Student mit dem Ziel, meinen Master in Informatik zu beginnen. Ich bin auf mehrere Open Source-Projekte gestoßen, die mich wirklich faszinieren und ermutigen, zu ihnen beizutragen (CloudStack, OpenStack, Moby und Kubernetes, um nur einige zu nennen). Ich habe festgestellt, dass die meisten von ihnen die Verwendung mehrerer Programmiersprachen (wie Java + Python + Go oder Python + C ++ + Ruby) gemeinsam haben. Ich habe mir bereits diese andere Frage angeschaut, die sich mit der Art und Weise befasst, wie mehrere Programmiersprachen miteinander kommunizieren: Wie können zwei verschiedene Programmierungen mit zwei verschiedenen Sprachen interagieren?

Ich möchte die Anforderung verstehen, die Unternehmen zur Verwendung mehrerer Programmiersprachen auffordert. Welche Anforderung oder Art von Anforderung lässt den Softwarearchitekten oder Projektleiter sagen: "Ich schlage vor, dass wir für Aufgabe 1 die Sprache X und für Aufgabe 2 die Sprache Y verwenden." Ich kann anscheinend nicht verstehen, warum mehrere Programmiersprachen in demselben Produkt oder derselben Software verwendet werden.

Diese Antwort bietet eine hervorragende Übersicht und enthält Links dazu, warum verschiedene Sprachen für ein Projekt unterschiedliche Vorteile bieten können. Es ist jedoch nicht nur eine Frage der sprachlichen Eignung, warum Projekte mehrere Sprachen verwenden.

Projekte verwenden aus sechs Hauptgründen mehrere Sprachen:

1. Kostenvorteile bei der Wiederverwendung von in anderen Sprachen geschriebenem Code;
2. Die Notwendigkeit, Legacy-Code einzubeziehen und aufzunehmen;
3. Verfügbarkeit von Codierern für bestimmte Sprachen;
4. Das Bedürfnis nach speziellen Sprachen für spezielle Bedürfnisse;
5. Legacy-Sprachverzerrungen; und
6. Schlechtes Projektmanagement (ungeplante mehrsprachige Verwendung).

Die Gründe 1 bis 4 sind insofern positiv, als eine direkte Ansprache dazu beitragen kann, dass ein Projekt schneller, effizienter, mit einem qualitativ hochwertigeren Produkt und mit einer einfacheren langfristigen Unterstützung abgeschlossen werden kann. Die Gründe 5 und 6 sind negativ, Symptome des Widerstands gegen notwendige Veränderungen, schlechte Planung, ineffektives Management oder eine Kombination all dieser Faktoren. Diese negativen Faktoren sind leider häufige Ursachen für "versehentlichen" mehrsprachigen Gebrauch.

Grund 1 , der Kostenvorteil der Wiederverwendung, ist zu einem immer wichtigeren Grund geworden, die Verwendung mehrerer Sprachen in einem Projekt zuzulassen, da Open Source-Software eine größere Rolle spielt und die Funktionen zum Auffinden der richtigen Codekomponenten im Web verbessert wurden. Die Philosophie "Lassen Sie uns alles intern programmieren" der vergangenen Jahrzehnte ist angesichts der wirtschaftlichen Gegebenheiten nach wie vor verblasst und im Grunde nie der kostengünstigste Ansatz für ein neues Projekt. Dies wiederum macht die Möglichkeit einer strikten Durchsetzung der Verwendung einer einzigen Sprache innerhalb eines Projekts seltener.

Insbesondere im Fall eines Projekts, bei dem gut verwaltete Open-Source-Komponenten wiederverwendet werden, kann die Verwendung mehrerer Sprachen enorme Kostenvorteile bringen, da die wiederverwendeten Komponenten sich hinter gut gestalteten Schnittstellen verstecken und von externen Gruppen ohne Kostenaufwand unabhängig gewartet werden. Im besten Fall ist das Mischen von Sprachen über diese Art der Wiederverwendung für das Projekt nicht teurer als die Verwendung von Betriebssystemkomponenten. Ich kenne kein besseres Beispiel für den Wert dieses Ansatzes als die groß angelegte Übernahme von Open-Source-Software durch Microsoft in ihren Browsern.

Grund 2 , die Notwendigkeit, Legacy-Code zu berücksichtigen, wird bei großen Projekten ignoriert. So viel Ärger Legacy-Code auch verursachen mag, die naive Annahme, dass er leicht durch neuen Code in einer neuen Sprache ersetzt werden kann, kann ein unglaubliches Risiko darstellen. Legacy-Code, auch schlechter Legacy-Code, enthält häufig einen impliziten "Vertrag" von Funktionen, die von der Community, die das Legacy-Produkt verwendet, erwartet werden. Diese Community ist häufig eine wichtige Einnahmequelle für ein Unternehmen oder das Hauptziel der Unterstützung für Regierungssoftware. Wenn Sie diesen impliziten Vertrag einfach verwerfen, können Sie bewusste Kunden in Scharen verfolgen und ein Unternehmen über Nacht bankrott machen, wenn andere Optionen verfügbar sind.

Zur gleichen Zeit, nicht alten Code in einer alten Sprache ersetzen kann genauso gefährlich sein , wie es Großhandel ersetzen. Ein Beispiel für den schlimmsten Fall ist die US-Veteranenverwaltung, die über eine große Anzahl lebenswichtiger Systeme verfügt, die in einer Sprache namens MUMPS (kein Scherz) codiert sind, die von Ärzten und nicht von Informatikern entwickelt wurde. Niemand will MUMPS lernen, und diejenigen, die es wissen, sterben buchstäblich ab. Programmierer müssen sich daher auf MUMPS einstellen, auch wenn sie versuchen, andere gebräuchlichere, leistungsfähigere und besser gewartete Sprachen zu verwenden.

Diese Art der mehrsprachigen Verwendung erfordert sorgfältige Planung. Diese Planung muss den Spagat zwischen dem Verlust jahrzehntelangen Kundenwissens und dem Verlust der Fähigkeit zur Unterstützung der Software auf der anderen Seite bewältigen. Techniken, die den alten Code hinter gut definierten Schnittstellen isolieren und neuen, leistungsfähigeren Code ermöglichen, den alten Code zu ersetzen, nachdem sein Verhalten gut dokumentiert wurde, können Abhilfe schaffen. Dieses alte Szenario ist jedoch niemals einfach und war (und ist auch weiterhin) die Ursache für den Niedergang vieler Unternehmen und Organisationen in einem breiten Spektrum von Größen.

Grund 3 , die Verfügbarkeit von Programmierern für verschiedene Sprachen, ist ein pragmatischer Faktor, den Projekte auf eigene Gefahr ignorieren. Unabhängig davon, wie sehr die Projektorganisatoren das Gefühl haben (richtig oder falsch), dass eine bestimmte Sprache für ihre Ziele am besten geeignet ist, wenn diese Sprache in Konflikt mit dem ihnen zur Verfügung stehenden Sprachkompetenzpool steht, leiden sowohl der Zeitplan als auch die Qualität des Produkts unter dem Lernen gebogen von Programmierern, die versuchen, eine neue Sprache zu lernen.

Ein rationalerer Ansatz besteht darin, die Sprachbedürfnisse des Projekts anhand der Funktionsbereiche zu analysieren. Ein genauer Blick auf das Projekt kann beispielsweise zeigen, dass es nur einen kleinen "Scheitelpunkt" an hochwertigem Code gibt, z. B. für die Implementierung eines proprietären Algorithmus, für den Codierungskenntnisse in einer weniger häufig verwendeten Sprache erforderlich sind. Andere Teile eines großen Projekts lassen sich häufig problemlos mit gängigeren Sprachen oder (noch besser) mit gut verwalteten Open-Source-Produkten bearbeiten. Die Analyse eines Projekts nach Sprachbedürfnissen kann somit einen wesentlich realistischeren und kostengünstigeren Ansatz für die Einstellung oder Anmietung von Spezialkenntnissen in bestimmten Sprachen bieten und auch dazu beitragen, die Schnittstellen zwischen Sprachen innerhalb eines einzelnen Projekts zu schärfen.

Grund 4 , bei dem unterschiedliche Sprachen für unterschiedliche Anforderungen verwendet werden, ergibt sich unmittelbar und reibungslos aus einer solchen Analyse der Projektanforderungen. Vorsicht ist auch hier geboten, da die Auswahl zu vieler Sprachen für die Unterstützung innerhalb eines einzelnen Projekts zu einer kombinatorischen Explosion der Komplexität sowohl bei der Unterstützung als auch bei den Schnittstellen zwischen Komponenten führen kann. Am sichersten ist es in Bezug auf die Kosten, zuerst die maximalen Möglichkeiten für die Wiederverwendung zu finden, insbesondere, wenn es gute Pakete gibt, die die Projektanforderungen nur durch Anpassung erfüllen können. Als nächstes sollte eine Entscheidung über eine kleine Anzahl von Sprachen getroffen werden, die die Mehrheit der ermittelten Bedürfnisse abdecken können. Bei wiederverwendungsintensiven Entwicklungen handelt es sich häufig um eine Art Klebercode.

Es ist im Allgemeinen keine gute Idee, mehrere Sprachen mit sehr ähnlichen Fähigkeiten auszuwählen, nur weil einige Mitglieder des Projekts die eine oder die andere mögen. Wenn es jedoch eine genau festgelegte Teilmenge von Fähigkeiten gibt, die von besonderen Sprachkenntnissen profitieren würde, kann dies ein guter Grund sein, mehrere Sprachen für die Entwicklung von neuem Code zu verwenden.

Grund 5 , der Widerstand gegen notwendige Änderungen in den verwendeten Sprachen, kann zu schwerwiegenden Projektstörungen und internen Konflikten führen. Als Benutzer DaveoIn einem Kommentar zu dieser Antwort wurde darauf hingewiesen, dass Änderungen für einige Projektmitarbeiter sehr schwierig sein können. Gleichzeitig ist der Widerstand gegen Veränderungen niemals ein einfaches Thema, weshalb er viel Streit verursachen kann. Die Verwendung von vorhandenen Sprachkenntnissen kann die Produktivität eines Projekts erheblich steigern, wenn die vorhandene Sprache ausreichend leistungsfähig ist, und zu einem Produkt mit hervorragender Qualität in einem Team führen, das reibungslos funktioniert und die Qualität achtet. Ältere Sprachkenntnisse müssen jedoch mit der Tatsache in Einklang gebracht werden, dass viele ältere Sprachen in Bezug auf erweiterte Funktionen, Verfügbarkeit von Komponenten, Open Source-Optionen und Unterstützung intelligenter Toolkits nicht mehr mit neueren Sprachen ergänzt werden können.

Damals und heute war das häufigste (und ironischerweise häufigste) Argument für die weitere Verwendung einer schwächeren, weniger lesbaren oder weniger produktiven Legacy-Sprache, dass die ältere Sprache die Produktion von effizienterem Code ermöglicht. Dies ist ein altes Argument, das bis in die 1950er Jahre zurückreicht, als die Benutzer der Assemblersprache das Aufkommen der Programmierung in FORTRAN und LISP oftmals erbittert kritisierten. Ein Beispiel, bei dem das Argument der Codeeffizienz bereits jetzt Gültigkeit haben kann, ist der verarbeitungsintensive Code, z. B. ein Betriebssystemkern, bei dem C die bevorzugte Sprache gegenüber C ++ bleibt (allerdings aus Gründen, die über die einfache Effizienz hinausgehen).

In den global vernetzten und leistungsfähigen maschinengestützten Projektumgebungen des neuen Jahrtausends ist die Codeeffizienz als Hauptargument für die Wahl einer Projektsprache jedoch noch schwächer geworden. Die gleiche Explosion von Computer- und Netzwerkhardware, die die Massenvermarktung von Anwendungen mit künstlicher Intelligenz ermöglicht hat, bedeutet auch, dass die Kosten für die menschliche Programmierung die Kosten für die ineffiziente Ausführung von Code auf spektakulär billiger Hardware und Cloudware leicht in den Schatten stellen können. In Kombination mit der höheren Verfügbarkeit von Komponentenbibliotheken, Open Source-Optionen und fortschrittlichen intelligenten Toolkits in neueren Sprachen wird die Anzahl der Fälle, in denen eine Sprache nur aus Effizienzgründen beibehalten wird, sehr gering. Auch in Fällen, in denen dies zutrifft,

Ein zwingenderer Grund für ein Projekt, bei alten Sprachen zu bleiben, liegt vor, wenn ein Projekt aus welchen Gründen auch immer nur wenige oder keine Möglichkeiten hat, sein Personal zu ändern. Dies kann beispielsweise der Fall sein, wenn eine wichtige ältere Produktlinie vollständig in einer Sprache codiert ist, in der nur das vorhandene Personal fließend ist. In solchen Fällen muss das Projekt entweder versuchen, in der alten Sprache zu programmieren, oder vorhandene Mitarbeiter in der Verwendung einer neuen Sprache schulen.

Die Schulung älterer Mitarbeiter in einer neuen Sprache kann für sich genommen eine Gefahr darstellen. Ich erinnere mich noch an einen Fall, in dem sich ein Mitglied eines Projekts, das gerade geschult und von C auf C ++ umgestellt worden war, aufrichtig darüber beschwerte, dass er die Vorteile objektorientierter Methoden einfach nicht verstand. Als ich mir seinen Code ansah, hatte er seine früheren 103 C-Funktionen in 103 Methoden für eine einzelne C ++ - Objektklasse konvertiert ... und zu Recht nicht gesehen, wie das irgendetwas half.

Die tiefere Botschaft ist, dass, wenn Menschen jahrelang oder jahrzehntelang in einer einzigen Sprache und einem Sprachstil programmiert haben, die Schwierigkeit, sie dazu zu bringen, auf neue Weise zu "denken", selbst mit guten Trainingsprogrammen fast unüberwindbar werden kann. In einigen Fällen bleibt möglicherweise keine andere Wahl, als jüngere Designer und Programmierer zu gewinnen, die besser mit den aktuellen Trends und Methoden vertraut sind.

Grund 6 , schlechtes Projektmanagement, spricht für sich. Die Auswahl und Verwendung von Sprachen in einem Projekt sollte immer explizit berücksichtigt und bewertet werden und darf nicht zufällig geschehen. Zumindest kann die Sprachauswahl einen großen Einfluss auf das langfristige Schicksal und die Supportkosten eines Projekts haben und sollte daher immer berücksichtigt und geplant werden. Werde kein MUMPS!

Ich kann anscheinend nicht verstehen, warum mehrere Programmiersprachen in demselben Produkt oder derselben Software verwendet werden.

Es ist ganz einfach: Es gibt keine einzige Programmiersprache, die für alle Bedürfnisse und Ziele geeignet ist.

Lesen Sie Michael L. Scotts Buch Programming Language Pragmatics

Einige Programmiersprachen bevorzugen Ausdruckskraft und Deklarativität (viele Skriptsprachen, aber auch Programmiersprachen auf hohem Niveau wie Agda , Prolog , Lisp , Haskell, Ocaml, ...). Wenn die Entwicklungskosten wichtig sind (menschlicher Zeitaufwand und Kosten für Entwickler), ist es angemessen, sie zu verwenden (auch wenn die Laufzeitleistung nicht optimal ist).

Andere Programmiersprachen begünstigen die Laufzeitleistung (viele Low-Level-Sprachen mit normalerweise kompilierten Implementierungen wie C ++, Rust, Go, C, Assembler, auch spezialisierte Sprachen wie OpenCL ...); Oft erlaubt ihre Spezifikation ein undefiniertes Verhalten . Wenn die Leistung des Codes von Bedeutung ist, sollten diese Sprachen bevorzugt verwendet werden.

Einige externe Bibliotheken sind in und für eine bestimmte Sprache und ABI geschrieben und berücksichtigen dabei Konventionen . Sie können diese andere Sprache verwenden müssen, und folgen Fremd Funktion Schnittstelle Konventionen, vielleicht durch einige Schreiben Glue - Code .

In der Praxis ist es unwahrscheinlich, dass eine Programmiersprache sehr aussagekräftig ist (was die Produktivität des Entwicklers verbessert, vorausgesetzt, ein Entwicklerteam verfügt über ausreichend Fachwissen) und zur Laufzeit sehr performant ist. In der Praxis gibt es einen Kompromiss zwischen Expressivität und Leistung.

Hinweis: Bei den Programmiersprachen gab es einige langsame Fortschritte: Rust ist ausdrucksvoller als C oder vielleicht sogar C ++, aber seine Implementierung ist fast genauso performant und wird sich wahrscheinlich verbessern, um ebenso schnelle ausführbare Dateien zu generieren. Sie müssen also während Ihres Berufslebens neue Programmiersprachen lernen. Es gibt jedoch keine Silberkugel

Beachten Sie, dass die Entwicklungskosten heutzutage immer höher sind (das war in den 1970er Jahren nicht der Fall - damals waren Computer sehr teuer - oder in einigen eingebetteten Anwendungen - mit einem großen Produktvolumen). Die Faustregel (sehr ungefähr) lautet, dass ein erfahrener Entwickler in der Lage ist, jedes Jahr etwa 25.000 Zeilen (debugged & dokumentierten) Quellcode zu schreiben, und dies hängt nicht wesentlich von der verwendeten Programmiersprache ab.

Ein gängiger Ansatz besteht darin, eine Skriptsprache (oder eine domänenspezifische Sprache ) in eine große Anwendung einzubetten . Diese Gestaltungsidee (bezogen auf die domänenspezifische Sprache) wird seit Jahrzehnten verwendet (ein gutes Beispiel ist der Emacs- Quellcode- Editor , der seit den 1980er Jahren Elisp für die Skripterstellung verwendet). Dann verwenden Sie einen leicht einbettbaren Interpreter (wie Guile , Lua , Python), ...) in einer größeren Anwendung. Die Entscheidung, einen Interpreter in eine große Anwendung einzubetten, muss sehr früh getroffen werden und hat starke Auswirkungen auf die Architektur. Sie werden dann zwei Sprachen verwenden: für Low-Level-Inhalte, die schnell ausgeführt werden müssen, einige Low-Level-Sprachen wie C oder C ++; für High-Level-Skripte die andere DSL- oder Skriptsprache.

Beachten Sie auch, dass eine bestimmte Software unter den meisten aktuellen Betriebssystemen (einschließlich Linux, Windows, Android, MacOSX, Hurd usw.) in mehreren zusammenarbeitenden Prozessen ausgeführt werden kann, die eine Art von prozessübergreifenden Kommunikationstechniken verwenden. Es kann sogar auf mehreren (oder vielen) Computern mit verteilten Computertechniken (z. B. Cloud-Computing , HPC, Client-Server, Webanwendungen usw.) ausgeführt werden. In beiden Fällen können problemlos mehrere Programmiersprachen verwendet werden (z. B. Code für jedes Programm, das auf einem Prozess oder Computer ausgeführt wird, in einer eigenen Programmiersprache). Lesen Sie Betriebssysteme: Drei einfache Teile für mehr. Auch fremde Funktionsschnittstellen(z. B. JNI ), ABIs , Aufrufkonventionen usw. ... erleichtern das Mischen mehrerer Sprachen in demselben Programm (oder derselben ausführbaren Datei ) - und Sie finden Codegeneratoren wie SWIG , die Ihnen dabei helfen.

In einigen Fällen Sie müssen mehrere Programmiersprachen mischen: Web - Anwendungen müssen Javascript oder Webassembly (die einzigen Sprachen in die meisten Web - Browser ausgeführt wird ) für das Teil im Browser ausgeführt wird (es gibt Frameworks zu erzeugen diese, zB ocsigen ). Kernel-Code benötigt einige Dinge (z. B. den Scheduler oder die Low-Level-Behandlung von Interrupts), um teilweise in Assembler geschrieben zu werden, da C oder C ++ nicht ausdrücken können, was dort benötigt wird. RDBMS-Abfragen sollten SQL verwenden. GPGPUs benötigen in OpenCL codierte Computerkerne oder CUDA verwaltet von C oder C ++ Host-Code, etc .... Einige Sprachen sind so konzipiert, dass sie eine solche Mischung ermöglichen (zB Anweisungen in C,asmCodestücke in meiner späten GCC MELT , etc ...).

In einigen Fällen verwenden Sie Metaprogrammiertechniken : In einigen Teilen Ihres großen Softwareprojekts wurde Code (z. B. in C oder C ++) mit anderen Tools (möglicherweise projektspezifischen Tools) aus einer Ad-hoc-Formalisierung generiert: Parser-Generatoren (zu Unrecht Compiler genannt). man denke an Compiler wie Bison oder ANTLR , aber auch an SWIG oder RPCGEN. Beachten Sie, dass GCC mehr als ein Dutzend spezialisierter C ++ - Codegeneratoren (einer für jedes interne DSL in GCC) enthält. Siehe auch dieses Beispiel. Beachten Sie, dass Metabugs schwer zu finden sind. Lesen Sie auch über Bootstrapping-Compiler sowie über Homoikonizität und Reflexion(Es lohnt sich, Lisp zu lernen , mit SBCL zu spielen und SICP zu lesen. Schauen Sie sich auch JIT-kompilierende Bibliotheken wie GCCJIT an . In einigen großen Programmen generieren Sie möglicherweise zur Laufzeit Code. Beachten Sie die zehnte Greenspun-Regel. ) Schauen Sie sich auch den Vortrag zu Circuit Less Traveled auf der FOSDEM2018 an.

Manchmal möchten Sie formelle Anmerkungen zu Ihrem Code bereitstellen (z. B. um Testern, statischen Analysatoren und Compilern zu helfen), indem Sie eine spezielle Anmerkungssprache verwenden (die möglicherweise als eine Art DSL angesehen wird). Schauen Sie sich ACSL mit Frama-C an, um C-Programme (sicherheitskritische) oder OpenMP- Pragmas für HPC mit Anmerkungen zu versehen . Vorsichtsmaßnahme: Das Schreiben solcher Anmerkungen kann viel Fachwissen und Entwicklungszeit erfordern.

Übrigens deutet dies darauf hin, dass einige Fähigkeiten in Bezug auf Compiler und Interpreter für jeden Entwickler nützlich sind (auch ohne in Compilern zu arbeiten). Lesen Sie also das Drachenbuch, auch wenn Sie nicht an Compilern arbeiten. Wenn Sie Ihren eigenen Interpreter codieren (oder wenn Sie Ihr DSL entwerfen), lesen Sie auch Lisp In Small Pieces .

Siehe auch dies & das & das & das Antworten von mir zu Ihrer Frage.

Lesen Sie auch den Quellcode mehrerer großer Projekte freier Software (auf Github oder von Ihrer Linux-Distribution ), um Anregungen und Erkenntnisse zu erhalten .

Einige Programmiersprachen haben sich auch durch Hinzufügen von Anmerkungen (als Pragmas oder Kommentare ) zu vorhandenen Sprachen entwickelt. Für Beispiele, denken Sie an ACSL (Kommentar-Erweiterung C - Programme mit Anmerkungen versehen , um ihre Beweise von zu ermöglichen Frama-C ) oder von OpenCL (ein C - Dialekt GPGPUs zu programmieren) oder OpenMP oder OpenACC #pragmas oder Common Lisp Typenannotationen .

PS: Es gibt auch soziale, organisatorische oder historische Gründe, Programmiersprachen zu mischen. Ich ignoriere sie hier, aber ich weiß, dass in der Praxis solche Gründe vorherrschen. Lesen Sie auch The Mythical Man Month

Viele Projekte werden nicht mit mehreren Programmiersprachen erstellt. Es ist jedoch üblich, Skripts in anderen Sprachen zu verwenden, um die Software zu unterstützen.

• Verwaltungstools, die separate Programme sind, werden manchmal in einer anderen Sprache geschrieben.
• Bibliotheken und APIs bieten häufig Bindungen für mehrere Sprachen an, sodass Entwickler die von ihnen bevorzugte Sprache verwenden können.
• Erstellungsskripte und verwandte Entwicklungsskripte verwenden häufig spezielle Sprachen.
• End-to-End-Tests einer Anwendung müssen nicht dieselbe Sprache verwenden.

Einige Projekte verwenden mehrere Sprachen in der Anwendung, z. B. einen Kern in einer niedrigeren Sprache, der Plugins in eine Skriptsprache integrieren kann. In einigen Ökosystemen (z. B. JVM oder .NET) ist die genaue verwendete Sprache nicht allzu wichtig, da mehrere Sprachen zur Laufzeit derselben Sprache eine gute Interoperabilität aufweisen. Ich könnte beispielsweise ein Projekt in Scala schreiben, das vorhandene Java-Bibliotheken verwendet und Skriptfunktionen in Groovy integriert.

Wenn ein Projekt aus mehreren Tools besteht, können diese auch in verschiedenen Sprachen entwickelt werden. Obwohl Konsistenz gut wäre, kann der verfügbare Entwicklungsaufwand insbesondere für Open Source-Projekte ein Engpass sein. Wenn jemand bereit ist, ein nützliches Tool zu entwickeln, aber nicht mit der Hauptsprache vertraut ist, ist dieses Tool möglicherweise wertvoller als Konsistenz.

Dies hat zwei Formen und viele Organisationen, die irgendwo zwischen den beiden liegen:

Die schlechte Form - die Organisation ist ein Chaos, und es gibt niemanden, der sicherstellt, dass es eine einzige technologische Vision für die Anstrengung gibt. Entwickler verwenden höchstwahrscheinlich die Sprache, in der sie sich am wohlsten fühlen, oder haben kürzlich mit einem neuen Framework oder einer neuen Sprache experimentiert und beschlossen, diese einfach zu verwenden, weil sie naiv optimistisch sind.

Die gute Form - die Organisation hat eine wirklich gute, saubere Architektur, die sich gut für die mehrsprachige Programmierung eignet. Entkoppeln von Anwendungen in unabhängige Komponenten mit einem genau definierten Begrenzungskontext. Diese Kombination ermöglicht es ihnen, die Programmiersprache auszuwählen, die es ihnen am einfachsten ermöglicht, diese bestimmte Komponente zu schreiben.

Realität - normalerweise ist es eher die erstere als die letztere. Ich habe gesehen, dass einige Unternehmen eine Sprache für ihre Geschäftsdomäne und eine andere für ihren Webserver und häufig die dritte für ihre Datenbankadministration ausgewählt haben, was technisch in Ordnung ist, aber bald mangelt es ihnen an technischem Verständnis (oder sie lehnen es ab, ihren Mitarbeitern zuzuhören). Dies bedeutet, dass alle drei Bereiche in einem großen Durcheinander verschwimmen und häufig weitere Sprachen eingeführt werden, die sich für die Lösung bestimmter Teile des Durcheinanders eignen.

Ich kann ein Beispiel für ein Programmierprojekt beisteuern, das seit 32 Jahren läuft und anscheinend noch viel Leben in sich birgt. Es ist eher kommerziell als Open Source.

Der Kern ist in einer domänenspezifischen Sprache geschrieben, die speziell für das Projekt erstellt wurde. Dies hat sich als äußerst nützlich erwiesen, insbesondere, weil es das Rollback in die Basisarchitektur integriert, aber in C-Code kompiliert wird, den wir dann mit dem Compiler der Plattform kompilieren. In dieser Zeit wurden etwa zwanzig Plattformen unterstützt, wobei 32-Bit- und 64-Bit-Varianten nicht berücksichtigt wurden. Derzeit werden sechs davon ausgeliefert.

Es hat ein in C ++ geschriebenes Add-On, das gestartet wurde, als ein ehemaliger Projektleiter davon überzeugt war, dass C ++ / MFC / Windows / x86 alle anderen Architekturen und Plattformen verdrängen würde, weshalb es notwendig war, C ++ zu bieten Personal einstellen können. Die Dinge verliefen nicht so, wie er es erwartet hatte.

Zusätzlich zu der Domänensprache und C ++ arbeiten Entwickler in LISP, das zum Schreiben von Testfällen verwendet wird, unter Verwendung eines im Test-Harness eingebetteten Interpreters. Wir dachten an einem Punkt darüber nach, LISP durch Java zu ersetzen, aber es stellte sich als glücklich heraus, dass wir dies nicht taten.

Es hat auch einen Wrapper für die Haupt-API, der in C # geschrieben ist. Dies geschah, als die Kunden dies verlangten, damit sie ihre Anwendungen in C # neu schreiben konnten. Es wird von einem Perl-Skript erstellt, das die C-Header-Dateien für die API sowie eine wichtige Konfigurationsdatei liest und den C # -Code für den Wrapper schreibt. Die gesamte Textverarbeitung in Perl war einfacher als in C ++.

Es verfügt über eigene Build-Systeme und benötigt diese, da die Domänensprache für make-basierte Build-Systeme nicht zugänglich ist. Die für UNIX-ähnliche Plattformen ist in Shell-Skripten, Perl und einigen kleinen Programmen in der Domänensprache geschrieben. Die für Windows-Plattformen ist in Batch-Sprache, Perl und denselben kleinen Programmen in der Domänensprache geschrieben. Das alte VMS-Build-System wurde in DCL geschrieben, aber seit über einem Jahrzehnt nicht mehr verwendet.

Der Compiler enthält einige YACC / Bison-Programme für die Domänensprache. Es gibt einen Testcode für Apple-Plattformen, der in Objective-C ++ geschrieben wurde. Einige der internen Websites des Teams (die für das Projektmanagement verwendet werden und nicht Teil des Lieferumfangs sind) sind in ASP geschrieben, andere in Perl als CGI-Skripte.

Grundsätzlich war dies ein Projekt zur Lösung eines schwierigen Problems. Es hat sich also gelohnt, spezielle Tools zu entwickeln, die für diesen Job noch besser geeignet zu sein scheinen als alles andere, was verfügbar ist. Das Team betrachtet das Programmieren als eine Fähigkeit, die in gewisser Weise unabhängig von der verwendeten Sprache ist. Sie sind daher bereit, eine neue Sprache zu verwenden, wenn dies eine Aufgabe erleichtert. Die Mode steht jedoch nicht ganz oben auf ihrer Prioritätenliste, sodass sie keine Aufgabe fragmentieren, indem sie eine neue Sprache kostenlos einführen.

Die Funktion dieses Codes ist die mathematische Modellierung, die auf Workstations und Servern verwendet wird (ich kann etwas freier sprechen, wenn ich das Produkt nicht identifiziere). Derzeit sind es ungefähr 25 Millionen LoC, bei einer Teamgröße von ungefähr fünfzig.

In einigen Fällen müssen Sie ein Tool verwenden (z. B. das UI-Toolkit eines Betriebssystems), auf das in einer bestimmten Sprache am einfachsten zugegriffen werden kann. Wenn Sie beispielsweise unter iOS und MacOS GUI-Anwendungen mit UIKit und AppKit schreiben möchten, ist das Schreiben in Swift oder Objective-C der schnellste und einfachste Weg, dies zu tun. (Möglicherweise gibt es Bindungen für andere Sprachen, aber möglicherweise stecken sie hinter der neuesten Betriebssystemversion, mit der Sie arbeiten. Daher bieten sie möglicherweise nicht alle Funktionen.)

So oft passiert es, wenn eine Anwendung plattformübergreifend ist, die Kernlogik der App in einer Sprache geschrieben ist, auf die beide zugreifen können, und die UI / OS-spezifischen Teile sind in der Sprache geschrieben, in der sie nativ arbeiten.

Wenn Sie also eine Windows- und MacOS-Anwendung schreiben, können Sie die Kernlogik in C ++ schreiben und C # für die Benutzeroberfläche unter Windows und Swift für die Benutzeroberfläche unter MacOS verwenden. Dies spart Zeit, da Sie die Kernlogik nicht zweimal schreiben und mit unterschiedlichen Bugs in beiden Apps usw. umgehen müssen. Es ermöglicht jedoch auch eine echte native Benutzeroberfläche, die nicht den kleinsten gemeinsamen Nenner zwischen Plattformen wie der Verwendung berücksichtigt Eine plattformübergreifende UI-Bibliothek würde.

Neben der Tatsache, dass einige Programmiersprachen für bestimmte Aufgaben besser geeignet sind, gibt es die praktische Realität.

In der praktischen Realität sind zwei besonders wichtige Punkte zu beachten:

1. Menschen haben unterschiedliche Erfahrungen und unterschiedliche Interessen in verschiedenen Programmiersprachen. - Das Erlauben der Arbeit in Sprachen, die sie mögen und beherrschen, kann unter Umständen zu einem besseren Endergebnis führen als das Erzwingen einer gemeinsamen Sprache.
2. Große Codebasen werden über lange Zeiträume von verschiedenen Personen erstellt. - Es gibt keine Möglichkeit, die Finanzierung oder die Anzahl der Freiwilligen zu erhalten, die erforderlich sind, um ein gesamtes Projekt umzuschreiben, sobald eine Sprache herauskommt, die besser dafür geeignet ist.

Und natürlich gibt es oft bestimmte Teile einer Anwendung, die ganz andere Anforderungen haben, wie zum Beispiel:

• Leistungssensitive Bereiche, die in einer kompilierten Sprache entwickelt wurden. Beispielsprache: C ++
• Bereiche, die kostengünstig, einfach zu ändern und möglicherweise anpassbar sein müssen und in einer Skriptsprache entwickelt wurden. Beispielsprache: Lua.
• GUI-Layout. Beispielsprache: HTML
• Installateur. Beispielsprache / Tool: WiX.
• Bauen. Beispielsprache / -werkzeug: Zu viele zum Auflisten, normalerweise mehrere auf einmal.

Darüber hinaus gibt es eine ganze Reihe von Tools, die von einer ausgeklügelten Codebasis verwendet werden, von denen viele die erforderlichen Anpassungen und Plugins in einer weiteren Sprache ermöglichen.

Zusätzlich zu den korrekten anderen bereits gemachten Punkten:
Erfahrungsgemäß werden viele Sprach- oder Umgebungsentscheidungen durch "Wenn Sie einen Hammer haben, sieht alles wie ein Nagel aus" getroffen, was bedeutet, dass die Leute dazu neigen, die Werkzeuge zu verwenden, mit denen sie vertraut sind.

Darüber hinaus ist die Einführung einer neuen Umgebung oder sogar Sprache eine große Investition in Lizenzen, Schulungen, möglicherweise Hardware, und mit großen Produktivitätsverlusten verbunden - Beschaffung, Installation, Konfiguration, Schulung dauern jeweils Wochen in einem größeren Unternehmen, und Sie beenden im Grunde genommen mit ein paar Anfänger-Entwicklern.
Es gibt im Grunde nie die Zeit, in eine modernere oder passendere Umgebung oder Sprache zu "investieren", also bleiben sie bei dem, was sie haben, bis es einfach nicht mehr funktioniert.

Speziell für Ihre Frage: Wenn mehrere Personen / Teams an der Entwicklung einer Lösung beteiligt sind, tendiert jede Gruppe dazu, sich an das zu halten, was sie am besten kennt, sodass die Gesamtlösung möglicherweise mehrere Sprachen enthält und in mehreren Umgebungen entwickelt wird.

Diese Frage (und einige der Antworten) scheinen davon auszugehen, dass Anwendungen monolithische Codeblöcke sind - dies ist nicht unbedingt der Fall.

Bei einer typischen Website wie Stack Exchange handelt es sich eigentlich um eine Reihe verschiedener Dienste, die unabhängig voneinander ausgeführt werden und sich untereinander austauschen. Diese Dienste können (und werden typischerweise) in verschiedenen Sprachen implementiert, wobei jede ihre eigenen Stärken hat.

Ich arbeite an einem winzigen Teil einer Online-Banking-Plattform, der sich an kleinere Gemeindebanken und Kreditgenossenschaften richtet. Diese Plattform besteht aus mehreren Komponenten - einem Web-Front-End, einer Datenbankschicht, einer Kommunikationsschicht von Drittanbietern usw. Dies sind alles unabhängige Anwendungen, die auf unterschiedlichen Servern mit unterschiedlichen Betriebssystemen ausgeführt werden. Auf der Client-Seite des Browsers wird Javascript ausgeführt, auf der Server-Seite werden Perl-Seiten erstellt, und in C ++ sind mehrere Dienste geschrieben, die als Abstraktionsschicht zwischen dem Perl-Code und dem Kernprozessor der Bank fungieren. Dies sind weitere C ++ - Anwendungen Weiterleiten von Nachrichten zwischen den verschiedenen Ebenen, eine kleine Auswahl an C ++ - Anwendungen und Perl-Skripten, um den Zustand verschiedener Prozesse zu überwachen und ihren Status an einen internen Monitor usw. usw. usw. zu melden.

Es gibt immer noch monolithische Anwendungen, aber selbst sie können aus verschiedenen Gründen unterschiedliche Sprachen nutzen. Sie können 90% einer Anwendung in Java schreiben, aber JNI verwenden, um C oder C ++ für leistungskritischere Abschnitte zu nutzen.

Ich möchte auf ein sehr spezifisches Beispiel des Motivs "Verschiedene Sprachen haben unterschiedliche Stärken" hinweisen: FORTRAN.

Fortran wurde ursprünglich entwickelt, um Ingenieuren die Arbeit mit numerischen Analysen zu erleichtern, und seitdem wurden große Anstrengungen unternommen, um Fortran-Compiler zur Ausgabe von sehr effizientem numerischem Code zu bewegen. Auf der anderen Seite ist der Einsatz von Computern seit jenen frühen Tagen in tausend Richtungen explodiert, von denen keine eine numerische Analyse beinhaltet, und die Entwicklung von Programmiersprachen ist weitgehend gefolgt, um die "reale" Welt zu ignorieren.

SO: Es ist heute und Sie arbeiten für ein Unternehmen mit einem ziemlich weitläufigen Produkt, das größtenteils in Java geschrieben ist (ich spreche hier aus persönlicher Erfahrung) . Sie werden jedoch feststellen, dass eine der Kernfunktionen des Produkts eine Form der numerischen Analyse erfordern wird, und alle besten Codes für diese bestimmte Analyse sind bereits im Internet verfügbar - in Fortran. Also, was machst du? Sie laden einen dieser Fortran-Codes herunter, ermitteln die Schnittstelle [dh die Argumente der obersten Unterroutine], erstellen einen JNI-Wrapper für ihn in C und packen ihn als Java-Klasse. BAM! Sie mussten sich nur in drei Sprachen gleichzeitig entwickeln. [insbesondere, wenn Sie feststellen, dass Ihr Fortran-Code COMMON-Blöcke (dh statischen Speicher) verwendet und aus Gründen der Threadsicherheit geändert werden muss]

Weil das Programmieren keine einzige Aufgabe ist. Auch die Erstellung eines Produkts ist keine Aufgabe. Es gibt mehrere Aufgabentypen, die sich am besten in verschiedenen Sprachen ausdrücken lassen.

Nehmen wir zur Konkretisierung etwas Einfaches wie eine eigenständige App an (für verteilte Apps sind weitere Aufgaben zu erledigen).

Ein Produkt muss sein

• geschrieben
• Zusammenstellen (dies umfasst sowohl das Zusammenstellen als auch das Sammeln von Ressourcen wie Bildern, Schriftarten usw. für die Bereitstellung)
• eingesetzt
• konfiguriert
• überwacht

Es ist sehr unwahrscheinlich, dass eine Sprache, die für das Schreiben der Laufzeit eines Produkts gut ist, für das Zusammenstellen eines Produkts genauso gut ist. Und so weiter.

Allerdings kann es sein, dass selbst der Prozess des Produktschreibens nicht optimal in einer Sprache ausgeführt wird.

Angenommen, das Produkt enthält viele strukturierte Daten. Ist die Struktur der Daten zum Zeitpunkt des Schreibens bekannt? Wenn dies der Fall ist, möchten Sie einige Datenbanken zum Zeitpunkt der Bereitstellung konfigurieren. Dies erfolgt optimalerweise in einer Sprache, die die Sprache generieren kann, die in Ihre Laufzeit kompiliert wird.

Was nun, wenn sich die Datenstruktur von Zeit zu Zeit ändern kann? Dann brauchen Sie eine strukturierte Möglichkeit, neue Datenkonstrukte in Code- und Datenbankkonfigurationen umzuwandeln. Dies geschieht am besten in einer weiteren Sprache.

Schaffst du das alles in der gleichen Sprache? Sicher. Ihre Effektivität hängt jedoch davon ab, wie schnell Sie ein Projekt fertigstellen können und wie widerstandsfähig Sie gegenüber Änderungen sind. Wenn ein Großteil Ihrer Arbeit mit bereits vorhandenen Tools automatisiert werden kann, kann eine andere Person innerhalb von zwei Tagen die Arbeit in 3 Monaten erledigen. Aber dieser Jemand würde andere Sprachen verwenden, um zu automatisieren, was Sie durch Wiederholung tun würden.

Software - Entwicklung ist so weit fortgeschritten , wo Sie können verschiedene Programmiersprachen im selben Projekt verwenden, und Sie können es funktioniert.

Dann stellt sich die Frage, warum Sie mehr als eine Sprache verwenden würden.

Ein Grund dafür ist, dass Sprachen veraltet sind und langsam durch neuere ersetzt werden. Wenn Sie Glück haben, können Sie dies Stück für Stück tun. Ihr Projekt wird also eine Mischung aus alter und neuer Sprache haben.

Ein weiterer Grund ist die Situation, in der Sprache X sehr häufig auf Plattform A verwendet wird, Sprache Y sehr häufig auf Plattform B verwendet wird, Sprache Z jedoch auf beiden Plattformen unterstützt wird. So wird allgemeiner Code in der Sprache Z geschrieben, die dann je nach Plattform mit X oder Y kombiniert wird.

Und die Leute benutzen gerne Code, den andere geschrieben haben (mit anderen Worten, Code, für den sie keine Zeit aufwenden mussten, um ihn selbst zu schreiben). Sie können von anderen geschriebenen Code in einer beliebigen Sprache verwenden und dann Code in der von ihnen bevorzugten Sprache hinzufügen.