>> We don't destabilize node-core for vocal minorities. > Absolutely not: If something is wrong, you change it and increment the major > version number. That's not "destabilizing" in any sense of the word, that's > improving functionality, and telling people that you broke reverse > compatibility in doing so.
You're about 2 years too late, Austin. We only break reverse-compatibility when absolutely necessary, and never for modules that are marked with the "Stable" stability level or higher. There are some actual real-world programs running on node making real money that pays real rents. Like it or not, Node is a relevant platform now, not just any old program. The time for major breaking changes is behind us. Even with the new streams API, which is by all accounts better, we only made one semantic change to existing functionality, and only because it is *literally impossible* to make the desired fixes without doing so. (And we provided workarounds for the most common cases where it's an issue, so that it's not an issue.) To justify that change, we have heaps of feedback from existing expert users, and confusion from new users. The amount of work that a breaking change involves today is astronomical, because we care about the people using it. I'm not talking about the code change, either, but the social upheaval of "Why'd you break my shit!?" I fear that there will be some semantic changes necessary to fix the HTTP client's problems in 0.12, but I hope that we can do everything we need to in a non-breaking way. The goal of node has *always* been to get to a state where it's effectively "done". We want node to be like awk or sed or grep: something that's just there, and taken for granted. > There's nothing "vocal minorities" about cross-platform coding. As far as I can tell, there are 3 people who care about putting back the directories.lib to package.json. All three of you are vocal. Everyone else either seems to not care, or agrees that it was a bad idea in the first place. That's the paradigm case of a "vocal minority". > Most people won't use 'crypto'. Does that make them a vocal minority? So, first of all, everyone who uses https uses crypto. That's not a minority. They just don't realize they're using it. Secondly, they're not vocal, because it's working for them just fine. They'll *become* vocal if we suddenly break their programs, though, you can bet on that! And the majority will agree with them that breaking crypto was a bad idea. > But ill-defined require() is just as much a bug as any of those. How is require() ill-defined? There's even detailed pseudocode in the documentation explaining exactly how it works. > When you say "pragmatism" I hear "I don't understand the the system works > together well enough to understand the consequences of my actions." That > there are no facts, no fixed laws of logic, no certainty, no objectivity. It > is the antithesis of semantics and objectivity. And it is not an appropriate > design strategy for any software system. Well, I think I understand how Node's module system and package paradigms work better than most people. I certainly have a unique perspective on the complications of debugging node module code you didn't write (since many reported npm bugs are actually package bugs, but I spend time tracking them down anyway). I work at a company that is one of the biggest node users, and I am in constant communication with the node core development team, as well as engineers at Voxer, Nodejitsu, and several others. When I say "pragmatic", I mean that practice and theory inform one another, rather than being a one-way relationship, and that empirical learnings from practice always trump conclusions drawn from theory. That means that userland program breakage is worse than any ideological breakage, and that context is more important than consistency. The "consequences of our actions" that we care about are making life easier for those people using Node for real applications running on real networks. Though I do occasionally monologue for 57 pages, I am not a character in an Ayn Rand novel, and as such, don't really care much about these theories regarding facts, fixed laws of logic, certainty, objectivity, or antitheses of semantics. I happen to think that getting stuff done in simple ways is an ideal design strategy for software. -- 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
