My Opinion on that matter is that people who think node should provide opinionated utilities and structures should make a "distro" with their opinions. That's how it works with the rest of minimalist software.
for example, the debian creators thought that their system should provide a linux base with GNU utilities and manage its software with fully-tested .deb packages. On Monday, 29 April 2013 09:45:06 UTC+2, greelgorke wrote: > > well, we should distinguish a bit. > > Devs coming from web-frontends probably never used or even heard about the > concept of streams, and it is causing troubles for them. > on the other side, backend devs are used to shared state, threads and all > the magic stuff around isolating concurrency in to more abstract models, > i.E. actors, green threads, stm etc. many of them never used or heard about > the concept of the single-threaded event loop. > then, there are devs, which managed to not bother about threads, > callbacks, etc, mostly because they used one "silver-bullet" framework, > that hid every thing away from them. i guess they will have the hardest way > to use or do node. ever wondered about questions like "how do i structure > my project in express?" > > i think node makes it easier to learn it's api by reducing itself to a few > core modules. i think it's a nice good way how node exposes relatively > low-leve api's in a relatively high level manner. but the thing with "let > userland handle the rest" makes it harder to enter the eco-system. > I don't think that we have real problems with nodes philosophy or it's > api. the biggest problem is the entry path to it. RoR success is mainly > related to the opinions it have in it. it leads the way. Express does it > too, but it's way less opinionated. I do not know many mvc-frameworks on > top of RoR, but there are several on top of express. > > here is it. there is no "userland" out there, that handles the rest. there > is a "doersland". the node philosophy is for the "do"ers, and it offers too > few to them who are "use"ers. i think it's worth to think about how to > bridge the node-philosophy into the "use"ers-land, because the ideas of > this philosophy still valid in userland as well. > > Am Sonntag, 28. April 2013 18:17:28 UTC+2 schrieb Isaac Schlueter: >> >> > 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> >> 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.
