4 ms·

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 fi

by theamk 8y ago

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.

quadcore 8y ago
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.
- otikik 8y ago
  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.
RodgerTheGreat 8y ago
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?
- theamk 8y ago
  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}
- bakul 8y ago
  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!
3xblah 8y ago
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.

by theamk 8y ago

quadcore 8y ago

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.

otikik 8y ago
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.

RodgerTheGreat 8y ago

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?

theamk 8y ago
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}
bakul 8y ago
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!

3xblah 8y ago

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.