Ideen zur Sprache

Wir haben wieder einmal Freitag: sprich, es wird Zeit für die neusten Informationen.
Heute möchte ich einmal über die Entwicklung der Sprach-Syntax schreiben.

Wie man sich vorstellen kann, ist es garnicht so einfach, in diesem Bereich Entscheidungen zu fällen: wenn man sich zu sehr an einer existierenden Sprache orientiert, kann es passieren, dass man diese einfach nur re-implementiert; jedoch muss man auch darauf achten, dass die Sprache gut zu erlernen ist - und da kann man sich bei bestehenden Sprachen ruhig eine Scheibe abschneiden.
Generell ist zudem zu beachten, dass die Sprache die gebotenen Sprachfeatures unterstützen und diese möglichst nahtlos in den Programmierfluss mit einbringen sollte.
Sprich: die Sprache ist abhängig vom Funktionsumfang der Sprache.
Daher sollte auch von Anfang an grob umrissen sein, welche Features die entsprechende Sprache unterstützen soll.
Auf ebendiese Features bin ich im letzten Posting schon einmal kurz eingestiegen.

Ein Beispiel: die Sprache soll den Speicherzugriff ermöglichen und diesen soweit möglich managen - die Speicherzugriffe selber sollten jedoch nicht zur Standard-Arbeit des Programmierers gehören. Daher wäre es hier z.B. ratsam, Bezeichner für Kern-Methoden von normalen Methoden abzuheben.
Dadurch erkennt man sofort, wo im Quelltext System-Funktionen genutzt werden - durch dieses Vorgehen kann ein Entwickler auch viel schneller mögliche Problembereiche im Quelltext ausfindig machen (moderne Programmiersprachen versuchen schließlich nicht umsonst, den Entwickler von heute von der Arbeit am Speicher abzukoppeln).

Nun aber zu einigen der im Titel versprochenen Ideen der Sprache: und da fangen wir auch direkt mit einem der wichtigsten Punkte an - das Einschließen von Code-Blöcken.
Es ist erschreckend, aber fast alle Sprachen benutzen dafür Klammern - am liebsten die geschweiften "{" und "}".
Nur einige Sprachen (z.B. Pascal) benutzen hierfür echte Codewörter.
Da diese Klammern überall im Quelltext auftauchen, prägen sie entscheidend das Erscheinungsbild einer Sprache und lassen sie dementsprechend (un-) strukturiert aussehen. Leider musste ich in meiner Laufbahn schon mehrfach feststellen, dass Programmierer Klammern zwar toll finden, da sie schnell einzutippen sind und da sie gut dafür geeignet sind, Blöcke zu kennzeichen (man schließt den Quelltext ja in einer Klammer zusammen), die meisten jedoch schnell in einen Trott bei der Klammer-Einrückung verfallen.
Warum für die eine kleine schließende Klammer nochmal eine ganze Zeile vergeuden - die sieht doch dann so leer aus. Und schon verschwindet die schließende Klammer hinter einem Befehl und fällt dort nicht weiter auf - zumindest bis diese eine Zeile bei Aufräumarbeiten gelöscht wird und der Compiler auf einmal Fehler über Fehler ausspuckt, weil irgendwo eine Klammer fehlt. Nur welche? Das ist die Frage.
Aus diesem Grund wird es in Chest Codewörter für das Bilden von Code-Blöcken geben - sie helfen dem Programmierer, eine gewisse Struktur zu wahren.

Insgesamt ist Chest als "sprechende Sprache" geplant - soweit es den Programmierfluss nicht stört, ist es angedacht, sprechende Codewörter statt kryptischer (leicht parsebarer) Sonderzeichen einzuführen und dem Programmierer auf diese Art und Weise eine Programmiersprache und keinen Programmierzeichensatz anzubieten.

So, das soll es für heute erst einmal gewesen sein...


Bis demnächst...
Wirsing