Macros can be useful but I feel like we should ban certain people from touching them.
For example, imagine if someone were to use the C preprocessor to create an elaborate object orientation system for C, calling it GObject, and then create an entire graphics stack up to and including a desktop environment, called, say, GNOME.
I think that's the kind of person who should no longer be allowed to use the C preprocessor.
@jordyd funny thing, the whole object model thing was literally supposed to be what GNOME was for
GNU Network Object Model Environment
the original vision was to create a competitor to things like Microsoft's OLE, or OpenStep, or CORBA, etc, back in the mid 90s when object orienting ALL THE THINGS was all the rage
@ky0ko @jordyd I forgot about that! Bringing back memories here of ORBit, the GNOME implementation of CORBA, and how I thought CORBA was a really cool idea and I wanted to try ORBit but I had no idea what I was doing and gave up. 😅 It's probably a good hint that the "new version", ORBit2, dates to 1998...
@Wolf480pl I'm not familiar with container_of but the BSD ones I think are mostly fine. When they were invented there wasn't really any readily-available alternative for that kind of functionality. GObject, on the other hand, could have been written using Objective-C, which had been around for quite some time by the time GNOME was created.
@jordyd OK, because the thing that sucks with TeX and latex is the macros, although TeX and latex are awesome although built from macros. Also gobject sucks, but it's strength is that 1) it exists, and 2) the API is portable to many languages. If you want to makes portable software there is still nothing that beats c.
@jordyd macros in C suck, no doubt; but GObject is not about abusing macros to get something, it's an API and ABI and comment-style convention for writing robust object-oriented and *incredibly* binding-friendly code in C. Macros are just commonly used with it to cut down the boilerplate. Should they have used Objective-C? Maybe, I don't know (GNUstep tried and basically failed); we wouldn't have nice bindings for one thing.
@jordyd (1/2) Vala is great! It's surely nicer than objc - it has sane syntax and native support for closures/async/await - but objc has that nice thing about it being "just C" so one can use C stuff directly... It's a shame GNOME doesn't have enough resources to maintain & support Vala properly; that is why it may not be attractive to real-world app developers (as opposed to the "language/ecosystem as an art" way of looking at it).
@jordyd (2/2) Vala's, in fact, so GObject-native that I've come to think of GObject as "Vala's object model, hand-rolled in plain C with a shitton of macros", as opposed to thinking of Vala as "a syntactic sugar for C/GObject".
That all being said, Vala just isn't good enough for low-level libs; Rust (with gtk-rs & gnome-class) is much better suited for that niche. The best thing about GObject is how one can write interoperable stuff in a mix of languages, so I'd go Rust for libs, Vala for apps.
"The C code generation is just the implementation of the current Vala compiler, it's of course not the only possible way. Generating assembly code or better writing a GCC frontend for Vala would be very nice but requires more work. This shouldn't make a large difference to developers using Vala, though, the result after compilation is the same, a native application/library creating GObjects at runtime."
The problem with turing complete macro systems like that is that they have no understanding of the source code they're manipulating, which leads to all kinds of headaches. There are Turing complete macro systems that do understand the code they're manipulating, such as Lisp's, or even C++'s templates