HN Explorer

30 comments

[ 1.9 ms ] story [ 51.8 ms ] thread
AdrianRossouw
Using extended characters like λ for your library is pretty hostile to users.
bevacqua
I don't, it's just the name I use on the readme. The library is published as the `contra` global.
colinramsay
And in all of the examples on the github page. Why not just get rid of the λ variable and use `contra` directly? I guarantee this will confuse/frustrate people otherwise.
callum85
Yeah it will confuse some but it'll probably pique some people's interest too. People like memorable little oddities sometimes.
colinramsay
Sure, but not in their code. All this does is blind people to the genuine values this project might have.
akerl_
If it's the name you use in all your examples, that's what you're recommending your users do. Recommending an extended character for that is hostile.
callum85
'hostile' is a pretty hysterical choice of word
kennu
Contra? Shouldn't it be Contrl? (Original name is Contrλ)
acjohnson55
This looks pretty cool, but it seems to me it has hardly more than a sprinkling of "functional taste". Promises are much more functional in the modern sense of preserving composability outside the abstraction by creating values that represent asynchronous computations, which can be composed flexibly with a then method.
Kiro
> The only reason contra isn't published as λ directly is to make it easier for you to type.

I don't understand this. Do you mean "so you don't need to use the λ character"?

WorldWideWayne
I don't get why the special character had to be used.
aroman
It doesn't. You can use whatever identifier you'd like, just as with every node module.
WorldWideWayne
No, I mean within the readme. It only served to confuse things.
toleavetheman
I think this library looks great. It seems to do just enough, and browser compatibility with a small filesize is wonderful.

I almost can't believe that all of the other (current) comments are complaining about the use of the λ character. Unicode is hardly a new concept, and it is certainly not "hostile" (hyperbole much?).

In fact, as modern languages like Julia become popular, I think we will see increased use of unicode characters in coding. Julia is very unicode friendly, which aids scientists and mathematicians when translating formulas to code. For example, it supports the "element of" operator ('∈') for testing if an item is in a set. These unicode characters actually _improve_ readability in many contexts, while being less convenient to type if you're only accustomed to ASCII.

xyzzy123
I guess not super hostile, but I just don't know how to type it in emacs or vim except by memorising the code point :/

e.g. in Vim: Ctrl-V, U, 3bb <ret>

Which is OK for this one library... but if I had delta and epsilon libraries too I could see it getting to be a pain.

In terms of typing efficiency, 6 keystrokes, it's about the same as just typing "contra" except harder to remember.

klibertp
For the quickest workaround if you need only a lambda char, bind something like this to some keys:

    (defun my-insert-lambda () 
        (interactive)
        (ucs-insert 955))
But there are many different options available in Emacs for inserting exotic characters, as listed here, for example: http://stackoverflow.com/questions/10192341/how-to-enter-gre... - I didn't have any need for them, as I only need lambda character when I'm programming in Racket (which understands this character natively, which is very nice!), but both abbrevs and input method ways of doing this look legit.
danabramov
Promises are a superior abstraction, easier to reason about, provides consistent error handling. Sadly (in my opinion), this is an `async`-like library.
aroman
What? Why? I disagree on all of those points. Promises are inconsistent[0], slow[1], and I find them a hassle compared to async. The Node.js core and community convention is to use callbacks and callback-embracing tooling for a good reason.

[0] http://lostechies.com/derickbailey/2013/09/20/consistency-pr...

[1] http://thanpol.as/javascript/promises-a-performance-hits-you...

notduncansmith
Performance: I cannot honestly remember a single case in my entire Node.js career where promise execution time was a performance bottleneck.

Inconsistency: If you're consistent in your promise library usage, then promises will always behave the same way. Wrap libraries as necessary.

Promises are incredibly easy to reason about - the code reads very synchronously. Until we have native concurrency primitives available at the language level, I'll settle for ".then". It's pretty much how I'd read it in my head anyways.

If promises are a hassle, you're probably not using them correctly.

danabramov
Your assumptions are outdated and this is FUD.

Promises that implement Promises A+ are consistent. The fact that jQuery's implementation is broken has no relation to promises whatsoever (nobody seriously calls them promises anymore).

But I was talking about a different kind of consistency: consistency in your code. Errors not being swallowed, the same representation for all async values.

The performance post you linked to is almost a year old and is quite outdated. Since it was posted, Bluebird[1] was written and leveled up the game:

    file                                 time(ms)  memory(MB)
    promises-bluebird-generator.js            171       16.52
    callbacks-baseline.js                     197       20.68
    promises-bluebird.js                      280       26.64
    promises-lvivski-davy.js                  616       58.75
    promises-dfilatov-vow.js                  672       80.59
    promises-cujojs-when.js                   731       68.74
    callbacks-caolan-async-waterfall.js       733       44.57
[1]: https://github.com/petkaantonov/bluebird/blob/master/benchma...
micahasmith
In order for us to use this in production we ordered all our programmers keyboards with lambda keys. jk but for real this is a really useful lib