5 ms·

Yes, many useful names are short: point, input, output, x, y, z, origin, r, g, b, alpha, color, vector, pi, string, file, buffer, open, close, print, format, c

by junke 10y ago

Yes, many useful names are short: point, input, output, x, y, z, origin, r, g, b, alpha, color, vector, pi, string, file, buffer, open, close, print, format, copy, move, list, load, run, id, pop, push, stack, context, env, user, draw, update, refresh. Also, notice how R, G, and B have a very clear meaning when put near "color"? Context is a thing our brain manages very well.

vorg 10y ago
Many of those short names are keywords (or pre-defined identifiers) in many programming languages, e.g. string, close, print, copy in Go. Having to use another name instead can also be difficult.
- junke 10y ago
  Poetry time: (let ((copy (copy-list list))) (list copy 'copy 'let)) A 13 syllabic verse (7+6, with caesura) (but yes, you are right)
  - fiddlerwoaroof 10y ago
    FWIW, I never have really found the ambiguity caused by using the same symbol as both a variable and a function to be a readability problem: I think people are generally pretty good at things like noun/verb ambiguity and so this kind of ambiguity sort of "clicks" with us. What has bitten me many times is accidentally overwriting a builtin function like max or len in python and then scratching my head about the strange errors that result from this.
    - junke 10y ago
      Overwriting is not so much a problem of naming than one of dynamic updates: some environments do actually display a warning when you change a global binding, which helps.
      - fiddlerwoaroof 10y ago
        That helps, but I find that a Lisp-2 like Common Lisp (I.e. A language with different namespace for variables and functions) is a more intuitive programming environment than languages with a single namespace.
        junke 10y ago
        I prefer Lisp-2 too.
        kazinator 10y ago
        I'm extremelly well informed about Lisp-1 versus Lisp-2. I chose Lisp-2 for my own Lisp dialect, with special support for working in the Lisp-1 style: there is a way to code with higher-order functions without ever using the dialect's equivalents of the funcall function or function operator. I thereby consider the Lisp-1 vs. -2 question to be a solved problem. The requirements which drive the preference for either are all valid. I, the designer, have simply taken both requirements and integrated them. Of course, requirements like, "I want to use list as a variable name without shadowing the lisp function" directly conflicts with "I want to reference functions and variables the same way without function or funcall". However the conflict can be confined down to the argument list of an individual form. I.e. "Sure, you can have both, just not in the argument list of the same form."
        fiddlerwoaroof 10y ago
        Incidentally, I've been using TXR a bit for text-processing recently, it's generally been pretty nice once I've figured out what exactly needs to be done to get the matching to work, but the various failure modes for the pattern language aren't very intuitive.
        kazinator 10y ago
        I don't disagree. If debugging that sort of thing were intuitive, we'd all be coding in Prolog. It's like an invisible "if" hidden in every statement which branches elsewhere if there is no match. @(assert) can help; if you know that something that follows must match, you get an exception if it doesn't. I used asserts in the man page checker: http://www.kylheku.com/cgit/txr/tree/checkman.txr http://www.kylheku.com/cgit/txr/tree/checkman.txr
- 0xD3ADB33F 10y ago
  I've gotten the habbit of removing the last vowel in those cases. Not always pretty but when documented it's pretty transparent.
0xD3ADB33F 10y ago
There's also the implicit assumption of underlaying knowledge. I remember writing some graphics routines and looked at some examples, but they always seemed to consist of a mess of single variable names. After reading up on the theory it became clear that they were all the conventional mathematical constants used in the formulas to derive the algorithm. If you were intimate with the math these names would be the obvious choice, yet if you were an outsider they would seem indecypherable. I now prefer to use simple english terms and put the math terms next to them as a comment, rather than the other way around. A caveat is that actual formulas might become a bit lengthy.

by junke 10y ago

vorg 10y ago

Many of those short names are keywords (or pre-defined identifiers) in many programming languages, e.g. string, close, print, copy in Go. Having to use another name instead can also be difficult.

junke 10y ago
Poetry time: (let ((copy (copy-list list))) (list copy 'copy 'let)) A 13 syllabic verse (7+6, with caesura) (but yes, you are right)
- fiddlerwoaroof 10y ago
  FWIW, I never have really found the ambiguity caused by using the same symbol as both a variable and a function to be a readability problem: I think people are generally pretty good at things like noun/verb ambiguity and so this kind of ambiguity sort of "clicks" with us. What has bitten me many times is accidentally overwriting a builtin function like max or len in python and then scratching my head about the strange errors that result from this.
  - junke 10y ago
    Overwriting is not so much a problem of naming than one of dynamic updates: some environments do actually display a warning when you change a global binding, which helps.
    - fiddlerwoaroof 10y ago
      That helps, but I find that a Lisp-2 like Common Lisp (I.e. A language with different namespace for variables and functions) is a more intuitive programming environment than languages with a single namespace.
      - junke 10y ago
        I prefer Lisp-2 too.
        kazinator 10y ago
        I'm extremelly well informed about Lisp-1 versus Lisp-2. I chose Lisp-2 for my own Lisp dialect, with special support for working in the Lisp-1 style: there is a way to code with higher-order functions without ever using the dialect's equivalents of the funcall function or function operator. I thereby consider the Lisp-1 vs. -2 question to be a solved problem. The requirements which drive the preference for either are all valid. I, the designer, have simply taken both requirements and integrated them. Of course, requirements like, "I want to use list as a variable name without shadowing the lisp function" directly conflicts with "I want to reference functions and variables the same way without function or funcall". However the conflict can be confined down to the argument list of an individual form. I.e. "Sure, you can have both, just not in the argument list of the same form."
        fiddlerwoaroof 10y ago
        Incidentally, I've been using TXR a bit for text-processing recently, it's generally been pretty nice once I've figured out what exactly needs to be done to get the matching to work, but the various failure modes for the pattern language aren't very intuitive.
        kazinator 10y ago
        I don't disagree. If debugging that sort of thing were intuitive, we'd all be coding in Prolog. It's like an invisible "if" hidden in every statement which branches elsewhere if there is no match. @(assert) can help; if you know that something that follows must match, you get an exception if it doesn't. I used asserts in the man page checker: http://www.kylheku.com/cgit/txr/tree/checkman.txr http://www.kylheku.com/cgit/txr/tree/checkman.txr
0xD3ADB33F 10y ago
I've gotten the habbit of removing the last vowel in those cases. Not always pretty but when documented it's pretty transparent.

0xD3ADB33F 10y ago

There's also the implicit assumption of underlaying knowledge. I remember writing some graphics routines and looked at some examples, but they always seemed to consist of a mess of single variable names. After reading up on the theory it became clear that they were all the conventional mathematical constants used in the formulas to derive the algorithm. If you were intimate with the math these names would be the obvious choice, yet if you were an outsider they would seem indecypherable. I now prefer to use simple english terms and put the math terms next to them as a comment, rather than the other way around. A caveat is that actual formulas might become a bit lengthy.