Konzept: Sinnvoll oder nicht?

Übersicht

Sonstiges

Smalltalk

Gehe zu Seite Zurück 1, 2, 3 Weiter

	pixelshooter	Do, Sep 27, 2007 19:18 Antworten mit Zitat
ich hab zwar auch linux, aber egal^^ das mit XSL meinte ich eig, um daraus andere Programmtexte für andere Sprachen zu generieren. aber gut, ich lass dich erst ma machen. Lass dann ma von dir hören ;D
>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

pixelshooter

Do, Sep 27, 2007 19:18
Antworten mit Zitat

ich hab zwar auch linux, aber egal^^
das mit XSL meinte ich eig, um daraus andere Programmtexte für andere Sprachen zu generieren.
aber gut, ich lass dich erst ma machen.
Lass dann ma von dir hören ;D

>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

	TheShadow Moderator	Di, Okt 02, 2007 14:31 Antworten mit Zitat
Nach dem lesen muß ich sagen - das ist die absurdeste Idee die ich je gesehen habe - diese lässt sich nie realisieren... Zum einen sehe ich keinen Sinn einzelne Codefragmente in Tags zu markieren - da diese Codefragmente von einem guten parser selbst erkannt werden können. Weiterhin wirst du keine Standard-Library erschaffen können die alle Sprachen abdecken wird... d.h. während Blitz sowas wie LoadImage hat - hat C das nicht und da musst du Librarys einbinden die das unterstützen... diese Libs müssen dann aber genau so funktionieren... d.h. kann die Lib ein Format mehr, dann ist die wieder mächtiger als Blitz-eigene... usw... du wirst nie ein Gleichgewicht finden können - außer eine Sprache kann dann mehr als andere - wo wir wieder beim Punkt sind, dass einzelne Sprachen inkompatibel werden... und da du scheinbar mit so einem Konzept genau das verhindern willst - sägst du gerade deinen eigenen Ast ab. Die einfachste Möglichkeit wäre die Erschaffung eines gemeinsamen Frameworks, welches in C geschrieben wäre und dann auf alle Sprachen (per Wrapper oder direkt) und Systeme portiert würde - das wäre für BB und etwa Java usw. sowie Windows, Linux usw. möglich... Doch es gibt da draussen schon viele Framewors - die zugegeben nicht so einfach sind wie die von Blitz. Dann wiederum sieht man den Vorteil nicht etwas in Java zu schreiben - wenn man es in C genau so gut schreiben könnte... ------ Ich persönlich hatte schon lange eine andere Idee... Eine neue Sprache ähnlich Basic - jedoch ohne Altlasten und mit der Power von C - und ganzen Schnickschnack (OOP) Ein Code würde dann so aussehen: Code: [AUSKLAPPEN] [EINKLAPPEN] IMPORT console IMPORT math CLASS test i:INT END SUB foo:INT () i:INT FOR i,1,90 IF i>10 AND i<80 console.writedouble(math.sin(i)) END END END Schlüsselwörter wie IF, AND, SUB usw... wären in der Sprache - der Rest wird über libs nachgeladen... Die Libs müssen eingebunden werden (etwa math, console). Jede Lib kann über präprozessor-direktiven für mehrere platformen wie linux/mindows ausgelegt werden. Die einzelnen Funktionen usw. müssten per libname angesprochen werden - ein import wäre nicht möglich. Jede lib hat autom. einen eigenen namespace - sowas wie SIN() wäre nicht möglich sondern man müsste math.sin() schreiben. Dadurch hätte man tatsächlich sowas wie ein Baukastensystem - wo einzelne Namen nicht mehr mit anderen kollidieren können. Ein Compiler würde dann den Code und verwendete Libs in eine Zielsprache (C++) umwandeln und per GCC zu binary kompilieren... Vorteil: -anders als bei C wurden die verwendeten Libs autom. eingelinkt - auch makefiles und komplizierte Konfigurationen wäre nicht notwendig -die header dateien wären auch nicht nötig - da die Deklarationen autom. generiert werden -da man einen konverter und keinen compiler hat, wird die optimierung den fertigen C++ compilern überlassen (warum soll man das Rad 2x erfinden?) -nahezu alle systeme würden dann unterstützt wo es auch c++ compiler gibt. Die Libs müsste man dann jedoch anpassen
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Di, Okt 02, 2007 14:31
Antworten mit Zitat

Nach dem lesen muß ich sagen - das ist die absurdeste Idee die ich je gesehen habe - diese lässt sich nie realisieren...

Zum einen sehe ich keinen Sinn einzelne Codefragmente in Tags zu markieren - da diese Codefragmente von einem guten parser selbst erkannt werden können.

Weiterhin wirst du keine Standard-Library erschaffen können die alle Sprachen abdecken wird... d.h. während Blitz sowas wie LoadImage hat - hat C das nicht und da musst du Librarys einbinden die das unterstützen... diese Libs müssen dann aber genau so funktionieren... d.h. kann die Lib ein Format mehr, dann ist die wieder mächtiger als Blitz-eigene... usw... du wirst nie ein Gleichgewicht finden können - außer eine Sprache kann dann mehr als andere - wo wir wieder beim Punkt sind, dass einzelne Sprachen inkompatibel werden... und da du scheinbar mit so einem Konzept genau das verhindern willst - sägst du gerade deinen eigenen Ast ab.

Die einfachste Möglichkeit wäre die Erschaffung eines gemeinsamen Frameworks, welches in C geschrieben wäre und dann auf alle Sprachen (per Wrapper oder direkt) und Systeme portiert würde - das wäre für BB und etwa Java usw. sowie Windows, Linux usw. möglich... Doch es gibt da draussen schon viele Framewors - die zugegeben nicht so einfach sind wie die von Blitz.

Dann wiederum sieht man den Vorteil nicht etwas in Java zu schreiben - wenn man es in C genau so gut schreiben könnte...

------

Ich persönlich hatte schon lange eine andere Idee...

Eine neue Sprache ähnlich Basic - jedoch ohne Altlasten und mit der Power von C - und ganzen Schnickschnack (OOP)

Ein Code würde dann so aussehen:

Code: [AUSKLAPPEN]

IMPORT console
IMPORT math

CLASS test
i:INT
END

SUB foo:INT ()
i:INT

FOR i,1,90
IF i>10 AND i<80
console.writedouble(math.sin(i))
END
END
END

Schlüsselwörter wie IF, AND, SUB usw... wären in der Sprache - der Rest wird über libs nachgeladen...

Die Libs müssen eingebunden werden (etwa math, console). Jede Lib kann über präprozessor-direktiven für mehrere platformen wie linux/mindows ausgelegt werden.

Die einzelnen Funktionen usw. müssten per libname angesprochen werden - ein import wäre nicht möglich. Jede lib hat autom. einen eigenen namespace - sowas wie SIN() wäre nicht möglich sondern man müsste math.sin() schreiben. Dadurch hätte man tatsächlich sowas wie ein Baukastensystem - wo einzelne Namen nicht mehr mit anderen kollidieren können.

Ein Compiler würde dann den Code und verwendete Libs in eine Zielsprache (C++) umwandeln und per GCC zu binary kompilieren...

Vorteil:
-anders als bei C wurden die verwendeten Libs autom. eingelinkt - auch makefiles und komplizierte Konfigurationen wäre nicht notwendig
-die header dateien wären auch nicht nötig - da die Deklarationen autom. generiert werden
-da man einen konverter und keinen compiler hat, wird die optimierung den fertigen C++ compilern überlassen (warum soll man das Rad 2x erfinden?)
-nahezu alle systeme würden dann unterstützt wo es auch c++ compiler gibt. Die Libs müsste man dann jedoch anpassen

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	pixelshooter	Di, Okt 02, 2007 16:38 Antworten mit Zitat
sicher deutlich einfacher zu realisieren. Meiner Menung nach ist auch die Sache, dass man sich schon als Anfänger sehr stark mit konfigurationen auseinandersetzen muss - oder man bleibt bei der standard library... Außerdem halt die sache evt. Fehlerhafter header und dass bibliotheken sehr gut den namespace verschmutzen können. Wenn dann noch in deiner Sprache wert auf Praxisnahe dinge wie GUI anbindung (passende Bibliotheken lassen sich finden, jeder hat da seinen liebling, ich zb Qt) etc. wäre das schon gut.
>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

pixelshooter

Di, Okt 02, 2007 16:38
Antworten mit Zitat

sicher deutlich einfacher zu realisieren. Meiner Menung nach ist auch die Sache, dass man sich schon als Anfänger sehr stark mit konfigurationen auseinandersetzen muss - oder man bleibt bei der standard library...
Außerdem halt die sache evt. Fehlerhafter header und dass bibliotheken sehr gut den namespace verschmutzen können.

Wenn dann noch in deiner Sprache wert auf Praxisnahe dinge wie GUI anbindung (passende Bibliotheken lassen sich finden, jeder hat da seinen liebling, ich zb Qt) etc. wäre das schon gut.

>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

	E. Urbach ehemals "Basicprogger"	Di, Okt 02, 2007 17:41 Antworten mit Zitat
@TheShadow: Zitat: Nach dem lesen muß ich sagen - das ist die absurdeste Idee die ich je gesehen habe - diese lässt sich nie realisieren... Danke, schön zu wissen. Besonders deshalb, weil ich monatelang fast alle auf mich zukommenden Probleme schon analysiert und mir überlegt habe, wie man sie lösen kann. Du hast mein Projekt ganz einfach nicht verstanden. Wir reden einander vorbei, obwohl wir dieselben Dinge meinen, denn es ist genauso, wie du es beschrieben hast: Zitat: Eine neue Sprache ähnlich Basic - jedoch ohne Altlasten und mit der Power von C - und ganzen Schnickschnack (OOP) Ein Code würde dann so aussehen: [...] Der XML-Code soll nur der Speicherung von Metadaten dienen, wie z.B. Autor, Version, Libraries die man mitlinken muss etc. Meine Idee war bloß, dass es nicht mehr auf die Syntax der Sprache ankommt. Wenn man jetzt deinen Beispielcode nimmt... Code: [AUSKLAPPEN] [EINKLAPPEN] IMPORT console IMPORT math CLASS test i:INT END SUB foo:INT () i:INT FOR i,1,90 IF i>10 AND i<80 console.writedouble(math.sin(i)) END END END ...dann wäre deine Variante die, dass man es direkt in C++ umwandelt und kompilieren lässt. Ich habe auch schon über diese Möglichkeit nachgedacht - die übrigens zu kleineren Kompilierzeiten führt -, aber sie hat einen entscheidenden Nachteil: Man ist an die Syntax gebunden. Was wäre, wenn jemandem dein SUB foo:INT () oder dein cosole.writedouble nicht gefällt? Er würde sich nicht mehr dafür interessieren, denn schließlich ist es nur ein Wrapper für C++, in einer anderen Syntax. Zitat: Die einfachste Möglichkeit wäre die Erschaffung eines gemeinsamen Frameworks, welches in C geschrieben wäre und dann auf alle Sprachen (per Wrapper oder direkt) und Systeme portiert würde - das wäre für BB und etwa Java usw. sowie Windows, Linux usw. möglich... Doch es gibt da draussen schon viele Framewors - die zugegeben nicht so einfach sind wie die von Blitz. Siehe meinen ersten, zweiten und dritten Beitrag auf der ersten Seite dieses Threads. Da mein dritter Post recht lang ist, hier das wichtigste: Zitat: Die Programmiersprachen werden nicht wirklich als solche angesehen. Es geht nur um die Syntax. Ihr werdet beim Programmieren mit C++ kein cout finden, auch keinen std-namespace, sondern nur die C++ Syntax. Das cout könnt ihr nur beim C++ Importer verwenden Deine Vorgehensweise wäre die folgende: Vorteile: Sehr schnelle Kompilierzeiten Dank C++ werden viele Plattformen unterstützt Dank C++ sehr effizient (wie du schon gesagt hast, man muss das Rad nicht 2x erfinden) Aufgrund des Frameworks werden keine Header und keine Libs benötigt, die man manuell mitlinken müsste Nachteile: Man kann nur die vom Entwickler festgelegte Syntax verwenden Metadaten, ToDo's, Bookmarks usw. bleiben weiterhin eine proprietäre Erweiterung, wenn sie denn überhaupt implementiert werden Es werden spezielle Parser benötigt (an dieser Stelle müsstest du das Rad neu erfinden, wieso nicht XML?) Meine Idee kann folgendermaßen dargestellt werden: Vorteile: Es können Metadaten gespeichert werden Es werden theoretisch beliebig viele Plattformen unterstützt, da jeder Hersteller sein eigenes Ausgabeformat entwickeln kann Die Effizienz ist variabel, in einigen Dingen ist Java (angeblich) schneller als C++, dort könnte man beispielsweise Java als Ausgabeformat angeben (auch wenn ich bezweifle, dass ein Performance-Freak nicht C++ wählt) Jede nur erdenkliche Syntax kann verwendet werden und die Daten sind trotzdem in einem einheitlichen Format - XML - gespeichert Das Konzept der Wiederverwendbarkeit ist hier besser realisierbar, da man eine einmal geschriebene Komponente in fast jedes Ausgabeformat konvertieren kann Aufgrund des Frameworks werden hier ebenfalls keine Header und keine Libs benötigt, die man manuell mitlinken müsste Nachteile: Längere Kompilierzeit Die physische Platzbelegung des Codes auf der Festplatte ist höher (aus 1 KB Code werden ca. 2 KB Code) Wie du siehst, verfolgen wir genau das gleiche Ziel, bloß dass ich noch ein paar Features mehr einbringen wollte - was natürlich in einer höheren Entwicklungszeit resultiert.
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Di, Okt 02, 2007 17:41
Antworten mit Zitat

@TheShadow:
Zitat:

Nach dem lesen muß ich sagen - das ist die absurdeste Idee die ich je gesehen habe - diese lässt sich nie realisieren...

Danke, schön zu wissen. Besonders deshalb, weil ich monatelang fast alle auf mich zukommenden Probleme schon analysiert und mir überlegt habe, wie man sie lösen kann.

Du hast mein Projekt ganz einfach nicht verstanden. Wir reden einander vorbei, obwohl wir dieselben Dinge meinen, denn es ist genauso, wie du es beschrieben hast:
Zitat:

Eine neue Sprache ähnlich Basic - jedoch ohne Altlasten und mit der Power von C - und ganzen Schnickschnack (OOP)

Ein Code würde dann so aussehen: [...]

Der XML-Code soll nur der Speicherung von Metadaten dienen, wie z.B. Autor, Version, Libraries die man mitlinken muss etc.
Meine Idee war bloß, dass es nicht mehr auf die Syntax der Sprache ankommt. Wenn man jetzt deinen Beispielcode nimmt...
Code: [AUSKLAPPEN]

IMPORT console
IMPORT math

CLASS test
i:INT
END

SUB foo:INT ()
i:INT

FOR i,1,90
IF i>10 AND i<80
console.writedouble(math.sin(i))
END
END
END

...dann wäre deine Variante die, dass man es direkt in C++ umwandelt und kompilieren lässt. Ich habe auch schon über diese Möglichkeit nachgedacht - die übrigens zu kleineren Kompilierzeiten führt -, aber sie hat einen entscheidenden Nachteil: Man ist an die Syntax gebunden. Was wäre, wenn jemandem dein SUB foo:INT () oder dein cosole.writedouble nicht gefällt? Er würde sich nicht mehr dafür interessieren, denn schließlich ist es nur ein Wrapper für C++, in einer anderen Syntax.

Zitat:

Die einfachste Möglichkeit wäre die Erschaffung eines gemeinsamen Frameworks, welches in C geschrieben wäre und dann auf alle Sprachen (per Wrapper oder direkt) und Systeme portiert würde - das wäre für BB und etwa Java usw. sowie Windows, Linux usw. möglich... Doch es gibt da draussen schon viele Framewors - die zugegeben nicht so einfach sind wie die von Blitz.

Siehe meinen ersten, zweiten und dritten Beitrag auf der ersten Seite dieses Threads.
Da mein dritter Post recht lang ist, hier das wichtigste:
Zitat:

Die Programmiersprachen werden nicht wirklich als solche angesehen. Es geht nur um die Syntax. Ihr werdet beim Programmieren mit C++ kein cout finden, auch keinen std-namespace, sondern nur die C++ Syntax. Das cout könnt ihr nur beim C++ Importer verwenden

Deine Vorgehensweise wäre die folgende:
user posted image

Vorteile:

Sehr schnelle Kompilierzeiten

Dank C++ werden viele Plattformen unterstützt

Dank C++ sehr effizient (wie du schon gesagt hast, man muss das Rad nicht 2x erfinden)

Aufgrund des Frameworks werden keine Header und keine Libs benötigt, die man manuell mitlinken müsste

Nachteile:

Man kann nur die vom Entwickler festgelegte Syntax verwenden

Metadaten, ToDo's, Bookmarks usw. bleiben weiterhin eine proprietäre Erweiterung, wenn sie denn überhaupt implementiert werden

Es werden spezielle Parser benötigt (an dieser Stelle müsstest du das Rad neu erfinden, wieso nicht XML?)

Meine Idee kann folgendermaßen dargestellt werden:
user posted image

Vorteile:

Es können Metadaten gespeichert werden

Es werden theoretisch beliebig viele Plattformen unterstützt, da jeder Hersteller sein eigenes Ausgabeformat entwickeln kann

Die Effizienz ist variabel, in einigen Dingen ist Java (angeblich) schneller als C++, dort könnte man beispielsweise Java als Ausgabeformat angeben (auch wenn ich bezweifle, dass ein Performance-Freak nicht C++ wählt)

Jede nur erdenkliche Syntax kann verwendet werden und die Daten sind trotzdem in einem einheitlichen Format - XML - gespeichert

Das Konzept der Wiederverwendbarkeit ist hier besser realisierbar, da man eine einmal geschriebene Komponente in fast jedes Ausgabeformat konvertieren kann

Aufgrund des Frameworks werden hier ebenfalls keine Header und keine Libs benötigt, die man manuell mitlinken müsste

Nachteile:

Längere Kompilierzeit

Die physische Platzbelegung des Codes auf der Festplatte ist höher (aus 1 KB Code werden ca. 2 KB Code)

Wie du siehst, verfolgen wir genau das gleiche Ziel, bloß dass ich noch ein paar Features mehr einbringen wollte - was natürlich in einer höheren Entwicklungszeit resultiert.

The box said, "Requires Windows XP or better", so I installed Ubuntu | Linux is NOT Windows
Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

	maximilian	Di, Okt 02, 2007 17:56 Antworten mit Zitat
Zu schade, dass schon mal jemand so eine Idee hatte, Basicprogger. Die Erfindung heißt "C" und ist eine offene bewährte Sprache, die platformübergreifend arbeitet und mit Standard-Headern versehen ist. Der Dokumentationszweig wird bei C-Programmen zur besseren Übersichtlichkeit meist in eine Datei mit dem Namen "readme.txt" gepackt. Tut mir leid dich enttäuschen zu müssen... :/
Variety is the spice of life. One day ignore people, next day annoy them.

maximilian

Di, Okt 02, 2007 17:56
Antworten mit Zitat

Zu schade, dass schon mal jemand so eine Idee hatte, Basicprogger. Die Erfindung heißt "C" und ist eine offene bewährte Sprache, die platformübergreifend arbeitet und mit Standard-Headern versehen ist.

Der Dokumentationszweig wird bei C-Programmen zur besseren Übersichtlichkeit meist in eine Datei mit dem Namen "readme.txt" gepackt.

Tut mir leid dich enttäuschen zu müssen... :/

Variety is the spice of life. One day ignore people, next day annoy them.

	Vertex	Di, Okt 02, 2007 18:05 Antworten mit Zitat
Hatte vor 2 Jahren die gleiche Idee. Siehe dazu http://www.portablegaming.de/d...rache.html Entstand einfach aus der Not heraus, dass es keinen Compiler für den Prozessor des PMinis gibt. Ein weiterer Vorteil dieser Sprache wäre übrigens, dass sie von jedem verstanden wird. Wenn man als Neuling in C Sternchen, Semikola, Klammern etc. mal nicht auf Anhieb einen Sinn ableiten kann, wäre das in XML durchaus möglich. Letzlich wäre aber eine XML Programmiersprache aber nicht das ware. Viel zu viel Aufwand um ein Code zu tippen. Ich finde btw., dass .NET hier einen perfekten Vorreiter zum Thema darstellt. Ob VB, C, Java, Pascal uvm. alle werden in einem Platformunabhängigen IL-Code kompiliert. Eine Bibliothek, geschrieben in C#, kann unter VB.Net problemlos genutzt werden. Dass es jedoch meist nur auf Windows Einsatz findet, ist bedauerlich. mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Di, Okt 02, 2007 18:05
Antworten mit Zitat

Hatte vor 2 Jahren die gleiche Idee. Siehe dazu http://www.portablegaming.de/d...rache.html

Entstand einfach aus der Not heraus, dass es keinen Compiler für den Prozessor des PMinis gibt.
Ein weiterer Vorteil dieser Sprache wäre übrigens, dass sie von jedem verstanden wird. Wenn man
als Neuling in C Sternchen, Semikola, Klammern etc. mal nicht auf Anhieb einen Sinn ableiten kann,
wäre das in XML durchaus möglich.

Letzlich wäre aber eine XML Programmiersprache aber nicht das ware. Viel zu viel Aufwand um ein Code
zu tippen.

Ich finde btw., dass .NET hier einen perfekten Vorreiter zum Thema darstellt. Ob VB, C, Java, Pascal uvm. alle werden in einem Platformunabhängigen IL-Code kompiliert. Eine Bibliothek, geschrieben in C#, kann unter VB.Net problemlos genutzt werden. Dass es jedoch meist nur auf Windows Einsatz findet, ist bedauerlich.

mfg olli

vertex.dreamfall.at | GitHub

	E. Urbach ehemals "Basicprogger"	Di, Okt 02, 2007 18:12 Antworten mit Zitat
@LordChaos: Wenn das ein Witz gewesen sein sollte, dann fand ich ihn - bei allem Respekt - nicht witzig. Wenn es ernst gemeint war, schlage ich vor, du liest den gesamten Thread inklusive aller Beiträge noch einmal durch. Sollte dein Verständnis dieses Projekts sich bis dahin nicht verändert haben, kann ich dir gern privat nachhelfen, meine ICQ-Nummer findest du in meinem Profil. Zitat: Tut mir leid dich enttäuschen zu müssen... Du enttäuscht mich, von dir hätte ich ehrlich gesagt etwas seriöseres erwartet als eine zum Thread unpassende Antwort, auch bekannt als "Spam". @Vertex: Wenigstens einer, der mich versteht Zitat: Hatte vor 2 Jahren die gleiche Idee. Hab ja gesagt, ich bin nicht der erste der sich sowas ausdenkt Zitat: Letzlich wäre aber eine XML Programmiersprache aber nicht das ware. Viel zu viel Aufwand um ein Code zu tippen. Siehe mein Diagramm im oberen Post. Man muss nicht direkt in XML programmieren. XML ist nur eine von verschiedenen Syntaxen, man kann auch mit der C++ Syntax bzw. mit der BASIC-Syntax programmieren. Das einzige, wofür XML benutzt wird, ist die Speicherform oder wie immer man das auch nennen sollte. Wenn ich die Daten direkt in C++ Syntax halten würde, wären wir wieder beim Problem der Wiederverwendbarkeit und bei den verschiedenen Parsern. Ein XML-Modell kann hingegen in alles mögliche umgewandelt werden, XML-Parser gibt es dafür genug, selbst für BMax wurden einige entwickelt.
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Di, Okt 02, 2007 18:12
Antworten mit Zitat

@LordChaos:
Wenn das ein Witz gewesen sein sollte, dann fand ich ihn - bei allem Respekt - nicht witzig.
Wenn es ernst gemeint war, schlage ich vor, du liest den gesamten Thread inklusive aller Beiträge noch einmal durch.
Sollte dein Verständnis dieses Projekts sich bis dahin nicht verändert haben, kann ich dir gern privat nachhelfen, meine ICQ-Nummer findest du in meinem Profil.

Zitat:

Tut mir leid dich enttäuschen zu müssen...

Du enttäuscht mich, von dir hätte ich ehrlich gesagt etwas seriöseres erwartet als eine zum Thread unpassende Antwort, auch bekannt als "Spam".

@Vertex:
Wenigstens einer, der mich versteht Smile

Zitat:

Hatte vor 2 Jahren die gleiche Idee.

Hab ja gesagt, ich bin nicht der erste der sich sowas ausdenkt Wink

Zitat:

Letzlich wäre aber eine XML Programmiersprache aber nicht das ware. Viel zu viel Aufwand um ein Code
zu tippen.

Siehe mein Diagramm im oberen Post.
user posted image

Man muss nicht direkt in XML programmieren. XML ist nur eine von verschiedenen Syntaxen, man kann auch mit der C++ Syntax bzw. mit der BASIC-Syntax programmieren. Das einzige, wofür XML benutzt wird, ist die Speicherform oder wie immer man das auch nennen sollte. Wenn ich die Daten direkt in C++ Syntax halten würde, wären wir wieder beim Problem der Wiederverwendbarkeit und bei den verschiedenen Parsern. Ein XML-Modell kann hingegen in alles mögliche umgewandelt werden, XML-Parser gibt es dafür genug, selbst für BMax wurden einige entwickelt.

	maximilian	Di, Okt 02, 2007 18:59 Antworten mit Zitat
@Basicprogger: Der Witz an der großen Welt der Programmiersprachen ist, dass alle verschieden sind. Wer sich in dieser Welt nicht zurechtfindet, nutzt C als universelle Sprache. Ich verstehe einfach den Sinn (zurecht!) nicht: Programmieren läuft im wesentlichsten Teil abstrakt im Gehirn ab. Zur Umsetzung wählt sich jeder genau das was er will. Der einzige gemeinsame Standard, der sich etabliert hat, ist die C-Syntax. Egal was für ein Tutorial du im Internet suchst und findest, in 90% aller Fälle findest du ein Stück C oder C++ Code. Weil beide Sprachen den idealen Kompromiss zwischen Umfang und Geschwindigkeit darstellen. Für einen neuen Standard ist schlichtweg kein Bedürfnis oder Platz da. So lange eine Sprache OOP oder prozedual ist (+ du ein gutes Standard-Framework, von denen es tausende gibt, verwendest) kannst du übrigens problemlos mit nem Texteditor das Programm konvertieren (oder mit nem 200 Zeilen-Keyword-Replacement-Programm). Und da man die Programmiersprache speziell für das Programm wählt, wird es wohl kaum zu einem Wechsel während des Programmierens kommen.
Variety is the spice of life. One day ignore people, next day annoy them.

maximilian

Di, Okt 02, 2007 18:59
Antworten mit Zitat

@Basicprogger: Der Witz an der großen Welt der Programmiersprachen ist, dass alle verschieden sind. Wer sich in dieser Welt nicht zurechtfindet, nutzt C als universelle Sprache.

Ich verstehe einfach den Sinn (zurecht!) nicht: Programmieren läuft im wesentlichsten Teil abstrakt im Gehirn ab. Zur Umsetzung wählt sich jeder genau das was er will.

Der einzige gemeinsame Standard, der sich etabliert hat, ist die C-Syntax. Egal was für ein Tutorial du im Internet suchst und findest, in 90% aller Fälle findest du ein Stück C oder C++ Code. Weil beide Sprachen den idealen Kompromiss zwischen Umfang und Geschwindigkeit darstellen. Für einen neuen Standard ist schlichtweg kein Bedürfnis oder Platz da.

So lange eine Sprache OOP oder prozedual ist (+ du ein gutes Standard-Framework, von denen es tausende gibt, verwendest) kannst du übrigens problemlos mit nem Texteditor das Programm konvertieren (oder mit nem 200 Zeilen-Keyword-Replacement-Programm). Und da man die Programmiersprache speziell für das Programm wählt, wird es wohl kaum zu einem Wechsel während des Programmierens kommen.

Variety is the spice of life. One day ignore people, next day annoy them.

	pixelshooter	Di, Okt 02, 2007 19:09 Antworten mit Zitat
bei solchen pragmatischen Sätzen wie "C/C++ ist gut, da brauchts nichts mehr" krieg ich immer angst. Wer hätte den vor einigen jahrzehnten an OOP gedacht? Ideen für neue funktionalitäten kann man ruhig auch mit neuen syntaktischen mitteln verbreiten - und wenn sich das system auch noch als transfer schnittstelle für vershciedene andere sprachen eignet, warum nicht?
>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

pixelshooter

Di, Okt 02, 2007 19:09
Antworten mit Zitat

bei solchen pragmatischen Sätzen wie "C/C++ ist gut, da brauchts nichts mehr" krieg ich immer angst. Wer hätte den vor einigen jahrzehnten an OOP gedacht?
Ideen für neue funktionalitäten kann man ruhig auch mit neuen syntaktischen mitteln verbreiten - und wenn sich das system auch noch als transfer schnittstelle für vershciedene andere sprachen eignet, warum nicht?

>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

	maximilian	Di, Okt 02, 2007 20:02 Antworten mit Zitat
Zitat: bei solchen pragmatischen Sätzen wie "C/C++ ist gut, da brauchts nichts mehr" krieg ich immer angst. Wer hätte den vor einigen jahrzehnten an OOP gedacht? Ideen für neue funktionalitäten kann man ruhig auch mit neuen syntaktischen mitteln verbreiten - und wenn sich das system auch noch als transfer schnittstelle für vershciedene andere sprachen eignet, warum nicht? Das ist aber 100% nicht das, was Blitzprogger will. Andere Ansätze (die sich selbstverständlich mit seinem bisherigen Ansatz kein bisschen verwirklichen lassen) gibt es bereits. Das dumme ist ja, wie beschränkt so ein XML-Dokument wäre. Funktionale Sprachen kann man damit überhaupt nicht benutzen.
Variety is the spice of life. One day ignore people, next day annoy them.

maximilian

Di, Okt 02, 2007 20:02
Antworten mit Zitat

Zitat:

Das ist aber 100% nicht das, was Blitzprogger will. Andere Ansätze (die sich selbstverständlich mit seinem bisherigen Ansatz kein bisschen verwirklichen lassen) gibt es bereits.

Das dumme ist ja, wie beschränkt so ein XML-Dokument wäre. Funktionale Sprachen kann man damit überhaupt nicht benutzen.

Variety is the spice of life. One day ignore people, next day annoy them.

	E. Urbach ehemals "Basicprogger"	Di, Okt 02, 2007 20:15 Antworten mit Zitat
Zitat: Das ist aber 100% nicht das, was Blitzprogger will. Auch wenn ich meinen Nickname schon seit längerem ändern wollte, ich heiße immer noch Basicprogger. Übrigens ist es genau das, was ich will. Der "Transfer" soll nicht nur in eine, sondern in beide Richtungen möglich sein, wobei der Export ein nicht umkehrbarer Transfer ist (zumindest nicht ohne größere Workarounds). Zitat: Andere Ansätze (die sich selbstverständlich mit seinem bisherigen Ansatz kein bisschen verwirklichen lassen) gibt es bereits. Ich wäre dir sehr dankbar, wenn ich die Links dazu kriegen könnte, interessiert mich wirklich sehr, wie ich meinen Ansatz verbessern kann. Zitat: Das dumme ist ja, wie beschränkt so ein XML-Dokument wäre. Dann schlag mir eine bessere Struktur für das XML-Dokument vor. Ich habe den Thread schließlich deshalb eröffnet, weil ich Kritik und Vorschläge hören wollte, und wenn du mir gleich einen praktischen Vorschlag liefern kannst, dann hätte ich mein Ziel immerhin schon teilweise erreicht
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Di, Okt 02, 2007 20:15
Antworten mit Zitat

Zitat:

Das ist aber 100% nicht das, was Blitzprogger will.

Auch wenn ich meinen Nickname schon seit längerem ändern wollte, ich heiße immer noch Basicprogger.
Übrigens ist es genau das, was ich will. Der "Transfer" soll nicht nur in eine, sondern in beide Richtungen möglich sein, wobei der Export ein nicht umkehrbarer Transfer ist (zumindest nicht ohne größere Workarounds).
Zitat:

Andere Ansätze (die sich selbstverständlich mit seinem bisherigen Ansatz kein bisschen verwirklichen lassen) gibt es bereits.

Ich wäre dir sehr dankbar, wenn ich die Links dazu kriegen könnte, interessiert mich wirklich sehr, wie ich meinen Ansatz verbessern kann.
Zitat:

Das dumme ist ja, wie beschränkt so ein XML-Dokument wäre.

Dann schlag mir eine bessere Struktur für das XML-Dokument vor.
Ich habe den Thread schließlich deshalb eröffnet, weil ich Kritik und Vorschläge hören wollte, und wenn du mir gleich einen praktischen Vorschlag liefern kannst, dann hätte ich mein Ziel immerhin schon teilweise erreicht Smile

	TheShadow Moderator	Di, Okt 02, 2007 20:52 Antworten mit Zitat
Zitat: Danke, schön zu wissen. Besonders deshalb, weil ich monatelang fast alle auf mich zukommenden Probleme schon analysiert und mir überlegt habe, wie man sie lösen kann. @basicprogger: glaub mir einfach - dein projekt ist nicht realisierbar... du kannst einen c++ artigen code nicht einfach nach xml und dann nach basic convertieren... es ist vergleichbar mit den sprachen. übersetze einen deutschen satz nach englisch und dann zurück - und es kommt nur schrott raus... ich glaube du hast dich nicht genug mit c++ und gar java beschäftigt... hm... an sich erinnert mich dein projekt an MONO - du nutzt aber xml statt binär-zwischencode - und statt JIT-Compiler einen normalen Compiler... und mit einem normalen compiler kriegst du irgendwann probleme... Bei MONO kann man mit mehreren Sprachen universelle Libs erzeugen und dann zusammenlinken - es gibt auch ein globales Framework... der Schlüssel bei MONO ist ein einziger JIT-Compiler (alle Quellsprachen wurden dafür ausgelegt) - was du nicht hast. Zitat: Der XML-Code soll nur der Speicherung von Metadaten dienen, wie z.B. Autor, Version, Libraries die man mitlinken muss etc. für die paar sachen würden neue keywords reichen - sinnlos sind die allemal (außer benötigte libs) Zitat: Man ist an die Syntax gebunden. Was wäre, wenn jemandem dein SUB foo:INT () oder dein cosole.writedouble nicht gefällt? Er würde sich nicht mehr dafür interessieren, denn schließlich ist es nur ein Wrapper für C++, in einer anderen Syntax. das mit syntax stimmt - das mit wrapper nicht Die Vorgehensweise von mir wäre anders als hier: http://www.blitzprog.de/quickupload/Diagramm1.png Das Framework wäre auch Basic-Code - das ebenfalls nach c++ konvertiert wird. Dann werden die c++ codes kompiliert und evtl. mit anderen libs autom. gelinkt Zitat: Metadaten, ToDo's, Bookmarks usw. bleiben weiterhin eine proprietäre Erweiterung, wenn sie denn überhaupt implementiert werden solche sachen gehören nicht in den code - sondern sache der IDE und co Hmmmm... wenn ich so überlege... GCC bzw MinGW (win32) unterstützen bereits viele Sprachen... Zitat: Frontends vary internally, having to produce trees that can be handled by the backend. The parsers are hand-coded recursive descent parsers. Until recently, the tree representation of the program was not fully independent of the processor being targeted. Confusingly, the meaning of a tree was somewhat different for different language front-ends, and front-ends could provide their own tree codes. In 2005, two new forms of language-independent trees were introduced. These new tree formats are called GENERIC and GIMPLE. Parsing is now done by creating temporary language-dependent trees, and converting them to GENERIC. The so-called "gimplifier" then lowers this more complex form into the simpler SSA-based GIMPLE form which is the common language for a large number of new powerful language- and architecture-independent global (function scope) optimizations. nach dem text können die GCC-Sprachen einen universellen GENERIC-Codebaum generieren. So wie ich verstehe könnte man auch so jetzt mehrere Sprachen nutzen um ein programm zu schreiben. Das ist wiederum um Welten einfacher als wie du es machen willst (doppel-crosscompiler).
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Di, Okt 02, 2007 20:52
Antworten mit Zitat

Zitat:

Danke, schön zu wissen. Besonders deshalb, weil ich monatelang fast alle auf mich zukommenden Probleme schon analysiert und mir überlegt habe, wie man sie lösen kann.

@basicprogger: glaub mir einfach - dein projekt ist nicht realisierbar...

du kannst einen c++ artigen code nicht einfach nach xml und dann nach basic convertieren... es ist vergleichbar mit den sprachen. übersetze einen deutschen satz nach englisch und dann zurück - und es kommt nur schrott raus...

ich glaube du hast dich nicht genug mit c++ und gar java beschäftigt...

hm... an sich erinnert mich dein projekt an MONO - du nutzt aber xml statt binär-zwischencode - und statt JIT-Compiler einen normalen Compiler... und mit einem normalen compiler kriegst du irgendwann probleme... Bei MONO kann man mit mehreren Sprachen universelle Libs erzeugen und dann zusammenlinken - es gibt auch ein globales Framework... der Schlüssel bei MONO ist ein einziger JIT-Compiler (alle Quellsprachen wurden dafür ausgelegt) - was du nicht hast.

Zitat:

Der XML-Code soll nur der Speicherung von Metadaten dienen, wie z.B. Autor, Version, Libraries die man mitlinken muss etc.

für die paar sachen würden neue keywords reichen - sinnlos sind die allemal (außer benötigte libs)

Zitat:

Man ist an die Syntax gebunden. Was wäre, wenn jemandem dein SUB foo:INT () oder dein cosole.writedouble nicht gefällt? Er würde sich nicht mehr dafür interessieren, denn schließlich ist es nur ein Wrapper für C++, in einer anderen Syntax.

das mit syntax stimmt - das mit wrapper nicht

Die Vorgehensweise von mir wäre anders als hier:
http://www.blitzprog.de/quickupload/Diagramm1.png

Das Framework wäre auch Basic-Code - das ebenfalls nach c++ konvertiert wird. Dann werden die c++ codes kompiliert und evtl. mit anderen libs autom. gelinkt

Zitat:

Metadaten, ToDo's, Bookmarks usw. bleiben weiterhin eine proprietäre Erweiterung, wenn sie denn überhaupt implementiert werden

solche sachen gehören nicht in den code - sondern sache der IDE und co

Hmmmm... wenn ich so überlege... GCC bzw MinGW (win32) unterstützen bereits viele Sprachen...

Zitat:

Frontends vary internally, having to produce trees that can be handled by the backend. The parsers are hand-coded recursive descent parsers.

Until recently, the tree representation of the program was not fully independent of the processor being targeted. Confusingly, the meaning of a tree was somewhat different for different language front-ends, and front-ends could provide their own tree codes.

In 2005, two new forms of language-independent trees were introduced. These new tree formats are called GENERIC and GIMPLE. Parsing is now done by creating temporary language-dependent trees, and converting them to GENERIC. The so-called "gimplifier" then lowers this more complex form into the simpler SSA-based GIMPLE form which is the common language for a large number of new powerful language- and architecture-independent global (function scope) optimizations.

nach dem text können die GCC-Sprachen einen universellen GENERIC-Codebaum generieren. So wie ich verstehe könnte man auch so jetzt mehrere Sprachen nutzen um ein programm zu schreiben. Das ist wiederum um Welten einfacher als wie du es machen willst (doppel-crosscompiler).

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	E. Urbach ehemals "Basicprogger"	Mi, Okt 03, 2007 9:25 Antworten mit Zitat
TheShadow hat Folgendes geschrieben: du kannst einen c++ artigen code nicht einfach nach xml und dann nach basic convertieren... es ist vergleichbar mit den sprachen. übersetze einen deutschen satz nach englisch und dann zurück - und es kommt nur schrott raus... Basicprogger hat Folgendes geschrieben: [...] wobei der Export ein nicht umkehrbarer Transfer ist (zumindest nicht ohne größere Workarounds). Wie du siehst, gibt es kein zurück, daher ist auch in meinem Diagramm kein Pfeil in diese Richtung zu sehen. Die einzige Möglichkeit ist die, den Importer zu benutzen. Er soll nur eine grobe Umwandlung vornehmen. TheShadow hat Folgendes geschrieben: hm... an sich erinnert mich dein projekt an MONO - du nutzt aber xml statt binär-zwischencode - und statt JIT-Compiler einen normalen Compiler... und mit einem normalen compiler kriegst du irgendwann probleme... Bei MONO kann man mit mehreren Sprachen universelle Libs erzeugen und dann zusammenlinken - es gibt auch ein globales Framework... der Schlüssel bei MONO ist ein einziger JIT-Compiler (alle Quellsprachen wurden dafür ausgelegt) - was du nicht hast. Basicprogger hat Folgendes geschrieben: Die Programmiersprachen werden nicht wirklich als solche angesehen. Es geht nur um die Syntax. Ihr werdet beim Programmieren mit C++ kein cout finden, auch keinen std-namespace, sondern nur die C++ Syntax. Das cout könnt ihr nur beim C++ Importer verwenden, wenn ihr einen vorhandenen Code importieren wollt. Beziehungsweise beim Exporter, dessen Code nicht erneut importierbar ist, was du ja schon mit deinem Sprachenbeispiel Deutsch/Englisch und zurück gezeigt hast. Zitat: ich glaube du hast dich nicht genug mit c++ und gar java beschäftigt... Ansichtssache. Zitat: für die paar sachen würden neue keywords reichen - sinnlos sind die allemal (außer benötigte libs) solche sachen gehören nicht in den code - sondern sache der IDE und co Nein, denn das Projekt ist speziell für wiederverwendbare Komponenten und Module gedacht, bei denen es nunmal ein Rolle spielt, in welcher Version eine Datei, zum Beispiel eine 3D-Vektor-Klasse, vorliegt. Datei = Modul in diesem Sinne. Metadaten gehören nicht in den Code - wie du schon gesagt hast -, sind aber auch nicht Sache der IDEs. Sie sind - wie es sowohl Windows als auch Linux tun - Teile der Datei bzw. des Dateiheaders. Da aber dieser Dateiheader bei den verschiedenen Betriebssystem nicht portabel bzw. austauschbar ist, habe ich mich entschieden - aus Gründen der Einfachheit und der Portabilität - einen Dateiheader mit allen benötigten Informationen einzufügen. Zitat: glaub mir einfach - dein projekt ist nicht realisierbar... Wie sich herausgestellt hat, hast du mir unterstellt, ein Feature entwickeln zu wollen, welches in der Tat nicht realisierbar wäre. Da ich aber keineswegs einen Importer für die exportierten Daten erstellen wollte, musst du deine Aussage nun anhand von anderen Kriterien beweisen. Ich würde mich sogar freuen, wenn du es beweisen könntest (nein wirklich, ist mein voller Ernst), denn das würde mir meine (möglicherweise) vergeudete Zeit ersparen. Doch im Moment sehe ich leider keine Möglichkeit, wie du beweisen könntest, dass dieses Projekt nicht realisierbar ist... Ich schlage vor, dass wir die Diskussion an diesem Punkt abbrechen. Da von mehreren Seiten behauptet wurde, dies sei nicht umsetzbar, liegt es jetzt an mir, das Gegenteil zu beweisen. Und das werde ich nicht mit Wortgefechten erreichen können, sondern nur durch fertige Demoversionen, die jedermann testen kann.
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Mi, Okt 03, 2007 9:25
Antworten mit Zitat

TheShadow hat Folgendes geschrieben:

du kannst einen c++ artigen code nicht einfach nach xml und dann nach basic convertieren... es ist vergleichbar mit den sprachen. übersetze einen deutschen satz nach englisch und dann zurück - und es kommt nur schrott raus...

Basicprogger hat Folgendes geschrieben:

[...] wobei der Export ein nicht umkehrbarer Transfer ist (zumindest nicht ohne größere Workarounds).

Wie du siehst, gibt es kein zurück, daher ist auch in meinem Diagramm kein Pfeil in diese Richtung zu sehen. Die einzige Möglichkeit ist die, den Importer zu benutzen. Er soll nur eine grobe Umwandlung vornehmen.

TheShadow hat Folgendes geschrieben:

hm... an sich erinnert mich dein projekt an MONO - du nutzt aber xml statt binär-zwischencode - und statt JIT-Compiler einen normalen Compiler... und mit einem normalen compiler kriegst du irgendwann probleme... Bei MONO kann man mit mehreren Sprachen universelle Libs erzeugen und dann zusammenlinken - es gibt auch ein globales Framework... der Schlüssel bei MONO ist ein einziger JIT-Compiler (alle Quellsprachen wurden dafür ausgelegt) - was du nicht hast.

Basicprogger hat Folgendes geschrieben:

Beziehungsweise beim Exporter, dessen Code nicht erneut importierbar ist, was du ja schon mit deinem Sprachenbeispiel Deutsch/Englisch und zurück gezeigt hast.

Zitat:

ich glaube du hast dich nicht genug mit c++ und gar java beschäftigt...

Ansichtssache.

Zitat:

für die paar sachen würden neue keywords reichen - sinnlos sind die allemal (außer benötigte libs)

solche sachen gehören nicht in den code - sondern sache der IDE und co

Nein, denn das Projekt ist speziell für wiederverwendbare Komponenten und Module gedacht, bei denen es nunmal ein Rolle spielt, in welcher Version eine Datei, zum Beispiel eine 3D-Vektor-Klasse, vorliegt. Datei = Modul in diesem Sinne. Metadaten gehören nicht in den Code - wie du schon gesagt hast -, sind aber auch nicht Sache der IDEs. Sie sind - wie es sowohl Windows als auch Linux tun - Teile der Datei bzw. des Dateiheaders. Da aber dieser Dateiheader bei den verschiedenen Betriebssystem nicht portabel bzw. austauschbar ist, habe ich mich entschieden - aus Gründen der Einfachheit und der Portabilität - einen Dateiheader mit allen benötigten Informationen einzufügen.

Zitat:

glaub mir einfach - dein projekt ist nicht realisierbar...

Wie sich herausgestellt hat, hast du mir unterstellt, ein Feature entwickeln zu wollen, welches in der Tat nicht realisierbar wäre. Da ich aber keineswegs einen Importer für die exportierten Daten erstellen wollte, musst du deine Aussage nun anhand von anderen Kriterien beweisen. Ich würde mich sogar freuen, wenn du es beweisen könntest (nein wirklich, ist mein voller Ernst), denn das würde mir meine (möglicherweise) vergeudete Zeit ersparen. Doch im Moment sehe ich leider keine Möglichkeit, wie du beweisen könntest, dass dieses Projekt nicht realisierbar ist...

Ich schlage vor, dass wir die Diskussion an diesem Punkt abbrechen. Da von mehreren Seiten behauptet wurde, dies sei nicht umsetzbar, liegt es jetzt an mir, das Gegenteil zu beweisen. Und das werde ich nicht mit Wortgefechten erreichen können, sondern nur durch fertige Demoversionen, die jedermann testen kann.

	pixelshooter	Mi, Okt 03, 2007 11:52 Antworten mit Zitat
Basicprogger hat Folgendes geschrieben: Zitat: für die paar sachen würden neue keywords reichen - sinnlos sind die allemal (außer benötigte libs)solche sachen gehören nicht in den code - sondern sache der IDE und co Nein, denn das Projekt ist speziell für wiederverwendbare Komponenten und Module gedacht, bei denen es nunmal ein Rolle spielt, in welcher Version eine Datei, zum Beispiel eine 3D-Vektor-Klasse, vorliegt. Datei = Modul in diesem Sinne. Metadaten gehören nicht in den Code - wie du schon gesagt hast -, sind aber auch nicht Sache der IDEs. Sie sind - wie es sowohl Windows als auch Linux tun - Teile der Datei bzw. des Dateiheaders. Da aber dieser Dateiheader bei den verschiedenen Betriebssystem nicht portabel bzw. austauschbar ist, habe ich mich entschieden - aus Gründen der Einfachheit und der Portabilität - einen Dateiheader mit allen benötigten Informationen einzufügen. Wird denn heute auf eigentlich nicht dorthingehörige angaben im Programmtext verzichtet? Wie ist das mit Dokumentationsblöcken? #pragma anweisungen? Ich halte das projekt für durchaus realisierbar - wenn man weiß, was man abbilden will. Dass nicht alle features in jede sprache verpackt werden können ist klar - dafür gibts wrapper. Eine solche Metasprache würe das wrapping sehr vereinfachen, weil parser von wrapper getrennt würde.
>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

pixelshooter

Mi, Okt 03, 2007 11:52
Antworten mit Zitat

Basicprogger hat Folgendes geschrieben:

Zitat:

für die paar sachen würden neue keywords reichen - sinnlos sind die allemal (außer benötigte libs)solche sachen gehören nicht in den code - sondern sache der IDE und co

Wird denn heute auf eigentlich nicht dorthingehörige angaben im Programmtext verzichtet? Wie ist das mit Dokumentationsblöcken? #pragma anweisungen?

Ich halte das projekt für durchaus realisierbar - wenn man weiß, was man abbilden will. Dass nicht alle features in jede sprache verpackt werden können ist klar - dafür gibts wrapper. Eine solche Metasprache würe das wrapping sehr vereinfachen, weil parser von wrapper getrennt würde.

>> Musikerstellung, Grafik und Design: http://www.pixelshooter.net.tc

	TheShadow Moderator	Mi, Okt 03, 2007 12:29 Antworten mit Zitat
Du fragtest selbst ob dein Projekt sinnvoll ist... da du dir nicht sicher bist... Ich bin der meinung es ist nicht sinnvoll... naja es ist meine Meinung. Wenn du meist du schaffst es, dann kannst du loslegen. Zitat: Wie du siehst, gibt es kein zurück, daher ist auch in meinem Diagramm kein Pfeil in diese Richtung zu sehen. Die einzige Möglichkeit ist die, den Importer zu benutzen. Er soll nur eine grobe Umwandlung vornehmen. Dein Diagramm ist dann falsch - ich sehe wohl den Weg zurück... (von xml nach basic, c++ und java)... wobei ich wie gesagt keinen Sinn sehe...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Mi, Okt 03, 2007 12:29
Antworten mit Zitat

Du fragtest selbst ob dein Projekt sinnvoll ist... da du dir nicht sicher bist... Ich bin der meinung es ist nicht sinnvoll... naja es ist meine Meinung. Wenn du meist du schaffst es, dann kannst du loslegen.

Zitat:

Dein Diagramm ist dann falsch - ich sehe wohl den Weg zurück... (von xml nach basic, c++ und java)...
wobei ich wie gesagt keinen Sinn sehe...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	E. Urbach ehemals "Basicprogger"	Mi, Okt 03, 2007 12:53 Antworten mit Zitat
Zitat: Du fragtest selbst ob dein Projekt sinnvoll ist... da du dir nicht sicher bist... Ich bin der meinung es ist nicht sinnvoll... naja es ist meine Meinung. Wenn du meist du schaffst es, dann kannst du loslegen. Ich bin dir auch sehr dankbar dafür, dass du deine Meinung hier präsentiert hast. Bloß, das klingt für mich wie "Soll der Idiot doch sein Programm anfangen und dann selber feststellen, dass es nicht möglich ist". Na gut, wenn ich dann am Punkt angelangt bin, wo ich merke, dass du doch Recht hattest, werde ich es hier bekanntgeben. Immerhin kann ich so etwas Erfahrung sammeln, sowohl auf die eine als auch auf die andere Weise Zitat: Dein Diagramm ist dann falsch - ich sehe wohl den Weg zurück... (von xml nach basic, c++ und java)... wobei ich wie gesagt keinen Sinn sehe... Oh, tut mir leid, da liegt ein Missverständnis vor, hier ist die korrigierte Version: Dazu noch diese interessanten Wikipediasites: http://de.wikipedia.org/wiki/G...rammierung http://de.wikipedia.org/wiki/M...chitecture Und hier ist der Artikel "Software-Lego gehört die Zukunft", von dem ich anfangs sprach: http://www.computerwoche.de/it...ws/584445/
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Mi, Okt 03, 2007 12:53
Antworten mit Zitat

Zitat:

Ich bin dir auch sehr dankbar dafür, dass du deine Meinung hier präsentiert hast.
Bloß, das klingt für mich wie "Soll der Idiot doch sein Programm anfangen und dann selber feststellen, dass es nicht möglich ist". Na gut, wenn ich dann am Punkt angelangt bin, wo ich merke, dass du doch Recht hattest, werde ich es hier bekanntgeben. Immerhin kann ich so etwas Erfahrung sammeln, sowohl auf die eine als auch auf die andere Weise Wink

Zitat:

Dein Diagramm ist dann falsch - ich sehe wohl den Weg zurück... (von xml nach basic, c++ und java)...
wobei ich wie gesagt keinen Sinn sehe...

Oh, tut mir leid, da liegt ein Missverständnis vor, hier ist die korrigierte Version:

user posted image

Dazu noch diese interessanten Wikipediasites:
http://de.wikipedia.org/wiki/G...rammierung
http://de.wikipedia.org/wiki/M...chitecture

Und hier ist der Artikel "Software-Lego gehört die Zukunft", von dem ich anfangs sprach:
http://www.computerwoche.de/it...ws/584445/

	TheShadow Moderator	Mi, Okt 03, 2007 14:01 Antworten mit Zitat
Zitat: Bloß, das klingt für mich wie "Soll der Idiot doch sein Programm anfangen und dann selber feststellen, dass es nicht möglich ist". es ist aus 2 Gründen nicht möglich 1) es ist extrem anspruchsvoll, weil... 2) die Sprachen sind zu unterschiedlich Beispiel: während Java einen GarbageCollector hat . Hat c++ es nicht. Während C++ dafür Pointer hat - hat Java das nicht. Deswegen kann man meist den Code nicht mal per hand sauber portieren.. Dein Ziel ist es den Code von Sprache X zu nehmen und dann autom. Code für Sprache Y zu generieren - Das geht nicht gut. Anders würde es aussehen, wenn du eigene Sprache erfindest die in Summe das minimalste aller Ausgabe-Sprachen können soll - dann geht es So war meine Idee mit Basic-artigen Konverter... jedoch hätte ich nur C++ als Output. Auserdem wäre die Sprache geradezu für C++-Ausgabe ausgelegt...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Mi, Okt 03, 2007 14:01
Antworten mit Zitat

Zitat:

Bloß, das klingt für mich wie "Soll der Idiot doch sein Programm anfangen und dann selber feststellen, dass es nicht möglich ist".

es ist aus 2 Gründen nicht möglich
1) es ist extrem anspruchsvoll, weil...
2) die Sprachen sind zu unterschiedlich

Beispiel: während Java einen GarbageCollector hat . Hat c++ es nicht.
Während C++ dafür Pointer hat - hat Java das nicht.
Deswegen kann man meist den Code nicht mal per hand sauber portieren..

Dein Ziel ist es den Code von Sprache X zu nehmen und dann autom. Code für Sprache Y zu generieren - Das geht nicht gut.

Anders würde es aussehen, wenn du eigene Sprache erfindest die in Summe das minimalste aller Ausgabe-Sprachen können soll - dann geht es

So war meine Idee mit Basic-artigen Konverter... jedoch hätte ich nur C++ als Output. Auserdem wäre die Sprache geradezu für C++-Ausgabe ausgelegt...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	E. Urbach ehemals "Basicprogger"	Mi, Okt 03, 2007 14:24 Antworten mit Zitat
Wie du willst, dann werde ich BASIC-Input und C++ Output als Standard nehmen und mich darauf konzentrieren. Der Parser hat jedoch bereits jetzt die Möglichkeit, das Ausgabeformat zu wechseln, so dass man - wenn man möchte - den Code doch noch in eine andere Sprache bzw. in ein anderes benutzerdefiniertes Format umwandeln kann. Dass es die Möglichkeit gibt, heißt ja nicht, dass man es implementieren bzw. benutzen muss Vielen Dank für alle Kritiken und Vorschläge, ich denke ich werde mit den minimalen Anforderungen anfangen, also TheShadow's besagtes "Basic2C++". Wenn alles gut läuft, dann kann ich die Software ja immer noch erweitern
The box said, "Requires Windows XP or better", so I installed Ubuntu \| Linux is NOT Windows Flua :: Profiler für BB und BMax :: Partikel-Engine für BMax :: Lyphia-Projekt Quellcode (BMax) :: Automatische Parallelisierung :: Meine Musik

E. Urbach

ehemals "Basicprogger"

Mi, Okt 03, 2007 14:24
Antworten mit Zitat

Wie du willst, dann werde ich BASIC-Input und C++ Output als Standard nehmen und mich darauf konzentrieren. Der Parser hat jedoch bereits jetzt die Möglichkeit, das Ausgabeformat zu wechseln, so dass man - wenn man möchte - den Code doch noch in eine andere Sprache bzw. in ein anderes benutzerdefiniertes Format umwandeln kann. Dass es die Möglichkeit gibt, heißt ja nicht, dass man es implementieren bzw. benutzen muss Smile

Vielen Dank für alle Kritiken und Vorschläge, ich denke ich werde mit den minimalen Anforderungen anfangen, also TheShadow's besagtes "Basic2C++". Wenn alles gut läuft, dann kann ich die Software ja immer noch erweitern Wink

	T-Moe	Do, Okt 04, 2007 3:21 Antworten mit Zitat
Das ist zwar ein bisschen aus der Luft gegriffen, aber ich hab mir etwas wegen deinem Problem mit <add /> usw. ueberlegt. Du solltest einfach <result of="12+24/13-(12*12)" /> oder so verwenden.

T-Moe

Do, Okt 04, 2007 3:21
Antworten mit Zitat

Das ist zwar ein bisschen aus der Luft gegriffen, aber ich hab mir etwas wegen deinem Problem mit <add /> usw. ueberlegt. Du solltest einfach

<result of="12+24/13-(12*12)" />

oder so verwenden.

	stfighter01	Do, Okt 04, 2007 13:18 Antworten mit Zitat
Du versuchst also so eine Art-Metakonverter für Sprachen zu basteln. Sinnvoller ist aber sicher das DotNet od. Javakonzept welches aus Programmcode ByteCode erzeugt welcher von entsprechenden VMs interpretiert werden kann. Einfacher wäre sicher ein entsprechender Blitz, Eiffel, Brainfuck-Compiler od. ä. welcher ByteCode für eines der vielen FrameWorks ausspuckt. In DotNet kannst du C++ / J++ / VB Programmieren und es kommt immer das selbe raus -> Durch die grosse Ähnlichkeit und die Möglichkeit auf die Gleichen Libs zuzugreifen ist meines wissens sogar Konvertierung zwischen den Sprachen möglich. Ich schliesse mich wohl TheShadow an wenn ich sage das so ein Projekt ob der (durchaus gewollten) Vielfalt der Programmiersprachen weder realisierbar noch sinnvoll ist.
Denken hilft!

stfighter01

Do, Okt 04, 2007 13:18
Antworten mit Zitat

Du versuchst also so eine Art-Metakonverter für Sprachen zu basteln.
Sinnvoller ist aber sicher das DotNet od. Javakonzept welches aus Programmcode ByteCode erzeugt welcher von entsprechenden VMs interpretiert werden kann.

Einfacher wäre sicher ein entsprechender Blitz, Eiffel, Brainfuck-Compiler od. ä. welcher ByteCode für eines der vielen FrameWorks ausspuckt.

In DotNet kannst du C++ / J++ / VB Programmieren und es kommt immer das selbe raus -> Durch die grosse Ähnlichkeit und die Möglichkeit auf die Gleichen Libs zuzugreifen ist meines wissens sogar Konvertierung zwischen den Sprachen möglich.

Ich schliesse mich wohl TheShadow an wenn ich sage das so ein Projekt ob der (durchaus gewollten) Vielfalt der Programmiersprachen weder realisierbar noch sinnvoll ist.

Denken hilft!

Gehe zu Seite Zurück 1, 2, 3 Weiter

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Konzept: Sinnvoll oder nicht?