While I find it flattering to be referred to as a "core guy" and I rarely correct people when they say it, you should know that I have less patches in to core than I have fingers.
One of the patches was quite large, but there are many people who spend far more time on core than I do. What I spend most of my time on is building apps. I have a startup, I write lots of node.js code for it. I use node "properly" by some definition of "the way the APIs were intended to be used". I think many other people do the same. You are absolutely correct that we cannot dictate how people *do* use an open source project. But, we can *recommend* a particular way and we shouldn't be concerned with breaking something that people do in a way we explicitly *do not recommend*. This is node.js, we still break API in major releases. No way are we going to *not* change or break an API because people are using it in a way that was not intended and in fact we recommended them not to use it for. How can we possibly justify that when we break working APIs people are using as recommended all the time? Node is not done. It needs to get better. We cannot improve it if we are not pushing it to its limits and the only way to do that is to use the right API for the right job. My insistence on use cases comes from *building apps* and wanting real needs to be demonstrated. My dismissal of use cases that are better fitted for another API come from handling may of these problems in the real world and seeing them easily solved by doing things the right way. We cannot move node forward if we're spending time optimizing use cases we agree are not being done the right way. But, there are limitations in what we have recommended and in the current APIs. The current issues with nextTick() come problems we've found at scale doing things the recommended way. -Mikeal On Jun 1, 2012, at June 1, 201211:15 AM, Marco Rogers wrote: > Man Bruno, you almost had a really strong message. But then you ruined it :) > > > > @isaac, @mikeal, > > This is turning into a real joke! > > > Agreed > > You tell us that you would like to change process.nextTick and you ask us for > feedback. > > Several people respond that this change is problematic for them and that they > would much prefer that you introduce a *new* API and use it internally to > solve your problems (and optionally make this new API public so that other > people who have similar problems to solve can solve it the same way you do). > > If you had listened to them, you'd have said: "ok guys, we understand that > this is a problem for you; there is another easy path that solves the problem > for us and won't put anyone else in trouble; let us do it." Case closed. > Everyone can move forwards! > > Instead you reply that anyway, the issue is already settled, the API will > change, and all the people who are asking for process.nextTick to be > preserved are just misusing node and need to rethink their applications with > child processes. > > If the issue was settled from the start anyway, you shouldn't have asked: > just make the change and tell us afterwards! Don't pretend that you care > about our opinion! > > Mostly agreed. The fact is the core guys do care about opinions. But they > often have biases about the way people "should" be using node. And if you're > not using it that way, it hurts your ability to argue successfully. Node is > opinionated, and Isaac and Mikeal in particular are opinionated. That's the > way this goes. Isaac is correct in saying we either change their minds or we > fork. > > That said, I do wish they would come into conversations like this being a > little less smug and sure that they are right. > > > The problem is that people like me (I don't know about paddybyers but I'm > assuming he is in a similar situation) are building real applications for > real customers, not I/O libraries for other nodejs developers. And you guys > simply don't know what building a real application means! > <snip> > > This is all unnecessary, insulting, and untrue. > > > So, when we tell you that we find process.nextTick useful because it allows > us to time slice computations, it does not mean that we don't understand > node. It just means that we know what we are building, that we have built > similar things before with other stacks, that we have done our homework with > the figures and that we consider that this approach is completely viable for > *our* use cases. > > So, please stop saying that we are doing things wrong and that our opinion > should not matter. We are building real things and we know what we are doing. > You just don't know what we are doing! > > Please, listen to your customers! > > > I had a few thoughts about this. I also think the core guys are often > presumptuous about how people use node. But that speaks to their view of the > core principles of node. It's not necessarily about ignoring constituencies. > But about moving node towards their own vision. Even if it means some > previous usage is no longer well supported. You can't dictate how people use > your open source code, but there's an argument that you also can't let that > stop you from moving your project in the direction you want it to go. > > The only problem with this is that in so many other arenas, proposed changes > have been shot down out of hand because "people depend on it" or "it would > break a lot of code". It feels arbitrary to me when breaking backwards compat > is okay and when it's not. I have long been an advocate that node can still > change and we should continue to refine the api and semantics. But I'm often > on the losing end of that. But now we're taking an extremely important, long > standing core semantic and changing it. I guess I just don't get it. > > Also as for "listen to your customers", it also made me laugh. Because I > thought of the cliche that's frequently going around about startups. "If > you're not paying money, you're not the customer, you're the product". I > would add a corollary. "If you're not the customer or the product, then you > don't really matter". Not saying that applies here. But it's an interesting > line of thought. > > :Marco > > > -- > Marco Rogers > marco.rog...@gmail.com | https://twitter.com/polotek > > Life is ten percent what happens to you and ninety percent how you respond to > it. > - Lou Holtz
