> I think the distinction between *doing* node and *using* is good call.
+ 1, in most cases I don't care about interoperability of my npm modules or complying to some ideologies at all. I just want to get things done with simplest and fastest way. On Monday, April 29, 2013 6:30:40 AM UTC+4, Marcel wrote: > > 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 > <bjou...@gmail.com<javascript:> > > 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 nod...@googlegroups.com<javascript:> >> To unsubscribe from this group, send email to >> nodejs+un...@googlegroups.com <javascript:> >> 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+un...@googlegroups.com <javascript:>. >> 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.
