Hacker News Reader

Comment by otikik | Hacker News Reader

Programming is not telling the machine what to do. That's the easy part.

What programming is about, and what's hard, is telling the next programmer what the machine does.

This makes the easy part a bit easier, and the hard part much harder, than using C. And I already disliked C to begin with, for similar reasons.

View on HN

Now I think you're right, but there is two strategies which boils down to the following: "you can either make a program that's so complex there is no obvious defect, or you can make a program so simple it's obvious there is no defect."

What it says is that the hard part to make the next programmer understand what the machine does is not reading code, it's code complexity. Training yourself to read terse code is O(1), understanding code is at least O(N) where N is the number of lines of code.

Before you start arguing, try it. Try writing code as simple and succinct as possible. You won't go back to anything else because it works. It does make programming simpler and more productive.

I did, once, when I was at school. It was great - everything was so fast to type, the program (a somewhat complex game) would fit in on two screens. I almost finished it in a week.

And the I had exams, and did not touch the computer for two weeks. When I came back, I forgot it all. Cx? Dzy? Those names were meaningless.

This was a very importantly lesson - programs must be maintaineable. Unless you want to spend your entire life working on a single piece of software, you want to be able to context switch, and do it quickly.

Many people use descriptive variable names to carry semantic information.

APLers use extremely consistent, stereotypical naming conventions which also carry semantic information. Think "Hungarian Notation" except it's just the prefix part. With consistently applied terse names, the same idea will result in the same code. Easier to visually pattern-match.

It's also worth considering that longer names are not necessarily more meaningful. It's pretty common for everyday programmers to use single letters for something like a loop induction variable. Sometimes longer is just... longer. Consider these three semantically identical K definitions:

    a:{x*x}
    b:{[n]n*n}
    c:{[number]number*number}

Is that third version really clearer than the first?

Most people have difficulty with the fact that an array expression can very compactly represent some powerful functions. For example,

  (+/*)\:

is matrix multiplication. The following computes the transitive closure of a binary relation (represented as a boolean square matrix):

  {x|x(|/&)\:x}

Its core has a similar "shape" as matrix multiplication:

  (|/&)\:

So in a sense variable names don't matter all that much! To grok this code you have to stop thinking in terms of item at a time operations and start thinking of operations over collection of items. If you know how to write unix shell pipelines you are already somewhat familiar with this paradigm except that a shell doesn't provide most of the more useful features of array languages!

I think the good rule of thumb is to have longer names in bigger scopes. So a variable for short loop or an argument to 1 line function can be single char, while arguments to medium length functions are a word, and globals (including functions) are one or multiple words.

To get to your example, the preferred signature would be:

    square:{x*x}

You could have made a note of what the variable names stood for and put it at the top or end of each source file, in a separate file or even on a piece of paper.

There is nothing inherently disadvantagous to using abbreviations as long as you have a key to the abbreviations.

Cx? Dzy? Those names were meaningless.

A programmer doesn't rely on variable names to understand what the machine does, or very little. The contrary is a myth. In other terms, you always check what a variable contains anyway. That being said, I make a distinction between obfuscated code and less code. The former is about presentation, which in my opinion you're free to decide while the later is about #node in the ast. Sort of.

I hereby inform you that I, a programmer, _do_ use variable names to understand what other programmers want the machine to do.

This is 100% real, and not a myth.

> Training yourself to read terse code is O(1) understanding code is O(N) where N is the number of lines of code.

Even granting that, this:

> f[iII]{m:0;$[k:-x;W(x){x-:1;j:y;N(k)y[i]:y[+i];y[k]:j;j:f[k;y;z];$[m<j;m:j;]};{N(#y)z[i]:y[i];W(j:z){m+:1;N(j){k:z[i];z[i]:z[j];z[j]:k;j-:1}}}];m}

Is not a single line of "terse code". It's a bunch of lines of code with the newlines and spaces removed.

> Try writing code as simple and succinct as possible.

I already strive to do that (I don't always succeed). But the operating word here is as possible. Not "above anything else".

I didn't wanted to say #node in the ast. The presentation or the variable names doesn't matter in terms of less code I believe. Whitney's code is obfuscated which is distinct from less code imo. To some extent. Succinct code is kind of great.

Just to confirm, I'm saying that after the user, the most important thing is less code.

In more practical terms, I'd say try "above anything else" to see where the actual limit is. From my experience, it's way further from where traditional programming is.

Worth noting that in the Excel world (a primitive array language), for business users, dense formulas without spaces or new lines are the norm (although it is possible to use those features). Syntax highlighting and step-by-step evaluation features make it easier to work with.

"Programming is not telling the machine what to do."

What is that called then?

I am interested in controlling hardware, whatever that is called.

I think Torvalds once said in a comment that is why he wrote his own kernel. He wanted better control of his hardware. Something like that.

"... telling the next programmer what the machine does."

You mean what the code does?

This sounds like drudgery. I can see why one might be overly sensitive about how source code looks before even attempting to read it.

I am just a hobbyist writing programs for myself. There is no "next programmer".

Unless you are writing one-off programs that you never come back to -- which is certainly possible! -- it's possible that "future you" is the next programmer.

That is true. There are some I never edit as long as they continue to work. Others I am continuously editing on a regular basis. Others are really "one-offs" that I keep just in case. If I need them again in the future, I might rewrite from scratch if my learning has changed significantly since the last edit.

I have found the best thing I can do for the "future me" is to keep programs relatively small and keep the number of files low. This is one reason I like terseness and the idea of keeping "everything" (almost) on one page/screen.

I am just not capable of understanding a large project as deeply as I would like. I thought this paragraph summarises the issue well:

"To them, once you've sufficiently studied that screen or two of code, you can understand all of it at the same time. If it's spread out over thousands of files, it's very difficult to understand all of it, which leads to bugs, unnecessary abstraction, and the need for advanced tooling just to work with your own project's code."

This is from https://github.com/tlack/b-decoded

Bingo.

It is tiring and unproductive to parse other programmers' BS made-up semi-languages. If your shit is so complex you can't handle "tab-switches" you are doing it wrong. Stop crafting these 20-dimensional rhombicosidodecahedrons if you work in a team, please. Just use regular paper and fold a bunch of swans.

Reply on news.ycombinator.com