On Thursday, January 24, 2013 12:57:13 PM UTC-7, Isaac Schlueter wrote: > > 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. > Node.js has broken reverse compatibility three times on me, and not in a minor version update, during a *patch* update. I'm not asking for an end to this, on the contrary, in all the cases it was a good and proper change. I am asking that we be told when such a change is made. Release Node.js 1.0. Do it now. And never stop making improvements when they are necessary. > 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. > Ignoring entire segments of use-cases will mean Node.js is either not "done", or, is permanently buggy. Obviously it's not exactly like shell utilities, some improvements will need to be kept maintained. Like crypto, for instance. I assume people know this. > 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". > I'm not advocating that Node.js use package.json for anything. Quite the opposite. I do agree with the position that there are changes to be made to enhance cross-platform compatibility And you must realize that the use case is far more than three people. How about, more like, everyone who wants to deploy a module to a web browser? > So, first of all, everyone who uses https uses crypto. That's not a > minority. They just don't realize they're using it. > I consider that using 'https', not 'crypto'. I don't believe that 'crypto' should be used directly by users, except HMAC and maybe PBKDF2. In all other cases you should be using 'tls' or 'https', or a library by someone who knows what they're doing that has correctly implemented a functionality that depends on the use of e.g. vanilla SHA-1. I.e. I'm an advocate that 'crypto' remain used only by a vocal minority, and that this is a good thing. > 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. > Breaking crypto was a necessary and proper idea. Except, where is version 1.0? > How is require() ill-defined? There's even detailed pseudocode in the > documentation explaining exactly how it works. > Maybe not ill-defined, rather, inconsistent with its own semantics, as previously described. > 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. > Knowing lots of use cases is helpful, it means you can realize more quickly when mistakes were made, and add more optional functionality when the lack of such functionality would make accommodating such use-cases impossible. But that won't mean that you're producing ideal code per se. > 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. > The ideal design strategy *is* being aware of what your software fundamentally *means*. Doing the correct thing with the design of software will always produce an ideal result in the end. Semantics are how we keep track of more variables than we can keep track of in our heads (for instance, modularity and functionality are some of the tools used to deploy semantics, though of course they're not automatically good tools to use). Logic, when it has assertions, if it has assertions, is by definition correct, and computer science is an inductive science, like when someone presents evidence that the squares of sides of a right triangle are greater than the square of the hypotenuse, we don't say "Oh, huh, maybe we should re-consider the Pythagorean theorem". No, we say "Well we know that can't be right, which of the premises did we get wrong?" (Probably the one where we must use a flat plane and Euclidean geometry.) Being pragmatic about it may lead you in the right direction most of the time (repeated tests "prove" that the value of pi is 22/7... maybe a good enough estimate for most people, but by no means going to work when you venture into advanced applications, and are left wondering why your buildings are toppling over), it may even be good enough to deploy to large corporations, but it won't /continue/ to lead you in that direction, and you won't know /why/ you ended up where you did. And then you're stuck repeating the same practices that led one to unwittingly stumble across success, but in reality do not. Like my example, npm ended up using local packages not because anyone realized that's the correct way to deploy software, but because the global install system and tangle of require.paths shell files was a complete and utter train wreck. -- 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
