4 ms·

As a very long time C programmer: don't try to be smart. The more you rely on fancy preprocessor tricks the harder it will be to understand and debug your code.

As a very long time C programmer: don't try to be smart. The more you rely on fancy preprocessor tricks the harder it will be to understand and debug your code. The C preprocessor gives you enough power to shoot yourself in the foot, repeatedly, with anything from small caliber handguns to nuclear weapons. You may well end up losing control over your project entirely. One nice example: glusterfs. There are a couple of macros in use there that, when they work are magic. But when they don't you lose days, sometimes weeks. This is not the way to solve coding problems, you only appear smart as long as you remember what you've built. Your other self, three years down the road is going to want to kill the present one, and the same goes for your colleagues a few weeks from now.

5- 1y ago
> as long as you remember what you've built yes! like any craft, this works only if you keep practising it. various implementations of k, written in this style (with iterative improvements), have been in constant development for decades getting very good use out of these macros.
switchbak 1y ago
Seems to me that this is now exponentially true with AI coding assistants. If you don't understand what you're adding, and you're being clever - you can quickly end up in a situation where you can't reason effectively about your system. I'm seeing this on multiple fronts, and it's quickly becoming an unsustainable situation in some areas. I expect I'm not alone in this regard.
- gitonthescene 1y ago
  I’d bet that a lot of the work done with AI assistants is decidedly _not_ clever.
gitonthescene 1y ago
Losing control of a project is likely more due to the programmers on it than the tools they use. IMHO _anything_ done consistently can be reasoned about and if necessary undone.
- jacquesm 1y ago
  Not necessarily. Sometimes the rot goes so deep that there is really no way out. And the C pre-processor has figured prominently in more than one such case in my career. And it was precisely in the kind of way that is described in TFA. For something to be doable it needs to make economic sense as well and that's the problem with nightmare trickery like this. Initially it seems like a shortcut, but in the long run the price tag keeps going up.
  - gitonthescene 1y ago
    Best guess is that your analysis is missing some detail. People not tools write programs. Also any serious discussion here ends up in politics. If you design your software so that the programmers are fungible then the software suffers regardless of your choices.
    - jacquesm 1y ago
      > Best guess is that your analysis is missing some detail. What do you base that guess on? I'm not saying it couldn't be done, I'm just saying that it sometimes just isn't worth it. > People not tools write programs. Yes. And just like people sometimes write crazy manifestos there isn't much point in fixing them, the purpose that they might have served is most likely better addressed by replacing them entirely. > Also any serious discussion here ends up in politics. Everybody knows HN doesn't do politics ;) > If you design your software so that the programmers are fungible then the software suffers regardless of your choices. Programmers are fungible not because they are cast from the same mold, but because - assuming they are responsible people - they can look past their present day horizon to the future, where after a lot of context switching they have to revisit that which they have made before, or, where they have to take over someone else's project, either because that person moved to a different role or because they've moved on entirely. It is with such a future in mind that you can, if you want, make the life of that person a little bit easier by focusing on clarity of thought rather than terseness in expression. Nobody ever died for want of a few keystrokes more, but I'd have been a lot happier if some people made a habit of writing down first what the pile of executable spaghetti they wrought was supposed to be doing in the first place. If you have not seen how bad it can get then more power to you. Just one anecdote, which I may have posted on HN before, but a long time ago I worked for a game studio where there was a programmer who got into a fight with management. He left and I had to take over his project. All of the variable names were fruits and all of the functions were vegetables (or the reverse, as I said, it is long ago). There were no comments. But there were some bugs that needed fixing. Clearly in his mind programmers were not fungible, and in my view the software suffered from his choices. So the one isn't necessarily a guarantee of the other (ok, n=1), though you might find them together every now and then. I've seen some absolutely brilliant code that was clever and clear. That's the kind of thing that I aspire to, not to see how far I can push the CPP to do stuff it was never intended to do in the first place. We have contests for that sort of thing but it isn't the kind of construct that you should foist off on others in your line of work. Not if we're ever going to get serious about that engineering thing. Recreational programming, that's a different story. Go wild, and I really hope you enjoy it. But if you submit your preprocessor based magical DSL as a pull request I'll nix it.
ryao 1y ago
ZFS has a very nice set of macros that work very well: https://github.com/openzfs/zfs/blob/master/include/os/freebsd/spl/sys/sysmacros.h https://github.com/openzfs/zfs/blob/master/include/os/freebs... See P2PHRASE() and friends. They were inherited from OpenSolaris.

5- 1y ago

> as long as you remember what you've built yes! like any craft, this works only if you keep practising it. various implementations of k, written in this style (with iterative improvements), have been in constant development for decades getting very good use out of these macros.

switchbak 1y ago

Seems to me that this is now exponentially true with AI coding assistants. If you don't understand what you're adding, and you're being clever - you can quickly end up in a situation where you can't reason effectively about your system. I'm seeing this on multiple fronts, and it's quickly becoming an unsustainable situation in some areas. I expect I'm not alone in this regard.

gitonthescene 1y ago
I’d bet that a lot of the work done with AI assistants is decidedly _not_ clever.

gitonthescene 1y ago

Losing control of a project is likely more due to the programmers on it than the tools they use. IMHO _anything_ done consistently can be reasoned about and if necessary undone.

jacquesm 1y ago
Not necessarily. Sometimes the rot goes so deep that there is really no way out. And the C pre-processor has figured prominently in more than one such case in my career. And it was precisely in the kind of way that is described in TFA. For something to be doable it needs to make economic sense as well and that's the problem with nightmare trickery like this. Initially it seems like a shortcut, but in the long run the price tag keeps going up.
- gitonthescene 1y ago
  Best guess is that your analysis is missing some detail. People not tools write programs. Also any serious discussion here ends up in politics. If you design your software so that the programmers are fungible then the software suffers regardless of your choices.
  - jacquesm 1y ago
    > Best guess is that your analysis is missing some detail. What do you base that guess on? I'm not saying it couldn't be done, I'm just saying that it sometimes just isn't worth it. > People not tools write programs. Yes. And just like people sometimes write crazy manifestos there isn't much point in fixing them, the purpose that they might have served is most likely better addressed by replacing them entirely. > Also any serious discussion here ends up in politics. Everybody knows HN doesn't do politics ;) > If you design your software so that the programmers are fungible then the software suffers regardless of your choices. Programmers are fungible not because they are cast from the same mold, but because - assuming they are responsible people - they can look past their present day horizon to the future, where after a lot of context switching they have to revisit that which they have made before, or, where they have to take over someone else's project, either because that person moved to a different role or because they've moved on entirely. It is with such a future in mind that you can, if you want, make the life of that person a little bit easier by focusing on clarity of thought rather than terseness in expression. Nobody ever died for want of a few keystrokes more, but I'd have been a lot happier if some people made a habit of writing down first what the pile of executable spaghetti they wrought was supposed to be doing in the first place. If you have not seen how bad it can get then more power to you. Just one anecdote, which I may have posted on HN before, but a long time ago I worked for a game studio where there was a programmer who got into a fight with management. He left and I had to take over his project. All of the variable names were fruits and all of the functions were vegetables (or the reverse, as I said, it is long ago). There were no comments. But there were some bugs that needed fixing. Clearly in his mind programmers were not fungible, and in my view the software suffered from his choices. So the one isn't necessarily a guarantee of the other (ok, n=1), though you might find them together every now and then. I've seen some absolutely brilliant code that was clever and clear. That's the kind of thing that I aspire to, not to see how far I can push the CPP to do stuff it was never intended to do in the first place. We have contests for that sort of thing but it isn't the kind of construct that you should foist off on others in your line of work. Not if we're ever going to get serious about that engineering thing. Recreational programming, that's a different story. Go wild, and I really hope you enjoy it. But if you submit your preprocessor based magical DSL as a pull request I'll nix it.

ryao 1y ago

ZFS has a very nice set of macros that work very well: https://github.com/openzfs/zfs/blob/master/include/os/freebsd/spl/sys/sysmacros.h https://github.com/openzfs/zfs/blob/master/include/os/freebs... See P2PHRASE() and friends. They were inherited from OpenSolaris.