5 ms·
This is highly intriguing, but I must ask why the JS community has this fascination with obscure identifiers like "_". It decreases readability when what shoul
by hamburglar 13y ago
This is highly intriguing, but I must ask why the JS community has this fascination with obscure identifiers like "_". It decreases readability when what should be a logically-chosen descriptive identifier for your class is replaced with a single character that visually recedes into the language syntax. Edit: I've grudgingly given jquery a pass on this because of its ubiquity, but come on, a stream library? Not to mention the fact that a reasonably popular lib already seems to have squatted on underscore.
- wcummings 13y agoIn my codebases, literally 1/10 lines or more contain at least one call to underscore.js, frequently more than one (not even including async). Its for brevity. If you wrote out underscore.* or Highland.* your code would become hard to read. These are utility functions that are used heavily. I'm excited about this, as someone who uses underscore.js and async together, heavily.
- hamburglar 13y agounderscore.js is a pretty good sized collection of utilities, which is why you call it a lot. I am having a hard time believing you're going to be constructing so many Highland streams that you need a one-character identifier for it to increase readability.
- wcummings 13y agoIf you look at the full docs, there is a lot of overlap, highland provides a lot of of the functions from underscore.js, and since from what I can tell its trying to unify the "javascript utility belt", I can only imagine more will be added.
- al2o3cr 13y ago"highland provides a lot of of the functions from underscore.js" "A lot of the functions" (versus "all of the functions") sounds like a one-way ticket to readability hell, since it means that an inattentive reader may assume the functions ARE from Underscore.
- wcummings 13y agoTo me the benefit of a convenient shorthand outweighs this, someone would figure it out really quick, seems like a non-issue. A few different libs use $ and the world doesn't end.
- ryanatkn 13y agoJS devs rely heavily on libraries to do things that most programmers would expect the language to handle. $ and _ have been adopted as toolkit identifiers and are littered throughout most JS codebases. Highland does much of what one would expect from _ via Underscore/Lodash. I'd bet most people think they improve readability.
- deleted 13y ago[deleted]
- badman_ting 13y agoJust seems like a silly thing to get hung up on.
- hamburglar 13y agoNaming is important for code readability. I think a lot of people recognize that. Which is why I'm so baffled by this trend of "screw it, I won't even bother with a name! Call everything underscore!"
- gruseom 13y agoPlease don't bikeshed in technical threads. One comment on something like this is more than enough; zero is probably better. When a new thing comes out, the discussion should focus on what's significant about it.
- deleted 13y ago[deleted]
- caolanmcmahon 13y agovar Highland = require('highland');
- hamburglar 13y agoYes, clearly you can do that, but it's obviously not your intent. All the docs use _ as the class name, and that's what you use internally. The class is named "_" and that's what people using it are going to expect to see if it becomes popular. You could make a better choice.
- caolanmcmahon 13y agoI think I'm getting the hang of HN ;)
- hamburglar 13y agoBut seriously, it seems like a pretty neat library. I just think your nomenclature is the suxxors and eventually we're going to look back on this trend and think, "boy, making everyone reading your code wonder which _ you're talking about is a pretty silly way to save a couple characters."
- bigonlogn 13y ago> You could make a better choice. But you can call it whatever you want, so... who cares? The choice is yours... Being a pedant is hardly constructive.
- e12e 13y agovar ‾ = require('highland'); // Meet overline, the new underscore
- Cthulhu_ 13y agoI agree; what I personally wonder is why Underscore and similar libraries don't make use of Javascript's prototype business and add methods to the array and object prototypes? Probably things I'm overlooking here, but, [1, 2, 3].map(stuff) is much nicer than _.map([1, 2, 3], stuff) and the like.
- b3n 13y agoIt's considered bad practice to add add methods to the prototypes of built in objects because it has the chance of breaking other people's code.
- jashkenas 13y agoHa ha. You're describing the state of affairs before Underscore existed, back when functional-ish programming in JavaScript was ruled by Prototype.js: http://prototypejs.org/ http://prototypejs.org/ ... which added a lot of useful methods to native prototypes. While handy in controlled and limited environments, mucking about with native prototypes quickly becomes extremely dangerous and difficult — once you have two third-party modules on the page that expect different versions of your patched prototype method ... once you have a new version of a browser that implements one of your previously-extended functions, but does it differently — you're pretty well screwed. Both of those things tended to happen in large sites.
- hamburglar 13y agoWhereas with _.map, you always know exactly which implementation you're getting, right? :)
- jashkenas 13y agoActually, you do. You've loaded it, and you can lock it down privately to your library or app with _.noConflict(). You can have ten different versions of Underscore loaded on the page, living in peace and harmony, in ten different third-party modules. Not that you should. But that you could.
- rubiquity 13y agoUnderscore uses the "_" variable because, well the library is actually named "underscore." Highland uses the "_" because... I don't have anything nice to say.