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.
