Was stört/fehlt euch bei aktuellen Programmiersprachen?
-
Keiner kommt auf die Idee Bytecode mit zu spezifizieren
-
Zeus schrieb:
Keiner kommt auf die Idee Bytecode mit zu spezifizieren
Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.
-
Kellerautomat schrieb:
Zeus schrieb:
Keiner kommt auf die Idee Bytecode mit zu spezifizieren
Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.
So hab ich nicht gemeint, ich will den Bytecode nicht als Executor auf Anwenderseite haben sondern als Exchanger auf Entwicklerseite.
-
Zeus schrieb:
Kellerautomat schrieb:
Zeus schrieb:
Keiner kommt auf die Idee Bytecode mit zu spezifizieren
Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.
So hab ich nicht gemeint, ich will den Bytecode nicht als Executor auf Anwenderseite haben sondern als Exchanger auf Entwicklerseite.
Was?
-
Kellerautomat schrieb:
Zeus schrieb:
Kellerautomat schrieb:
Zeus schrieb:
Keiner kommt auf die Idee Bytecode mit zu spezifizieren
Liegt vlt daran, dass unsere Sprachen nativ laufen sollen.
So hab ich nicht gemeint, ich will den Bytecode nicht als Executor auf Anwenderseite haben sondern als Exchanger auf Entwicklerseite.
Was?
Wenn du eine Library in C++ schreibst, dann kannst du diese nicht gut weiter geben. Du brauchst precompiled Versionen für alle möglichen Plattformen und unterschiedliche Objekt Formate, etc. Und wenn du Templates hast, ist eh hopfen und malz verloren.
Hier wäre ein Bytecode interessant. Ich kompiliere meine Library in den Bytecode und gebe sie dir. Und ob du diese nun auf Linux oder Windows auf 16 bit oder 128bit Architekturen verwendest ist egal - der Bytecode hat alle notwendigen Infos ohne aber dass er der offene Source Code ist.
-
Sucht ihr immer Sachen, die es schon gibt? Gib doch einfach GIMPLE weiter
-
Was mich bei derzeitigen Programmiersprachen stört?
- Viele Programmiersprachen unterstützen noch globale Variablen, dabei werden diese heutzutage nicht mehr verwendet, weil sie unschöne Effekte produzieren.
Wesentlich schöner wäre es nativ Konstrukte bereitzustellen, welche die Möglichkeit bieten über mehrere Funktionen Variablen zu verteilen (die nicht immer als Parameterlisten übergeben werden müssen) und auch entsprechende Methoden/Operatoren zur Verfügung stellen, um den Lese-/Schreibzugriff zu regeln.- Anhand von Python finde ich es sehr schön den Benutzer anhand von Syntax zur Codestrukturierung zu bringen. Nichts ist grausamer als nicht eingerückten und geordneten Code lesen zu müssen. Zusätzlich gefällt mir die native Unterstützung von Dictionaries.
Als Fazit muss ich daher sagen, Python bietet schon recht vieles was ich mir an einer Programmiersprache wünsche. Jedoch habe ich für meinen ersten Punkt bisher in Python noch keine Möglichkeit dafür gefunden, muss jedoch auch zugegeben mich nicht mehr intensiv mit Python zu beschäftigen, da mein momentaer Fokus auf ANSI-C liegt und ich acuh wie der Thread-Ersteller und einige andere hier an einer eigenen Sprache mit Compiler arbeite. Diese Sprache ist jedoch sehr sehr rudimentär - PL0, falls jemandem dies etwas sagt. Geplant ist ab einem bestimmten Zeitpunkt geeignete Operationen für globale Variablen bereitzustellen um diese zu "Semi-Globalisieren".
-
Nirvash schrieb:
Was mich bei derzeitigen Programmiersprachen stört?
- Viele Programmiersprachen unterstützen noch globale Variablen, dabei werden diese heutzutage nicht mehr verwendet, weil sie unschöne Effekte produzieren.
Wesentlich schöner wäre es nativ Konstrukte bereitzustellen, welche die Möglichkeit bieten über mehrere Funktionen Variablen zu verteilen (die nicht immer als Parameterlisten übergeben werden müssen) und auch entsprechende Methoden/Operatoren zur Verfügung stellen, um den Lese-/Schreibzugriff zu regeln.Du meinst Objekte?
-
otze schrieb:
Du meinst Objekte?
Oder Module.
-
otze schrieb:
Du meinst Objekte?
Im Prinzip ja, aber mit der grammatikalischen Einschränkung, dass außerhalb der main-Methode kein globaler Datentyp deklariert werden kann.
-
Shade Of Mine schrieb:
Wenn du eine Library in C++ schreibst, dann kannst du diese nicht gut weiter geben. Du brauchst precompiled Versionen für alle möglichen Plattformen und unterschiedliche Objekt Formate, etc. Und wenn du Templates hast, ist eh hopfen und malz verloren.
Hier wäre ein Bytecode interessant. Ich kompiliere meine Library in den Bytecode und gebe sie dir. Und ob du diese nun auf Linux oder Windows auf 16 bit oder 128bit Architekturen verwendest ist egal - der Bytecode hat alle notwendigen Infos ohne aber dass er der offene Source Code ist.
Nur, damit ich das richtig verstehe: Als Library-Entwickler kann ich dann meine Lib zu Bytecode kompilieren. Diesen Bytecode gebe ich an andere Entwickler weiter, sie kompilieren ihr Programm mit dem Bytecode meiner Lib zu Maschinencode?
Nirvash schrieb:
- Viele Programmiersprachen unterstützen noch globale Variablen, dabei werden diese heutzutage nicht mehr verwendet, weil sie unschöne Effekte produzieren.
Wesentlich schöner wäre es nativ Konstrukte bereitzustellen, welche die Möglichkeit bieten über mehrere Funktionen Variablen zu verteilen (die nicht immer als Parameterlisten übergeben werden müssen) und auch entsprechende Methoden/Operatoren zur Verfügung stellen, um den Lese-/Schreibzugriff zu regeln.Ich bin der Meinunung, dass das Problem nicht globale Variablen sind. Das Problem ist, dass sie "zu global" sind. Globaler State ist teilweise einfach nötig, für z.B. Logger, stdin/stdout, Mutexe, etc.
Das Problem ist, dass er nicht richtig enkapsuliert ist. Man sollte auf keine Variablen über Modulgrenzen hinweg zugreifen können, die sind ein Implementierungsdetail des Moduls.Nirvash schrieb:
- Anhand von Python finde ich es sehr schön den Benutzer anhand von Syntax zur Codestrukturierung zu bringen. Nichts ist grausamer als nicht eingerückten und geordneten Code lesen zu müssen. Zusätzlich gefällt mir die native Unterstützung von Dictionaries.
Gezwungene Einrückung finde ich unschön, sorry. Dictionaries gehören nicht in den Sprachkern. Es gibt viele verschiedene Möglichkeiten, wie man sie implementieren kann. Bäume, Hashtabellen, sortierte Arrays. Und bei allen gibt es noch Varianten, die sich in den Details unterscheiden. Je nach Situation kann eine andere Datenstruktur angemessen sein.
Mit überladbaren Typ-Konstruktoren und Klammern könnte man sich solche Syntax einfach selbst definieren. An diesen Features arbeite ich gerade.
-
enkapsuliert
Wort des Jahres.
-
Kellerautomat schrieb:
Shade Of Mine schrieb:
Wenn du eine Library in C++ schreibst, dann kannst du diese nicht gut weiter geben. Du brauchst precompiled Versionen für alle möglichen Plattformen und unterschiedliche Objekt Formate, etc. Und wenn du Templates hast, ist eh hopfen und malz verloren.
Hier wäre ein Bytecode interessant. Ich kompiliere meine Library in den Bytecode und gebe sie dir. Und ob du diese nun auf Linux oder Windows auf 16 bit oder 128bit Architekturen verwendest ist egal - der Bytecode hat alle notwendigen Infos ohne aber dass er der offene Source Code ist.
Nur, damit ich das richtig verstehe: Als Library-Entwickler kann ich dann meine Lib zu Bytecode kompilieren. Diesen Bytecode gebe ich an andere Entwickler weiter, sie kompilieren ihr Programm mit dem Bytecode meiner Lib zu Maschinencode?
Ja. Für OpenSource ist das irrelevant da du ja den Code hergeben kannst. Es ist aber enorm kompliziert in C++ Closed Source Libraries zu haben. Ein Bytecode würde das Problem lösen.
Weiters kann man dann den Schritt weiter gehen und sagen: ich biete mein Programm als Bytecode an. Alles was du dann brauchst ist der Bytecode compiler und kannst dir zB für deine Linux Distribution mein Programm aus den Sourcen bauen, ohne dass ich dir Zugriff auf meine Sourcen geben muss. Dennoch kannst du deine libc linken und dein openssl verwenden, etc.
-
Interessante Idee. Klingt aber ziemlich schwer, das einerseits so zu machen, dass der Bytecode plattformunabhängig bleibt und gleichzeitig nicht zu viel vom Originalcode übrig bleibt, um den Bytecode einfach dekompilieren zu können.
-
Kellerautomat schrieb:
Interessante Idee. Klingt aber ziemlich schwer, das einerseits so zu machen, dass der Bytecode plattformunabhängig bleibt und gleichzeitig nicht zu viel vom Originalcode übrig bleibt, um den Bytecode einfach dekompilieren zu können.
Bitte keinen Bytecode, sonst fangen die ersten an, irgendeinen JIT-Compiler oder Interpreter zu bauen, und dann haben wir Java 2.0, wo doch Java 1.0 schon keiner braucht.
-
Außerdem bedeutet ein plattformunabhängiger Bytecode, dass es plattformübergreifenden Viren gibt.
Das brauche nich nicht, die ganzen Viren sollen doch bitte bei Windows bleiben.
-
Kellerautomat schrieb:
Interessante Idee. Klingt aber ziemlich schwer, das einerseits so zu machen, dass der Bytecode plattformunabhängig bleibt und gleichzeitig nicht zu viel vom Originalcode übrig bleibt, um den Bytecode einfach dekompilieren zu können.
Ja. Deshalb gibt es das auch noch nicht so wirklich. Der GCC hat sowas ähnliches (GIMPLE) weil die das ja eh brauchen um die unterschiedlichen Backends und Frontends miteinander zu verknüpfen.
Aber es ist tricky - keine Frage. aber es wäre richtig toll
-
hobbymarxist schrieb:
Bitte keinen Bytecode, sonst fangen die ersten an, irgendeinen JIT-Compiler oder Interpreter zu bauen, und dann haben wir Java 2.0, wo doch Java 1.0 schon keiner braucht.
Ich muss aber zugeben, ich finde die Idee einer VM mit JIT-Compiler grundsätzlich gut. Das Problem ist halt leider die Performance. Hat denn schon mal jemand versucht, C++ oder eine andere non-GC Sprache in Bytecode zu kompilieren und in einer VM laufen zu lassen?
hobbymarxist schrieb:
Außerdem bedeutet ein plattformunabhängiger Bytecode, dass es plattformübergreifenden Viren gibt.
Das brauche nich nicht, die ganzen Viren sollen doch bitte bei Windows bleiben.
Wenn jemals jemand Viren in meiner Sprache Sprache schreiben sollte, wäre das eine Ehre für mich. Dann werde ich auch darüber nachdenken.
-
C++ oder eine andere non-GC Sprache in Bytecode zu kompilieren und in einer VM laufen zu lassen?
Beispielsweise Forth. Und C sollte wohl auch nicht so schwer sein. Prinzipiell kann ja auch gleich nativer Code hergenommen werden und mittels VM wie blochs abgearbeitet werden.
-
Shade Of Mine schrieb:
Der GCC hat sowas ähnliches (GIMPLE) weil die das ja eh brauchen um die unterschiedlichen Backends und Frontends miteinander zu verknüpfen.
LVVM -- Low Level Virtual Machine macht genau das. clang benutzt das als Backend.