How is it unreadable? I've spent a fair amount of time digging my teeth into it, and I find it fantastic. It's terse, but far from unreadable.
I tend to label code that makes me do that "unreadable"; it's not that I literally can't read it (I routinely deal with worse) but it requires more effort than I consider reasonable for the medium it is presented in.
https://bitbucket.org/ngn/k/src/master/m.c
It is plain to any developer that this fits all definitions of "unreadable" and honestly I think in this case it falls on you to explain why you think it isn't.
False.
I am a developer. It is readable to me.
> I think in this case it falls on you to explain why you think it isn't
Why code isn't unreadable?
What a silly question!
You simply don't know how to read it.
If you do not know Java, you might say all Java code is unreadable. Why would you expect any other language to be different?
Honestly I think that either one of three things is going on here:
1. you can look at m.c, identify a line like "A1(a1,atnv(tX,1,A_(x)))A2(a2,atnv(tX,2,A_(x,y)))A3(a3,atnv(tX,3,A_(x,y,z)))A2(aA,atnv(tA,2,A_(x,y)))A2(aa,atnv(ta,2,A_(x,y)))" and easily understand what it means in the context of the ngn/k interpreter
or
2. you understand the code on the same level the rest of us do (can parse it but need to manually take notes on what everything means) ... but you want people to think you belong to group #1
or
3. you are trolling, in which case good job I guess since I spent like 5 minutes typing this comment out
cc -E m.c | indent | grep -v INDENT | less
The variables x,y,z are used to describe the first, second and third arguments. This is a common convention, so you get used to it.
tX, tA and ta are type enums.
A1(f,b) is just a 1-ary function f with the body b; A2 2-ary, and A3 3-ary. A_(f...) is a list of A (box) objects; literally (A[])({f1, f2, ... fn}) to avoid an extra definition.
atnv is a mnemonic for allocate of (t)ype, le(n)gth, (v)alues. This is not dissimilar from Arthur's ktn(t,n) function, except it also fills the buffer with the values (memcpy).
These are allocation wrappers for the rest of the interpreter.
I've tried to write some about why this style is better on HN previously:
- https://news.ycombinator.com/item?id=10876975
- https://news.ycombinator.com/item?id=8476294
and I'm used to a certain amount of abuse from people who think I'm "trolling" because I have adopted a similar style for my own work:
- https://github.com/geocar/dash/blob/master/d.c#L63
- https://github.com/geocar/con/blob/master/con.c
I don't let it bother me though. Occasionally you meet people who can be convinced to take a certain leap of faith, and then you get to have very interesting conversations about making software that you can't have otherwise.
Perhaps you've heard this said of other things as well: That learning lisp makes you a better programmer even if you do not use lisp. This thing here, is kind of like that.
On the other hand, I think that there are two aspects of this style that need to be separated - the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code. There is something else to the style that might be applied to get those, and perhaps that would be more important to teach than the ability to read 'notation-like' code (for lack of a better name).
I do understand the claim that the identifier style is what helps you understand and review the code much better, so it may be an enabler.
> They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand.
Oh they're not the only one. Look at maths papers from the last ten years versus just twenty years ago: So much more verbose! So hostile to brevity!
The benefit to a good notation is keeping in your head the solution.
The downside to a good notation is that it keeps people from contributing to the solution that don't understand the notation.
My conjecture: People who can't learn the notation can't contribute for other reasons.
My second conjecture: This shit isn't as hard as people think it is.
> the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code.
This is not true! When I wrote the first kOS kernel, I wrote it with newlines and tabs because I didn't know any better. When I rewrote it in this style, I noticed a lot of code duplication that I could only see because the kernel now fit on a screen. This made my program smaller (original kernel was around 50kb the new one was around 30kb) which left more room in cache for programs making them faster as well. I was also able to see bugs that were only visible because I could see the caller and the callee at the same time and correct them. It all adds up!
Since then, I've had numerous opportunities to see similar effects in other programs. Learning how to use notation has made me a better programmer.
Also, elsewhere you said: "Perhaps then this isn't C, but a language compatible with (at least a few) C compilers."
Since you know Arthur, is there any chance you can ask him to specify the license of b?
""" riverrun, past Eve and Adams, from swerve of shore to bend of bay, brings us by a commodius vicus of recirculation back to Howth, Castle and Environs.
Sir Tristram, violer d'amores, fr'over the short sea, had passencore rearrived from North Armorica on this side the scraggy isthmus of Europe Minor to wielderfight his penisolate war; nor had topsawyer's rocks by the stream Oconee exaggerated themselse to Laurens County's giorgios while they went doublin their mumper all the time.... """
The difference is that I don't think anyone makes the claim that Finnegan's Wake is readable or easy to work with. Everyone's pretty much agreed that this is a very unusual style that takes an enormous amount of time and effort to appreciate and understand. The style is fine, if it's someone's "thing" then great, more power to them. But what gets me is people pointing to this style of coding and feigning ignorance or surprise that others could find it troublesome and making a big point of saying "Well it's easy for me, I guess you're just not smart" when confronted about it
Hey listen, I understand that other people find it troublesome.
The thing is that I think it's something people can learn if they want, and I think there are benefits to doing so.
I only object to the label "it's unreadable" because it demands the author (or someone else) make it "readable" to cure, when the right fix is to fix the programmer: to give them the experiences needed to be able to read it.
That's admittedly not very easy for the novice reader- certainly it would be much better for them to write less dense and use a smaller vocabulary, and that's why, just with English, we start novice readers with less dense study materials that utilise a smaller vocabulary.
However it's a mistake to think that just because business English is a bit more dense than Goodnight Moon, that it's unreadable, and it's a worse one to think its lack of accessibility is without some value to the writer.
I should think people should want to seek out that value in exactly the same way.
Though I disagree with the claim of unreadability, for the reason you've mentioned—readability is a matter of conventions, never an absolute—I don't think it really 'demands' anything. If I were to call this a non-standard C coding style, then I don't think you or anyone would disagree; but that is just a statement of fact, not a demand to standardise it. I think a claim of unreadability can be read charitably in the same way, as a statement of the fact that "people used only to the standard C programming style will find this difficult to read", not any demand or even request that it be otherwise.
If saagarjha means here be dragons they should say so: Fewer people would misunderstand them!
But I think you and I both know this is not what they meant.
Heylisten,Iunderstandthatotherpeoplefindittroublesome.Thethin
gisthatIthinkit'ssomethingpeoplecanlearniftheywant,andIthinkt
herearebenefitstodoingso.Ionlyobjecttothelabel"it'sunreadable
"becauseitdemandstheauthor(orsomeoneelse)makeit"readable"tocu
re,whentherightfixistofixtheprogrammer:togivethemtheexperienc
esneededtobeabletoreadit.That'sadmittedlynotveryeasyforthenov
icereadercertainlyitwouldbemuchbetterforthemtowritelessdensea
nduseasmallervocabulary,andthat'swhy,justwithEnglish,westartn
ovicereaderswithlessdensestudymaterialsthatutiliseasmallervoc
abulary.Howeverit'samistaketothinkthatjustbecausebusinessEngl
ishisabitmoredensethanGoodnightMoon,thatit'sunreadable,andit'
saworseonetothinkitslackofaccessibilityiswithoutsomevaluetoth
ewriter.Ishouldthinkpeopleshouldwanttoseekoutthatvalueinexact
lythesameway.Arthur Whitney once wrote: One day I asked him, "Roger, do you do math in English or Cantonese?" He smiled at me and said, "I do it in Cantonese because it's faster and it's completely regular."
In this comment you make the opposite point: that one should write in a style readers will most easily understand as they currently are.
You may think, because one example is of code and the other of prose, that those points are not in conflict--but they are.
All are proper English, as any linguist will tell you, but Scots English is more or less mutually unintelligible.
AAVE is relatively understandable because of pop-culture, but without previous exposure to it, someone who didn't have any influence to it would be confused in an environment that heavily uses it.
And if you got sat in front of a Cajun family, despite the relative amount in common with them, linguistically, you'd be bewildered at some of their heavily French-influenced vocabulary and structure.
Conventions, style, standards, etc are explicitly created for the purpose of lowering the barrier to entry for understanding and maintaining a piece of code. The maximum number of potential users who can quickly interpret and be productive with said code is the purpose of the concept of readability.
Unless you are claiming a specific advantage for the stylistic choices over simply taking more care to write more conventionally readable code, I don't understand your objection to the term unreadable.
"unreadable" in common parlance of the software world is not taken to mean literally impossible to parse but simply, not optimised for ease accessibility for the maximum number of people in the shortest amount of time. I'm afraid that means that the fact there is debate over this to such an extreme suggests this is at the very least, not very readable.
As with everything, there is a balance required. Unreasonable lengths should not have to be undertaken to maximise code readability. I do wonder what advantages you attribute to this style which you think justifies any potential trade-off in readability? What is gained for such a potential expense?
Perhaps then this isn't C, but a language compatible with (at least a few) C compilers.
This language is something you can learn to read as effortlessly as you read other languages (perhaps more so), you simply haven't learned how to read this yet.
If you want to suggest readability is defined in that way and no other, how can someone who does not know this language make a statement about its readability?
I'm not sure I'm convinced with this line of thinking, because it's incredibly exclusionary, just watch:
> I do wonder what advantages you attribute to this style which you think justifies any potential trade-off in [me being unable to read it]? What is gained for such a potential expense?
Why would anyone want your input on something you do not understand?
Why would anyone write in Chinese if you cannot understand Chinese?
What is the point in this kind of definition of "readability"?
Does that make sense? Surely it's much more useful to talk instead about what the capability of the programmer is that can read and write and maintain code written this way, instead of the possible missed opportunities of the programmer that cannot?