Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Natürlich – unterschiedliche Sprachen haben unterschiedliche "Fähigkeiten". JavaScript erlaubt Inline‑Funktionen, IIFEs, Closures, Funktionen in Funktionen, hat Arrow‑Functions u.s.w. Pascal z.B. erlaubt keine Inline‑Funktionen, keine anonymen Funktionen, keine IIFEs u.s.w. Man kann die Semantik generalisieren – aber nicht jede Sprache kann jede Semantik abbilden. Das ist wie bei Musiknotation: Du kannst Noten schreiben, aber nicht jedes Instrument kann jeden Ton spielen. Ich kann eine Inline‑Funktion als Hypertext‑Block definieren, aber z.B. Pascal kann sie nicht darstellen. Also muss der Exporter sagen: "Nicht möglich" oder "anders lösen". Hypertext‑Code wäre also eine "Superset‑Semantik". Beim Export stellt sich natürlich die Herausforderung "kann die Sprache das?". Für solche Fälle muss natürlich noch ein alternativer Weg gefunden werden, eine Art "CSS" für das HTML, also wie man nicht exportierbare Features behandelt. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Natürlich – unterschiedliche Sprachen haben unterschiedliche "Fähigkeiten". JavaScript erlaubt Inline‑Funktionen, IIFEs, Closures, Funktionen in Funktionen, hat Arrow‑Functions u.s.w. Pascal z.B. erlaubt keine Inline‑Funktionen, keine anonymen Funktionen, keine IIFEs u.s.w. Man kann die Semantik generalisieren – aber nicht jede Sprache kann jede Semantik abbilden. Das ist wie bei Musiknotation: Du kannst Noten schreiben, aber nicht jedes Instrument kann jeden Ton spielen. Ich kann eine Inline‑Funktion als Hypertext‑Block definieren, aber z.B. Pascal kann sie nicht darstellen. Also muss der Exporter sagen: "Nicht möglich" oder "anders lösen". Hypertext‑Code wäre also eine "Superset‑Semantik". Beim Export stellt sich natürlich die Herausforderung "kann die Sprache das?". Für solche Fälle muss natürlich noch ein alternativer Weg gefunden werden, eine Art "CSS" für das HTML. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Natürlich – unterschiedliche Sprachen haben unterschiedliche "Fähigkeiten". JavaScript erlaubt Inline‑Funktionen, IIFEs, Closures, Funktionen in Funktionen, hat Arrow‑Functions u.s.w. Pascal z.B. erlaubt keine Inline‑Funktionen, keine anonymen Funktionen, keine IIFEs u.s.w. Man kann die Semantik generalisieren – aber nicht jede Sprache kann jede Semantik abbilden. Das ist wie bei Musiknotation: Du kannst Noten schreiben, aber nicht jedes Instrument kann jeden Ton spielen. Ich kann eine Inline‑Funktion als Hypertext‑Block definieren, aber z.B. Pascal kann sie nicht darstellen. Also muss der Exporter sagen: "Nicht möglich" oder "anders lösen". Hypertext‑Code wäre also eine "Superset‑Semantik. Beim Export stellt sich natürlich die Herausforderung "kann die Sprache das?". Für solche Fälle muss natürlich noch ein alternativer Weg gefunden werden, eine Art "CSS" für das HTML. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Natürlich – unterschiedliche Sprachen haben unterschiedliche "Fähigkeiten". JavaScript erlaubt Inline‑Funktionen, IIFEs, Closures Funktionen in Funktionen, hat Arrow‑Functions u.s.w. Pascal z.B. erlaubt keine Inline‑Funktionen, keine anonymen Funktionen, keine IIFEs u.s.w. Man kann die Semantik generalisieren – aber nicht jede Sprache kann jede Semantik abbilden. Das ist wie bei Musiknotation: Du kannst Noten schreiben, aber nicht jedes Instrument kann jeden Ton spielen. Ich kann eine Inline‑Funktion als Hypertext‑Block definieren, aber z.B. Pascal kann sie nicht darstellen. Also muss der Exporter sagen: "Nicht möglich" oder "anders lösen". Hypertext‑Code wäre also eine "Superset‑Semantik. Beim Export stellt sich natürlich die Herausforderung "kann die Sprache das?". Für solche Fälle muss natürlich noch ein alternativer Weg gefunden werden, eine Art "CSS" für das HTML. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Natürlich – unterschiedliche Sprachen haben unterschiedliche "Fähigkeiten". JavaScript erlaubt Inline‑Funktionen, IIFEs, Closures Funktionen in Funktionen, hat Arrow‑Functions u.s.w. Pascal z.B. erlaubt keine Inline‑Funktionen, keine anonymen Funktionen, keine IIFEs u.s.e. Man kann die Semantik generalisieren – aber nicht jede Sprache kann jede Semantik abbilden. Das ist wie bei Musiknotation: Du kannst Noten schreiben, aber nicht jedes Instrument kann jeden Ton spielen. Ich kann eine Inline‑Funktion als Hypertext‑Block definieren, aber z.B. Pascal kann sie nicht darstellen. Also muss der Exporter sagen: "Nicht möglich" oder "anders lösen". Hypertext‑Code wäre also eine "Superset‑Semantik. Beim Export stellt sich natürlich die Herausforderung "kann die Sprache das?". Für solche Fälle muss natürlich noch ein alternativer Weg gefunden werden, eine Art "CSS" für das HTML. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Natürlich – unterschiedliche Sprachen haben unterschiedliche "Fähigkeiten". JavaScript erlaubt Inline‑Funktionen, IIFEs, Closures Funktionen in Funktionen, hat Arrow‑Functions u.s.w. Pascal z.B. erlaubt keine Inline‑Funktionen, keine anonymen Funktionen, keine IIFEs u.s.e. Man kann die Semantik generalisieren — aber nicht jede Sprache kann jede Semantik abbilden. Das ist wie bei Musiknotation: Du kannst Noten schreiben, aber nicht jedes Instrument kann jeden Ton spielen. Ich kann eine Inline‑Funktion als Hypertext‑Block definieren, aber z.B. Pascal kann sie nicht darstellen. Also muss der Exporter sagen: "Nicht möglich" oder "anders lösen". Hypertext‑Code wäre also eine "Superset‑Semantik. Beim Export stellt sich natürlich die Herausforderung "kann die Sprache das?". Für solche Fälle muss natürlich noch ein alternativer Weg gefunden werden, eine Art "CSS" für das HTML. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen: Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen, hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen – Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, nicht die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...

Hallo Felix, wenn du Code nicht als Text speicherst, sondern als "strukturierte Hypertext‑Elemente", dann passiert etwas Entscheidendes: Die Darstellung ist von der Ziel‑Programmiersprache entkoppelt! Das bedeutet: - "<function>" ist eine Funktion – egal ob JS, Python, PHP, u.s.w. - "<param>" ist ein Parameter – egal wie die Syntax aussieht - "<block>" ist ein Block – egal ob "{}", "begin/end", Einrückung - "<compute>" ist ein Ausdruck – egal ob "+", "add()", "(+ x y)" Du beschreibst also Bedeutung, nicht Syntax. Und das ist exakt das, was Compiler‑Frontends tun – nur tun sie es viel komplizierter. Transcompiling würde plötzlich trivial werden. Wenn du Hypertext‑Code hast, kannst du: - JS exportieren - Python exportieren - C# exportieren - Rust exportieren - u.s.w. ...weil du nur die "Syntax‑Schablone" auszutauschen brauchst. Beispiel die erwähnte Hypertext‑Struktur: ~~~ <function name="foo"> <params> <param>x</param> <param>y</param> </params> <return> <compute> <left>x</left> <operator>+</operator> <right>y</right> </compute> </return> </function> ~~~ Export nach JavaScript: ~~~ function foo(x, y) { return x + y; } ~~~ Export nach Python: ~~~ def foo(x, y): return x + y ~~~ Export nach Lua: ~~~ function foo(x, y) return x + y end ~~~ Export nach Rust: ~~~ fn foo(x: i32, y: i32) -> i32 { x + y } ~~~ Export nach C#: ~~~ int foo(int x, int y) { return x + y; } ~~~ Du siehst: Die Struktur bleibt gleich – nur die Syntax ändert sich. Und deshalb wäre Transcompiling in solch einem System "lächerlich einfach". Anfänger könnten einmal eine Funktion bauen und dann sehen, wie sie in anderen Sprachen aussieht. Das wäre ein zusätzliches Lernwerkzeug. Oder Leute, die Prototypen bauen – Ein Prototyp könnte in JS laufen, später in Python exportiert werden oder in C# für Unity oder in Lua für ein Spiel. Ohne das Rad neu erfinden zu müssen. Oder Leute, die DSLs bauen hätten damit eine perfekte Grundlage, denn mein beschriebenes Konzept bedeutet "semantische Darstellung von Code". Hypertext-Coding wäre ein Schritt in Richtung "Generalisierung und Standardisierung von Programmiersprache", denn Hypertext-Code beschreibt die Bedeutung, sondern die Syntax. Hypertext-Code ist sprachneutral und eindeutig, eine Art "universelle Repräsentation" von Code, – eine Meta‑Sprache als Abstraktion über allen Programmiersprachen. Gruß, fischlak -- Eitelkeit und Intelligenz sind Gegensätze. Nur Mist, dass ich so eitel bin...