12 ms·
Given that Java doesn't have typedefs how would you reduce the verbosity of : ConcurrentHashMap<String, Integer> foo = new ConcurrentHashMap<String, Integer
by chittis 16y ago
Given that Java doesn't have typedefs how would you reduce the verbosity of :
ConcurrentHashMap<String, Integer> foo = new ConcurrentHashMap<String, Integer>();
- jarin 16y agoI would argue that you don't really need to, since auto-completing code editors and displays with enough resolution to support more than 80 columns are pretty ubiquitous.
- Groxx 16y agoThere you're largely screwed, but Java is well-known for being extremely verbose, and of course there will be languages that don't have basic features others have had for decades. 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); But yes, it's a pain. Java's largely a pain.
- jedsmith 16y agoI see your Java, and raise you Objective-C: 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]; This isn't to kick off pet language wars, by the way, just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java.
- Groxx 16y agodisclaimer: I have not tried these. Totally pulling these from a quick googled-refresher of macros. #define withZip someoneCouldntComeUpWithAShorterNameWithZipcode #define dictWith dictionaryWithObjectsAndKeys or #define dictWith NSDictionary dictionaryWithObjectsAndKeys so you can [dictWith: key, value, key, value] :) I forget, does XCode intelligently handle macros? Or does using a macro destroy its helpful features, like code completion? I actually have a "hashWith" utility function for my .NET code. Saves me a ton of ugh-induced headaches.
- Fargren 16y agoI haven't worked a lot with XCode, but I remember using macros without problem.
- jedsmith 16y agoDoing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to context switch to a header just to mentally resolve symbols. Instead of using a macro for the selector: NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil]; It would probably be far more efficient to macro the entire call using C99's variadics: NSDictionary *frob = DICT(v1, k1, v0, k0); Still wouldn't walk that road, personally.
- leon_ 16y agoYup, macros are a bad idea in that regard. Had to work on a codebase where the prior programmer had fancy defs like _dict k1, v1, k2, v2, k3, v3 dict_ I wasn't too happy about that :/
- deleted 16y ago[deleted]
- Groxx 16y agoThe reason I went for the selector is because it makes the macro into essentially a function-typedef. I don't know any languages which allow typedefs to specify things like `Class.short = Class.super_long_name_here`, even though it's essentially the same concept, especially if looked at from a C standpoint. It's a minimally-intelligent text replacement. 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.
- extension 16y agoWhile it can get a bit silly sometimes, I've come to really appreciate the verbosity of Obj-C method calls. Explicit parameter names make them very self-descriptive, and grouping the entire call within brackets makes structure obvious. Compare: canvas.drawImage(kittens.subImage(vec2(10,10),vec2(20,20)),vec2(30,30)) vs [canvas drawImage:[kittens subImageAt:vec2(10,10) withSize:vec2(20,20)] at:vec2(30,30)]
- rtaycher 15y agoYes but some of the examples of obj-c I've seen look ridiculously wordy compared with the smalltalk equivalents (even if you ignore op overloading). (setObject: forKey:) vs (at: put:). for ex.
- Stormbringer 16y ago"just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java." Dude. Are you still using CGA? Unless for your IDE you're running emacs on your wristwatch or phone there's no place for that shit in the real world, and you have no excuse. Ditch that green cathode ray tube, here, have 50c and go buy yourself a real monitor. :D
- glenjamin 16y agoLines longer than 80 chars are harder to scan, and sticking to this rule allows tiling of windows. Maximising code windows on a widescreen is a huge waste. Even with long lines the average line length will be far shorter. This is Guido's reasoning for keeping PEP8's rule to 80 chars.
- berntb 16y agoIt is fascinating to see people having 24+" monitors -- and seeing ca 30 lines of code on their screen, because of the real estate eaten by their IDEs. 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?
- gnosis 16y ago"Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe." You can't print code longer than 150 characters wide? Since when?
- berntb 16y agoSigh, are you trolling or new? OK, I'll answer. 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.
- jbooth 16y agoYeah, 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.
- mhansen 16y agoDo something like the Google Collections Library does: HashMap<String, Integer> foo = Maps.newHashMap(); The return type of newHashMap is determined by the type of foo, so you don't need to repeat the generic types in angle brackets. public static <K, V> HashMap<K, V> newHashMap() { return new HashMap<K, V>(); } http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?com/google/common/collect/Maps.html http://google-collections.googlecode.com/svn/trunk/javadoc/i... (I'm not a fan of Java myself, but there are some tricky ways to cut down on its verbosity)
- bpodgursky 16y agoThe Collections class built into Java has a lot of timesavers like this too--singleton, singleonList, singletonMap, and Arrays has stuff like Arrays.asList( ... ). 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();
- deleted 16y ago[deleted]
- cabalamat 16y agoI'd write the code in Python (or indeed any sensible modern language). foo = {}
- leon_ 16y agoand then you get an int instead of a string and your python app explodes. let's not start on "sensible modern" languages.
- cabalamat 16y agoYes, you do get bugs in Python due to variables being the wrong type... however the time it takes to fix them is vastly less than the time it takes to write the reams of boilerplate that Java requires (not to mention the cognitive overload caused by said reams of boilerplate). My ideal would be an optionally typed language.
- xyzzyz 16y agoWhat if you want to create an instance of other type of dictionary? {} works only for built-in dicts.
- IDisposableHero 16y agoDoesn't Java have any kind of type inference for variables yet? C# allows you to say var foo = new Dictionary<string, int>(); and foo's type is infered as Dictionary<string, int>
- nradov 16y agoJust declare a new class with a short name that extends ConcurrentHashMap<String, Integer>.