All you have give up for this is tightly-packed arithmetic statements, like this:
5*5-3
Instead, you have to give your tokens some breathing room:
5 * 5 - 3
Yes, but in this case it's not about readability, but about extremely significant whitespace. Forgetting a space and your code has a totally different meaning.
There's an easy fix for part of the problem: bind shift-space to underscore. Yes, you still require shift, but IMO it's the stretch not the shift that makes typing an underscore jarring.
Unless you use Emacs (as the author seems to), in which case you have S-Space bound to starting/ending selection. But in general yes, one can rebind underscore to something that doesn't require pressing Shift.
It moves your pinky, your smallest and least mobile finger, to move up two rows, which requires a typical person to completely flatten that finger. Either that, or you end shifting your whole hand. Which means that you end up moving your hand a lot while typing because the underscore may easily be the most common keyboard character encountered in some programs.
Obviously everyone has different shaped hands - but for me, the pinky doesn't need to be entirely flat to reach the underscore. I also don't have to shift my whole wrist.
Either way, reaching the + key on QWERTY-102 is objectively more difficult than the underscore [uses the pinky, is farther away than the underscore from homerow], and also requires a shift-modifier. I use + far more than _ while I'm coding. (And I'm currently writing most of my code in Go, so I use _ quite a bit since it's a blank identifier.)
Maybe I just have big hands, but it honestly doesn't impede my typing at all to add an underscore to the text.
One of the most efficient everyday optimizations I've made in the past few years was to adopt the lisp-style naming convention for my local file system hierarchy. Removing all capitalization and special characters (other than the dash) makes navigating via CLI much easier. And having a predictable naming scheme means I rely on tab completion slightly less too, as I have more predictive capability regarding how I might have named things in the past. More generally, treating my home folder as, essentially, an exposed API for which I'm the primary consumer has paid dividends.
The Kinesis Advantage keyboard effectively does this, except the left half is for backspace. Since it has very conveniently placed modifier keys like ctrl under my thumbs, I remapped capslock to shift so that it's on the home-row.
Some Japanese keyboards do this. Tiny spacebars and extra modifier keys. I've always wanted to buy one and put keys like backspace and delete on my thumbs.
I think the left side is more suited for backspace. Which is how my Compaq keyboard is setup - the key is physically divided into two.
Perhaps the spacebar is just too big, and could be divided better into other modifiers. My left thumb is usually wasted (though not on a Mac, where the thumb can easily reach the Command key.)
Some people however - seem to alternate thumbs on the spacebar - or rather use the other hands thumb to the hand that just typed a character. I personally always use the right thumb to space.
This misses one point when comparing Lisp to languages like Ruby. Lisp does not have infix notation. Therefore, you never have to worry that "foo-bar" (the symbol) could ever be confused with "foo - bar” the operation subtracting bar from foo. That’s because in Lisp, foo-bar is written "(- foo bar).”
Since a Lisp programmer spends all his time writing "(- foo bar),” when he sees “foo-bar,” his brain easily parses it as a symbol, and he never needs to wonder whether it should actually have been “foo - bar” with spaces to separate the infix operator from the symbols representing variables.
I don't think this has anything to do with infix versus prefix. It works in Lisp because the reader knows (roughly speaking) that symbols are terminated by whitespace or parentheses.
If you wrote a version of Ruby that was still infix but where you needed to put spaces around all symbols, then "foo-bar" would work fine there, too.
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 accident by mistakenly typing foo-bar and having the parser think you meant a hitherto undefined symbol.
Whether that’s a worthy tradeoff is a matter of opinion, and I’ll take Avdi’s word for it that he believes the benefits of calling symbols foo-bar outweigh the odd time you might type the wrong thing. I’m just pointing out in addition to the “whitespace is the separator” argument you both make, there’s also the “foo - bar doesn’t mean foo subtract bar” argument.
Except that in Lisp "-number" is totally different than "- number" and I rarely have to worry about it when I code in Lisp. I code in both Lisp and Ruby on a regular basis, and I don't see the ability to write "x-y" as any real advantage. I already separate my tokens with white space by default because I see "x-y" as a single token.
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.
I know that, but it’s highly incidental to my point, as I’m sure you’re aware. It’s obviously true that (foo - bar) is legal, as is (foo-bar), as is (foo - bar + bash), as is (foo-bar + bash) and so on, but they’re still much less likely to be mistaken for foo-bar in an infix language.
I’m sure you knew perfectly well that I meant you never type foo - bar meaning foo subtract bar :-)
Such rules ("all operators must be space-hugged") are special cases, and I think raganwald's point is that such special cases make at-a-glance mental parsing more difficult. Lexing and parsing in Lisp is much more straightforward than in, say, Python. Hence, mental lexing and parsing has fewer barriers. This is a direct result of using s-expressions, which implies no in-fix operators.
I'd add that it also works because nobody ever says "foo-bar". What "foo" and "bar" actually are, plus context, lets the (human) reader know what's going on.
Even if I don't know what programming language you're talking about, if I see x2-x1 or margin-75 I know you probably mean subtraction, and if I see last-name or message-id you probably mean a single identifier. I've seen plenty of Lisp code that says things like x2-x1 in docstrings (because it is shorter) and I've never found it to be confusing.
I write code slower than my typing speed anyway. This sort of typing efficiency obsession leads people to use dvorak or crazy non-standard keyboards. No thanks, not worth caring about.
I don't understand why people wouldn't be obsessed with typing efficiency.
Granted you don't need to type all that fast for programming. However I do have to type full-speed when writing documentation, composing an e-mail, working on a presentation, etc.
Not to mention Dvorak and "crazy non-standard keyboards" demonstrably reduce RSI, which is a far greater benefit than typing speed. (Unless you like having disgusting chemical compounds injected into your wrists; or want your wrist cut open so that doctors can work on some of the most delicate tissues in the body.)
disagree. like_underscores. concerns about using shift key seem misplaced & for those who have some form of birth defect that prevents use of two fingers simultaneously, keyboard remapping is easy.
With me as well, though it is getting slightly annoying to the people I work with that it's been transferring over into some of the PHP code I have to write.
That's a bit contrived considering you're (a) writing a sentence and (b) you use some really short words (i.e., "I", "It", and "Is"). I think for things like FileNotFound or similar its not really that different in readability, and comes down to preference.
Using dot as a name separator is actually the convention the R programming language, so it's certainly not a new idea. Ironically, it used to be the case that R did not allow _ as a variable character.
Semicolons. Underscores. Spaces. Tabs. Every couple weeks it's some new minutiae profiled as the cause of all the world's problems. Don't people have better things to focus on than this?
Some people are detail-oriented. How can you expect Mr. Grimm to obsess over corner cases in his code but shrug at what he perceives are problems with representing it?
The people who think only in terms of the “big picture” while glossing over the details are not programmers. They are “architects.”
EDIT: This second statement is probably not correct. I would use strikethrough if I could. But the first statement still rings true with me, many programmers are detail-oriented, which means that they care about lots of things other people would consider irrelevant. Whether this is, on the whole, a good thing or not is another matter. But I do not think it is surprising.
I feel that you're mostly right. However I think we all focus on different details, to an extent.
For example, I'm a great typist so the underscore key has never really bothered me.
But to call the author out on being detail oriented would be inane of me. I myself don't like keyboards that have small backspace keys. I also still hate OS X for having the window control cluster on the top-left corner.
I know I certainly get paid to think about the details. The only variable here is which details.
Interesting that he calles dashes "ordinary, easy-to-type, recognizable, [and] visually unambiguous."
What he's referring to as a dash is actually a hyphen (-), which is pretty ambiguous when compared to the en dash (–) and em dash (—), both of which require modifier keys to type (and are frequently used in prose, to counter another of his claims). Fortunately, I've never seen em dashes or en dashes used in code.
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 were meant to be taken in that context. If he'd chosen to preempt the pedantic readers by making that context explicit, it would have only diluted the article with noise that most people would rightly assume is implied by the context.
I don't know what your keyboard looks like, but mine doesn't have en- or em-dashes on it, and I wouldn't even consider them for a programming language syntax.
[1] Even when using en-dashes and em-dashes in prose, they can often be typed with multiple consecutive hyphens, e.g., '--' and '---' in LaTeX.
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 silly. (Though I'll admit, the point of it being improperly handled with underlined fonts is certainly a valid complaint.)
>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.)
Lot's of editors do. In Eclipse, for one, it's common to see function names and such shown as hyperlinks when you click on them (with underlines), which makes their definition open (like a function call is "linked" to the function definition).
I can see where that would be ambiguous. I think he mentioned using shift once or twice per sentence as a baseline for comparing how often we should have to use the shift key when coding. As for the underlining issue, the other reply already mentioned that many editors will underline code.
Come to think of it, I do know some editors that support HTML rendering inside comment blocks.
How would you use it for coding, though? Unless you stripped it before the compile phase I would think any formatting in a rich-text format would choke up almost any interpreter or compiler.
It doesn't need to be rich text. It can just be the way the editor does syntax highlighting. Say, for example, underline all function names. The compiler won't know anything about this style and will therefor not choke on it.
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.
people outside the US call them dashes as well, though perhaps not with the same frequency. ... --- ... is not 'dot dot dot hyphen hyphen hyphen dot dot dot', for example
Only nerds know what underscores are? I think anybody who grew up in the early Napster/Limewire/Kazaa days knows what an underscore is because they probably downloaded a file like Michael_Jackson_-_Beat_It.mp3
Any time I have some feelings, I try to clean up the emotions and use my reason. Underscores solve a lot of problem and are useful in technology and programming and then suddenly i_love_underscores.
As a daily python user at home and at work, I realized I'm typing a huge amount of underscores. My keyboard supports rebinding keys and programming macros (a feature I've never used until now) so I remapped an extra \ key on it so that it would type _ without me holding shift. Small change, but it's much less of a strain.
I've been thinking about trying to find a reasonable way to map the underscore to shift+space, but I'm not sure if that would somehow break some application that expects otherwise. It also seems to be quite difficult to achieve on Windows without registry hacks (I presume it would be easier on Linux, but haven't tried it yet).
It's very easy on Windows with the strange and wonderful AutoHotkey [1]. I recommend the more advanced AutoHotkey_L fork [2], but this script should work in either version.
Install AutoHotkey and then create a file called Underspace.ahk with this content:
; Underspace for AutoHotkey
; Converts Shift+Spacebar to underscore
#SingleInstance force
+Space:: Send _
Now launch that file.
Try Shift+Space and it should type an underscore for you.
If you want to stop the script later, find a green "H" in your system tray and right-click it.
After you try it, I'll be curious how it works out for you. Myself, after trying it for just a minute or two, I'm not so sure if I like it. I'm finding a lot of spurious underscores before capitalized words, or after a word like "I" that ends with a capital letter. That's because I've been sloppy about the timing of when I press the Shift key before or after a space.
So I won't be using this script myself (not that I need it - I don't like to code using names_with_underscores) but maybe others will find it useful.
This tool looks really cool. I see what you mean about the spurious underscores... think I'll try it out for a day and see whether or not I can live with it. Thanks!
After writing a decent amount of Clojure recently, underscores do seem ugly, but I think I find commas even more annoying. I can accept underscores for the reasons raganwald mentioned, but having to write [1, 2, 3] instead of just [1 2 3] bothers me more than it probably should.
I noticed this too after using Coffeescript, going back to plain JS.
It's especially annoying when shuffling array elements or function parameter around: all items need to be separated by a colon, except for the last one, that must not have a trailing comma, making line swapping a nightmare. Drives me nuts.
Maybe it's just me, but I never notice issues like this. Some people want to completely optimize their experience, like when Vim users tell me it's better than Emacs because they don't have to reach for the cursor keys.
I dunno. For some reason this super-optimisation of keystrokes doesn't bother me. Avoiding reaching for the mouse is good, but I don't particularly care if I have to hit shift.* Maybe I prefer to think more and type less, or something. I can't quite say.
* Admittedly the French keyboard where all numbers in the top row are shifted, and symbols are unshifted, drives me kind of crazy, but that could just be due to hard in-grained training on an American keyboard layout.
It's like the difference between wearing silk underwear and hessian underwear. Or being able to code while listening to an audio book vs needing peace and quiet. It's not a question of thinking less, or thinking more, or being more careful. Some people can put up with this stuff, and some people can't.
Really just a matter of convention, and dash is too heavily associated with minus. A single underscore is a permissible variable name in some languages; in Go it has a special meaning (blank identifier). Would a single dash be as well? For example, how would you interpret
i - -
Is it i (minus) (variable named dash)? And is `i--` a legitimate variable name? Maybe Ruby doesn't have this construct, but then it would have a completely different naming contention from existing languages.
130 comments
[ 4.1 ms ] story [ 202 ms ] threada = 5
b = 3
everybody from nearly every programming language would expect that after
c = a-b
you will find c to be 2 not nil (or throwing an exception or whatever)
I agree with the OP. CamelCase and underscores are both scourges.
:).
Properly typing an underscore should utilize two hands and shouldn't require a stretch at all.
Either way, reaching the + key on QWERTY-102 is objectively more difficult than the underscore [uses the pinky, is farther away than the underscore from homerow], and also requires a shift-modifier. I use + far more than _ while I'm coding. (And I'm currently writing most of my code in Go, so I use _ quite a bit since it's a blank identifier.)
Maybe I just have big hands, but it honestly doesn't impede my typing at all to add an underscore to the text.
(I mean, it's not like I'm physically incapable. I just instinctively hit SPACE with my right thumb.)
Getting used to using my left thumb would just be awkward.
I also have a nasty habit of using the LSHIFT exclusively. Even when it's not technically appropriate to do so.
Japanese ThinkPad USB keyboard (with TrackPoint!): http://i.imgur.com/4dWVJ.jpg
Perhaps the spacebar is just too big, and could be divided better into other modifiers. My left thumb is usually wasted (though not on a Mac, where the thumb can easily reach the Command key.)
Some people however - seem to alternate thumbs on the spacebar - or rather use the other hands thumb to the hand that just typed a character. I personally always use the right thumb to space.
Since a Lisp programmer spends all his time writing "(- foo bar),” when he sees “foo-bar,” his brain easily parses it as a symbol, and he never needs to wonder whether it should actually have been “foo - bar” with spaces to separate the infix operator from the symbols representing variables.
If you wrote a version of Ruby that was still infix but where you needed to put spaces around all symbols, then "foo-bar" would work fine there, too.
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 accident by mistakenly typing foo-bar and having the parser think you meant a hitherto undefined symbol.
Whether that’s a worthy tradeoff is a matter of opinion, and I’ll take Avdi’s word for it that he believes the benefits of calling symbols foo-bar outweigh the odd time you might type the wrong thing. I’m just pointing out in addition to the “whitespace is the separator” argument you both make, there’s also the “foo - bar doesn’t mean foo subtract bar” argument.
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.
I’m sure you knew perfectly well that I meant you never type foo - bar meaning foo subtract bar :-)
Even if I don't know what programming language you're talking about, if I see x2-x1 or margin-75 I know you probably mean subtraction, and if I see last-name or message-id you probably mean a single identifier. I've seen plenty of Lisp code that says things like x2-x1 in docstrings (because it is shorter) and I've never found it to be confusing.
Granted you don't need to type all that fast for programming. However I do have to type full-speed when writing documentation, composing an e-mail, working on a presentation, etc.
Not to mention Dvorak and "crazy non-standard keyboards" demonstrably reduce RSI, which is a far greater benefit than typing speed. (Unless you like having disgusting chemical compounds injected into your wrists; or want your wrist cut open so that doctors can work on some of the most delicate tissues in the body.)
Honestly, I've always found them to be more human readable than CamelCase.
I_think_it_is_objectively_much_more_readable
The difference in length is pretty small anyway.
Names tend to be pretty small anyway. Here are some random ones from the code I'm working on (Sococo Teamspace)
CreateVariant - a method
soLogWriteInfo - a method (I didn't write)
clHeadSSt - a circular list head for a stream
Now we just need to design a whole new language :(
The people who think only in terms of the “big picture” while glossing over the details are not programmers. They are “architects.”
EDIT: This second statement is probably not correct. I would use strikethrough if I could. But the first statement still rings true with me, many programmers are detail-oriented, which means that they care about lots of things other people would consider irrelevant. Whether this is, on the whole, a good thing or not is another matter. But I do not think it is surprising.
For example, I'm a great typist so the underscore key has never really bothered me.
But to call the author out on being detail oriented would be inane of me. I myself don't like keyboards that have small backspace keys. I also still hate OS X for having the window control cluster on the top-left corner.
I know I certainly get paid to think about the details. The only variable here is which details.
Many country specific keyboards also need modifier keys to access the hyphen.
What he's referring to as a dash is actually a hyphen (-), which is pretty ambiguous when compared to the en dash (–) and em dash (—), both of which require modifier keys to type (and are frequently used in prose, to counter another of his claims). Fortunately, I've never seen em dashes or en dashes used in code.
I think it's pretty clear from the article that his comments were meant to be taken in that context. If he'd chosen to preempt the pedantic readers by making that context explicit, it would have only diluted the article with noise that most people would rightly assume is implied by the context.
I don't know what your keyboard looks like, but mine doesn't have en- or em-dashes on it, and I wouldn't even consider them for a programming language syntax.
[1] Even when using en-dashes and em-dashes in prose, they can often be typed with multiple consecutive hyphens, e.g., '--' and '---' in LaTeX.
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 silly. (Though I'll admit, the point of it being improperly handled with underlined fonts is certainly a valid complaint.)
Lot's of editors do. In Eclipse, for one, it's common to see function names and such shown as hyperlinks when you click on them (with underlines), which makes their definition open (like a function call is "linked" to the function definition).
Well, mine does, and I used to have a co-worker who actually used it for coding. So there you go. :-)
How would you use it for coding, though? Unless you stripped it before the compile phase I would think any formatting in a rich-text format would choke up almost any interpreter or compiler.
(I'm using a Kinesis Advantage keyboard.)
Install AutoHotkey and then create a file called Underspace.ahk with this content:
Now launch that file.Try Shift+Space and it should type an underscore for you.
If you want to stop the script later, find a green "H" in your system tray and right-click it.
After you try it, I'll be curious how it works out for you. Myself, after trying it for just a minute or two, I'm not so sure if I like it. I'm finding a lot of spurious underscores before capitalized words, or after a word like "I" that ends with a capital letter. That's because I've been sloppy about the timing of when I press the Shift key before or after a space.
So I won't be using this script myself (not that I need it - I don't like to code using names_with_underscores) but maybe others will find it useful.
[1] AutoHotkey home page: http://www.autohotkey.com/
[2] AutoHotkey_L: http://l.autohotkey.net/
(minor edit for clarity)
It's especially annoying when shuffling array elements or function parameter around: all items need to be separated by a colon, except for the last one, that must not have a trailing comma, making line swapping a nightmare. Drives me nuts.
Then use a language which allows trailing commas in lists, param-lists, maps, e.g. grOOvy
I dunno. For some reason this super-optimisation of keystrokes doesn't bother me. Avoiding reaching for the mouse is good, but I don't particularly care if I have to hit shift.* Maybe I prefer to think more and type less, or something. I can't quite say.
* Admittedly the French keyboard where all numbers in the top row are shifted, and symbols are unshifted, drives me kind of crazy, but that could just be due to hard in-grained training on an American keyboard layout.
A sometimes used _ is okay. Its_using_it_almost_all_the_time_that_the_author_is_questioning.