... IT-Consulting, Aikido, Strategie und alles was mir sonst noch einfällt und nicht in mein englisches Blog passt...

Mittwoch, 18. September 2013

Polyglotte Programmierung ist Alltag

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

Keine Kommentare: