Neue Programmiersprachen: 11 Wege, Ihre Softwareentwicklung neu zu definieren

Die meisten Entwickler verrichten ihre tägliche Programmierarbeit in einer - oder mehreren - traditionellen und etablierten Sprachen. Dennoch steigt der Anteil derer, die nach neuen Werkzeugen lechzen, um Programmierprobleme zu lösen. Diese Tendenz manifestiert sich im Aufstieg domänenspezifischer Programmiersprachen (Domain Specific Languages = DSLs), die sich vor allem dadurch auszeichnen, dass sie kompakt, fokussiert - und nicht für allgemeine Zwecke gedacht sind. Dennoch könnten diese Programmiersprachen auf Dauer einen besonderen Platz in ihrem Entwicklungs-Werkzeugkasten einnehmen.

11 Programmiersprachen, die Sie kennen sollten

Wir haben ein knappes Dutzend neue(rer) Programmiersprachen für Sie zusammengestellt, die ihre Nische gefunden haben.

Reactive Clojure

Wenn Sie Clojure mit React verbinden, erhalten Sie ein System, das alle Möglichkeiten reaktiver Frontends mit der soliden, funktionalen Stärke von Clojure verbindet. Reactive Clojure ermöglicht, eine komplexe Sammlung von Frontend-Komponenten anzulegen und sie mit Funktionen zu verknüpfen. Das Reactive-Framework kümmert sich um die Details und stellt sicher, dass die Anwendungsdaten reibungslos zwischen Ihren Komponenten und der Datenbank fließen. Clojure bringt die funktionale Grundlage mit, um auch ungewöhnliche Use Cases zu realisieren.

Reactive Clojure ist eine gute Option, um Code zu schreiben, der die Frontend-Komponenten zusammenhält. Sein Multithreading-Modell eignet sich perfekt für komplexe und reaktive Dashboards, die mehrere Tasks parallel reporten.

Nickel

Ein Großteil der Programmierarbeit spielt sich heute in Konfigurationsdateien ab. Diese Dateien, die oft in JSON, YAML oder sogar XML kodiert sind, haben sich von einer guten Idee zu einem komplexen Ritual entwickelt. In einigen Fällen geht das soweit, dass die Entwickler gar nicht mehr programmieren, sondern sich endlosen Konfigurationsdatei-Marathons hingeben, um ihr Ziel zu erreichen.

Eine Programmiersprache, um Konfigurationsdateien zu erstellen, hat also in jedem Fall eine Daseinsberechtigung. Nickel ist eine Art Template mit eingebetteter Logik, mit der sich nicht-statische Konfigurationsdateien anlegen lassen. Ein Parameter könnte beispielsweise unter der Woche einen anderen Wert aufweisen als am Wochenende. Kommt Nickel zum Einsatz, erstellt es eine neue Konfigurationsdatei, die zu allen empfangenen Parametern passt.

Die Struktur der Programmiersprache ist größtenteils funktional - Type Checking steht jedoch bei Bedarf zur Verfügung. Dabei ist "Korrektheit" ein großes Thema, denn gut geschriebener Nickel-Code garantiert, dass der Output sowohl den Syntax- als auch allen anderen Regeln, die Sie durchsetzen müssen, entspricht. Der Compiler von Nickel ermöglicht die Erstellung von Verträgen und überprüft im Anschluss, ob diese regelkonform funktionieren. Nickel ist eine sehr praktische Lösung für moderne IT-Architekturen.

Kobra

Die Schöpfer von Kobra wollten eine Sprache erschaffen, die Ingenieuren, Wissenschaftlern und anderen nicht-professionellen Programmierern Zugang zu Machine Learning ermöglicht. Das Ergebnis ist eine visuelle Sprache für maschinelles Lernen.

Der Kobra-Editor setzt codeähnliche Sequenzen mit Drag-and-Drop-Kacheln zusammen, die gängige integrierte Routinen für statistische Analysen und Machine Learning darstellen. Der Prozess fühlt sich ein wenig an wie R mit Data Frames, die aus tabellarischen Daten konstruiert werden, gepaart mit einer Kollektion grafischer Display-Funktionen, um beispielsweise Dashboards zu erstellen.

Bicep

Eine der nützlichsten Cloud-Funktionen ist die Möglichkeit, Server nach Bedarf zu nutzen, um Lastspitzen abzufedern.

Viele Devops-Teams schreiben inzwischen Code für die diversen APIs, die von den unterschiedlichen Clouds unterstützt werden. Microsoft hat hingegen beschlossen, noch einen Schritt weiterzugehen und im Rahmen seiner Infrastructure-as-Code-Philosophie eine vereinfachte Programmiersprache entwickelt, um Server in Azure zu starten: Bicep.

Bicep selbst ist für Infrastrukturüberlegungen auf höherer Ebene konzipiert und weist eine stark deklarative Struktur auf, die es ermöglicht, Anweisungen in beliebiger Reihenfolge zu integrieren und anschließend vom Azure Resource Manager optimieren zu lassen. Eine Type-Safety-Funktion unterstützt dabei, Fehler zu vermeiden.

Frink

Es soll Menschen geben, die bei der Wahl ihrer Bank darauf achten, dass die eingesetzte Buchhaltungssoftware ganze Zahlen statt Fließkommazahlen verwendet. Schließlich ist die Fehlerquote bei letzteren bekanntermaßen groß.

Bei Frink handelt es sich um eine "einheitenbewusste" Programmiersprache, die für dieses spezifische Problem entwickelt wurde. Jede Variable in Frink enthält nicht nur eine Zahl, sondern auch eine Angabe über die Maßeinheit. Die Umrechnung der Einheiten ist dank der Frink-Konfigurationsdatei einfach. Der Kernmechanismus verwendet auch Zahlen mit beliebiger Genauigkeit, um Probleme mit Auf- und Abrundungen zu vermeiden - quasi Type Checking für numerische Maßeinheiten.

Faust

Klangsynthese mag erst einmal wie ein relativ spitzer Anwendungsfall erscheinen - ist aber in vielen Fällen äußerst nützlich, etwa wenn es um Game Development, Virtual Reality oder jede andere Art von Applikation geht, bei der gute Soundqualität eine tragende Rolle spielt.

An dieser Stelle kommt die DSL Faust ins Spiel, deren Nomenklatur dem Begriff "functional audio stream" entspringt. Die Struktur von Faust ist rein funktional, alle Funktionen bilden eine Sound-Processing-Pipeline. Das Backend stellt eingehende Töne numerisch dar - der Code selbst ist ein Funktionsset das zu einem Endergebnis zusammengestellt oder kombiniert werden kann. So lassen sich beispielsweise Echo- oder Halleffekte erzeugen, indem der Code Output aufgesplittet und um eine Verzögerung ergänzt wird. Faust-Programmcode lässt sich in C++, C, LLVM-Bitcode, WebAssembly, Rust und einige andere Sprachen übertragen. Er ist also nahezu universell anwendbar.

Melrose und Glicol

Wenn ein Programmierer eine Musik-Band gründen wollte, würde er wahrscheinlich keinen Schlagzeuger per Annonce suchen. Er würde vielmehr einen Code schreiben, um die Rhythmen für eine Drum-Maschine vorzugeben. Wenn er das erledigt hätte, würde er auch die anderen Bandmitglieder durch Subroutinen ersetzen. Auf diese Weise könnte er sogar ein ganzes Sinfonieorchester aufbauen.

Melrose und Glicol sind zwei Programmiersprachen, die für diese Art der Musikproduktion entwickelt wurden. Beide ermöglichen, mit nur wenigen Tastenanschlägen umfangreiche Kompositionen zu erstellen. Melrose arbeitet dabei auf einer höheren Ebene mit der in der westlichen Musik üblichen Zwölfton-Oktave. Die Noten werden in Sequenzen gruppiert und die Software übernimmt einen Großteil der Routinearbeiten, etwa die Transposition. Der Output kann an jedes MIDI-fähige Instrument übertragen werden. Dabei ist der Programmcode auch in der Lage, auf eingehende Signale über den MIDI-Port zu reagieren.

Bei Glicol handelt es sich um ein Tool auf Rust-Basis, das viele Tasks erfüllt, die auch Melrose beherrscht - allerdings auf einem niedrigeren Niveau. Glicol-Code ist in die digitale Signalverarbeitung integriert und bietet eine breite Palette musikalischer Optionen. Das Tool arbeitet mit einer Open-Source-Audio-Engine.

WebAssembly und Wase

Die effizienteste Art, Anweisungen an einen Computer zu übermitteln, besteht darin, sie in Binärform zu kodieren und auf die grundlegenden CPU-Operationen zu beschränken. Jeder Chip hat seine eigene bevorzugte Binärsyntax und einige Sprachen wie Pascal oder Java weisen ein neutrales Binärformat auf, das für lokale, virtuelle Maschinen gedacht ist. WebAssembly tritt in diese Fußstapfen und bietet Webbrowsern vorverarbeiteten Binärcode kombiniert mit Text in einem Standardformat. Das Ziel: Den verkleinerten JavaScript-Code, der das Rückgrat von Webanwendungen bildet, durch etwas zu ersetzen, das noch lauffähiger ist und nahezu native Geschwindigkeit realisiert.

Dabei verwenden viele Entwickler WebAssembly, ohne es direkt zu programmieren. Sie nutzen Compiler, die höhere Sprachen in WebAssembly konvertieren, das in Browsern ausgeführt werden kann. Es gibt auch Bestrebungen, Low-Level-Sprachen zu entwickeln, die einen Großteil der Grundstruktur von WebAssembly in einer für Menschen lesbaren Form darstellen. Eine solche Option ist beispielsweise Wase, das eine C-ähnliche Syntax mit starker Typisierung bietet.

WebAssembly findet auch außerhalb von Webbrowsern Verwendung - und zwar als allgemeine Methode zur Kodierung von Anweisungen mit einer Stack-Maschine, ähnlich der JVM von Java. Redpanda ist beispielsweise eine Plattform für Streaming-Daten, die Entwicklern die Möglichkeit bietet, die Daten während der Übertragung mit in WebAssembly geschriebenem Code zu optimieren oder zu ändern.

Java 17

Technisch gesehen ist Java keine neue Programmiersprache. Einer der größten Vorteile von Java ist seine Rückwärtskompatibilität zu älteren Versionen. Das macht es in der Regel ziemlich einfach, zehn oder sogar 20 Jahre alten Code für die neuesten JVMs zu kompilieren.

Java 17 ist in dieser Auflistung enthalten, weil die Sprache inzwischen so stark modernisiert wurde, dass sie für einen Zeitreisenden aus den 1990er Jahren kaum wiederzuerkennen wäre. Einige der vielen zusätzlichen Funktionen und Erweiterungen, wie der verbesserte Zufallszahlengenerator oder die strengere Semantik für die Fließkommamathematik, fokussieren auf die Herausforderungen, die bei der Arbeit mit komplexem, numerischem Code entstehen. Andere, wie die starke Kapselung und die erweiterte Switch-Semantik, bringen eine Mischung aus Disziplin und Flexibilität in die Kernsprache. Alles in allem ist es dank all dieser Verbesserungen einfacher denn je, sicheren und zuverlässigen Code zu schreiben. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.

Softwareentwicklung: Neue Wege in der Qualitätssicherung

Für Entwickler, die mit Cloud-nativen Technologien arbeiten, sind Softwaretests und Qualitätssicherung wichtige Aspekte der Produktentwicklung. Die meisten Teams haben derartige Tests an den Anfang des Entwicklungsprozesses – nach links – verlagert, wovon sich die Bezeichnung Shift Left Testing ableitet. So wird die Qualität des Codes geprüft, während dieser sich noch durch die CI/CD-Pipeline bewegt.

Continuous Integration/Continuous Delivery (CI/CD) umfasst mehrere zusammenhängende Praktiken, von der Integrations- und Test- bis hin zur Bereitstellungs- und Implementierungsphase, und dient der Verbesserung der Softwarebereitstellung. Die einzelnen Phasen der Anwendungsentwicklung werden automatisiert und stetig überwacht, wodurch ihr größter Mehrwert entsteht. Der Trend zu dieser Art der Qualitätssicherung zeigt, dass DevOps und andere moderne Entwicklungspraktiken immer beliebter werden. Diese Arbeitsweise ermöglicht es Entwicklern selbstständiger zu arbeiten und mehr Verantwortung für ihre Anwendung zu übernehmen.

Erst in jüngster Zeit haben Entwickler End-to-End-API- und Browsertests in ihre CI/CD-Praktiken aufgenommen und so den Umfang ihrer qualitätssichernden Maßnahmen erweitert. Sie prüfen nun bereits in frühen Phasen ihrer Arbeit, wie Code sich in verschiedenen Browsern verhält und wie er mit wichtigen Datenquellen interagiert. Daraus entstehen neue Schnittstellen mit anderen Testverfahren, die ihrerseits früher als bisher üblich angewandt werden, wie Unit- oder Security-Tests. Die frühe Durchführung von Tests stellt sicher, dass potenzielle Fehler schnellstmöglich erkannt werden, wodurch Unternehmen bares Geld sparen und Entwicklern mehr Zeit für die Fertigstellung innovativer Produkte bleibt.

Cloud-Tempo fordert neue Testmethoden ein Traditionell läuft Softwareentwicklung nach dem sogenannten Wasserfallmodell ab, bei dem Tests erst kurz vor der Veröffentlichung, am rechten Ende der Handlungskette, durchgeführt werden. Das ergibt auf den ersten Blick durchaus Sinn, da so alle Fehler beseitigt werden, um anschließend eine perfekte Version der Software zu veröffentlichen. Diese Methode bringt allerdings auch Probleme mit sich. Fehler, die nicht rechtzeitig erkannt werden, können Folgefehler nach sich ziehen, deren Entfernung noch kniffliger und aufwendiger ist. Außerdem ist es problematisch, wenn Kunden erst bei späteren Tests eingebunden werden. Sollten dabei noch Fehler erkannt werden, kostet deren Behebung wertvolle Zeit. Selbst Fehlerberichten und Verbesserungsvorschlägen von Testern können Entwickler sich oft nicht widmen, weil ihnen die Zeit fehlt. Diese Probleme können dank Shift Left Testing behoben werden. Die Migration in die Cloud und der Einführung agiler, an DevOps-Praktiken orientierte Entwicklungsmethoden ermöglichen ein deutliches schnelleres Entwicklungstempo, welches durch manuelles, traditionelles Testen behindert wird. Daher wird das Testen in frühere Phasen des Entwicklungsprozesses verlagert und nicht mehr von speziellen Testteams durchgeführt, sondern direkt von einzelnen Personen aus allen Entwicklungsteams. So ermöglichen Entwickler eine schnelle Freigabe des Codes und gewährleisten gleichzeitig ein hohes Qualitätsniveau bei jedem Release.

Je früher, desto besser Die eingesetzten CI/CD-Praktiken und die frühen Tests sorgen dafür, dass ein Code jederzeit einsatzbereit ist. Entwickler erkennen zunehmend den Wert von End-to-End-Tests während ihrer CI-Builds. API-Tests ermöglichen es Teams, End-to-End-Workflows zu verifizieren, indem sie HTTP-Anfragen und API-Aufrufe verketten, so dass sie alle Ebenen ihrer Systeme von jedem Standort aus validieren können. Browsertests können die Sicht des Benutzers während kritischer Phasen der Anwendungslogik erfassen, wodurch sich zeigt, welchen Einfluss UI-Änderungen auf Webanwendungen haben können. Viele Probleme können nun von Entwicklern direkt erkannt werden, ohne dass weitere Experten hinzugezogen werden müssen. So werden Korrekturschleifen eingespart und es bleibt viel mehr Zeit, um auf die wichtigen Details zu achten. „Teams aus verschiedenen Bereichen sind dafür verantwortlich den Code zu testen, ihn fortwährend zu überwachen und die gesammelten Daten in die Analyse mit einzubeziehen.“ Stefan Marx, Datadog Die bereits genannten Tests werden umso wertvoller, wenn Teams die Möglichkeit haben, die gewonnenen Ergebnisse mit Daten aus ihrem gesamten Stack in Beziehung zu setzen. Mit einfachem Zugriff auf korrelierte Metriken, Traces und Logs verfügen sie über den nötigen Kontext, um fehlgeschlagene Tests zu erkennen und Fehler zu beheben, die während der Entwicklungsphase nicht erkannt wurden. So kann fehlerhafter Code gestoppt werden, noch bevor dieser in Produktion geht. Qualitätssicherung wird somit zu einem ganzheitlichen Prozess, der jeden Teil des Entwicklungszyklus und Daten aus jedem Teil des Stacks einbezieht.

Qualitätssicherung ist Gruppenarbeit Die Neuerungen in der Qualitätssicherung betreffen nicht nur das Vorziehen von Testvorgängen, sondern auch eine grundlegende Veränderung in der Art und Weise, wie Entwicklerteams innerhalb eines Unternehmens zusammenarbeiten. Teams aus verschiedenen Bereichen sind dafür verantwortlich den Code zu testen, ihn fortwährend zu überwachen und die gesammelten Daten in die Analyse mit einzubeziehen. So kann beispielsweise ein Frontend-Entwickler ein Problem bei der Integration seiner letzten Änderungen anhand der Strukturierung der Backend-APIs erkennen und anschließend gemeinsam mit dem Backend-Team die beste Lösung erarbeiten. Idealerweise führen diese Änderungen so zu einem Auflösen von Silos und einer offeneren und direkten Kommunikation zwischen den einzelnen Teams.

Continuous Integration: Neue Wege in der Softwareentwicklung

In der Software-Entwicklung zeichnet sich ein Wandel ab: Das so genannte Wasserfallprinzip, bei dem Programmierer monatelang auf den Launch einer neuen Version mit großem Funktionsumfang hinarbeiten, hat allmählich ausgedient. Immer mehr Software-Anbieter setzen stattdessen auf „Continuous Integration“ (CI).

Kontinuierlicher Erweiterungs- und Verbesserungsprozess

Bei dieser Entwicklungsmethode geht es darum, Software kontinuierlich zu erweitern und zu verbessern. Die neuen Releases sind schmaler, der Umfang an Features geringer. Man spricht daher auch von einem „Soft Launch“. Dafür stehen den Kunden neue Funktionen aber auch wesentlich früher zur Verfügung. Nicht selten werden diese im Zwei-Wochen-Rhythmus veröffentlicht – Stichwort „Continuous Delivery“ (CD). Dadurch lassen sich geschäftliche Anforderungen der Kunden schneller umsetzen.

Schnellere Bereitstellung neuer Funktionen

Der Kunde profitiert aber nicht nur von der schnelleren Bereitstellung neuer Features und Funktionen, sondern auch von einer Steigerung der Software-Qualität. Bei der Wasserfall-Methode programmieren die Entwickler monatelang, bis ihre Komponenten zur Gesamtlösung, dem so genannten Build, zusammengebaut und danach getestet werden. Entsprechend viele Fehler müssen anschließend aufwändig behoben werden.

Automatisierte Testprozesse

Bei CI dagegen erfolgen Entwicklung und Testprozess in kleinen Einheiten, die am Ende eines Arbeitstages in Repositories zur Versionskontrolle eingecheckt werden. Über Nacht bauen Server die Code-Komponenten dann automatisiert zusammen („Nightly Build“) und testen sie auch gleich. Der gesamte Prozess – programmieren, zusammenfügen, testen – findet also täglich statt. Fehler können auf diese Weise sofort korrigiert werden. Dadurch lässt sich die Nutzerfreundlichkeit kontinuierlich verbessern – ein enormer Gewinn für die Customer Experience.

Agile Methoden und DevOps unterstützen den Trend

Die agile Vorgehensweise von CI und CD steht im engen Zusammenhang mit dem Prozessverbesserungsansatz DevOps. Hier geht es darum, alle an der Systemadministration und Software-Entwicklung beteiligten Abteilungen zu vernetzen, Prozesse zu optimieren und die Entwicklungszyklen zu verkürzen. Auch dies sind wichtige Hebel, um die Customer Experience zu verbessern und die Kundenbindung zu erhöhen.

Softwareentwicklung in kleinen Schritten

Den Analysten von IDC zufolge wird DevOps in den IT-Abteilungen deutscher Unternehmen zunehmend zum wichtigen methodischen Framework für die Entwicklung und den Betrieb von Applikationen – insbesondere bei Cloud-basierten Anwendungen. Bereits vor einem Jahr gaben in einer IDC-Umfrage 77 Prozent der Unternehmen an, DevOps-Prozesse zu nutzen. Begünstigt wird CI zudem durch den anhaltenden Trend zur agilen Softwareentwicklung. Denn bei agilen Methoden wie Scrum erfolgt die Planung und Entwicklung ebenfalls in kleinen Einheiten, so genannten Sprints, die täglich im Team evaluiert werden.

Mehr Flexibilität, regelmäßiger Austausch

Nicht nur für die Kunden, auch für die Entwicklungs- und Projekt-Management-Teams bietet CI in Verbindung mit agilen Development-Prozessen klare Vorteile. Durch das Denken und Planen in kleinen Entwicklungseinheiten sind sie in der Lage, wesentlich flexibler zu agieren als im Rahmen eines großen Software-Projekts. So können die Programmierer schneller und häufiger Änderungen am Programm-Code vornehmen. Zudem sorgen die häufigen Abstimmungen dafür, dass alle Beteiligten immer auf dem aktuellen Stand sind und regelmäßig Feedback auf ihre Arbeit erhalten, was wiederum zu einem steigenden Qualitätsbewusstsein führt.

Hoher Kollaborations- und Kommunikationsbedarf

Allerdings bringt diese Arbeitsweise auch einen enormen Kollaborations- und Kommunikationsbedarf mit sich. Agile Software-Entwicklung und CI funktionieren nur bei einem permanenten Austausch aller Beteiligten. Die Teams treffen sich während eines Sprints täglich und stimmen sich in so genannten Daily Stand-Ups ab. Darüber hinaus gibt es alle zwei Wochen ein Review, in dem festgehalten wird, was bis dato erreicht wurde und was verbessert werden kann. Für eine solche Arbeitsweise muss allerdings im Vorfeld erst eine entsprechende Kommunikationskultur geschaffen werden.

Soft-Skills werden immer wichtiger

Auch Soft Skills gewinnen vor diesem Hintergrund an Bedeutung. Das belegt die Studie „Upskilling 2020“ des DevOps Institute, für die 1260 Führungskräfte aus IT-Unternehmen in verschiedenen Ländern befragt wurden. Demnach sind für die Arbeit nach dem DevOps-Ansatz Team-Player-Eigenschaften, Einfühlungsvermögen und Kreativität zunehmend gefragt. Hinzu kommen hohe Qualitätsansprüche. Denn: Nach zwei Wochen wird die Arbeit der Einzelnen von der gesamten Mannschaft begutachtet. Das sorgt zwar für eine steigende Software-Qualität, erhöht aber auch den individuellen Druck.

Hilfreiche Tools für CI-Entwicklung und agiles Projekt-Management

Unterstützung für die Entwicklung nach der CI-Methode bieten zahlreiche Tools, mit denen sich die programmierten Komponenten zusammensetzen und verlinken beziehungsweise unterschiedliche Versionen verwalten lassen. Dazu zählen auf Compiler-Ebene zum Beispiel der Microsoft Team Foundation Server sowie das Java-basierte Open-Source-Programm Jenkins. Und im Projekt-Management helfen dedizierte Werkzeuge wie Jira oder Confluence, einen Sprint von zwei Wochen zu organisieren, neue Aufgaben aus dem Backlog zu ziehen und Zeitpläne aufzustellen.

CI hilft, Komplexität zu reduzieren

Software-Projekte sind hochkomplexe Vorhaben, in die viele Mitarbeiter involviert sind und die hohen Anforderungen gerecht werden müssen – vor allem an die Qualität und Einhaltung von Lieferterminen. Continuous Integration hilft, diesen Anforderungen durch eine hohe Flexibilität und die Reduzierung von Komplexität gerecht zu werden.