6 ms·
Yeah, and congrats, now you have to hire people who already know what a foo is. The great thing about ConcurrentHashMap<Long,String> isn't writing it, it's rea
by jbooth 16y ago
Yeah, and congrats, now you have to hire people who already know what a foo is.
The great thing about ConcurrentHashMap<Long,String> isn't writing it, it's reading it. Even if you're not a Java programmer you know exactly what that is (and FWIW it's world-class on implementation). We could do with some syntactical sugar to make that constructor line a little simpler, but declaring the type and calling a specific constructor, not masking either with personal shorthand are both Good Things if someone's going to have to read that code later.
- KaeseEs 16y agoI am skeptical of the claim that verbosity for its own sake aids comprehension. To borrow an example from Rob Pike, reading buf[thisVariableIsTheLoopIndex] = foo(...); is no more obvious than buf[i] = foo(...); and indeed is more likely to slow the programmer down by killing his train of thought and mental flow.
- jedsmith 16y agoThe problem with that example is how contrived and narrow it is. All it proves is that verbosity doesn't aid loop indices. ConcurrentHashMap<K, V>, on the other hand, says everything it needs to in the name. As does NSMutableArray, and so on. Apples and oranges, here.
- gnosis 16y agoSo I suppose this leads Rob Pike to use one-character names for all the variables and functions in his programs? Such programs must be a joy to read.
- IDisposableHero 16y agoClose. Which is what I don't like about the samples that I have seen in his Go language. Code like "Fmt.PrintF" seems a step backwards to me.
- beagle3 16y agoHis code actually _is_ a joy to read and use. Some of it requires more than a passing scan. But that's true of any code worth reading - if you don't need to scan it twice, it's most probably useless and bureaucratic, and could be done away with if a better design is used.
- gnosis 16y agoI very much doubt his code is both a joy to read and made up exclusively of one-character variable and function names. It's one or the other.
- beagle3 16y agoHis local indices are usually one letter (i, j, k), his local counters are usually one letter (m, n). His accumulators are sometimes one letter - much like math expressions. He gives a more descriptive names to variables that live for more than a 10 lines or code or so. And that's way more of a joy than reading a Java sourceful of "indexThatGoesSourceThe2ndArray"
- jbooth 16y agoI really don't get what you're driving at here. Are you claiming there's a java language requirement that array indices are named with more than one letter? That's not what the screen in front of me says. "He gives a more descriptive names to variables that live for more than a 10 lines or code or so." Ok, now we're talking. I like go and Rob Pike's reputation speaks for itself but don't put words in the guy's mouth, go has strong typing in a way that's much more similar to Java than whatever your pet language is, the major difference is syntactical sugar that infers types more often, and a looser contract for interface (both of which I agree with).
- beagle3 16y ago> Are you claiming there's a java language requirement that array indices are named with more than one letter? No, but it _is_ common practice to name things with long names, rather than one letter, even if they are loop indices. E.g., in the FLTK source code, most objects inside a short loop are called "o", e.g., things like for (Widget o = window->first(); o; o = o->next()) { o->activate(); o->show(); } I think that is extremely readable, 'o' in my mind stands for object in the same way that 'i' stands for index. Have you ever seen Java code in the wild that follows such a convention? I haven't -- it's always things like theWidget or even theChosenWidget instead. > I like go and Rob Pike's reputation speaks for itself but don't put words in the guy's mouth Please don't put anything in my mouth. I'm paraphrasing pike, you may disagree with the paraphrasing, but I was referring to, http://www.lysator.liu.se/c/pikestyle.html http://www.lysator.liu.se/c/pikestyle.html , specifically the section titled "Variable names". It's about C, and predates Go by some 18 years (and Java by 6). Not any "pet language" of mine.
- IDisposableHero 16y agoPersonally, I find "thisVariableIsTheLoopIndex" to be a terrible loop index variable name. But "i" isn't great either. "index" seems to be closer to the sweet spot to me. Or "fooIndex" and "barIndex" if loops over foo and bar collections are both in play. That beats the hell out or trying to parse "i" and j" as indexes over two collections. The simple rule is that the larger the scope of the variable the longer the name - i.e. the more widely references to the var occur, the further they are from the definition, the more descriptive the name has to be.
- mhansen 16y agoI think the verbosity complaint here isn't about the length of the name, it's about having to repeat the type and generic arguments.
- jbooth 16y agoYeah, repeating the generics is cumbersome and we could do with a better syntactical sugar for that. Typically, the type's only reapeated if you're assigning to the same exact type as your constructor. In most cases, Map<K,V> foo = new ConcurrentHashMap<K,V> is more idiomatic than typing ConcurrentHashMap twice. Although concurrent is a little special because it's an implementation detail that you sometimes want to enforce via types.