I think the distinction between *doing* node and *using* is good call. I wrote a tampering HTTP proxy server in node; I used streams and callbacks. I wrote a web application with lots of waiting on database and filesystem chatter; I used fibers w/ futures.
On Sun, Apr 28, 2013 at 11:22 PM, Bruno Jouhier <bjouh...@gmail.com> 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 nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > 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 nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com 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 nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
