Warum wir immer neue Programmiersprachen brauchen werden

Struktur und Interpretation von Computerprogrammen von Harold Abelson und Gerald Jay Sussman ist eines der besten Bücher über Programmierung, die jemals geschrieben wurden. Es war seiner Zeit viele Jahre voraus.

Die Vorteile der funktionalen Programmierung, die dort hervorgehoben wurden, sind immer noch eine ständige Inspirationsquelle für Redner, Lehrer und andere Autoren. Es zeigte die Kraft und die Mängel der objektorientierten Programmierung, als es noch jung war. Dank objektorientierter Programmierfanatiker werden die Kräfte schnell beworben. Andererseits dauerte es Jahre, bis die Gemeinde die Mängel erkannte.

Das letzte Kapitel war ganz einem anderen Konzept gewidmet, das im populären Dialog noch nicht viel diskutiert wird: der Notwendigkeit neuer Programmiersprachen. Obwohl das Buch mit Lisp sympathisierte, behauptete es eindeutig, dass es nicht die endgültige Programmiersprache ist. Keine Sprache wird jemals sein.

Wir werden immer neue Programmiersprachen brauchen, um unsere Ausdruckskraft zu verbessern. Dies ist keine triviale Aussage, und um zu verstehen, was dahinter steckt, müssen wir zwei Ebenen tiefer gehen.

Was ist eine Programmiersprache?

Siehe folgende Funktion:

fun square(a: Int) = a * a
// Usageprint(square(10) + square(20))

Was bedeutet das squaredefiniert?

Aus technischer Sicht ist es nur eine Vereinfachung und der Körper kann alle Anrufe ersetzen:

// Kotlinprint(10 * 10 + 20 * 20)

Aus Sicht des Programmierers squareist viel mehr. Die Tatsache, dass wir eine solche Funktion definieren können, ist nicht nur eine einfachere Möglichkeit, eine Operation durchzuführen, sondern ermöglicht es uns auch, ein Konzept der Quadratur auszudrücken. Diese Funktion ist eine Abstraktion.

Wenn es komplexer wäre, könnten wir all diese Komplexität hinter einem einfachen Funktionsaufruf verbergen. Das ist Programmieren: Verschiedene Programmiersprachenfunktionen ermöglichen es uns, Dinge auf unterschiedliche Weise auszudrücken.

Entwicklung der Programmiersprachen

Die Programmierbranche entwickelt sich weiter, ebenso wie Programmiersprachen. Denken Sie an die for-Schleife. Anfangs gab es nur eine When-Schleife.

Bald bemerkten Programmierer ein gemeinsames Muster:

// Cint i = 0;while(i < n) { i++; // ...} 

Der whileAusdruck wurde immer wieder verwendet, um über etwas zu iterieren - hauptsächlich über Zahlen, Adressen oder Iteratoren.

Also haben wir for-Schleifen eingeführt:

// C++for (int i = 0; i < n; i++) { // ...}

Bald stellte die Industrie fest, dass die for-Schleife hauptsächlich zum Iterieren von Elementen aus einer Liste verwendet wird.

Aus diesem Grund haben die Sprachen eine neue Variante der for-Schleife eingeführt, die wiederholt werden soll list:

// Kotlinfor(e in list) { // ...}

Wir brauchen also neue Funktionen

Aber Sprachen entwickeln sich, warum nicht bei ihnen bleiben?

Es ist wahr, dass sich Sprachen entwickeln. In einigen Fällen ist es wirklich beeindruckend, wie alte Sprachen wie C ++, Java oder JavaScript funktionale Programmierelemente, für die sie nicht entwickelt wurden, gut unterstützen können. Das Problem ist jedoch, dass neue Funktionen alte nicht ersetzen, sondern hinzugefügt werden.

In Bezug auf Programmiersprachenfunktionen ist mehr nicht unbedingt besser. Es ist verwirrend, wenn wir dasselbe Konzept auf viele verschiedene Arten ausdrücken können.

Denken Sie an Scala. Der größte Einwand bei Scala ist, dass zu viele verschiedene Funktionen es extrem schwierig machen zu verstehen, was im Code eines Entwicklers mit etwas zu viel Kreativität vor sich geht.

Die Programmiersprache Go hat ihre Popularität auf Einfachheit aufgebaut. Es geht nicht darum, wie viele Funktionen einige Sprachen haben, sondern darum, die perfekten Funktionen zu haben.

Meiner Meinung nach liebt deshalb jeder Kotlin so sehr. Es ist die am besten gestaltete Programmiersprache, die ich kenne.

Dafür gibt es starke Gründe:

  • Es war 6 Jahre lang in der Beta und hat sich während der gesamten Zeit iterativ weiterentwickelt
  • Es wurde von JetBrains entwickelt, die ihr Verständnis für Programmiersprachen und deren Verwendung seit Jahren beherrschen

Während der Beta-Phase wurden einige wichtige Funktionen vollständig implementiert und dennoch vor 1.0 entfernt. Unter ihnen sind Tupel. Kotlin hat sie voll unterstützt! Das Kotlin-Team entfernte jedoch die Unterstützung für Tupel vor Kotlin 1.0, da ihre Analysen und Experimente zeigten, dass Tupel mehr schaden als nützen und die Benutzer stattdessen Datenklassen verwenden sollten. Dies zeigt, dass JetBrains die Bedeutung eines guten Designs versteht.

Eine andere Sprache, die gut gestaltet ist, ist Swift. Es wurde viel schneller entwickelt und die Entwickler, die es entworfen haben, haben viele Fehler gemacht. Apple hat das Design jedoch mit fast jeder größeren Version geändert. Sie kümmern sich nicht wirklich um das Erbe.

Entwickler meckern, aber vom Design her ist es großartig. Obwohl sie das nicht lange machen können. Je mehr Dinge in Swift enthalten sind, desto höher sind die Kosten für Designänderungen. Ich glaube auch nicht, dass sie in der Lage sind, wichtige Funktionen zu ändern.

Wenn wir also gut gestaltete neue Sprachen haben, sind sie die endgültigen Sprachen?

Überhaupt nicht. Branchen entwickeln sich weiter. Unser Denken entwickelt sich weiter. Daher müssen sich auch Programmiersprachen weiterentwickeln.

Eine Sache ist, dass Ideen für neue Funktionen und Denkweisen geboren werden und perfekt gestaltete Sprachen nicht mehr perfekt sind.

Die zweite Sache ist, dass wir mehr über das Programmieren lernen. Klassen und Methoden sind in Java standardmäßig geöffnet. Kotlin hat sie beide standardmäßig endgültig gemacht, weil Entwickler die Vererbung stark überbeanspruchten, wenn sie es nicht hätten sein sollen.

Java-Klassenmitglieder waren standardmäßig paketprivat. Dieser Modifikator wurde fast nie verwendet. Kotlin erlaubt es überhaupt nicht, aber stattdessen sind Klassenmitglieder standardmäßig öffentlich, da dies der häufigste Modifikator für sie ist. Wir ändern unsere Gewohnheiten und lernen, daher sollten sich auch die Sprachen mit uns ändern.

Das dritte ist, dass sich die Paradigmen ändern. Ich sehe eine Stagnation in Bezug auf Programmierparadigmen, aber wir müssen noch einige in die tägliche Praxis einführen.

Wohin ging die logische Programmierung? Beachten Sie, dass Sie dieses Paradigma verwenden und nur eine Reihe von Einschränkungen für eine Website bereitstellen können und erwarten, dass die Website basierend auf diesen automatisch erstellt wird. Das kann man umsetzen. Außerdem werden früher oder später neue Paradigmen geboren. Es kann nicht sein, dass wir alles erforscht haben.

Schließlich werden neue Technologien geboren und die alte Denkweise, die durch die vorherigen Sprachen repräsentiert wird, ist möglicherweise nicht angemessen.

Denken Sie an Blockchain. Wenn ich mit Leuten spreche, die einen Wechsel in Betracht ziehen, möchten sie ihre Lieblingssprachen wie Java oder JavaScript verwenden. Wenn ich mit Blockchain-Entwicklern spreche, behaupten sie, dass Blockchain in Sprachen entwickelt werden muss, die dafür entwickelt wurden.

Zum Beispiel ist ein Vertrag ein Konzept, das in der Programmierung kein Äquivalent hat. Es kann von der Klasse simuliert werden, aber dies ist schädlich für die Art und Weise, wie die Leute darüber denken. Es ist schädlich, wenn wir versuchen, neue Dinge mit alten Worten auszudrücken. Es ist, als würde man ein Auto „Stahlpferd“ nennen und versuchen, aus Tierärzten Mechaniker zu machen.

Schließen

Denken Sie an Mathematik. Das Gleichgewicht kann auf beschreibende Weise ausgedrückt werden:

Zwei plus drei sind fünf

Obwohl es etwas völlig anderes ist, als es mit der mathematischen Notation auszudrücken:

2 + 3 = 5

Dies ist nicht die einzige Optimierung für Lesbarkeit und Platzbedarf. Diese beiden Notationen bedeuten dasselbe, aber sie repräsentieren völlig unterschiedliche Konzepte. Dies ist aus Sicht eines Computers nicht wichtig - was die beschreibende Form leicht in mathematische übersetzen kann -, aber es ist das Wichtigste für uns Menschen.

Wenn es nicht wichtig wäre, würden wir Assembler anstelle von Java, JavaScript, Python oder Kotlin verwenden. Aber es ist wichtig. Deshalb brauchen wir einen immer besseren Ausdruck und neue Programmiersprachen.

Über den Autor

Marcin Moskała (@marcinmoskala) ist Trainer und Berater und konzentriert sich derzeit darauf, Kotlin in Android- und fortgeschrittenen Kotlin-Workshops anzubieten (weitere Informationen finden Sie hier). Er ist außerdem Redner, Autor von Artikeln und eines Buches über die Android-Entwicklung in Kotlin.