Es geht also nicht drum, mehrere tausend Befehle zu übersetzten, sondern eine Bibliothek zu haben, die auf allen Programmiersprachen gleichermaßen funktioniert.
Dass JAVA objektorientiert ist und PureBasic nicht, dass spielt keine Rolle, der Nutzer wird eine QuellCode-Datei haben, wie die hier gepostete, oder mit ganz anderem Code.
In PureBasic sieht das Ergebnis dann so aus. Wenn man ein Interface bereit stellt, welches ohne Programmiercode, sondern mit fertigen Bausteinen daher kommt, schränkt man zwar die Möglichkeiten ein, stellt aber gleichzeitig damit sicher, dass diese vorhandenen Befehle auf allen Systemen das gleiche Ergebnis liefern.
Der "Quell-Code" kann dann in JAVA, C# oder PureBasic ausgegeben werden und mit dem JDK oder dem PureBasic-Compiler lauffähig gemacht werden.
Klar sind die internen Befehle bei JAVA anders als bei PureBasic und die Frage ist auch, ob man nur in eine Richtung übersetzen kann oder in beide.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Wieso das Ganze? So kann man eine Art VisualDesigner / PureFORM für Fenster und Spiele nutzen, der dann Code ausgibt, den man beliebig erweitern kann.
Das Erweitern wäre dann für erfahrene Nutzer.
Und da kann dann auch gleich der Hinweis kommen, dass der Code nach individueller Veränderung eventuell nicht mehr SprachenConverter-Kompatibel ist.
Eine Art RISC-Sprache
Aber nicht Urschleim wie bei ASM, sondern halt weniger Befehle, die es leicht ermöglichen Spiele, GUIs und was es sonst noch gibt, zu erstellen.
Einen kleinen Aufwand wird die Übersetzung der StandardBefehle machen wie: Str(), Left(), Right(), ... (String-Operatoren)
und Sqrt(), Sin(), Cos() ...
Aber man muss ja am Anfang nicht gleich alles auf einmal können.
Es würde ja reichen wenn man * + / - richtig umsetzt und die Klammern.
Es soll als Einstieg in die Programmierung dienen und den "Kindern" bzw. den Neulingen keine Sprache vorschreiben. Und ihnen den Umstieg leichter machen. Und wenn man einmal Code geschrieben hat, finde ich es immer lästigt, wenn man diesen dann selbst umschreiben muss. Das demotiviert ja.
Mein Programm ist natürlich noch nicht perfekt und dass die Maus, die am Stift klebt unter dem großen Viereck verschwindet, ist Absicht, die Layertechnologie ist schon integriert, wie man sehen kann, wird nur der Stift ganz nach oben gesetzt.
Genauso das Clicken und Ziehen, zurzeit werden alle Ebenen gleichermaßen abgefragt. Dadurch passiert es, dass man mit einem Ziehen alle Teilchen zusammenschieben kann.
Das ist kein Bug, es ist im Moment nur nicht integriert, dass es anders berücksichtigt wird.
es ist nunmal Fakt, daß man auf sie angewiesen ist, sieht man ja schon bei PB (auch wenn sie da integriert ist). Ohne Lib kommt man einfach nicht weit.
