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.

▲

jacquesm 3 days ago | parent | next [-]

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.

▲

piaste 2 days ago | parent [-]

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

▲

jacquesm 2 days ago | parent [-]

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.

	▲	piaste a day ago \| parent [-]
		It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version? Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.

▲

electroly 3 days ago | parent | prev [-]

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.

▲

arboles 3 days ago | parent [-]

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.

▲

mlochbaum 3 days ago | parent [-]

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.

▲

arboles 3 days ago | parent [-]

The article: "Let's make sense of the C code by the APL guy"

Do you think the article meant to say it was more likely that the code wasn't inspired by APL?

▲

mlochbaum 3 days ago | parent [-]

I think the article expresses no position. Most source code for array languages is not, in fact, inspired by APL. I encourage you to check a few random entries at [0]; Kap and April are some particularly wordy implementations, and even A+ mostly consists of code by programmers other than Whitney, with a variety of styles.

I do agree that Whitney was inspired to some extent by APL conventions (not exclusively; he was quite a Lisp fan and that's the source of his indentation style when he writes multi-line functions, e.g. in [1]). The original comment was not just a summary of this claim but more like an elaboration, and began with the much stronger statement "The way to understand Arthur Whitney's C code is to first learn APL", which I moderately disagree with.

[0] https://aplwiki.com/wiki/List_of_open-source_array_languages

[1] https://code.jsoftware.com/wiki/Essays/Incunabulum

	▲	arboles 3 days ago \| parent [-]
		I unfortunately glossed over the part of the original comment that gives it substance: "The most obvious of the typographic stylings--the lack of spaces, single-character names, and functions on a single line--are how he writes APL too." That's backing for a claim. Also, I haven't once written APL. I think this might've been borderline trolling, just because of how little investment I have in the topic in reality. Sorry.