> I don't think that node will go mainstream by trying to convert mainstream > developers to the callbacks and streams paradigm, simply because it is > too hard.
This is a judgement that is not substantiated by any evidence whatsoever. The evidence suggests that most node users, beyond the initial learning curve, have a pretty easy time with streams, events, and callbacks. Compared to the learning curve of, say, Haskell or Clojure or Erlang or even C (which are all pretty popular, and at least C is as "mainstream" as it gets), it's a trivial hurdle. When users come from the front-end, where these concepts have already been around for ages in various forms, it's even less of a hurdle. While the peculiarities of system internals and TCP are a bit new for many, of course, Node's API is much easier to pick up quickly than any web browser's. The evidence I'm referring to is the increasing rate of growth of our module ecosystem, Node developer jobs being filled, and companies using node in their products, vs the comparatively low rate of these questions on the mailing list, irc, issues, and stackoverflow. It is a minority that has serious trouble with this, and they tend to learn quickly, and never have trouble with it again. (As shown in this case by this thread, where Slobodan grokked the answers quickly and moved on while we all debated the best way to answer his question :) Node is pretty obviously on the path to mainstream-ness, and patterns that deviate from its minimal set are pretty fringe. (The least fringe alternative control-flow pattern is Promises, by a long shot, helped by the fact that it has considerable uptake in the front-end JS world.) On Sun, Apr 28, 2013 at 7:22 AM, Bruno Jouhier <[email protected]> wrote: > Hi Nuno, > > Your post is helpful. I'll try to challenge it in a constructive way. I > think that most of disagreement comes from a different perspective on means > and ends. > > From your perspective, node is an end in itself: you **do** node; you build > streams; you write callbacks; etc. For you, adherence to node's core > philosophy is paramount. > > From my perspective, node is just a means to an end: we **use** node. For > us, the end is to more our product forwards. Node is just one piece of the > puzzle we are assembling (an important one). For us, node's core philosophy > is "interesting" but it is not binding. > > Our team is growing and when I'm bringing new people on board I'm not > teaching them callbacks and streams; I'm teaching them streamline. This is > because I need them to get up to speed quickly and I also need to have a > code base which is simple, robust, easy to maintain and homogeneous. They > can still learn callbacks and streams on their own and I'm encouraging them > to be curious but our internal coding standard is streamline. > > Also, I considered node's philosophy when architecting our new system. But I > have difficulties to fit what we are doing into the streams and pipes > paradigm. It does not feel "natural" and I don't see what benefits I would > gain. For me, it is much more natural to architect our system as classical > modules that **consume** streams than as streams that would be piped into > each other. I find the pure asynchronous nature of node very appealing but I > find the streams & pipes philosophy less appealing. Maybe there is also a > question of maturity: the asynchronous APIs are something we can very easily > build upon today (in part thanks to streamline); the streams & pipes looks > more like an experiment in progress, which may turn out to be a real > breakthrough but which would be introducing too much complexity for us > today. > > I also have a different perspective on node's APIs. I followed the > discussions on the new streams API and I was always amazed by the very > strong focus on the "building streams" side. I find this very complex and > fragile. In our system, we very rarely build a stream but we consume a lot > of streams. So we have a small wrapper that gives us a very simple API to > consume streams. We are not following the core philosophy but it does not > really matter for us. What matters is that we can build our product. > > Now, when a person comes the the mailing list with a question, I wonder what > his perspective is. Does he want to **do** node, or is he just trying to > **use** node to build something? If his goal is to **do** node, then yes, > Mikeal is right with his hard line: people should not blur the message and > give him advice that may distract him from node's philosophy. But what if > all he wants is to **use** node, maybe in ways that are not completely > aligned with node's core philosophy, like we do? should we stick to the hard > line, or should we let him explore "other ways" that may be a better answer > to his needs. > > The node ecosystem is growing fast, with people that **do** node, and I > don't want to disrupt this. But I feel that there is a great opportunity for > node to go more mainstream (like PHP and RoR). I don't think that node will > go mainstream by trying to convert mainstream developers to the callbacks > and streams paradigm, simply because it is too hard. I think that it can do > so by being open and letting people just **use** node, and this is where > alternate tools may help. > > I don't have a good answer to what the line of conduct should be on the > mailing list. But I don't think that excluding discordant voices is the > right solution (in this specific case but also in general). > > Bruno. > > > On Sunday, April 28, 2013 3:01:05 AM UTC+2, Nuno Job wrote: >> >> Node means a certain set of things, and part of those things are callbacks >> and streams. >> >> Callbacks and streams are hard to learn because its a new programming >> paradigm you don't learn in school. It was hard for me too and I did it when >> this was still up for discussion. And I had good friends to teach me that >> really knew node. >> >> Developers will always try to fast track to their already understood >> paradigms; but that is not node. This existing paradigm makes sense to build >> network proxies; which node is awesome for. To node programs are proxies. >> >> A person should always start with callbacks and streams until he >> understands them, closures, and the event loop. Then he can make informed >> decisions on what to use when. >> >> However node is not the solution to all problems and if you wanted to >> build a general purpose replacement for Ruby on Rails in JS you probably >> wouldn't use callbacks and streams by something else as discussed. >> Personally i think this would be great, an would follow closely such a >> project. It could even interopt with node and npm but its not node! >> >> Given my opinions above it makes sense that i would advocate that a node >> beginner should start with the standard idioms: callbacks and streams. It >> might even make sense to make these documented as "the standard" on the >> site. >> >> However its possible that this is not the best solution for the person >> that asked the question, but then maybe that person shouldn't be using node >> and instead the brand new super cool thing someone will build. Or maybe he >> needs to learn how node works and then decide, by himself, that something >> else makes more sense. >> >> The ecosystem exists, it has an interoperability model, and works great >> for what node is for (check node success). Improvements on this model are >> possible (like streams2) but even those aren't without backlash. Breaking >> changes are also awesome, but its not node >> >> Nuno >> >> Ps. Cause this doesn't seem obvious to everyone, these are just my >> personal opinions. And I expressed them here mostly in respect to Bruno who >> did a blog post i thought was respectful and thoughtful, and i felt >> compelled to respond in the same manner. We have a great community and i >> respect a lot the work and passion community members put into their projects >> >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
