The gab programming language

[u/Fine_Seaworthiness19]

Hi all!

I am a long-time lurker of this sub, and a language enthusiast. I have been working on my own programming language for several years, and I finally worked up the courage to post it.

The language is called gab. I'm heavily inspired by lua, clojure, and smalltalk.

All the code is on github here and I've built a small website for the language here.

The language design, runtime, and standard library are all entirely my own work without the use of an LLM. However, I did consult LLMs occasionally when I wanted to research certain subjects (such as the difference between c11 atomics on x86 and arm).

I'm looking for any kind of feedback on the language, its goals/ergonomics, and the website itself.

Thank you for taking a look!

[u/EggplantExtra4946]

https://github.com/gab-language/cgab/blob/main/src/cgab/cgab.c

It's really curious to have a single file with 15 thousands LOCs containing the lexer, parser, data structures, bytecode compiler, interpreter and GC all in one files. Usually you would split it into as many files at minimum. It makes me think that this entire language is AI slop.

[u/CertNZone → u/EggplantExtra4946]

AI normally follows standard practice since it's just rule of averages. If they've done something odd (I haven't looked at their code) I would sooner assume hand written

[u/EggplantExtra4946 → u/CertNZone]

AI normally follows standard practice since it's just rule of averages.

That's a weak counter evidence. The size of this file is one of several reasons that makes me think it's AI generated. I think it's way too spotless, regular and tidy for a code of that size and complexity. Also it looks to me like way too much energy was spent on the optimization of the utilities rather than on the design and implementation of the language itself.

I'm looking at the jit branch and it's even more evident, looking at jit.c. The code is developped in such a breadth depth manner it's ridiculous. Almost 2000 LOCs of utility code that currently do nothing and a not single function dealing with instruction encoding. That's not how humans work, especially for complex code like that. For this kind of code you would make a basic program that can jit simple expressions and then add more stuff and utilities, depth first development.

If they've done something odd (I haven't looked at their code) I would sooner assume hand written

How convenient. And for the record that's not odd, it's inhuman. Who the fuck write 15 thousands LOCs and don't even bother to extract type definitions into a separate header file?

[u/CertNZone → u/EggplantExtra4946]

Yeah, super fair. Obviously I should have looked at what they'd written before commenting

I personally prefer to write fewer, longer files than a series of small ones so was ready to give them the benefit of the doubt but 15,000 does sound insane for a single file. Especially given how new to making programming languages they sounded

[u/Fine_Seaworthiness19 → u/EggplantExtra4946]

Ah I think the confusion with instruction makes sense to me now. I’m working on a copy-and-patch jit compiler in that branch, so there is actually almost zero instruction encoding for me to do. I actually just have to perform some relocations, and that’s all I have to touch in the machine code. That’s where there isn’t any instruction encoding involved

[u/Fine_Seaworthiness19 → u/EggplantExtra4946]

I originally did have it broken out into multiple c source and header files. It doesn’t actually make things easier in c unfortunately, because there’s not a good module/package system. And it makes it harder to include your code in other projects.

Since I want gab to easily embed in other people’s c projects, I’ve tried to keep it to a single c file. This way people can just include the source file and not have to worry about linking at all!

This is a common approach in c. Although I do agree that cgab.c is quite big, it might make more sense to generate this file with another program, like SQLite does or something.

I’m curious as to what you think the 2000 lines of utility code that do nothing in the JIT branch are.

Also, just look at the git history! The progress of this repository has been incremental over the last several years