actualprogram's comments

The irony of this question should be apparent if you search for packages on npm today. How many "new projects" are there?

In answer, why not create a new project? NPM INC controls npm, hasn't contributed it to the node foundation (despite playing a pivotal role in creating said foundation), and hasn't been especially good at taking contributions recently.

A new project dodges all those existing problems, demonstrates alternate approaches are both feasible and compatible, and destroys the myth that npm is fundamental to node, rather than simply the first of many package management systems that take advantage of node's import semantics.

io.js made a lot of noise about this, and has reached a "compromise" position that is indistinguishable to the end-user - or is LTS going to take V8 version bump over its 2.5-year life?

No?

Then take your scare quotes and bang your drum elsewhere, because from where I stand, the new boss is pretty much the same as the old boss.

If by "match V8" you mean "skip most V8 changes"? V8 revs on par with Chrome, at a pace about four times what you say.

Turns out that despite pillorying Joyent for sticking to V8 major versions, it is the only reasonably-correct thing to do for the ecosystem to remain usable.

I suppose it could just be coincidence that the io.js fork didn't just disable, but did non-trivial work to remove facilities that allowed for competing (and totally open source) profiling & debugging tooling.

Certainly casts a "community governance" spat in a bit of a new light when suddenly the major movers behind the fork turn out to have a significant financial interest in it.

HA! Hahahaha. hahaa.... wheeze

Acquisitions are thoroughly NDA'd. A few of the core team may have been told (but relationships are not universally cordial - recall that Strongloop and Nodesource are direct competitors). The io.js community in general was absolutely not told.

I expect there are a few people who feel a bit betrayed that one of the major movers in a supposed grass-roots community-oriented fork appears to have done it only to make themselves a better acquisition target.

While they're not wrong to feel that way, StrongLoop have been telegraphing this particular intention for a long time (at least since hiring Roth).

Node's API stability is a wonderful and many-layered thing. While more and more of the API is moving towards stability in the colloquial "is this going to change between versions?" sense, it's still a mixture.

See this section of the node docs for a description of the different classifications of 'stability' within the API: https://nodejs.org/api/documentation.html#documentation_stab...

If you're concerned with stability, the best thing you can do is wait for the LTS release to come off the 4 branch.

A quick glance at outstanding issues will show a number of integration bugs are still outstanding, and the new v8 was landed only a few days previously - incompatibilities with new versions of v8 can take a while to surface in node.

It's important to remember that semver makes no promises about stability. While we're used to "N.0" meaning "stable and ready for upgrade," that's a non-semver idea that is explicitly disregarded in the semver release model. Node moving from 3.* to 4.0.0 only indicates that there are breaking changes(1).

If you have concerns about stability, you should take signals on that from the node LTS group, and pick LTS releases.

1 - whether or not this is good, bad, or merely a different permutation of the things that are turning your hair grey, I leave as an exercise to the reader.

Let's review the conditions of your example:

  no source,
  no debugger,
  two function calls

And the assertion that // works as a strategy. There's only two things you could possibly comment out, so really the example is not so much "explained poorly" as "conceived poorly". Don't shoot the messenger - it's your example.

As for the further explanation here, allowing a debugger makes the search irrelevant - there's only one piece of information the binary search can tell you: which function causes the segfault, but as you observe, that information's available from the debugger already. And no, it doesn't matter if you reframe things as "a percentage of an instruction stream".

The objection to binary search is not "binary search in the codebase can never tell you anything," it's that it's a method that can't -- not "doesn't" but "can't" -- produce a non-trivial testable hypothesis. Does this mean you can't ever use it? You may have no choice. But it's a terrible place to start, and most of the information it offers is available through other means, often with more precision.

I can. It's long and tedious, because a lot of it is very simple things you learn very early on writing and maintaining software.

You seem to be arguing that your example demonstrates the fact that you can localize a bug in the code with binary search; specifically that the bug must exist in either a() or b(), and that running them independently is both possible and will determine the single location of the bug.

This is not true. It is only true in the case that one assumes bugs must have single locations, and that those locations can be found with binary search over what amount to incomplete programs. In other words, you're assuming the prior, begging the question, etc.

It's tempting to say "real code isn't like this contrived example" but in fact this contrived example is the best possible demonstration of why blind binary search is a poor strategy. Let us say the 'bug' exists in a(). You seem to be assuming this is the necessary consequence:

main () { a(); b(); } -- segfaults main () { a(); /* b(); / } -- segfaults main () { / a(); / b(); } -- doesn't segfault

But this isn't the only possibility. With the bug existing in a(), you could also see this result:

main () { a(); b(); } -- segfaults main () { a(); / b(); / } -- segfaults main () { / a(); / b(); } -- segfaults

You would expect this in situations where b() uses data structures created by a().

We may also see this result, still assuming the bug exists in a():

main () { a(); b(); } -- segfaults main () { a(); / b(); / } -- doesn't segfault main () { / a(); / b(); } -- segfaults

If above we learned nothing, here we've actually got a falsehood - our binary search has localized the bug to b(), but it actually exists in a()!

So, in practice, binary search fails to localize a bug in a(). All of these situations can be created by having a() write a global which is relied upon by b() - a() may write to a protected area, b() may have a default value, a() may write nonsense, or pass an integer where b() expects an address - none of this is particularly exotic, they're all the sort of things you get every day when debugging segfaults.

We might now delve into a competing series of contrived examples of a() and b() and argue about their relative prevalence in the world (which none of us are capable of knowing), because if some case is particularly rare, it may make binary search very slightly better than flipping a coin in this case.

Instead, I will point out that this is once again* assuming the prior, and that we have these simple (if shockingly annoying) facts:

1) side effects exist 2) in the presence of side-effects, binary search cannot predict the location of a bug.

And it follows that in the sense that a "scientific" hypothesis has predictive power, then binary search over the codebase is basically the homeopathy of debugging.