Comment by rwillink

2 years ago

He showed K @ Royal Society & bunch of apl & aplus guys were there. Someone asked , where are the comments? AW said comments get out of date with all the changes, if you can’t read the code you Shldnt be working on it. We then all looked at each other..

24 comments

rwillink

Reply
082349872349872  2 years ago

So far the highest ratio of comment to code I've seen is Hsu's thesis (~200 pages of commentary[0] to ~20 lines of code[1]) at 10 pages/line.

[0] https://scholarworks.iu.edu/dspace/bitstreams/dcbd5240-8454-...

[1] https://www.bonfire.com/co-dfns-thesis-edition/

(a) come to think of it, theses are one and done

(b) thanks to Kragen for pointing out this 02019 work!

msla  2 years ago

This immaturity is one reason I don't like array languages: They ape mathematical conventions but mathematicians are interested in communicating, if only with other mathematicians, and so write clearly and understandably. That source code (if you can call it that, as I'm not entirely convinced it's the form Whitney himself programs in) is the opposite of clear to the point of being comically dense, in every sense of the term.

Concision is the handmaiden of clarity.

  • harrison_clarke  2 years ago

    i spent a day writing code like that. it becomes readable surprisingly quickly.

    i don't think i'm going to get into the practice of doing it to that extreme, but i'll probably adopt the multiple-things-per-line part for side projects, and skip the shortening of keywords

    with a wide monitor, you can have 3 files like this open at a time. you can fit a surprisingly large program on the screen at once, which is the benefit of coding like that

hi-v-rocknroll  2 years ago

> if you can’t read the code you Shldnt be working on it

An ultimate expression of insider elitism and knowledge hoarding, which can be a self-interested asset to profitable, closed-source, specialized software.

For everyone else, code should present no surprises whenever possible with semantic expressiveness and reserve comments for explanation of surprises, design choices, and protocols.

  • xelxebar  2 years ago

    I don't know about you, but if you don't know the basics about woodworking and have no interest in learning, I certainly don't want you building my furniture. That, um, has nothing to do with elitism.

    There is a real tradeoff between making code friendly to the uninitiated and making code ergonomic for the expert. It's completely natural that non-initiates feel unwelcome when the code is written for domain experts. In your company's codebase, is it really best to optimize for onboarding newcomers over optimizing for the productivity of your engineers? Where along that spectrum maximizes your goals?

    Are we building chairs or are we building chair-builders?

magicalhippo  2 years ago

> if you can’t read the code you Shldnt be working on it

I don't know this AW guy, but to me that's a huge red flag and a sign that a programmer hasn't worked on anything substantial. Ie non-trivial stuff that's maintained by a team over time.

Being able to read the code is irrelevant, as the comments should tell you why the code is doing what it's doing.

For example, yeah I trivially can see the code is doing a retry loop trying to create a file with the same name.

That looks like a bug, if you can't create the file with that name, you change the name in the retry loop.

But the comment will tell me this is due to certain virus scanners doing dumb stuff, so we might have to try the same name a few times.

Sure, good code will have few comments as most of it should be self-documenting through good structure and names of classes and variables. But in non-trivial code there will always be places where it is not obvious why the code does what it does.

  • JonChesterfield  2 years ago

    Defining substantial as written by a team over a long period of time seems to be putting the value in the wrong place. Is the important thing what the software does, or that it took a lot of people a long time to write it?

    • magicalhippo  2 years ago

      I didn't say long time to write it. I said maintained by a team over time.

      Sure there might be some substantial software that was written as a one-off (ie not modified after release), but that's the minority by far.

  • hi-v-rocknroll  2 years ago

    > hasn't worked on anything substantial

    This isn't the case. It's more likely a lack of business socialization combined with individual hyper-achievement. Reminds me of Ian Pratt in some ways.

    An annoyance in tech, both startups and corporate, is technically-capable people but with outsized egos.