Fine, but I would not call Haskell, Clojure or Erlang mainstream! I was more thinking of PHP, Visual Basic and the likes.
On Sunday, April 28, 2013 6:17:28 PM UTC+2, Isaac Schlueter wrote: > > > 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 > <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 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.
