When the g'parent poster commented that 1) it's a known troll but 2) the information is correct anyway, I decided to look further into the topic.

* I had graduated 4 years earlier. Many companies don't care about GPA at that point.

Banning him now makes me think the developers of Thunderbird are ego maniacs.

    HashMap<String, Integer> foo = Maps.newHashMap();

  public static <K, V> HashMap<K, V> newHashMap() {
    return new HashMap<K, V>();
  }

(I'm not a fan of Java myself, but there are some tricky ways to cut down on its verbosity)

Also it's rarely important that you know the actual type of Map you're using (the interface is what's important), so you can just call

Map<String, Integer> foo = Maps.newHashMap();

The closest you can get in Java is to wrap it in a private, internal class. Which also lets you rename some verbose or frequently-combined operations, say:

  foo.someoneCouldntComeUpWithAShorterName() -> wrapped.succinct()
  -- or --
  foo.store(val);
  foo.store(val);
  foo.store(val); // I hate void functions...
  -> wrapped.store(val,val,val);

    NSString *thing = [NSString stringWithFormat:@"Result: %@", [foo someoneCouldntComeUpWithAShorterNameWithZipcode:08205 name:@"larry" parcels:5]];
    NSDictionary *request = [NSDictionary dictionaryWithObjectsAndKeys:@"iphoneapp/0.1", @"User-Agent", @"news.ycombinator.com", @"Host", nil];

  canvas.drawImage(kittens.subImage(vec2(10,10),vec2(20,20)),vec2(30,30))

  [canvas drawImage:[kittens subImageAt:vec2(10,10) withSize:vec2(20,20)] at:vec2(30,30)]

  #define withZip someoneCouldntComeUpWithAShorterNameWithZipcode 
  #define dictWith dictionaryWithObjectsAndKeys
  or 
  #define dictWith NSDictionary dictionaryWithObjectsAndKeys
  so you can [dictWith: key, value, key, value]

I actually have a "hashWith" utility function for my .NET code. Saves me a ton of ugh-induced headaches.

Instead of using a macro for the selector:

    NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil];

    NSDictionary *frob = DICT(v1, k1, v0, k0);

IMO, something like `[NSDictionary with:key,val,key,val,nil]` is far less brain-taxing than `DICT(key,val,key,val)`. It fits without modifying the language or the syntax, it merely makes something long shorter, and the usage implies it does nothing "shiny" - you even keep the class name you're calling, making it clearer what you should be expecting, and it still allows access to all other parameters without modification or even thinking differently. DICT(...) is ambiguous about what kind of dictionary it's returning.

I wasn't too happy about that :/

This is Guido's reasoning for keeping PEP8's rule to 80 chars.

To add maiming to injury, these guys write in modern Cobol (a.k.a Java).

Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe. (I love my iPad, but It'll be iPad 3 before it is half as nice for browsing code [edit: as paper].)

I have about 2 full pages of code on the same size of monitor. Of scripting language. I doubt that I have abnormally bad memory or write too complex code... I just like to be productive.

Edit: oK, downvote if you want. But please also add a counter argument for wasting all that screen area?

You can't print code longer than 150 characters wide?

Since when?

The point of printing and browsing code is that it is easier and nicer than to read it on a screen (you'll have a portable with you at the cafe anyway to search, annotate, etc.) If you get lots of broken lines, it isn't readable.

Point was, you lose a capability with long lines -- a nice way to go over code. This is important for many of us.

Edit: Point jedsmith, write it off as grumpy-old-man syndrome. Sigh, I just can't get that this isn't understood by everyone, anymore.

We no longer live in the days of typewriters or daisychain printers with fixed column widths.

We now have these wonderful things called laser printers which can print using fonts.

Fonts are resizeable. Even to the point that 150+ columns could be fit on one unbroken line.

And even lines that long can be quite readable if you print in landscape.

Second, in what you quote from: easier and nicer than to read it on a screen.

So your argument seems to be that it is equally nice to read fewer lines of paper in a smaller font. Huh? Also, my eyes can't handle 4 pages on a page any more -- and your eyes won't be able to do that after 40, either.

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.

  buf[thisVariableIsTheLoopIndex] = foo(...);

  buf[i] = foo(...);

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.

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.

Such programs must be a joy to read.

It's one or the other.

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"

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).

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 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 , 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.

I agree. Everyone on earth agrees with you. I don't know if I've ever in my whole career seen a >1 character loop index variable name. Congrats.

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.

  var foo = new Dictionary<string, int>();

   foo = {}

My ideal would be an optionally typed language.

Comfort comes from trust and exposure, among other things, and I'd say that most white men have more relationships with women than with people of color.

The legacy and history of the feminist struggle and the civil rights struggle, although related, are vastly different. I would be careful equating the two under any circumstances.