You can name it whatever you want. That's one of the benefits using a module system.

So why do we have this trend of using meaningless and ambiguous identifiers, and in particular, why would you do it in example code? I thought that as an industry, we'd moved past the folly of giving things terse and unhelpful identifiers in order to save a few bytes or keystrokes.

I think the example code is written using _ to convey the similarity for those familiar with underscore/lodash. In 2015, that's most JS developers.

Just hazarding a guess.

You notice that all the libraries that do this (underscore, jQuery, Lodash, et al.) offer features that are almost language features. Things so useful but generic that they could almost be integrated into the language syntax.

In this case, there's also the problem that 'Stream' is already used by node.

> In this case, there's also the problem that 'Stream' is already used by node.

Haha, well, your grandparent would like you to know that's no reason to avoid a particular name. Module system! ;)

  > var BoringStream = require('stream');
  > var Stream = require('highland');

Or if we like special chars, we could get really cute:

  > var $tream = require('highland');

It's like Stream, but, you know, blingier.

Just as you wouldn't use multiple libraries that bound a CSS selector function to the $ variable, I don't think you'd use underscore and lodash in the same javascript code. Similarly, highlandjs looks to supplant the underscore idioms with stream semantics, and you wouldn't mix both libraries in the same codebase.

Yeah that's basically what his point is. Except you misunderstood to interpret any suggestion that people use underscore and lodash together.

While I can grant that it does seem to solve a lot of the same problems as underscore and lodash, this is just asking for confusion and complication down the road. You shouldn't make a decision that makes things hard for people to deal with in the future if they choose to use your product. There is well established meaning now to $ and _ in js land, pick another identifier.

I still think the collision with underscore and lodash is intentional and appropriate. It makes a statement saying, "this library is designed to supplant underscore. Do not use underscore and this library together".

> Do not use underscore and this library together

Together in the same module. One can port one module at a time. It's what I do in my current job, each module can use a different set of technologies and we don't have to port everything at once.

I'm not certain I understand how their use of _ is any different from Lo-dash or Underscore's use of the variable. Just because they're not first to the party doesn't mean they can't hop on the established semantics.

Their use of _ actually made it easier for me to follow their examples.

I think that it's pretty reasonable for a similar library to use the same character if the syntax is similar. As an example, the Domtastic library copies the jQuery syntax literally, allowing an easy transition for new users.

It also makes users aware that the library is likely to cover aspects of the other, so they should carefully consider if they really want to include the new one.

$ is used for doc.QS or doc.QSA pretty frequently these days

I agree with not using the underscore character, while Underscore/Lodash are still popular. Personally, I do `H = require('highland')`, whenever I'm using it.

For real. Highland should just use an H.

That's exactly what I use, var h = require('highland');

Or a Greek capital letter Lambda: Λ

Λ(['1', '2', '3'])

Is that a valid variable name? Would that mean Λ is unicode?

It is a valid Unicode letter so should be acceptable in EcmaScript 5.

How does one type that?

Like this: Λ ;)

Windows: Alt+x 03BB

Linux: Ctrl+Shift+u 03BB (still pressing Ctrl+Shift)