Programming thread

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Json and other serialization may need to have that, also some kinds of dynamic debug printing or introspection. It's just nice to have so I want it
Json technically contains no actual type information though. (for historical and how js works under the hood reasons)

But yeah, for debugging, type info is definitely a nice to have.

For AoT compiled languages its certainly much less important than for something like .net or java though, because in those, the type info allows for more optimizations when jit-ing.
 
Been looking into Zig and it seems like the best C-like option for a serious project, I need a language that other people won't turn into slop shit because it has 999999 features like C++ but has more ergonomics than C like generics, type information at runtime. Does anyone have suggestions?
C. These "modern" features only hold you back by convincing you that you need them (and that C doesn't have them).
 
Just chiming in to say Lisp is the ugliest shit I've ever had the displeasure of reading. Prefix notation is AIDS.

Yes, I am malding.

SICP is a pretty good read so far though.

t. former linguist
 
Been looking into Zig and it seems like the best C-like option for a serious project, I need a language that other people won't turn into slop shit because it has 999999 features like C++ but has more ergonomics than C like generics, type information at runtime. Does anyone have suggestions?
I use D, it has a million features but you aren't forced into any of them (including GC) and also has a more limited subset of features labelled as "betterC" if you're into that. It has quite good design overall and is probably the best language choice for me until Jai releases. Also zig is a gay tranny language run by a sped so I wouldn't recommend using it at all.
 
Just chiming in to say Lisp is the ugliest shit I've ever had the displeasure of reading. Prefix notation is AIDS.

Yes, I am malding.

SICP is a pretty good read so far though.

t. former linguist
You will learn to appreciate the raw power of such notation as you start working with more heavy use of tree structures—particularly Abstract Syntax Trees (ASTs). That aside, the way all of the expressions nest and flow into each other is very conceptually and aesthetically pleasing.
 
Just chiming in to say Lisp is the ugliest shit I've ever had the displeasure of reading. Prefix notation is AIDS.

Yes, I am malding.

SICP is a pretty good read so far though.

t. former linguist
You will learn to appreciate the raw power of such notation as you start working with more heavy use of tree structures—particularly Abstract Syntax Trees (ASTs). That aside, the way all of the expressions nest and flow into each other is very conceptually and aesthetically pleasing.
Prefix notation is far better than infix notation, as there is no order precedence. Sure it's a few more groupings, but that barely even matters in the grand scheme of things.

It also allows you to do stuff like partial application very easily, along with giving you higher order functions for free. Oh and instead of passing in only a specific amount of arguments, you can very easily just put whatever amount of args in, as you need.
 
Just chiming in to say Lisp is the ugliest shit I've ever had the displeasure of reading. Prefix notation is AIDS.

Yes, I am malding.
It took me twenty five years of programming, with a decade or so of that being professionally, before the design of Lisp actually percolated into my brain. It took me developing a program that was deterministic and homoiconic in Prolog before it clicked that Lisp would have been superior, as I'm not using any of the non-determinism that Prolog is designed to provide. Now I firmly believe that "we've been doing it all wrong" in providing a multitude of operator conditions, like infix, postfix, et cetera. I think theoretical mathematics would do well to backport a consistent operator design into its theory. I believe it would make a lot of the awkward constructs mathematicians wrangle a lot more approachable. (But I'm mostly recapitulating the Metamath guys here.)

Almost all of today's Lisps focus on being run-time engines, but there's a really underserved niche for non-interpreted Lisp-like compiled languages, ie. without eval. There are some hints in this direction like Stalin Scheme and Chicken Scheme but these keep the interpreter.
 
Last edited:
Almost all of today's Lisps focus on being run-time engines, but there's a really underserved niche for non-interpreted Lisp-like compiled languages, ie. without eval. There are some hints in this direction like Stalin Scheme and Chicken Scheme but these keep the interpreter.
This isn't a Scheme/Lisp for static compilation like you're describing, but still, an interesting project is Sassy, which is an x86 compiler written in Scheme.

So it obviously uses an sexpr syntax for the assembly. And also obviously, it allows escaping to Scheme to generate code.

Interestingly, the author wrote it in fairly portable Scheme. R5RS Scheme with a few almost universally implemented SRFIs and like a couple implementation dependent things like file-exists? and delete-file.

There's a few Scheme implementations that have it in their package repos as a library you can import.

I have no use for it anytime soon but it's still really neat.
 
I've been working on a compiler for years now and struggling to find what direction to go, I wanted to do typescript but for C but it's been done so much. I'm debating just making my own backend, I'm tired of LLVM and shit I just want a 0.1 second compile in a C like language that's simple but ergonomic with a few modern features like generics and introspection. At the moment it fully works transpiling to C and a half done AT&T assembly output. It's not a toy either it has full type checking and a full abstract syntax tree, there are no shortcuts.

For instance here is how my language is currently doing enumerations, the plan is to have switch pattern matching over the type.

Code:
enum Event<T> {
    Data(payload: T, timestamp: int),
    Error(message: char*, code: int),
    Empty
}

// not implemented but an example
switch (event) {
    Event.Data d -> printf("%d/n", d->code),
    Event.Error e -> {
        panic("error %d: %s/n", e->code, e->message);
        abort();
    }
}

Now imagine that for the last rest of the language, cleaning up some cruft and adding a few features that are proven over the decades since C was designed, and the rest would be dead simple just like C so that writing a compiler for it or a new backend is straightforward.

The thing is I just can't trust these modern langauges, they always go retard mode 10 years in and abandon their first principles. I have to do it myself and keep the retards away.
 
I've been working on a compiler for years now and struggling to find what direction to go, I wanted to do typescript but for C but it's been done so much. I'm debating just making my own backend, I'm tired of LLVM and shit I just want a 0.1 second compile in a C like language that's simple but ergonomic with a few modern features like generics and introspection. At the moment it fully works transpiling to C and a half done AT&T assembly output. It's not a toy either it has full type checking and a full abstract syntax tree, there are no shortcuts.

For instance here is how my language is currently doing enumerations, the plan is to have switch pattern matching over the type.

Code:
enum Event<T> {
    Data(payload: T, timestamp: int),
    Error(message: char*, code: int),
    Empty
}

// not implemented but an example
switch (event) {
    Event.Data d -> printf("%d/n", d->code),
    Event.Error e -> {
        panic("error %d: %s/n", e->code, e->message);
        abort();
    }
}

Now imagine that for the last rest of the language, cleaning up some cruft and adding a few features that are proven over the decades since C was designed, and the rest would be dead simple just like C so that writing a compiler for it or a new backend is straightforward.

The thing is I just can't trust these modern langauges, they always go retard mode 10 years in and abandon their first principles. I have to do it myself and keep the retards away.
maybe try improving upon tcc?

it's a neat compiler itself.

It doesn't really support a ton, but If you are making your own maybe you could add some of the features you would want to see.
 
maybe try improving upon tcc?

it's a neat compiler itself.

It doesn't really support a ton, but If you are making your own maybe you could add some of the features you would want to see.
I've used tcc and it was integrated at one point so it would spit C code into tcc internally to compile. I've already made my own is what I'm saying, it's already a fully working compiler at 15k lines
 
I've been working on a compiler for years now and struggling to find what direction to go, I wanted to do typescript but for C but it's been done so much. I'm debating just making my own backend, I'm tired of LLVM and shit I just want a 0.1 second compile in a C like language that's simple but ergonomic with a few modern features like generics and introspection. At the moment it fully works transpiling to C and a half done AT&T assembly output. It's not a toy either it has full type checking and a full abstract syntax tree, there are no shortcuts.

For instance here is how my language is currently doing enumerations, the plan is to have switch pattern matching over the type.

Code:
enum Event<T> {
    Data(payload: T, timestamp: int),
    Error(message: char*, code: int),
    Empty
}

// not implemented but an example
switch (event) {
    Event.Data d -> printf("%d/n", d->code),
    Event.Error e -> {
        panic("error %d: %s/n", e->code, e->message);
        abort();
    }
}

Now imagine that for the last rest of the language, cleaning up some cruft and adding a few features that are proven over the decades since C was designed, and the rest would be dead simple just like C so that writing a compiler for it or a new backend is straightforward.

The thing is I just can't trust these modern langauges, they always go retard mode 10 years in and abandon their first principles. I have to do it myself and keep the retards away.
Have you looked into using QBE?
 
If you load the new .jp domain without js enabled, it gives you some options for commands you can run to solve the challenge the new anti-DDoS system gives you. I wrote my own in (nearly) pure bash:
Bash:
(
    s='89a1b14a083c792c80b4e0ad9e223dbf_6974d89d'
    d=16
    n=45300
    target=$(( 1 << (32 - d) ))

    shacmd=`which sha256sum` || shacmd=(`which shasum` -a 256) || exit 1
    until h=`printf '%s%d' "$s" "$n" | "${shacmd[@]}"` && (( 16#${h:0:8} < target )); do
        (( n++ ))
    done

    printf '%d\n' "$n"
)
n is normally set to 0, but I set it higher here to speed up testing for this example challenge.

Posting it here because it makes heavy use of some cool builtins to require as few dependencies as possible. It runs kinda slowly compared to other languages, but it will run on any unix-like system with bash (even old versions like 3.2 on mac) and some sha256 checksummer. Due to its speed, I'm naming my implementation Tortoise.

I love shell scripting because it encourages going wild and figuring out clever hacks to get shit done quicker with fewer characters lol.

This is the python implementation from the page that I used as a reference:
Python:
import hashlib

s='89a1b14a083c792c80b4e0ad9e223dbf_6974d89d'
d=16
n=0
target=1<<(32-d)

check=lambda i: int(hashlib.sha256((s+str(i)).encode('utf-8')).hexdigest()[:8], 16) < target
print(next(i for i in iter(lambda: n if check(n) else (exec('globals()[\'n\']+=1') or n), None) if check(i)))
 
Last edited:
How do you guys read documentation. I just started learning apis and the docs are so fucking dense that I reread them over and over but still dont comprehend them.
Read, experiment, read again, experiment again if needed, repeat.
Idk if there is better way. You will get used to it tho, and you will understand quicker the more experience you get.
 
How do you guys read documentation. I just started learning apis and the docs are so fucking dense that I reread them over and over but still dont comprehend them.
A strategy you have these days is asking an LLM to explain it to you. Reading APIs is a skill. Learning it takes time and practice. Just keep on keepin' on.
 
Back
Top Bottom