Jai Programmiersprache von Jonathan Blow

[starcow]

Wie die meisten von euch bestimmt wissen, entwickelt Jonathan Blow ja die eigene Programmiersprache "Jai".
Mich würde interessieren, ob hier einige schon Erfahrungen damit gemacht haben und/oder wie sie die Sprache bewerten. Vielleicht auch im Vergleich zu "Zig", welche ja auch sehr vielsprechend ist.

Gruss starcow

[xq]

Vielleicht auch im Vergleich zu "Zig", welche ja auch sehr vielsprechend ist.

Im Gegensatz zu Jai ist Zig tatsächlich evaluierbar. Bei Jai musst du entweder in die Closed Beta, und du musst afaik sogar demnächst dafür zahlen.

Nachdem ich erfahren habe, dass die Toolchain für Jai closed source wird, ist das Projekt für mich gestorben, da ich gerne eine wartbare Compilerinfrastruktur hätte.

Man sieht halt von der Sprache auch nur Dinge im Livestream, kann mir deshalb kein wirkliches Bild davon machen.

Hier obligatorische Werbung für ⚡️Zig⚡️ einfügen

[starcow]

Nachdem ich erfahren habe, dass die Toolchain für Jai closed source wird, ist das Projekt für mich gestorben, da ich gerne eine wartbare Compilerinfrastruktur hätte.

Sorry für die Frage: Was ist eine "Toolchain" in diesem Kontext?

[antisteo]

JAI klingt für mich wie JAIPL (Just another imperative programming language)

Ich bringe meinen Azubis nicht mal mehr Objektorientierung bei. Eher sollen sie in Services und in relationalen Datenschemen denken.

Ich bin der Überzeugung, dass Logische Programmierung das nächste große Shit wird. Man sieht es schon an den ganzen No-Code-Tools, die quasi nur noch ein Wissensmodell über die Software aufbauen.

[xq]

Sorry für die Frage: Was ist eine "Toolchain" in diesem Kontext?

Compiler, Linker, Disassembler, ...

Ich schlage mich auf Arbeit mit einem verbuggten Closed Source Compiler (C++Builder) rum, und der Support ist nur so mittelgeil. Das heißt, ich kann die Probleme nicht irgendwie selbst lösen, sondern muss auf einen offiziellen Fix warten

[Helmut]

Vielleicht auch im Vergleich zu "Zig", welche ja auch sehr vielsprechend ist.

Im Gegensatz zu Jai ist Zig tatsächlich evaluierbar. Bei Jai musst du entweder in die Closed Beta, und du musst afaik sogar demnächst dafür zahlen.

Nachdem ich erfahren habe, dass die Toolchain für Jai closed source wird, ist das Projekt für mich gestorben, da ich gerne eine wartbare Compilerinfrastruktur hätte.

Das stimmt nicht. Es wird nur in der ersten öffentlichen Phase closed source sein, weil er verhindern will, dass forks die Sprache verwaschen. Langfristig will er den Code aber öffentlich machen. Kosten wird es nichts.

[xq]

Das stimmt nicht. Es wird nur in der ersten öffentlichen Phase closed source sein, weil er verhindern will, dass forks die Sprache verwaschen. Langfristig will er den Code aber öffentlich machen. Kosten wird es nichts.

Dann war ich hier misinformiert. Tschulligung für die Fehlinformation!

[Schrompf]

Nuja, dann kann man ja mit Anschauen warten, bis das Ding offen und mature ist. Ist ja nicht so als hätten wir einen Mangel an Programmiersprachen und würden durstig auf eine neue warten.

[Lord Delvin]

Ich schlage mich auf Arbeit mit einem verbuggten Closed Source Compiler (C++Builder) rum, und der Support ist nur so mittelgeil. Das heißt, ich kann die Probleme nicht irgendwie selbst lösen, sondern muss auf einen offiziellen Fix warten

Ich auch. ECJ. Kennt jeder hier. Ist open source, aka wenn ich will, dass es jemals gefixt wird, muss ich es selbst machen. Mal schauen, was mein Manager von dem Vorschlag halten wird.


Zur Sache: gibt's da irgendeinen Link, der einem irgendwie bei der Beurteilung des Projekts helfen würde? Würde mich interessieren, ob es mehr als Hybris ist.

[Alexander Kornrumpf]

Hier obligatorische Werbung für ⚡️Zig⚡️ einfügen

Ich habe jetzt mal eine Stunde oder so damit rumgespielt und bin hart abgeprallt.

Nehmen wir mal beispielhaft:

https://zig.news/kristoff/what-s-a-stri ... n-zig-31e9

das Code Beispiel ist, I kid you not,

fn funnyPrint(msg: []u8) void {
std.debug.print("*farts*, {s}", .{msg});
}

Sorry, ich bin nicht 14 Jahre alt. Mich nervt das.

Das beschriebene Problem ist "The most common newbie mistake", was ich als framing auch nicht mag, aber ist sicherlich Geschmacksache (unlike das Beispiel, das ist definitiv geschmacklos).

Die Lösung ist "Watch the talk". Der Typ ist sich nicht zu blöd 3 Seiten darüber zu schreiben was "newbies" alles nicht verstehen, aber um es zu verstehen, muss man sein Video anschauen. _Das_ kann er nicht hinschreiben.

Wenn ich es richtig verstehe ist der so eine Art Pressesprecher für das Projekt.

Für mich vereint das vieles was an Open Source schief läuft.

[Alexander Kornrumpf]

Ich hatte mit xq noch in PN weitergesprochen, und er hatte mich auf ein paar Missverständnisse meinerseits hingewiesen. Es ist anscheinend doch zu lange her dass ich mal was in C implementiert habe. Letztlich ist es ja auch irrelevant ob zig mir persönlich gefällt.

Wenn ich evaluieren müsste, ob ich eine Sprache produktiv einsetzen will, und das ist dann vielleicht auch wieder der Bogen zur Ausgangsfrage, dann evaluiere ich eben nicht nur die abstrakte Schönheit der Konzepte -- die kann ich für zig sowieso nicht seriös beurteilen -- sondern z. B. auch die Verfügbarkeit und Professionalität von Dokumentation. Das mag jetzt ein bisschen unfair erscheinen, vielleicht ist zig die beste Sprache der Welt und ich verstehe es nur nicht, aber realistisch gewinnt dann eben Rust was bei allen potentiellen Schwächen die Rust sicher auch hat, einen relativ guten Job macht zu erkären, was es sein will und warum.

Was ich noch nicht ganz verstanden (im Sinne von: genügend darüber gelesen) habe und eventuell nochmal selbst recherchieren werde, hier aber trotzdem mal formuliere, falls es auch für Dritte interessant ist:

Ich behaupte jetzt einfach mal ein Array variabler (nicht zur Compilezeit bekannter) Länge (C freispeicher Array, std::vector, python list, Java ArrayList, you name it) ist mit Abstand die beliebteste Datenstruktur weltweit überhaupt. Der Tradeoff, den man da hat ist dass man entweder kein Boundschecking hat (C, schnell, unsicher) oder halt boundschecking zur Laufzeit (python, Java, relativ langsam, sicherer).

Wenn ich dann sowas lese wie "C hat dieses unsichere char[], was letztlich char* ist, aber wir hier bei Rust haben char[123] (oder wie auch immer die Rust Syntax ist) und da bekommen wir compiletime boundschecking, ganz toll" dann scheint mir das völlig an der Realität vorbeizugehen, weil ich in der Realität eben gerade nicht beim Schreiben des Codes schon weiß dass das Array 123 lang sein wird.

Ich bin sicher sie haben eine schlaue Lösung dafür aber sie steht in den Dokus weiter hinten als ich sie logisch erwarten würde.

[Lord Delvin]

Wenn ich dann sowas lese wie "C hat dieses unsichere char[], was letztlich char* ist, aber wir hier bei Rust haben char[123] (oder wie auch immer die Rust Syntax ist) und da bekommen wir compiletime boundschecking, ganz toll" dann scheint mir das völlig an der Realität vorbeizugehen, weil ich in der Realität eben gerade nicht beim Schreiben des Codes schon weiß dass das Array 123 lang sein wird.

Ich bin sicher sie haben eine schlaue Lösung dafür aber sie steht in den Dokus weiter hinten als ich sie logisch erwarten würde.

Nein haben sie nicht. Das ist einfach Propaganda und natürlich kann einem eine beliebig tolle Programmiersprache keine bessere Lösung für eine ArrayList präsentieren indem man einfach sagt, feste Länge muss reichen.

Ich habe btw. nie verstanden, warum es in C++ kein Compilerflag gibt, die ganzen Prüfungen reinzucompilen. Aber letztlich gibt es valgrind und das hat mir fast immer gereicht.

Leider ist die Antwort viel zu oft Propaganda oder Unkenntnis. Erstaunlich, dass es hier nicht um Jai geht, wo das doch eigentlich das Thema war.

[xq]

Wenn ich dann sowas lese wie "C hat dieses unsichere char[], was letztlich char* ist, aber wir hier bei Rust haben char[123] (oder wie auch immer die Rust Syntax ist) und da bekommen wir compiletime boundschecking, ganz toll" dann scheint mir das völlig an der Realität vorbeizugehen, weil ich in der Realität eben gerade nicht beim Schreiben des Codes schon weiß dass das Array 123 lang sein wird.

Ich bin sicher sie haben eine schlaue Lösung dafür aber sie steht in den Dokus weiter hinten als ich sie logisch erwarten würde.

Nein haben sie nicht. Das ist einfach Propaganda und natürlich kann einem eine beliebig tolle Programmiersprache keine bessere Lösung für eine ArrayList präsentieren indem man einfach sagt, feste Länge muss reichen.

Sowohl Rust, als auch Go, Zig und mittlerweile C++ (std::span) haben die "Slice", also ein Pointer + Länge. Das kann man in C auch machen, ist aber weit mühsamer. Slices können boundary checks machen und bei out-of-bounds eine Panic auslösen und damit lieber crashen als mit kaputten Daten weiterarbeiten

[Lord Delvin]

Nein haben sie nicht. Das ist einfach Propaganda und natürlich kann einem eine beliebig tolle Programmiersprache keine bessere Lösung für eine ArrayList präsentieren indem man einfach sagt, feste Länge muss reichen.

Sowohl Rust, als auch Go, Zig und mittlerweile C++ (std::span) haben die "Slice", also ein Pointer + Länge. Das kann man in C auch machen, ist aber weit mühsamer. Slices können boundary checks machen und bei out-of-bounds eine Panic auslösen und damit lieber crashen als mit kaputten Daten weiterarbeiten

https://en.cppreference.com/w/cpp/conta ... perator_at

Für mich sieht das nicht aus, als würde da was geprüft werden. Auch nicht wenn man ein Flag setzt. Außerdem sehe ich nicht, wie ich da zur Laufzeit ein resizing mache, was ich bräuchte, um z.B. eine HashMap oder einen StringBuffer zu realisieren.
Damit ist es zwar im C++-Universum vielleicht der neuste Scheiß, kann aber immer noch nicht das, was Ada vermutlich schon immer kann.

Ehrlich gesagt kann ich mich bei meiner täglichen Arbeit nicht erinnern, in den letzten Jahren überhaupt mal eine Datenstruktur mit fixer Größe gebraucht zu haben. Womit sie jetzt für mich noch unerheblicher wären als z.B. der Zoo an parallelen Listen und Queues, den man so hat.
Ich will jetzt nicht sagen, dass es völlig nutzlos ist; ich habe das ja auch implementiert. Ist auch nicht viel Arbeit. Nur eben einfach nicht relevant.

Nebenbei finde ich es erstaunlich, dass die C++-Implementierung als dynamic -1 verwendet und nicht 0, wie bei den zero-sized arrays. Vielleicht will sich da jemand die Option offen halten, zu machen was ich vorschlage :)

[Krishty]

https://en.cppreference.com/w/cpp/conta ... perator_at

Für mich sieht das nicht aus, als würde da was geprüft werden.

Ja; sie geben keine Garantie einer Prüfung, sondern deklarieren es als undefiniertes Verhalten. Tatsächlich lassen sich bei den meisten Implementierungen die Prüfungen zuschalten; bei Visual C++’ STL ist bspw. im Debug-Modus alles geprüft.

Ich hatte sowas wie span mal vor zehn Jahren selber implementiert. Als ich sah, wie mies die Code Generation ist, hab ich’s rausgeschmissen und werd’s nie wieder anfassen.

Das ist aber vor allem der ganzen Legacy in C/C++ geschuldet (ABI für komplexe Aufrufparameter und Rückgabewerte; extrem dummes Speichermodell, das ordentliche Aliasing-Analyse fast unmöglich macht; …). Rusts Propaganda von Zero-Cost Safety finde ich nicht sofort absurd und werde mich da mal richtig einlesen müssen, sobald ich einen Winter in einer abgelegenen Hütte in Alaska verbringe.

[Alexander Kornrumpf]

https://en.cppreference.com/w/cpp/conta ... perator_at

Für mich sieht das nicht aus, als würde da was geprüft werden.

Ja; sie geben keine Garantie einer Prüfung, sondern deklarieren es als undefiniertes Verhalten. Tatsächlich lassen sich bei den meisten Implementierungen die Prüfungen zuschalten; bei Visual C++’ STL ist bspw. im Debug-Modus alles geprüft.

Ich hatte sowas wie span mal vor zehn Jahren selber implementiert. Als ich sah, wie mies die Code Generation ist, hab ich’s rausgeschmissen und werd’s nie wieder anfassen.

Das ist aber vor allem der ganzen Legacy in C/C++ geschuldet (ABI für komplexe Aufrufparameter und Rückgabewerte; extrem dummes Speichermodell, das ordentliche Aliasing-Analyse fast unmöglich macht; …). Rusts Propaganda von Zero-Cost Safety finde ich nicht sofort absurd und werde mich da mal richtig einlesen müssen, sobald ich einen Winter in einer abgelegenen Hütte in Alaska verbringe.

Einen Winter hatte ich nicht aber einen regnerischen Nachmittag mit Erkältung zuhause: Rust hat viele Ideen, die erstmal gut aussehen, auch wenn ich nicht beurteilen kann, wie sehr sie in der Praxis im Weg sind. Rust hat _natürlich_ auch Implementierungen für Vector/ArrayList und assoziative Arrays (e.g. HashMap). Ich habe neulich ein Zitat gelesen, ich wünschte ich könnte es wiederfinden, dass die allermeisten Programmierer nur diese zwei Datenstrukturen kennen.

Kommt also jetzt drauf an. Wenn du an Problemen arbeitest bei denen die Arraygröße bekannt ist bekommst du alles as advertised, wenn du an Problemen arbeitest, die mir und anscheinend auch "Lord Delvin" in der Praxis begegnen, benutzt du vector wie das ganze andere Fußvolk halt auch, kannst dich aber darüber freuen, dass concurrency durch die Mutabilitätsregeln trivial wird. Also letzteres kann ich nur theoretisch bestätigen, habe es nicht ausprobiert. Ist aber ein ziemlich großer win, auch ohne das Array-Zeug.