Underscores are stupid

Post by davidcuddeback » Tue, May 15, 2012, 8:40 PM UTC

drbawb wrote: post #65

davidcuddeback wrote: post #56

Earlier quoted context omitted.

He's discussing this in the context of writing code, not typography. I think it's fair to assume we're starting with the premise that we would only choose characters that are easily typed on common keyboards. Choosing uncommon characters in programming languages, such as en-dashes and em-dashes, is choosing to deliberately make our lives more difficult [1]. I think it's pretty clear from the article that his comments…

Well, the author himself is pretty ambiguous. While most of the article talks about code, the author mentions underscores being ambiguous in the context of underlined fonts. (I don't even think my text editor [for code] supports underlined fonts.) He also mentions only using shift once or twice per sentence when writing prose. So it would seem that the author is just hating on _ in all contexts. Which is kind of sill…

Post by draegtun » Tue, May 15, 2012, 9:34 PM UTC

  Personally, I'd prefer to see the English conventions carried over to
  the use of general use of hyphen and underscore in identifiers in
  the core (and everywhere else).

  By that, I mean that, in English, the hyphen is notionally a
  "higher precedence" word-separator than the space
  (or than its intra-identifier stand-in: the underscore).

  For example: there's an important difference between:

      initiate_main-sequence_detonator_phase()

  and:

      initiate_main_sequence-detonator_phase()

  The former initiates the detonator phase for the main sequence;
  the latter initiates the main phase of the sequence detonator.

  More simply, there's a difference between:

       $obj1.set_difference($obj2);

  and:

       $obj1.set-difference($obj2);

  The first is setting a difference; the second is computing a difference-of-sets.

  The rule I intend to use and recommend when employing this new
  identifier character in multiword names is that you should place an
  underscore between "ordinary unrelated" words, and a hyphen only
  between a word and some modifier that applies specifically to that word.

  Which, if applied to Temporal, would lead to:

      my $now = DateTime.from_epoch(time);

      The C method also has the synonym C.

      (These are also available through the methods C and
      C, respectively.)

      There's a C method,

      The C method returns a number 1..5

      The C method returns the day of the quarter.

      The C method returns the day of the year,

      The method C returns the second truncated to an integer.

      The C method returns the C object

  (i.e. only C actually uses underscore).

  Oh, and the optional C argument to C should probably
  become C for consistency with the C method
  (or, preferably, we should jut bite the bullet and go with C
  throughout).

  Damian

Post by maikeru » Tue, May 15, 2012, 10:58 PM UTC

auxbuss wrote: post #104

moron wrote: post #96

Earlier quoted context omitted.

That's actually not very interesting. He was talking about hyphens, but calling them dashes, because normal people do that unless they are talking about typography.

No. "normal people" call them hyphens. I think it is a mainly USian curiosity to call hyphens dashes. The Rest of the World calls hyphens, well, hyphens. It's only the US that call them dashes. I've no idea why that is.

Post by raganwald » Wed, May 16, 2012, 12:28 AM UTC

Karellen wrote: post #106

raganwald wrote: post #74

Earlier quoted context omitted.

You are echoing Avdi’s point. I understand it, I just happen to disagree with it. If Lisp was an infix language, then yes foo-bar would mean something different to the parser than foo - bar because of the whitespace. But what’s also at stake is whether that language would be readable to humans without mistakes. Part of what makes Lisp work, IMO, is that you never try to type foo - bar, so you never run into an accide…

"you never try to type foo - bar" Unless you have a function called "foo", and you want to pass it the subtraction function as it's first parameter and the value "bar" as its second. In which case (foo - bar) is perfectly valid, reasonable, and completely different from (foo-bar). Even though Lisp is not an infix language, foo-bar does mean something different to the parser than foo - bar because of whitespace.

Post by DeepDuh » Wed, May 16, 2012, 5:11 AM UTC

gurkendoktor wrote: post #88

DeepDuh wrote: post #78

Earlier quoted context omitted.

"let the compiler work its magic." if you want that, use a higher level language. One of the foundations of C is that there is as little implicit behavior as possible. I'd hate to be left in the dark whether my . will now result in a pointer or a dereferenced value and I doubt it would even work for the compiler to figure this out in all edge cases.

C is full of implicit type conversions. I think the key is that C is based on value semantics and not references, and that makes pointers full-blown values with their own address, conversions, … - something closer to C's integer types than to other languages' references, and equally picky about operators.