Was stört/fehlt euch bei aktuellen Programmiersprachen?



  • 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.

    http://genesys.pro/doku.php/kellerautomat:start



  • 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.



  • Kellerautomat@work schrieb:

    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. 🤡

    Ich bin durchaus an Deiner Lösung interessiert, ich vermute jedoch, dass sie mit anderen Dingen meiner Syntax kollidiert.

    An der Funktionsdeklaration habe rund 2 Jahre gewerkelt (also nicht hauptberuflich ;-)), die aktuelle Fassung ist ein Kompromiss aus verschiedenen Für und Wider. Die Sprache und deren Entwicklung ist nicht öffentlich, damit ich nach Belieben ändern kann.
    Ich lasse mich gerne zu einer eleganteren Lösung inspirieren.

    Kellerautomat@work schrieb:

    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.

    Quelltexte laufen bei mir unter 'source'.

    Kellerautomat@work schrieb:

    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.

    Ich habe keine gefunden. Insbesondere funktionierte damals nichtmals das Beispielprogramm:
    C++: libffi => Segmentation Fault

    Ich wollte mal eine für proggen.org zusammenstellen, aber ich komme ja zu nix. Ggfs. vor Ort Wünsche äußern. Am längsten habe ich dafür benötigt, sie unter Windows ans Laufen zu bekommen. Unter Linux war es eigentlich Verhältnismäßig einfach.



  • Xin schrieb:

    Kellerautomat@work schrieb:

    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. 🤡

    Ich bin durchaus an Deiner Lösung interessiert, ich vermute jedoch, dass sie mit anderen Dingen meiner Syntax kollidiert.

    An der Funktionsdeklaration habe rund 2 Jahre gewerkelt (also nicht hauptberuflich ;-)), die aktuelle Fassung ist ein Kompromiss aus verschiedenen Für und Wider. Die Sprache und deren Entwicklung ist nicht öffentlich, damit ich nach Belieben ändern kann.
    Ich lasse mich gerne zu einer eleganteren Lösung inspirieren.

    Meine Syntax ist im Moment:

    <func-token> f(int x, string s)
    {
    }
    

    Also nichts weltbewegendes. <func-token> wird wohl entweder 'function', 'func', 'fn', 'proc', 'procedure', oder so. Im Moment gefällt mir 'fn' am besten. Was ich mit dem Rückgabetyp mache, weiß ich noch nicht.

    Kellerautomat@work schrieb:

    Quelltexte laufen bei mir unter 'source'.

    Source... Sourcecode... Code... für mich alles dasselbe. 🙂
    Der 'Code', den du meinst, den nenne ich einfach Bytecode.

    Xin schrieb:

    Kellerautomat@work schrieb:

    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.

    Ich habe keine gefunden. Insbesondere funktionierte damals nichtmals das Beispielprogramm:
    C++: libffi => Segmentation Fault

    Ich wollte mal eine für proggen.org zusammenstellen, aber ich komme ja zu nix. Ggfs. vor Ort Wünsche äußern. Am längsten habe ich dafür benötigt, sie unter Windows ans Laufen zu bekommen. Unter Linux war es eigentlich Verhältnismäßig einfach.

    Die Doku ist offenbar im github Repository, ein Hinweis auf der Website nicht vorhanden.
    https://github.com/atgreen/libffi/blob/master/doc/libffi.info



  • Ich habe immer diese Referenz benutzt: http://www.atmark-techno.com/~yashi/libffi.html

    Kleiner Quirk: libffi benötigt beim Erzeugen einen Zeiger auf ein Array mit ffi_types für die Argumenttypen. Dieser Zeiger muss gültig bleiben. Hat mich ewiges Debugging gekostet ...


Anmelden zum Antworten