Was stört/fehlt euch bei aktuellen Programmiersprachen?
-
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.
-
Danke für die Hinweise auf LLVM und GIMPLE. Da ich sowieso fürs erste ein LLVM-Frontend schreiben wollte, werde ich mich damit so oder so beschäftigen müssen.
Auch danke für die ganzen Anregungen, Wünschen, Beschwerden - etc. Sollte noch jemand was in die Richtung für mich haben, nur zu
@Xin: Mich würde dann noch generell interessieren, wie deine Sprache vom codeild her aussieht. Könntest du ein kleines Beispiel zaubern? Mir ist schon klar, dass du nicht alle deine Ideen hergeben willst, aber es muss ja auch nicht alles sein, was deine Sprache kann
-
Kellerautomat@work schrieb:
@Xin: Mich würde dann noch generell interessieren, wie deine Sprache vom codeild her aussieht. Könntest du ein kleines Beispiel zaubern? Mir ist schon klar, dass du nicht alle deine Ideen hergeben willst, aber es muss ja auch nicht alles sein, was deine Sprache kann
Wirklich lauffähige, nennenswerte Algorithmen habe ich derzeit nicht im Angebot, aktuell bin erstmal aus der Proof Of Concept-Phase raus.
Ich hatte vor Jahren mal 'nen Quicksort laufen, dann vieles über den Haufen geworfen und bis letztes Jahr mich alleine mit dem +-Operator begnügt. Mehr war nicht erforderlich um mit Konzepten zu spielen. Die grundlegenden Operatoren habe ich erst seit ein paar Monaten wieder drin.Auf die Schnelle kann ich Dir nur ein paar Screenshots hochladen, die ich als Beispiel für die Anbindung an externe Libs gemacht habe. Ein wirkliches Bild für den Code vermittelt das in dem Sinne aber leider nicht.
-
Auch wenn man da jetzt nicht so viel sieht, hier ein paar Fragen dazu:
- Deine Syntax, um Funktionen zu deklarieren, hat ziemlich viele Tokens, die alle vermutlich nicht noetig waeren, damit es eindeutig geparst werden kann. Warum?
- Du hast das Keyword 'code' anstatt z.B. 'proc', 'function' o.ae. gewaehlt. Fuer mich ist eine Klasse z.b. aber auch Code. Warum gerade 'code'?
- Du kannst hier offenbar externe, native Funktionen direkt aufrufen, ohne einen Wrapper zu schreiben. Wie ist das implementiert? :p
Ansonsten hab ich eine Ablehnung gegenueber Konstrukten, die eine Programmiersprache einer natuerlichen Sprache aehnlich wirken lassen. Dazu gehoert deine 'x is T' Syntax. Das ist aber nur meine persoenliche Meinung.
-
Kellerautomat schrieb:
- Du hast das Keyword 'code' anstatt z.B. 'proc', 'function' o.ae. gewaehlt. Fuer mich ist eine Klasse z.b. aber auch Code. Warum gerade 'code'?
Code als Data Paradigma
Kellerautomat schrieb:
- Du kannst hier offenbar externe, native Funktionen direkt aufrufen, ohne einen Wrapper zu schreiben. Wie ist das implementiert? :p
libffi oder vergleichbare Implementierung sowie eigene.
-
code ist wahrscheinlich das gleiche wie Haskells ExitCode.
Was mich stört ist das "
is", das könnte man genauso gut weglassen oder zumindest durch ein ":" ersetzen, das macht den Code optisch etwas schöner.
-
Kellerautomat schrieb:
Auch wenn man da jetzt nicht so viel sieht, hier ein paar Fragen dazu:
[*]Deine Syntax, um Funktionen zu deklarieren, hat ziemlich viele Tokens, die alle vermutlich nicht noetig waeren, damit es eindeutig geparst werden kann. Warum?Weil ich auch etwas hin und her gerissen bin, ob in der Kürze die Würze liegt oder nicht. In dem Fall bin der Meinung, dass sich Funktionen genauso wie Variablen deklarieren lassen sollten.
Kellerautomat schrieb:
[*]Du hast das Keyword 'code' anstatt z.B. 'proc', 'function' o.ae. gewaehlt. Fuer mich ist eine Klasse z.b. aber auch Code. Warum gerade 'code'?
Eine Klasse ist kein Code, sondern eine Datenstruktur.
Klassen können aber mit Methoden verknüpft werden, was nichts anderes als code ist, die eine Referenz zu ihrer Klasseninstanz kennen.Kellerautomat schrieb:
[*]Du kannst hier offenbar externe, native Funktionen direkt aufrufen, ohne einen Wrapper zu schreiben. Wie ist das implementiert? :p
Beim Interpretieren derzeit mit libffi.
Kellerautomat schrieb:
Ansonsten hab ich eine Ablehnung gegenueber Konstrukten, die eine Programmiersprache einer natuerlichen Sprache aehnlich wirken lassen. Dazu gehoert deine 'x is T' Syntax. Das ist aber nur meine persoenliche Meinung.
Dem stimme ich zu. Mir gehen aber etwas die Operatoren aus und irgendwann muss man dann sich wieder Buchstaben behelfen. Und da ist 'is' wenigstens nachvollziehbar und kurz.
-
Xin schrieb:
Kellerautomat schrieb:
Auch wenn man da jetzt nicht so viel sieht, hier ein paar Fragen dazu:
[*]Deine Syntax, um Funktionen zu deklarieren, hat ziemlich viele Tokens, die alle vermutlich nicht noetig waeren, damit es eindeutig geparst werden kann. Warum?Weil ich auch etwas hin und her gerissen bin, ob in der Kürze die Würze liegt oder nicht. In dem Fall bin der Meinung, dass sich Funktionen genauso wie Variablen deklarieren lassen sollten.
Hihi, ich hab mich mit genau demselben Problem auseinandergesetzt. Man will das Codebild möglichst konsistent halten, aber dann wird der Code u.U. länger.
Ich hab mich zugunsten der Kürze entschieden.
Xin schrieb:
Kellerautomat schrieb:
[*]Du hast das Keyword 'code' anstatt z.B. 'proc', 'function' o.ae. gewaehlt. Fuer mich ist eine Klasse z.b. aber auch Code. Warum gerade 'code'?
Eine Klasse ist kein Code, sondern eine Datenstruktur.
Klassen können aber mit Methoden verknüpft werden, was nichts anderes als code ist, die eine Referenz zu ihrer Klasseninstanz kennen.Ah, wir reden also von zwei verschiedenen Arten von Code. Während du von ausführbarem Code sprichst, rede ich von Sourcecode.
Xin schrieb:
Kellerautomat schrieb:
Ansonsten hab ich eine Ablehnung gegenueber Konstrukten, die eine Programmiersprache einer natuerlichen Sprache aehnlich wirken lassen. Dazu gehoert deine 'x is T' Syntax. Das ist aber nur meine persoenliche Meinung.
Dem stimme ich zu. Mir gehen aber etwas die Operatoren aus und irgendwann muss man dann sich wieder Buchstaben behelfen. Und da ist 'is' wenigstens nachvollziehbar und kurz.
Auch das Problem kann ich nachvollziehen. Ich hab mich dann aber bemüht, Operatoren für häufiger gebrauchte Konstrukte zu bevorzugen. 'Häufig' ist natürlich nicht objektiv beurteilbar, aber Funktionen sollte man doch öfters brauchen.
-
Ach, und zu libffi: Gibts dazu irgendwo eine brauchbare Doku? Als ich vor ein paar Tagen auf deren Website vorbeigeschaut habe, habe ich keine gefunden.
