nicht angemeldet
Lieber fischlak,
Du kannst mir also kein Code-Beispiel aus einem einigermaßen fertigen Projekt zeigen. OK, dann ist das so. Kann ich gut mit leben.
Eigentlich ist die Nummer mit Folding, Peek und übermäßiger Inline-Lokalisierung nur ein Versuch, die Unzulänglichkeit moderner Code-Editoren zu kompensieren.
Das ist ein Vorwurf an „moderne Code-Editoren“ (Begriff ist von Dir, Definition fehlt noch). Dabei stellt sich dem ahnungslosen Leser (wie ich einer bin) die Frage, warum Editoren, die seit vielen Jahren gepflegt und entwickelt werden (Geany ist über 20 Jahre alt, VS Code über 10, vi ganze 50 - Kate etwa 20), für Dich unzulänglich sind. Immerhin werden sie von genau solchen Leuten entwickelt, für die sie prinzipiell gedacht sind: Programmierer. Editoren als Werkzeuge, die Programmierer für ihresgleichen bauen und entwickeln! Und für Dich sind sie unzulänglich? Wie kann das sein?
Ich bin Deinem Wunsch entsprochen und hab mir mal die Mühe gemacht und ein Beispiel erstellt.
Mein Wunsch war ein völlig anderer. Aber lass' doch mal sehen, was Du extra für mich zusammengestellt hast.
Das Beispiel zeigt einen funktionierenden Prototypen einer eigenen Meta‑Sprache, die den Zweck haben soll, den Bedarf nach solchen Tricks wie Folding und Peek gar nicht erst aufkommen zu lassen.
In anderen Worten: Anstelle von JavaScript schreibst Du mir ein Beispiel, welches mit XML das JavaScript beschreiben soll. Also anstatt das JavaScript direkt zu haben, muss ich es mir erst aus Deinem XML-Code zusammenreimen. Und das Ergebnis ist dann ein Vorgang, bei dem XML nach JavaScript transpiliert wird, um dann von einer JS-Engine geparst und in Bytecode umgewandelt zu werden.
Auch hier stellt sich meinem ahnungslosen Ich die Frage nach dem Warum.
Das wäre sogar visuell besser als jeder Editor heute.
Den Beweis für diese Aussage musst Du erst noch erbringen, denn statt JavaScript-Code in einem Editor zu schreiben, wie es das Handwerk eines (JS-)Programmierers eben ist, kommst Du mit einer Beschreibungssprache als zusätzlicher Komplexitätsschicht daher.
Function foo ├── Params │ ├── x │ └── y └── Return └── Compute ├── left: x ├── operator: + └── right: y
Ein Diagramm! So als hätte ein JS-Parser den Quelltext geparst und nun ein Datenmodell im Speicher erstellt. Also genau das, was aktuelle JS-Engines (Du hattest sie an anderer Stelle bereits erwähnt) längst seit Jahren leisten.
JavaScript (und andere aktuelle Programmiersprachen) sind ja extra dafür entworfen worden, dass man solcherlei Beschreibungen in Kurzform als Programmcode notiert, weil dieser für den Menschen besser lesbar ist (Stichwort Hochsprache), als eine Beschreibungssprache auf XML-Basis!
Schauen wir Dein Beispiel von der Lesbarkeit in aktuellem JavaScript einmal an:
function sum (x, y) {
return x + y;
}
Als Pfeilfunktion ein Einzeiler:
const sum = (x, y) => x + y;
Und nun als HTJS:
<function name="add">
<params>
<param>x</param>
<param>y</param>
</params>
<body>
<return>
<compute>
<left>x</left>
<operator>+</operator>
<right>y</right>
</compute>
</return>
</body>
</function>
Da wäre ich ja schön blöd, wenn ich als JS-Programmierer solche XML-Monster schreiben müsste, nur um sie dann ohnehin nach JavaScript transpilieren zu lassen! Nicht auszudenken, wie dann ein komplexeres Projekt aussehen sollte, wie z.B. mein Framework für Quizze.
WENN Browser sowas KÖNNTEN, dann würden sie den Javascript-Code genauso anzeigen, wie es aktuelle Code-Editoren tun. Inkl. CSS für Syntax-Highlighting.
Und der Vorteil gegenüber nativem JavaScript-Code in einem Editor wäre dann welcher? Der Preis dafür wäre jedenfalls indiskutabel hoch!
Das wäre eine neue Art, Code zu repräsentieren. Browser könnten das sofort, wenn sie HTJS verstünden. Diese Idee ist eigentlich ziemlich mächtig, weil sie das Grundproblem löst, das ich seit Postings beschreibe: Textdateien sind ein schlechtes Format für Code.
Jetzt wollte ich gerade etwas sarkastisch formuliertes schreiben, will aber konstruktiv bleiben. Deine Idee ist nicht dumm, hat sich aber offenbar von Anfang an nicht als optimal durchgesetzt, denn sonst hätten wir längst anders geartete Entwicklungsprozesse, die dem entsprächen, was Du gerade beschreibst. Also bleibt mir nur der Schluss, dass Du Dich da in etwas verrennst, bei dem Dir mehr als nur meine Person in diesem Thread zu zeigen versucht, dass es Dein persönlicher und für offensichtlich alle anderen ungeeigneter Ansatz ist, in JavaScript zu entwickeln.
Vielleicht verstehst Du jetzt, was ich meine...
Warum nur glaubst Du, ich hätte Dich nicht verstanden? Und nicht bereits beim ersten Mal? Weil ich Dir nicht zustimme?
Liebe Grüße
Felix Riesterer
fischlak
Rolf B
Julius
Gunnar Bittersmann
MudGuard