The code is unreadable, formatted in the style of an IOCCC entry–and this looks intentional. I wonder why.
I'm still not sure that this terse style in C improves reading. I agree that lots of concise idioms present in APL family of languages do improve reading (once you picked them up), and I do like lots of short functions more than a number of long functions (another contrast to IOCCC, where you don't see many functions). But those languages are tailor made to maximize this aspect. You for example don't think much about loop invariants in APL and friends because they are mostly implicit, and in turn you get very good refactorability. Would it improve other non-array languages? I doubt.
It did seem a little "off" to me, but I couldn't put my finger on it; thanks for describing what was wrong with it.
> It is likely that you can actually understand the thing with only proper renaming.
Fair point, but I usually like to keep my use of renaming to understand code for the decompiler :)
It’s important that many/most cultural norms are not optimal, they are arbitrary. So don’t immediately discount something for looking weird.
The point of this style isn’t obfuscation, it’s clarity and compactness. The compactness boosts the signal to noise ratio and allows the programmer to retain more information in working memory. I haven’t programmed C like that and wouldn’t, but I definately understand and respect the theory behind it.
I have on the other hand written q like that, at first skeptical of the style. But after a couple days, I wouldn’t have it any other way. Being able to fit your entire program on a single screen has pretty profound productivity benefits. It also makes IDEs unnecessary.
For other code structured like this, check out Kona, J or kdb+/q.
In general, I don’t think refusing to believe is a very useful attitude. See: Chesterton’s Fence.
When I first saw examples of how terse K and APL code gets, my thought was “obviously, the language was designed to solve this specific example or it wouldn’t be this terse”. But after the 100th or so significantly different example, one can’t NOT admit that the problems are simple, and common practices are just incredibly bloated..... which leads some (me for example) to adopt a much terser style.
However my poor statically typed brain is keeps struggling on how to mix Haskell (...) with APL/k. Video on that topic is here[0].
One of the reasons I wrote iKe was to demonstrate that the same primitives which are well-suited to constructing databases and financial models can be applied to computer graphics. With little more than bindings that supply appropriate IO capabilities, you can even write games in K:
https://github.com/JohnEarnest/ok/blob/gh-pages/ike/examples...
https://github.com/JohnEarnest/ok/blob/gh-pages/ike/examples...
That part I have some experience with, and I think that's not the case. I was taught APL (in a CS course) along with a hundred or so other students, and it was nearly universally disliked; IIRC, it only resonated with some of the EE people. The department's administration was even written in APL, and nobody wanted to touch it. After finishing my assignments, I've never wanted to look at it again. So I, for one, doubt the style is universally likable.
I agree; it's definitely a niche thing. It takes quite a while to get into it. Even if you understand the basics; if you don't like 'puzzling with code', you won't be idiomatic. And most people don't like puzzling with code; they want to get things done. You need to do quite a lot with it to start recognising the idioms, but once you do it's a blast. And it makes both reading and writing quite easy. That's why I think doing something like the advent of code in one of these languages will help a lot; I had to quit this year because a project at up my time I reserved for aoc19. The exercises I did though where cool to solve in k.
False. I can read it just fine. Ergo, it is readable.
You cannot read it, and that is a different problem.
> I wonder why
Because there are benefits you do not understand.
It is very strange to me that you assume someone who does something doesn't get anything out of it simply because you don't get anything out of it.
https://news.ycombinator.com/item?id=22009831
> It is very strange to me that you assume someone who does something doesn't get anything out of it simply because you don't get anything out of it.
I don't believe I assumed that?
This is clearly your lack of ability here.
However, when I see someone doing something I cannot do, I want to learn more. That's how I get better. I think there are other people out there like that who might just need a little bit of encouragement, and that's why I reply: Not to convince you, but to convince them it's okay to learn something that few people understand (but those that do think is really cool!)
I think that your second paragraph is great, but this first paragraph, which comes across as a snide judgement of your parent as an SO-reliant trend-follower, is unwarranted. Your parent may have made too hasty a declaration of unreadability, but that tells you only what kind of code saagarjha wants to read, not, except indirectly at best, what kind they write.
And yet accurate.
People who follow trends are like other people who follow trends, at least in that way. They will never see something new so long as they do doing what everyone else does.
Understanding why someone else makes a difference choice can be illuminating. Given that the author of the original k has written at least 5 or 6 versions of the language interpreter from scratch every time in this style, he must be doing something right. Right?
Not necessarily, but others have pointed out reasons why one might write code this way.
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?