Programming thread

has anyone here used zig? whats the learning curve like for it. See im at a cross roads where i want to start using lowlevel stuff but ive never really gotten along with C, C++ looks like some sort of java-C abomination, and every single person ive ever seen use or support the use of rust has been the most insufferable looking or sounding person imaginable. So i guess the question is should i try zig or stick to trying to learn C.
 
has anyone here used zig? whats the learning curve like for it. See im at a cross roads where i want to start using lowlevel stuff but ive never really gotten along with C, C++ looks like some sort of java-C abomination, and every single person ive ever seen use or support the use of rust has been the most insufferable looking or sounding person imaginable. So i guess the question is should i try zig or stick to trying to learn C.
either stick to C or move to C++
zig is fucking annoying, the compiler is way too opinionated, and doesn't mesh well with quick prototyping (shit itself when unused variables)
C is simple and the major compilers know their place in the world (not questioning the programmer), also C11 and C23 have a lot of nice additions, C11 for example added generics
in general until the end of time i will shill C because its the simplest language and without additional bullshit, you only get the bare minimum you need + some nice additions, like the string and math standard libraries

I really recommend browsing the c reference on cppreference, it shows you what every version of the standard added and all the standard library functions etc etc, the search function is a bit shitty tho, so make sure the url contains /w/c/ and not /w/cpp/
 
has anyone here used zig? whats the learning curve like for it. See im at a cross roads where i want to start using lowlevel stuff but ive never really gotten along with C, C++ looks like some sort of java-C abomination, and every single person ive ever seen use or support the use of rust has been the most insufferable looking or sounding person imaginable. So i guess the question is should i try zig or stick to trying to learn C.

C is a rite of passage for low-level programming and you should go through with it.
The way it handles strings and arrays is kind of unpleasant, and its ecosystem is outdated, but the language is so simple that it forces you to think about things you usually take for granted when programming. It reverses the pajeet brainwashing done by python, java and node; and for that alone it's worth it.

If you really don't want C or C++, give D a shot:
  • systems programming language
  • syntax like C and C++
  • compiler is super fast
  • no header files
  • rich standard library
  • interfaces nicely with C libraries
  • better templates than C++
  • has three compiler implementations (in-house, gnu, llvm)
It does have a garbage collector, but you don't have to use it:
https://dlang.org/blog/the-gc-series/

D also supports a mode called betterC which relies only on the C runtime library, so you get to write C code (almost 1:1) with commodities of modern languages (and no GC):
https://dlang.org/spec/betterc.html#retained
In a way, betterC is C with training wheels.
 
I've decided to do baremetal raspberry pi today since I only have a pi zero, no mini hdmi cable and the only microusb i have is only for charging

lets just say its a pain
This is one of the first steps in how you truly learn to master programming.
 
  • Like
Reactions: Marvin
This is one of the first steps in how you truly learn to master programming.
there's something intangible but very valuable you can get out of having a vague idea of how the whole thing works
if you don't even understand the basic conventions underlying everything, you will be stuck relying on other people's abstractions and assuming the wrong things, and will end up creating brittle, inflexible, niggerlicious bullshit without knowing why or how to fix it
 
its one thing to make your own app program from scratch without using external libraries, but its whole another beast writing something without having access to standard libraries and syscalls
this is called "making a specialized operating system that isn't really an os because it just does the thing you want it to do"
...which is a lot like regular programming except the function you use to talk to the hardware does the talking very directly and there's no operating system to help you if you fuck up and access the wrong memory
 
finally managed to rewrite the heartbeat example from david welch's repo

kinda embarassed that it took me like 8 hours...
but still, I managed to do something :)

C:
volatile unsigned int *const GPFSEL0 = (volatile unsigned int *const) 0x20200000;
volatile unsigned int *const GPFSEL1 = (volatile unsigned int *const) 0x20200004;
volatile unsigned int *const GPFSEL2 = (volatile unsigned int *const) 0x20200008;
volatile unsigned int *const GPFSEL3 = (volatile unsigned int *const) 0x2020000c;
volatile unsigned int *const GPFSEL4 = (volatile unsigned int *const) 0x20200010;
volatile unsigned int *const GPFSEL5 = (volatile unsigned int *const) 0x20200014;

volatile unsigned int *const GPSET0 = (volatile unsigned int *const) 0x2020001C;
volatile unsigned int *const GPSET1 = (volatile unsigned int *const) 0x20200020;

volatile unsigned int *const GPCLR0 = (volatile unsigned int *const) 0x20200028;
volatile unsigned int *const GPCLR1 = (volatile unsigned int *const) 0x2020002C;

extern void dummy(unsigned int);

void gpioSet(const int pin) {
    if(pin < 32) {
        *GPSET0 = 1 << pin;
    } else {
        *GPSET1 = 1 << (pin-32);
    }
}

void gpioClear(const int pin) {
    if(pin < 32) {
        *GPCLR0 = 1 << pin;
    } else {
        *GPCLR1 = 1 << (pin-32);
    }
}

int main(void) {
    {
        // sets some alternate function for pin 47 (which is ACT LED)
        // practically unneeded since it still blinks with ts removed
        unsigned int a = *GPFSEL4;
        const unsigned int mask = ~(0b111 << 21);
        a = a & mask;
        a = a | (1 << 21);
        *GPFSEL4 = a;
    }
    for(;;) {
        gpioClear(47);
        for(int x = 0; x < 0x80000; x++) dummy(x);
        gpioSet(47);
        for(int x = 0; x < 0x80000; x++) dummy(x);
        gpioClear(47);
        for(int x = 0; x < 0x80000; x++) dummy(x);
        gpioSet(47);
        for(int x = 0; x < 0x300000; x++) dummy(x);
    }
    return 0;
}
 
either stick to C or move to C++
zig is fucking annoying, the compiler is way too opinionated, and doesn't mesh well with quick prototyping (shit itself when unused variables)
C is simple and the major compilers know their place in the world (not questioning the programmer), also C11 and C23 have a lot of nice additions, C11 for example added generics
in general until the end of time i will shill C because its the simplest language and without additional bullshit, you only get the bare minimum you need + some nice additions, like the string and math standard libraries

I really recommend browsing the c reference on cppreference, it shows you what every version of the standard added and all the standard library functions etc etc, the search function is a bit shitty tho, so make sure the url contains /w/c/ and not /w/cpp/
I just need a fucking cleanup at end of scope keyword in C. I refuse to use the ugly GOTO / SEH __try / __finally. Also, honestly, I'm not opposed to an opinionated compiler; Rust wasn't too bad but didn't seem to like me finding ways around it wanting very expensive deep clones of a hashmap bucket for example

Perfect language would be a language like C but with features that more support data oriented design and a dedicated defer I also like const variables by default. Oh and far more clear order of operations. I hate reading *ptr++ = foo;

On another tangent: Thought I'd give the latest Claude AI a go on a IRP processing queue in my legacy filesystem driver project.


Thought it wasn't too terrible of a task actually since an IRP queue is a pretty driver agnostic thing and there are quite a few Microsoft open source examples for it to have trained on.

It used usermode synchronisation primitives It decided to allocate HUGE arrays and structs on the very limited driver stack, not only this but there were glaring race conditions and deadlocks. It also wasn't cancel safe which is more forgiveable since most drivers aren't anyway.

I'd be curious to know what other Kiwis experiences with multithreaded AI code is like to see if it's shit only in the domain of drivers or in general
 
Oh and far more clear order of operations. I hate reading *ptr++ = foo;
kiwi farms k/lispcirclejerk here to inform you that order of operations is very easy to know if you just put loads of parentheses around everything
also ++ is inherently cursed because it evaluates to 1 thing and implicitly inserts an assignment statement too because fuck you
it's useful for being terse (as in your example) but is it really worth it?

thought: what if there was a c-like language that had lisp sexprs and lisp macros but otherwise was mostly like c
I'd be curious to know what other Kiwis experiences with multithreaded AI code is like to see if it's shit only in the domain of drivers or in general
llms produce code in a manner similar to copy and pasting several stack overflow posts and random chunks of github repo into a program, but in a much more fine-grained fashion, by using a statistical model that outputs bits of code instead of finding random so answers and doing the needful with the copy and paste keys
the quality of the resulting programs is what you would expect. want it to demonstrate a simple usage of an api? works great. want it to make part of a driver, where you have to actually think about how everything fits together? probably not
 
it's useful for being terse (as in your example) but is it really worth it?
The semantic is clear and unambiguous. Figured you LISP guys would be responsive to that.

Been trying to port my little Ruby Pong game over to Windows. I am shocked at how low-resolution keypress timing data is. I guess I do use a bog-standard Lenovo shovelware keyboard. Best looking resolution in terms of press timing is my gaming mouse, Steelseries Prime+. "Oh well." GetAsyncKeyState() is going to work just fine for this. Might end up being even more terse than the /dev/input code, which is pretty ugly. Surprises me that the Any% Warpless WR holder playing SMB3, which requires multiple 2 frame windows, uses a keyboard. Maybe one of those 1000Hz gaming boards? Anyone here have one of those? Have you actually gotten <10ms measurements out of it?
 
  • Agree
Reactions: Rango Dango
isn't that lisp
good point but i'm thinking of something that doesn't need a garbage collector, and not even really lisp (it just looks like it and has a similar macro system)
The semantic is clear and unambiguous. Figured you LISP guys would be responsive to that.
it's clear and unambiguous if you are looking at (or have memorized) the precise interactions between all the operators involved, which i admit is not too hard in most cases, but it really isn't very lispy
also if a programming language ends up having ambiguous semantics it has very big problems that are far worse than any academic sperging about whether post-increment syntax is hard to read
 
Perfect language would be a language like C but with features that more support data oriented design and a dedicated defer I also like const variables by default. Oh and far more clear order of operations. I hate reading *ptr++ = foo;
There's Better C, a subset of D that can depend only on the C runtime.
Page said:
Nearly the full language remains available. Highlights include:
  1. Unrestricted use of compile-time features
  2. Full metaprogramming facilities
  3. Nested functions, nested structs, delegates and lambdas
  4. Member functions, constructors, destructors, operating overloading, etc.
  5. The full module system
  6. Array slicing, and array bounds checking
  7. RAII (yes, it can work without exceptions)
  8. scope(exit)
  9. Memory safety protections
  10. Interfacing to C++
  11. COM classes and C++ classes
  12. assert failures are directed to the C runtime library
  13. switch with strings
  14. final switch
  15. unittest
  16. printf format validation
 
C is a rite of passage for low-level programming and you should go through with it.
there's something intangible but very valuable you can get out of having a vague idea of how the whole thing works
if you don't even understand the basic conventions underlying everything, you will be stuck relying on other people's abstractions and assuming the wrong things, and will end up creating brittle, inflexible, niggerlicious bullshit without knowing why or how to fix it
Will second this wholeheartedly. Although it's a royal pain in the ass specifically going through the motions for C's string and arrays gives you a much better appreciation of low-level memory management and data manipulation than any more recent language ever could. The moment you learn how the latest languages abstracted and improved upon the presentation of stuff like strings is the moment you start appreciating just what the tools have given you, and more importantly, just what the limitations are.

true chads use parentheses as 99% of the language's syntax
the other 1% is the other stuff, like numbers and strings, because those are occasionally useful for writing typical programs
I am forever thankful I came to programming from a chemical engineering background for this reason. Parentheses are not a nuisance, they are not superfluous, they break up your logic in easily understood chunks with clear progression and leave no room for misinterpretation. You are not smart for ignoring them, your code is not improved by figuring out a way to avoid them, you're simply an arrogant ass who thinks he's smarter than the average Jeet without appreciating that simple and straightforward understanding is the way to sustainable code and long-term product longevity.
 
Back