Hacker News Reader

Comment by kelnos | Hacker News Reader

kebab-case is fine in strings, but many languages will parse that as

    BinaryExpression(Identifier("kebab"), Identifier("case"), Operator.MINUS)

I admit there's personal preference and just quirks of vision involved, but I don't think I've ever had an issue distinguishing '_' and '.'. One thing you can do, which helps also with breaking up long chains of calls that would give you a really long line, is break it up with newlines, e.g.:

    foo
      .bar_baz
      .blah()

View on HN

I believe that syntactic limitation to be a historical mistake that we keep doubling down on for no good reason. There's really no practical purpose to parse a-b as (a - b), as evidenced by popular style conventions for pretty much ever language with a binary minus operator.

COBOL has used the hyphen a.k.a. dash as the word separator in identifiers.

Then IBM PL/I (in 1964, when it was still named NPL) has replaced it with the underscore, to avoid the confusion with minus.

All the other programming languages that use underscores have taken this usage from PL/I.

Most LISP variants have continued to follow the COBOL practice, because they also have avoided the use of the minus sign as an operator.

Because ASCII includes only a single ambiguous HYPHEN/MINUS sign, as long as programs are restricted to be written in ASCII it is difficult to use the same sign both as an operator as a word separator. If U+2212 were used for the minus sign and U+002D for hyphen, with a typeface that differentiates them, the hyphen could replace the underscore, but that would not change anything for typing as they would still be two distinct keys.

For easier typing, I use a Dvorak variant, where -/_ is on the home row. Whoever uses the underscore more frequently than the minus may revert which of them is obtained with shift and which without shift.

You can try to use U+2013 en dash (–) for hyphen.

Proper hyphen is U+2010.

Hyphen, which is the correct symbol for separating words in a compound word, is much shorter than the en dash, which is used in other contexts, e.g. as a figure dash.

The en dash has about the same length as the minus sign, so they cannot be distinguished visually, which is the purpose of using different characters for the word separator and for the mathematical operator.

I think it's more about reducing cognitive load. I wouldn't want "+" to be used for anything that isn't adding, for example. Having to differentiate a-b from a - b sounds tedious and error prone.

There's precedent for this, though - 123.456 is lexed as one token in most languages, but foo.bar is three. It doesn't seem to be causing much issue in practice for readability because the context is sufficiently distinctive. Having / not having whitespace around the character would be even more distinctive, though, no?

FWIW I did write a fair bit of XPath (in XSLT context) and XQuery back in the day, which do allow kebab-case identifiers and use them for standard library names other than types, while also using minus as a binary operator. I don't recall ever consciously thinking about how to differentiate the two uses, not even when still learning the ropes coming from C++ and C#; it "just worked". Of course, this is anecdotal - it would be interesting to poll people with prior experience with kebab-case languages that have also been exposed to other styles regarding their overall preference and this specific ambiguity.

People usually don't mix up pointers in C (foo) with multiplication (foobar) nor divisions (foo / bar) with comments ( // ).

So I don't really think people would have a problem with kebab case after getting used to it for a couple of minutes.

At most it's an error of 'a-b' not in scope. Unless you have dynamic scoping or somehow have a variable 'a-b' and also want to perform 'a - b'. I think the rule that binary operators must be separated by spaces is much easier to reason about then not having certain characters usable in identifiers.

The only solution being polish notation for all operators

That’s not the only solution. You can also use different characters. In fact, kebab–case should not use minuses, but dashes, like this:

  kebab-case   // three tokens: ‘kebab’ ‘minus’ ‘case’
  kebab–case   // single token ‘kebab n–dash case’
  kebab—case   // single token ‘kebab m–dash case’

;-)

A great solution for messing with people. Much like the “smart quotes”

I'll admit to not putting space around binary operators when I write code, counting on format-on-save to fix it :)

You'll have to put one extra Space before each "-" that is an operator. But you also won't have to reach for Shift every time you had to type "_", which is usually much more common. So I think even in this case you might end up typing code slightly faster on average!

I'm a fan of that idea; I would love to see other common operators (such as vertical pipe) reclaimed for expressing operations way more common in the past decade than bit twiddling (e.g. iterator/filter chaining, like in shell pipelines).

This begs the question why we don’t allow spaces in identifiers. (We do allow them in file names for example.)

It complicates parsing significantly unless you avoid keywords altogether (i.e. all syntax is punctuation) or use some form of https://en.wikipedia.org/wiki/Stropping_(syntax) as early PLs did.

Reply on news.ycombinator.com