Map the end key to (, and the left arrow to ), and you're hitting both characters with your thumbs.
Then maybe map brackets to PageDown and the down arrow, and braces to PageUp and up arrow for an easy reach with the ring finger. Or those big delete/backspace keys in the middle could be useful.
No self-respecting vim user needs any of these keys.
Finally a language I can get behind. I was never able to get into closure, but couldn't put my finger on the reason why. If only more languages could redefine themselves to be more usable and admit they have been outdated for years.
> The [] keys are closer to the central row of your keyboard than the less comfortable ().
> You don't need to hold the shift key to type [] therefore you can code faster.
That's true only for a standard US-qwerty keyboard layout. My [] are located at altGr + (). These guys clearly haven't though i18n through. And if there are such blatant omissions on their front page, who knows what's lurking in the code ?
I can use it, but I can't touchtype it, so I do feel a little stupid sometimes typing on qwerty and probably couldn't do it without at least glancing at my hands. Its worth it for me though because I spend so much more typing on my own colemak keyboard than I type on qwerty.
The standard recommendation is to type Sholes 5-10 minutes a day to maintain your ability to hurt your wrists. I haven't bothered to do that and it's a good thing I leave my keycaps alone for the few times I run a VM that is stuck in US layout. I've lost the rolls and fingerings as I've gained them with Colemak.
It's really sad when I have to use someone else's computer, but then I remember that my emails were never longer than a tweet when I first started with Colemak.
> And if there are such blatant omissions on their front page, who knows what's lurking in the code ?
There probably are bugs but not because they're unaware of every keyboard layout. It's far easier to accommodate different languages, currencies, number formats, etc than it is to accommodate every keyboard layout.
English and US keyboard layouts (or its close relatives), for better or worse, dominate the programming world.
I don't think the conclusion you've drawn, that there must be issues with the code because your local keyboard layout hasn't been thought of, is logical. That's like saying that because the language keywords and standard library aren't in your native language, there must be dragons lurking in the code.
Having said all this, Clochure does appear to be a nice little April 1st joke and should be flagged with prejudice!
Even for US keyboards, the obviously better step is to replace "(" and ")" with "9" and "0" -- familiar key location but without the shift key. Plus you avoid using the pinky finger which is an ergonomic win.
Edit: note that there might be a small tradeoff in readability.
I know some lisp programmers who uses this[1] to code.
The left foot pedal open a parenthesis, the right one close all parenthesis.
I find that's quite clever, though, considering the use of theses two characters.
I've said it before: j and k are the obvious replacements if you want to ruthlessly Huffman-code your Lisp-typing experience. I, mean how often do you really see j or k inside the text of an atom? Not very often.
Seriously though, the problem isn't parentheses, the problem is prefix notation and the "inside-out" nature of composed function calls. The latter admittedly can happen in imperative code too, but is encouraged in functional programming. It just makes the code an immediate turn-off to try to read for me.
I'd like to see a lisp that allows all the kinds of different brackets. ( 〖〗〘〙〚〛〈〉() [] <> and maybe more.) I think i can make the code easier to read. All we would need was a emacs script. When the cursor is on the closing bracket there could be a drop down menu. But aside from Haskell Language creators seem to be god dammed afraid of unicode in the language.
Racket allows for (), [] or {} in code and it seems that in practice [] is used to distinguish some syntactic forms that have nested parens from normal function calls such as the let and cond forms. So instead of
After using TCL for several years and actually liking it, I have to admit the brackets look better. Plus lately I'm all about anti-rsi and shift parens is getting to be a major hassle.
(a constant gets pushed onto the stack. functions like "power" and "+" operate on the stack)
So this also works:
2 30 2 power +
Although I don't really use it anymore, my calculator (an HP scientific calculator) also uses reverse polish notation, so you can keep intermediate values on the stack, and do complex calculations without using parentheses at all. This is also good for keeping people from asking to borrow your calculator in math class. :)
What is the syntax that you posted? It looks just like RPN in reverse. Ok, that was a stupid question. I just figured out that is just "polish notation." It must keep a stack of operations that don't have their operands yet.
One thing to add is that [] is much closer to the right pinky finger, which immensely boost the typing speed comparing to ().
Now that's what I call a true re-thinking in code productivity.
If we go another step further we might consider using ;
;+ 1;- 3 2;;
I am liking it already.
Why not use some other delimiter than parentheses?
We tried various possibilities. Square and curly brackets lose because they are less directional than parens (left and right differ in fewer pixels); < and > lose because they don't wrap around enough to enclose expressions longer than tokens.
76 comments
[ 5.0 ms ] story [ 127 ms ] threadMap the end key to (, and the left arrow to ), and you're hitting both characters with your thumbs.
Then maybe map brackets to PageDown and the down arrow, and braces to PageUp and up arrow for an easy reach with the ring finger. Or those big delete/backspace keys in the middle could be useful.
No self-respecting vim user needs any of these keys.
(Also, maybe I'm insane, but I think I do find the square brackets a bit easier to read...)
Something about vertical lines being easier to "separate out", while parentheses, being curved, blend in more with the letters. Who'd have thought?
http://en.wikipedia.org/wiki/Poes_law
> You don't need to hold the shift key to type [] therefore you can code faster.
That's true only for a standard US-qwerty keyboard layout. My [] are located at altGr + (). These guys clearly haven't though i18n through. And if there are such blatant omissions on their front page, who knows what's lurking in the code ?
(It is not so bad to hit both shift keys to get back åäö.)
Edit: mpyne -- good thought, but we international users have our national keyboards in the fingertips, it is imho generally easier to switch layouts.
Edit 2: dkersten -- my productivity-porn time wasting is used up by browsing Emacs packages. :-) I'll check it out if I get wrist problems.
It's really sad when I have to use someone else's computer, but then I remember that my emails were never longer than a tweet when I first started with Colemak.
For [], I have to move my hand to the right, away from home position.
There probably are bugs but not because they're unaware of every keyboard layout. It's far easier to accommodate different languages, currencies, number formats, etc than it is to accommodate every keyboard layout.
English and US keyboard layouts (or its close relatives), for better or worse, dominate the programming world.
I don't think the conclusion you've drawn, that there must be issues with the code because your local keyboard layout hasn't been thought of, is logical. That's like saying that because the language keywords and standard library aren't in your native language, there must be dragons lurking in the code.
Having said all this, Clochure does appear to be a nice little April 1st joke and should be flagged with prejudice!
Edit: note that there might be a small tradeoff in readability.
[1]: http://img2.generation-nt.com/xbox-360-pedalier_090320025800...
Just enclose j and k in parentheses on those rare occasions. Problem solved.
Really? So now... in place of "lots of irritating superfluous parentheses" you get "lots of irritating superfluous square brackets"?
meh
"So on the eve of April 1st we sat down in a brainstorm session with a team of PLT experts."
So this also works:
Although I don't really use it anymore, my calculator (an HP scientific calculator) also uses reverse polish notation, so you can keep intermediate values on the stack, and do complex calculations without using parentheses at all. This is also good for keeping people from asking to borrow your calculator in math class. :)What is the syntax that you posted? It looks just like RPN in reverse. Ok, that was a stupid question. I just figured out that is just "polish notation." It must keep a stack of operations that don't have their operands yet.
Why not use some other delimiter than parentheses?
We tried various possibilities. Square and curly brackets lose because they are less directional than parens (left and right differ in fewer pixels); < and > lose because they don't wrap around enough to enclose expressions longer than tokens.
http://www.paulgraham.com/arcfaq.html