Hacker News Reader

Comment by quadcore | Hacker News Reader

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.

View on HN

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.

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.

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?

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}

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!

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.

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

Reply on news.ycombinator.com