Comment by arboles
5 days ago
We know, the beginning of the article tells us his C code is APL-inspired. So many comments that just summarize the article on a surface level.
5 days ago
We know, the beginning of the article tells us his C code is APL-inspired. So many comments that just summarize the article on a surface level.
Yes, but... even if you know that it is APL inspired, that does not change the fact that this is not how you want to write C.
The C pre-processor is probably one of the most abused pieces of the C toolchain and I've had to clean up more than once after a 'clever' programmer left the premises and their colleagues had no idea of what they were looking at. Just don't. Keep it simple, and comment your intent, not what the code does. Use descriptive names. Avoid globally scoped data and functions with side effects.
That doesn't look smart and it won't make you look smart, but it is smart because the stuff you build will be reliable, predictable and maintainable.
Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.
Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?
Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.
(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)
That's a great question.
I found this on SO:
https://stackoverflow.com/questions/59553295/selective-macro...
Maybe that would work for your use case?
What I like about your question is that I always assumed the answer was a hard 'no' but that appears not to be the case.
1 reply →
The beginning of the article talks about not learning APL--specifically mentions that he's not here to talk about APL--and proceeds into a wide-eyed dissection of the C without mentioning APL syntax again. It also doesn't, literally, say that the C is like APL; it says Arthur is an APL guy who writes weird C code. Another comment disagrees that this is APL style at all--which is it?? I think you could have given me more credit than this. I read the article and participated as best I could. I'm always happy to bump APL related articles so they get more visibility.
It's irrelevant that someone doesn't think the code is APL-inspired. Their disagreement is as much with the article as your comment. I felt like what is written in the article already implied what I then read in your comment. Credit where due, the disagreement with the article probably would've not been posted if the implications in that part hadn't been re-stated plainly. Comments like these can be useful as pointers to specific aspects of an article, where conversations can be organized under, now that I think about it.
Dunno why electroly is dragging me into this but I believe you've misread the article. When it says "His languages take significantly after APL" it means the languages themselves and not their implementations.
3 replies →