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

@jordyd (i learned that from an email conversation i had with stallman!)

@ky0ko @jordyd i think
the reason why smalltalk worked so well as an object oriented system
was perhaps
because it WASN'T BUILT ON C

@hirojin @ky0ko They could have used Objective-C, which had been around for quite some time, if they wanted to use C libraries

@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...

@jordyd if you stopped them from using the preprocessor, they'd just make their own language that transpiles to C and call it Vala or something

@jordyd btw. what do you think about macros used in kernel, like container_of, or in BSD, eg. the TAILQ ones?

@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.

struct myStruct {
int myStuff;
linked_list_node node;
struct myStruct *s;
linked_list_node *n1 = s->;
s = container_of(myStruct, node, n1);

@Wolf480pl A bit strange but it doesn't appear overly complex or error-prone

(I might have written some things in a different order than in kernel, I've only seen it once or twice).

It does some pointer arithmetic under the hood, and I think doing it by hand every time would be more error-prone than using the macro.

@jordyd It's used a lot in the kernel, because they always embed linked list nodes within the structs that they want to keep on the list.

@Wolf480pl a small, short, and often-repeated bit of code is exactly the kind of thing macros are good at

@Wolf480pl especially given C has no generics (well there’s _Generic in C11 but it’s not incredibly powerful) and functions declared inline aren’t always inlined

@jordyd I feel like some poor bastard in a Lovecraft novel, just having glimpsed an unspeakable cosmic horror

@jordyd What then about the people who said "wow, this is a mess! Better wrap it in a new language 'Vala' so we can use that hard work without dealing with the macros."

@wictory At one point I made a series of TeX and LaTeX posts, and "LaTeX allergy" is a pun on that and the literal allergy to the material latex

@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.

@wictory imo they could have accomplished all that by doing it in Objective-C and writing C bindings, which would have been a lot cleaner and a lot less work

@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.

@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

@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."

@jordyd i can't tell whether this is sarcastic or not but i wholeheartedly agree

@jordyd I mean it's actually turing complete, unlike the C preprocessor

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

Sorry for the late reply btw, I mostly don't check this account much

Sign in to participate in the conversation

Octodon is a nice general purpose instance. more