Earlier quoted context omitted.
In 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.
underscore.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.
How I want to write Node: Stream all the things
21–30 of 118 posts
Re: How I want to write Node: Stream all the things
#22This 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 me…
Just seems like a silly thing to get hung up on.
Re: How I want to write Node: Stream all the things
#23Earlier quoted context omitted.
underscore.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.
If 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.
"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.
Re: How I want to write Node: Stream all the things
#24Earlier quoted context omitted.
Yes, 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.
I think I'm getting the hang of HN ;)
Re: How I want to write Node: Stream all the things
#25Earlier quoted context omitted.
var Highland = require('highland');
Yes, 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.
But you can call it whatever you want, so... who cares? The choice is yours... Being a pedant is hardly constructive.
Re: How I want to write Node: Stream all the things
#26This 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 me…
Re: How I want to write Node: Stream all the things
#27This 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 me…
I 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.
Re: How I want to write Node: Stream all the things
#28This 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 me…
I 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.
You're describing the state of affairs before Underscore existed, back when functional-ish programming in JavaScript was ruled by Prototype.js:
... 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.
Re: How I want to write Node: Stream all the things
#29Earlier quoted context omitted.
Just seems like a silly thing to get hung up on.
Naming 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!"
When a new thing comes out, the discussion should focus on what's significant about it.
Re: How I want to write Node: Stream all the things
#30I'm curious which features highland provides which RxJS doesn't. From what I understand, composable streams from any data source with backpressure support is pretty much the definition of Rx. Sometimes simplicity is a feature, too, though.
Rx doesn't handle back-pressure or laziness, so it's for only really for handling events.
Is there some way to know what kind of source you've got, or are the the sources constructed in a way that chooses which behavior you get?