Warum Chest?

updated

Heute habe ich mir vorgenommen zum Beginn des Wochenendes mal ein bisschen mehr zu schreiben - und zwar dazu, warum es Chest überhaupt geben soll.

Diese Frage wurde mir schon x-fach gestellt, deswegen hoffe ich mal, dass die Antwort schon halbwegs gut formuliert ist. ;-)
Wie bei allem steht natürlich der Lerneffekt im Vordergrund - wie damals auch schon bei AlPhAbEt.
Seitdem haben sich meine Fähigkeiten in den Bereichen Parser-, Scanner- und Interpreterbau jedoch weiterentwickelt und ich möchte endlich einmal eine ordentliche höhere Sprache designen.

Achja... Und dann gibt es da noch einen Grund: Java ist zum kotzen.
Das soll kein politisches Statement sein - schließlich bin auch ich jemand, der (zur Zeit) vollzeit mit dieser Sprache arbeitet.
Jedoch wurden bei der Entwicklung von Java Entscheidungen getroffen, durch die die Sprache sehr viel an Potential einbüßen musste.
Das fängt schon bei den nicht-vorhandenen unsigned Typen an - ich will einfach keine BINÄR-Daten haben, in denen negative Werte vorkommen.
Der viel gravierendere Aspekt ist jedoch die komplette "Abkoppelung" vom System.
Abkoppelung in Anführungszeichen, da diese System-Zugriffe schon vorhanden sind, nur eben so versteckt und so tief im System vergraben, dass man als nutzender Programmierer nicht in der Lage ist, selbst Einfluss darauf zu nehmen.
(Beispielsweise ist im openJDK schön zu sehen, dass der Dateizugriff in Java über einfachen C-Code realisiert wird. Warum wird mir als Entwickler aber verwehrt, ebenso nach außen kommunizieren zu können?)
[Ich bin letztens über die JNI (Java Native Interface) gestolpert. Diese unterstützt tatsächlich das Einbinden von externen Resourcen. Allerdings ist in meinen Augen auch hier die eingesetzte Variante lediglich suboptimal.]

Einige mögen nun sagen, dass dies deshalb getan wurde, um die Sicherheit der Sprache zu erhöhen.
Das bedeutet im Umkehrschluss, dass Sun der Meinung ist, dass ihre Programmierer eher dazu geeignet sind, sicherheitskritischen Code zu schreiben, als externe Entwickler.
Auch sind viele nützliche Dinge mit dem Speicher allein deshalb nicht machbar, weil man unbedingt ein vollständiges Speicher-Management anbieten wollte.
Das ist an sich nicht das Problem, sondern eher, dass man sich die Sache leicht gemacht hat, anstatt das Speicher-Management ordentlich zu programmieren und dadurch auch komplizierten Speicherzugriff zu ermöglichen.
Oder wie schnell können Sie mir die Byte-Darstellung eines double-Wertes beschaffen, ohne über die Double-Klasse gehen zu müssen - bei der man zudem noch nicht mal weiß, wie es denn dort implementiert wurde und warum dort etwas getan werden kann, dass man nicht selber programmieren kann?

Kurz gesagt soll Chest folgendes werden:

• eine ordentlich designte Programmiersprache mit ausgewählten Elementen aus verschiedenen Sprachen sein


• auf einer eigenen virtuellen Maschine basieren
• 
  
• ein Plugin-Interfacing für die VM bieten, durch das Systemzugriffe für Chest-Programme ermöglicht werden sollen


• eine ausgefeilte Speicherverwaltung bieten, die zum einen vollständige Garbarge-Collection und Speicherzugriffs-Kontrolle bietet, aber trotzdem ordentliches Arbeiten mit dem Speicher erlaubt

Es ist viel zu tun und es wird sicher nicht immer einfach sein, aber wenn das Ergebnis erst einmal zu sehen ist, wird man erkennen, dass es sich gelohnt hat.


Bis demnächst...
Wirsing

Chest-Blog eröffnet

Hiermit ist der Chest-Blog offiziell eröffnet.
Er wird mich während der Entwicklung dieser neuen Programmiersprache begleiten.
Ich werde im Verlaufe Design-Aspekte beleuchten, Sprachbeispiele, Dokumente und anderes präsentieren und damit die Entstehung selbst dokumentieren.
Hoffentlich wird euch Lesern dieser Blog soviel Freude bereiten, wie mir die Entwicklung von Chest Freude bereiten wird.


Bis demnächst...
Wirsing