Hacker News Reader

Comment by scott_s | Hacker News Reader

How can you say it was a mistake when it only took one week? There was a cost, they paid it, now they can reap the benefits.

I program in C++ extensively. I "deal with it" a lot. I write things like this all the time:

    MapType::const_iterator it = map.find(x);
    if (it != map.end()) {
        // x is in map, process it
    }

I've done it for years, I know how to do it, and there are great benefits to getting iterators back from my data structures. Yet, I always feel a warm fuzzy when writing data processing scripts in Python, and I get to say:

    if x in map:
        # x is in map, process it

My point: even though one can have learned to "deal with it," there can still be a benefit to not having to deal with it anymore.

View on HN

> How can you say it was a mistake when it only took one week? There was a cost, they paid it, now they can reap the benefits.

The cost is not just time (although that's certainly a big cost). They rewrote working production code for fun. Why this is a bad idea will likely derail the conversation so I'll just direct you here:

http://www.joelonsoftware.com/articles/fog0000000069.html

Joel's excellent essay does not apply here. The Netscape re-write was a re-write. That is, it was not a translation. Netscape looked at their code base, and decided, "We don't like the design of the architecture of our code. We're going to throw it out, re-design it, and re-implement it from scratch."

The Dropbox team clearly did not do that. They translated it from one language to another; the design did not change. Much of that translation was with an automatic tool. Again, there is a difference between re-implementing something, and translating it.

Further, the examples in Joel's posts took years. This took a week. The situations are completely different.

Personally, I find it disingenuous to link to an article and say "He has my argument" without actually stating what your argument is.

The scope is much smaller, but the problems are still the same, namely introducing new bugs to working production code and surrendering ground to competitors.

The scope is so small that it's on par with any other feature.

If they really rewrote it in a week, then either it was trivial or they were able to reuse the bulk of it. The Spoelsky article applies to neither of those cases.

Read the article. Their first step was to run their existing JavaScript through a js2coffeescript converter.

That essay is a classic. It is also wrong.

See http://www.perlmonks.org/?node_id=115511 for my original opinion when I read it. Nothing I've seen since has changed that basic option. (But wow, the technologies that I thought would go somewhere. It is humbling to see how wrong I was. But the points are still good.)

Now years later consider carefully that the "failure" that Joel criticized is what lead to Mozilla, Firefox, and the second browser wars. Furthermore consider that Netscape had no real choice with its rewrite. As a company they were going to die. Hence their effort to open source the code. But they didn't have licenses to everything in their browser, therefore the open source version couldn't even run!

Now I'll grant that the decision to rewrite working production code is always to be undertaken carefully. It can easily go wrong. But in this case Dropbox decided to do it, they've done it, they've had no ill consequences (the lack of consequences is not an accident - they knew how to do it well), and they are more than satisfied with the result. Given those facts it would probably be a good idea for you to be taking notes and asking yourself how come your immediate prediction turned out wrong instead of saying, "They were stupid to try that."

I've mentioned this on HN already but despite the fact that I agree with Joel about many things, I really hate when people pull that article out of their hat like it is some sort of debate ender.

Netscape was already fucked prior to starting the rewrite, mostly due to their ill-conceived forays into "groupware".

If Navigator wasn't rewritten when it was the layout engine from the rewrite wouldn't have existed to power Firefox and Mozilla probably wouldn't exist as an entity right now. So in a very indirect way, the Netscape rewrite actually saved the Netscape browser lineage and probably helped the web from falling into a much longer mini-dark-ages than it did around the NS/IE 5-6 era. And there's not really any good evidence that it did the old "Netscape" any harm since it isn't like Navigator was ever a significant profit center anyway (I know they did charge for corporate usage of Navigator, but that was never going to be a sustainable business, so the rewrite had no impact on that).

In C++'s defense in the one example you gave, you could have just done this and had the same amount of code:

   if (map.find(x) != map.end()) {
   }

No, because then I would need to find it again (eiter through the find() member function, or through operator[]) to get a reference to it. Without a reference, I can't process it.

Why? In your original example you said "process x". You can also "process x" in mine:

if (map.find(x) != map.end()) { // do stuff with x }

You don't need the iterator to do anything with x. And if you do need the iterator (to perhaps keep iterating or something?) then you would also need to do extra work in the JavaScript example.

> There was a cost, they paid it, now they can reap the benefits.

Quick example of how you're wrong: their version history is now trashed. They're going to pay the price for that for years.

And the price will be about zero.

Reply on news.ycombinator.com