On Tue, Apr 10, 2012 at 19:16, Isaac Schlueter <i...@izs.me> wrote: > It is not our goal to make programs look blocking when they are in > fact parallel (that's a bad complexity trade-off).
depend is not a very good measure either. Streamline is more for people who write applications than for library writers. And people don't publish whole applications to NPM. There are also a few who use it browser side.
On Wednesday, April 11, 2012 3:49:00 AM UTC+2, Mikeal Rogers wrote:
> NodeUp is not exclusively node core committers nor has it ever included > the full list of committers so the views represented should not be viewed > as "core".
> While our personal views about coffeescript may be negative node is > committed to support (but not include or bundle) the use compile target > languages. No one will ever have the level of support that javascript has > but we won't be going out of our way to disable it.
> GitHub Followers are a good indication that something is interesting, they > should not be considered supporters or an accurate representation of > adoption. For instance:
> express: 5,823 > npm: 2,605
> There is no question that npm has wider adoption than express. While > express is hugely popular it *requires* npm to be installed :)
> One thing I've noticed is that GitHub followers mean you have something > interesting, not that you have something they use. My suspicion is that > many followers don't actually use the project they are following but find > it interesting enough to keep an eye on.
> The closest metric we have for adoption is "depended on" > http://search.npmjs.org/. But, this metric also falls short. For > instance, depending on express is an indicator of how well it's been > adopted by people building plugins, same with connect, but not a good > indicator for it's actual adoption since web frameworks are mainly used by > applications which are not pushed to the registry. Similarly, coffeescript > has a larger representation that it's actual usage since *any* module > written in coffeescript includes it as a dependency.
> Fibers has about 12 modules that depend on it. Streamline has about 4. If > you want to compare that against common utilities that use standard node > practices for async (request:420,socket.io.202,redis:175) it's quite low. > Even comparing fibers and streamline to popular flow control libraries that > use standard node practices (async:354,step:64) fibers and streamline have > sparse adoption.
> Not saying nobody uses them or that they don't have a bit of a following, > but by the actual numbers we have their adoption is quite limited compared > with standard node practices, especially when compared to how vocal they > are championed on this list whenever a thread like this appears.
> It would seem that the majority of node developers are content with > standard callbacks and find ways to deal with them and are not running > towards blocking style abstractions, they just don't care enough to yell a > lot on every thread like the authors of alternatives.
> On Apr 10, 2012, at April 10, 20126:26 PM, Joe Ferner wrote:
> > Not sure if 10 was it, that's the only one I could find from searching > > the text of the episodes. They are definitely not coffeescript fans if > > you listen through a couple of the episodes.
> > On Apr 10, 9:13 pm, Mark Hahn <m...@hahnca.com> wrote: > >>> I think it was episode 10 of nodeup (http://nodeup.com/ten) where > they
> >> railed on it for 10 minutes. There is also a pull request (https:// > >> github.com/joyent/node/pull/2472) where they complain about it that is > >> pretty funny.
> >> They didn't trash coffeescript, they were trashing the idea of using it > for > >> node core. There is a big difference.
On Wednesday, April 11, 2012 3:49:00 AM UTC+2, Mikeal Rogers wrote:
> NodeUp is not exclusively node core committers nor has it ever included > the full list of committers so the views represented should not be viewed > as "core".
> While our personal views about coffeescript may be negative node is > committed to support (but not include or bundle) the use compile target > languages. No one will ever have the level of support that javascript has > but we won't be going out of our way to disable it.
> GitHub Followers are a good indication that something is interesting, they > should not be considered supporters or an accurate representation of > adoption. For instance:
> express: 5,823 > npm: 2,605
> There is no question that npm has wider adoption than express. While > express is hugely popular it *requires* npm to be installed :)
> One thing I've noticed is that GitHub followers mean you have something > interesting, not that you have something they use. My suspicion is that > many followers don't actually use the project they are following but find > it interesting enough to keep an eye on.
> The closest metric we have for adoption is "depended on" > http://search.npmjs.org/. But, this metric also falls short. For > instance, depending on express is an indicator of how well it's been > adopted by people building plugins, same with connect, but not a good > indicator for it's actual adoption since web frameworks are mainly used by > applications which are not pushed to the registry. Similarly, coffeescript > has a larger representation that it's actual usage since *any* module > written in coffeescript includes it as a dependency.
> Fibers has about 12 modules that depend on it. Streamline has about 4. If > you want to compare that against common utilities that use standard node > practices for async (request:420,socket.io.202,redis:175) it's quite low. > Even comparing fibers and streamline to popular flow control libraries that > use standard node practices (async:354,step:64) fibers and streamline have > sparse adoption.
> Not saying nobody uses them or that they don't have a bit of a following, > but by the actual numbers we have their adoption is quite limited compared > with standard node practices, especially when compared to how vocal they > are championed on this list whenever a thread like this appears.
> It would seem that the majority of node developers are content with > standard callbacks and find ways to deal with them and are not running > towards blocking style abstractions, they just don't care enough to yell a > lot on every thread like the authors of alternatives.
> On Apr 10, 2012, at April 10, 20126:26 PM, Joe Ferner wrote:
> > Not sure if 10 was it, that's the only one I could find from searching > > the text of the episodes. They are definitely not coffeescript fans if > > you listen through a couple of the episodes.
> > On Apr 10, 9:13 pm, Mark Hahn <m...@hahnca.com> wrote: > >>> I think it was episode 10 of nodeup (http://nodeup.com/ten) where > they
> >> railed on it for 10 minutes. There is also a pull request (https:// > >> github.com/joyent/node/pull/2472) where they complain about it that is > >> pretty funny.
> >> They didn't trash coffeescript, they were trashing the idea of using it > for > >> node core. There is a big difference.
> If you are ignoring coffeescript because of this then that is a shame. I > use absolutely nothing but coffeescript and I can't imagine living without > it.
Yes it's a make or break for me. A language that doesn't even get its scoping at least somewhat right is a no-go for me .Introducing a new global variable messes up some code that worked before far below just because it happens to have a local variable named the same way? I don't even understand what a "great idea" it was to go back to implicit variable declaration, global or local, while everyone else after years of experience is pushing that down, a few characters for declaring a varible (local and global) is nothing compared to the hours of joy debugging. Javascript idiosyncratic scoping is already scraping that limit for me, and if it wouldn't have the momentum of being the web language, I'd already frown about that.
No, as long the two "benchmarks" behave different IO wise, they are incorrect and you compare apples with oranges. E.g. If you want to fill buffers to full limit, and do it both wise. And try to come up with aproperiate flow control in vanilla code, yes its not uber trivial to write. Thats the whole point. There is no overhead in runtime, since streamline will translate to script you would write anyway. The only overhead is during startup when streamline does the parsing/generating.
> A language that doesn't even get its scoping at least somewhat right is
a no-go for me .
Any yet you use a language that defaults everything to global.
The lack of the var statement is the only thing wrong with scoping at the moment and I showed you a nice workaround. Otherwise scoping is more than "somewhat" right and a big improvement over javascript.
> Any yet you use a language that defaults everything to global.
Its not like you got much choice when you do client-side web development. Default to local is IMHO not any better than default to global. Why default to anything? Jhint warns nicely about any default to globals.
> The lack of the var statement is the only thing wrong with scoping at the > moment and I showed you a nice workaround. Otherwise scoping is more than > "somewhat" right and a big improvement over javascript.
Bringing us back to the topic of "workarounds" to "problems" not acknowledged as problems but canted to the "way of [X]".
If I ever put up the focus, I'd rather get my own javascrip-meta-language that eases/encorages heavy use of immutables to get another advantage of functional programming in.
On Wed, Apr 11, 2012 at 9:37 AM, Mark Hahn <m...@hahnca.com> wrote: > You would obviously be happy with Erlang. Can't you code server-side in > Erlang?
On 10 April 2012 14:46, Bruno Jouhier <bjouh...@gmail.com> wrote:
> It's like you have to follow the dogma and the last thing you should do is try things out and make up your own mind.
> Come on guys, I don't care if you'll end up using streamline or not but please BE CURIOUS AND TRY THINGS OUT.
Considering the variety of replies in the thread I don't think its fair to call it dogma.
Absolutely people should try new things out, but some have implied in this thread that suggesting that the solution to (not knowing what to do about) 'callback hell' is to add abstractions and meta-languages... which seems hasty to me.
I'd be surprised if didn't agree on some level that it's worthwhile encouraging incoming coders to first reach a fairly basic level of familiarity before they explore that stuff.
Also, you should learn JavaScript. It's unavoidable, after all, so you'll always end up dealing with it somehow. (For similar reasons, you should learn C as well.)
A lot of people seem to be ok with using JavaScript without any meta language in front of it. Some of them even claim it's better than the alternatives, and they have some tricks and practices that make callbacks decidedly un-hellish. So maybe try that out, too.
On Wed, Apr 11, 2012 at 02:18, Richard Marr <richard.m...@gmail.com> wrote: > On 10 April 2012 14:46, Bruno Jouhier <bjouh...@gmail.com> wrote: >> It's like you have to follow the dogma and the last thing you should do is try things out and make up your own mind.
>> Come on guys, I don't care if you'll end up using streamline or not but please BE CURIOUS AND TRY THINGS OUT.
> Considering the variety of replies in the thread I don't think its > fair to call it dogma.
> Absolutely people should try new things out, but some have implied in > this thread that suggesting that the solution to (not knowing what to > do about) 'callback hell' is to add abstractions and meta-languages... > which seems hasty to me.
> I'd be surprised if didn't agree on some level that it's worthwhile > encouraging incoming coders to first reach a fairly basic level of > familiarity before they explore that stuff.
Adding to what Isaac said. Many of us have gone through "callback hell" and don't have that problem anymore, it's not Node.js or JavaScript issue. Check available solutions, listen to those who've been there. Important note: asynchronous programming requires some time to get with it, and it will always be like that, it doesn't matter whether you work with plain callbacks or trying out some ready solution. Never expect to find solution that in 5 minutes will make your problem gone, from my perspective everyone needs at least few days playing with it to workout/learn solution that will feel comfortable with.
On Wednesday, April 11, 2012 11:24:15 AM UTC+2, Isaac Schlueter wrote:
> Trying stuff out is great. Do that.
> Also, you should learn JavaScript. It's unavoidable, after all, so > you'll always end up dealing with it somehow. (For similar reasons, > you should learn C as well.)
> A lot of people seem to be ok with using JavaScript without any meta > language in front of it. Some of them even claim it's better than the > alternatives, and they have some tricks and practices that make > callbacks decidedly un-hellish. So maybe try that out, too.
> On Wed, Apr 11, 2012 at 02:18, Richard Marr <richard.m...@gmail.com> > wrote: > > On 10 April 2012 14:46, Bruno Jouhier <bjouh...@gmail.com> wrote: > >> It's like you have to follow the dogma and the last thing you should do > is try things out and make up your own mind.
> >> Come on guys, I don't care if you'll end up using streamline or not but > please BE CURIOUS AND TRY THINGS OUT.
> > Considering the variety of replies in the thread I don't think its > > fair to call it dogma.
> > Absolutely people should try new things out, but some have implied in > > this thread that suggesting that the solution to (not knowing what to > > do about) 'callback hell' is to add abstractions and meta-languages... > > which seems hasty to me.
> > I'd be surprised if didn't agree on some level that it's worthwhile > > encouraging incoming coders to first reach a fairly basic level of > > familiarity before they explore that stuff.
>> Streamline is more for people who write applications than for library
writers.
Thanks for putting that crystal clear Bruno. It's very positive when people say what their tools are good for, and not so adequate for imho.
The way you write your applications is entirely up to you, and you are always right to do what you feel confortable. As for libraries, the decisions you make have implications on those using your libraries.
For people wanting to know a bit more on bruno's views he shared a blogpost I found very informative:
Am Dienstag, den 10.04.2012, 20:14 +0200 schrieb Axel Kittenberger:
> On Tue, Apr 10, 2012 at 3:37 PM, Yi Tan <yi2...@gmail.com> wrote: > > you really should spend a few hours learning coffee script if the js > > callback syntax make you uncomfortable
> Unless coffee script fixes its "implicit local variable is global if > the names match and just dont take care to not accidently name it > equally" I will not touch it with a long stick.
<fanboy>Use coco, it's much better there! And it's cooler anyway. :)</fanboy>
> (...) Methods with callbacks are not required to have async code in them, they just generally do. If you replace doIt with say a getUserFromCache method where 99% of the time you get cache hits and the function just returns the user this would be completely valid (...)
You can do that but I think the consensus is that it's not a good idea because it complicates reasoning about your code:
method(params, cb); doSomethingElse();
Will doSomethingElse() run before or after cb() ? -- Jorge.
If your function is asynchronous only sometimes, consider getting rid of that ambiguity by using process.nextTick() on your callback in the cases where calling it won't be async.
On Thu, Apr 12, 2012 at 2:27 AM, Jorge <jo...@jorgechamorro.com> wrote: > On Apr 11, 2012, at 2:16 AM, Joe Ferner wrote:
> > (...) Methods with callbacks are not required to have async code in > them, they just generally do. If you replace doIt with say a > getUserFromCache method where 99% of the time you get cache hits and the > function just returns the user this would be completely valid (...)
> You can do that but I think the consensus is that it's not a good idea > because it complicates reasoning about your code:
> method(params, cb); > doSomethingElse();
> Will doSomethingElse() run before or after cb() ? > -- > Jorge.
On Apr 10, 2012, at 9:48 PM, Alexey Petrushin wrote:
> When a question rises again and again it's a good sign of problem.
> To make clear I'm not in any way blame the node on it, it has tons of advantages and it's ok to have problem. > Every advanced machinery have some sort of problems or limitations - it's ok.
> But what's not ok - is to have false delusion, to believe that a problem is a feature, or even worse - call it "The Rails/Node way".
> Because if You call the problem as it deserves - the problem - there's always room for progress and improvement. And maybe someday it will be completely fixed and become not a problem but another advantage.
> But when You ignore it or believe that it's a "feature" or "the right way" - the problem always will be there, it's a way to stagnation.
> Yes You can become tolerable to ugly code and buy wider screen to fit all those callbacks, but it doesn't matter. > Perceptions doesn't change the objective reality, no matter how much people believe that false is true, false still and always will be the false.
> So, maybe it's worth to stop call this problem a "feature"?
> I think I'm done writing benchmarks. Even if I come up with a > benchmark that shows streamline is faster I'm still not going to use > it and I couldn't recommend anyone else use it either. The community > as a whole doesn't back that kind of syntax so I couldn't submit a > module to npm if I wrote it using streamline.
You could of course, yes. There's people writing their modules in CS and publishing/pushing just the JS output to npm. E.g. pdfkit:
>> On Thu, Apr 12, 2012 at 2:27 AM, Jorge <jo...@jorgechamorro.com> wrote: >>> On Apr 11, 2012, at 2:16 AM, Joe Ferner wrote:
>>> (...) Methods with callbacks are not required to have async code in them, they just generally do. If you replace doIt with say a getUserFromCache method where 99% of the time you get cache hits and the function just returns the user this would be completely valid (...)
>> You can do that but I think the consensus is that it's not a good idea because it complicates reasoning about your code:
>> method(params, cb); >> doSomethingElse();
>> Will doSomethingElse() run before or after cb() ?
> If your function is asynchronous only sometimes, consider getting rid of that ambiguity by using process.nextTick() on your callback in the cases where calling it won't be async.
On Tue, Apr 10, 2012 at 10:13 PM, Naouak <tard...@gmail.com> wrote: > Am I the only one that thinks that we talk about Callback Hell only because > we are not used to used callback everywhere ?
Bruno, we are evangelizing callbacks because this is the only it can possibly work in JavaScript. You can add a preprocessing step (which is apparently what streamline is doing) - we will not do that. You can add some crazy longjmp in your extension and juggle executions stacks and try to forget how much memory they are or fight with stack over flows - we will not do that. JavaScript has a run-to-completion model which we do not seek to circumvent. Node is JavaScript - even more than that - Node is V8 JavaScript. If V8 adds generators, we will have them - if not then not. One of the key reasons Node is successful (unlike all of other server-side JS systems) is because it actually uses JavaScript and not some JavaScript-like language.
I'm glad you like Node. As you said, it is simple and fast. It got that way by keeping things simple and fast. It will remain simple and fast by continuing to strive for those goals.
This is a discussion to bring up with the EcmaScript committee.
I commented in long form on Bruno's blog, but it's not showing for some reason. Here are the highlights:
...(paragraphs talking about my experience helping newcomers)...
Node had "promises" early on and we learned a very important lesson with them. Hiding the non-blocking nature of code is bad! ... Node "promises" had a method called "wait" that would just suspend the current stack and return the value after the promise was resolved. This was dangerous .... Luckily Ryan has the sense to remove this feature quite quickly, but it left a bad taste in all our mouths ever since for ... faux blocking.
...(some paragraphs saying that streamline isn't as evil as promise.wait was)...
I think streamline is a brilliant piece of engineering and I'm sure there are people who really benefit from such a tool. Just understand it's not for everyone.
On Sat, Apr 14, 2012 at 7:35 PM, <r...@tinyclouds.org> wrote: > On Sat, Apr 14, 2012 at 9:30 AM, Bruno Jouhier <bjouh...@gmail.com> wrote: > > I posted a follow-up on my blog:
> Bruno, we are evangelizing callbacks because this is the only it can > possibly work in JavaScript. You can add a preprocessing step (which > is apparently what streamline is doing) - we will not do that. You can > add some crazy longjmp in your extension and juggle executions stacks > and try to forget how much memory they are or fight with stack over > flows - we will not do that. JavaScript has a run-to-completion model > which we do not seek to circumvent. Node is JavaScript - even more > than that - Node is V8 JavaScript. If V8 adds generators, we will have > them - if not then not. One of the key reasons Node is successful > (unlike all of other server-side JS systems) is because it actually > uses JavaScript and not some JavaScript-like language.
> I'm glad you like Node. As you said, it is simple and fast. It got > that way by keeping things simple and fast. It will remain simple and > fast by continuing to strive for those goals.
> This is a discussion to bring up with the EcmaScript committee.
