Hacker News Reader

Comment by smcl | Hacker News Reader

I was genuinely curious how this can be considered clear, readable code that someone would like to write, maintain and support since it flies in the face of all the usual conventions. I will not enumerate them here, you know them.

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

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

3. you are trolling, in which case good job I guess since I spent like 5 minutes typing this comment out

View on HN

Sure.

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.

I've read and appreciate your previous posts. They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand.

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.

Thanks for giving this an actual shot. I appreciate it's alien tech, but it's something I've grown quite fond of over the last few years and I enjoy talking about it.

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

Speaking of kOS: any chance we can get some updates? I know a bunch of people (myself included) who are really really excited about it.

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?

http://www.kparc.com/b/

i can confirm, geocar's understanding of the code is correct

If you are interested, try something like this to start making sense of the code:

  cc -E m.c | indent | grep -v INDENT | less

and separately read k.h for typedefs etc.

Reply on news.ycombinator.com