71–80 of 131 posts
What colour do you want your bikeshed painted today? I for one, don't like the "->" operator in C. It requires two characters and the use of the shift key. I would like that the next standard just used "." for all member access and let the compiler work its magic and guess what needs to be done. Of course that would break a sizeable amount of legacy code, but who cares about that anyway. The important is that the cod…
I think they should make keyboards with the spacebar divided, and make the left half (or I guess the right if you're left-handed) into a shift key.
(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.
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…
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.
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.
And yet we insist that a programmer be able to write every modern programming language on a 50-year-old typewriter. You know, just in case.
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.
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.)
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…
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.
What colour do you want your bikeshed painted today? I for one, don't like the "->" operator in C. It requires two characters and the use of the shift key. I would like that the next standard just used "." for all member access and let the compiler work its magic and guess what needs to be done. Of course that would break a sizeable amount of legacy code, but who cares about that anyway. The important is that the cod…
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.
Earlier quoted context omitted.
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 accide…
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 hav…
A sometimes used _ is okay. Its_using_it_almost_all_the_time_that_the_author_is_questioning.