Von Zeit zu Zeit wird die Idee, das man deutlich mehr als eine Programmiersprache beherrschen sollte unter der Bezeichnung "Polyglotte Programmierung" – also "vielsprachige Programmierung" – als progressive Erkenntnis oder auch als Wettbewerbsvorteil proklamiert. Mich verblüfft das immer wieder – ebenso wie die ablehnenden Reaktionen einiger Entwickler zu dieser Idee.
Schließlich leben wir schon lange in einer Welt, in der es für Entwickler unverzichtbar und meines Erachtens auch Alltag ist, mehr als eine Sprache zu benutzen.
In den meisten Fällen, die über triviale "Hallo, Welt!" Beispiele hinaus gehen, kommen heute fast immer mehre Sprachen (seien es Programmier- oder Beschreibungssprachen) zum Einsatz. Gucken wir uns nur mal einige wenige Beispiele an:
.Net, Desktop-Anwendung
- C# (oder VB.Net oder eine andere Sprache der Wahl) für die Logik
- SQL für die verwalteten Daten
PHP, Web-Anwendung
- PHP - für die Implementierung der Logik,
- HTML - für die logische Gestaltung der Benutzungsschnittstelle
- CSS - für die optische Gestaltung der Benutzungsschnittstelle
- SQL - für die verwalteten Daten
- Wahlweise: Shell-Syntax - mindestens zum starten und stoppen des Servers, kopieren von Dateien etc. (kann ggf. auch mit einem grafischen Interface gemacht werden)
- Wenn es etwas mehr sein darf
- Java-Script - für Interaktionen im Oberflächenlayer
- die jeweilige Sprache (oft XML-basiert) für die Konfiguration des Build-Servers
- Config-Sprache des Servers (e.g. apache-conf)
Ruby, Web-Anwendung, Stack von ~2012
- Ruby - für die Logik
- haml - für die logische Gestaltung der Oberfläche
- Sass - für die optische Gestaltung der Oberfläche
- Coffeescript - für die 'clientseitige' Logik
- yaml - für diverse Einstellungen, nicht zuletzt die Unterscheidung zwischen Test- und Realbetrieb
- RSpec / Cucumber - für die lokalen Tests
- Capybara DSL - für remote Tests
- SQL - für die verwalteten Daten
Java, Web-Anwendung, Minimalistisch
- Java - für die Logik
- HTML - für die logische Gestaltung der Benutzungsschnittstelle
- CSS - für die optische Gestaltung der Benutzungsschnittstelle
- JSP-taglibs - für die dynamischen Teile der Oberfläche
- SQL - für die verwalteten Daten
- XML - für die Buildskripte
- Property-File Syntax -
- Wenn es etwas mehr sein darf
- Java-Script für Interaktionen im Oberflächenlayer
- die jeweilige Sprache (oft XML-basiert) für die Konfiguration des Build-Servers
- Config-Sprache des Servers (e.g. apache-conf)
Und ähnlich sieht es bei allen weiteren mir bekannten Umgebungen aus, wenn wir von professioneller Softwareentwicklung (Nein, Excel-Markos zähle ich nur selten dazu, manchmal aber schon) sprechen.
Also sollte die Frage heute weniger denn je lauten "Was ist denn unsere Standardsprache" sondern viel mehr "Welche Sprache passt am besten zum Problem".
Bis demnächst
Michael Mahlberg
1 Kommentar:
We can't wait to see what best electric pencil sharpener enhancements the approaching years convey. The Toybox 3D Printer is designed for use by children and younger people—Toybox Labs suggests a minimum age of 5, and that there be an adult round when the printer is in use. The Toybox should be enjoyable for people of any age—printing with it is a good exercise to convey mother and father and kids together. The Toybox 3D Printer works properly as a model designed for children, providing dependable printing from a browser or cell system and some thousand toys to print, plus inventive choices to output drawings or photographs. The MakerBot Replicator+ 3D printer is a marked improve over its predecessor, providing higher velocity, a larger build space, and workflow solutions for professionals.
Kommentar veröffentlichen