Please do. Although I'll probably never write C in that style, most of us here will probably learn a few things that will eventually prove useful. (And it probably will also serve as a historical document of a "skill"(?) that is apparently soon to be lost to obscurity...)

> soon to be lost to obscurity

well, about that i’m just not so sure.

as we like to say, “skill”, for whatever reason you chose to use quotes, cannot be easily bought on a Turkish fish market.

there are people out there who write atwc, and they are not atw. the following 40 lines of c are written strictly arthur-style, and are occasionally very useful. in the faq section of the readme there is an answer to a popular question “why is it written this way, and how to learn to write software this way”.

https://github.com/kparc/pf

> please do

now that i think of it, i already did just that once, only forgot. getting old sucks, and also forgetting things is a great skill i learned from atw. as he likes to say, “kelas, ignorance is bliss”. Here you go - all you ever need to know about how to read and write atwc:

https://github.com/kparc/bcc/blob/master/d/sidenotes.md#styl...

> inequality x!=y is not used at all, because it is two chars. instead, we test with x-y, which holds true when operands differ

I think this is the line in the document that represents his coding style the most. Sacrificing legibility for plebs to save one character per comparison.

> represents his coding style the most

i agree that atw’s inequality test is a bit cheeky, but like everything else it is a matter of habit. a convention. eventually you just begin to see what is subtraction and what is comparison.

here’s another classic example of the same effect:

x=x+1

makes perfect sense to everyone, right?

wrong. to some, the right answer is “no, they are not”.

I am not saying it's bad. I kinda understand the motivation behind atw style in general. Modern code is written like prose:

    if (IsValidFile(fileName)) {
        var rawRecords = ReadFileAsRawRecordIterator(PreprocessFile(fileName), config);
        foreach (var rawRecord in rawRecords) {
            var record = ParseRawRecord(rawRecord, config);
            //and so on
        }
    }

But you have to trust the prose. At one point or another, you find a bug in some free software you haven't written yourself, open its source code and are met with ravioli code written in prose. And you cannot trust this prose because there is a bug in it. So you open this tiny method, the you open PreprocessFile, ReadFileAsRawRecordIterator, ParseRawRecord, the implementation of IRawRecordIterator, then a few more methods that these methods call themselves and try to thread the control flow through these methods, jumping from file to file. I can see how atw style code can help with that, especially after you retrain yourself to read it like math.

> it is not. this style is extremely regular, very readable and writable, and escapes a whole galaxy of typical C blunders. i can expand on that if you wish.

Please do! I'd like to learn. If you can expand on this in the README section as well that would be great.

> README

good idea, why not

for a more throw-me-in-the-water introduction, here are my notes on another famous public domain release from atw. some remarks are specific to the codebase, but essentially it is a general introduction to atwc:

https://github.com/kparc/bcc/blob/master/d/sidenotes.md

and here’s a less involved way to get lit:

https://github.com/aaalt/altc

Awesome, I'm checking these out. Thanks!