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 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.
@bugaevc opinion on Vala?
@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.
@jordyd (1/2) so like Swift? Dunno why they haven't done that (though it's not like one of these approaches has clear benefits over another). Here's what Jürg Billeter (Vala creator) wrote about this back in 2006:
@jordyd (2/2)
"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."
@bugaevc I was wondering, why not make Vala compile directly rather than to C macros (LLVM or GCC backend) but (1) use GObject as the default ABI and (2) generate C header files