5 ms·

No, the parent is correct. JavaScript developers do not lose any sleep because '1' + 0 = 10. We learned to do integer math with integers and moved on. We learne

No, the parent is correct. JavaScript developers do not lose any sleep because '1' + 0 = 10. We learned to do integer math with integers and moved on. We learned to just use === and moved on. The Dropbox devs apparently didn't want to go through that learning curve, which is fine, but rewriting your application in another language just so that you don't have to look at semicolons is a big bikeshedding mistake. Writing new code in CoffeeScript and only rewriting legacy code as needed would have been a more sane way to transition.

scott_s 14y ago
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.
- MatthewPhillips 14y ago
  > 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 http://www.joelonsoftware.com/articles/fog0000000069.html
  - scott_s 14y ago
    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.
    - MatthewPhillips 14y ago
      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.
      - scott_s 14y ago
        The scope is so small that it's on par with any other feature.
        deleted 14y ago
        [deleted]
  - jsight 14y ago
    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.
    - btilly 14y ago
      Read the article. Their first step was to run their existing JavaScript through a js2coffeescript converter.
  - btilly 14y ago
    That essay is a classic. It is also wrong. See http://www.perlmonks.org/?node_id=115511 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."
  - georgemcbay 14y ago
    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).
- adgar 14y ago
  > 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.
  - rimantas 14y ago
    And the price will be about zero.
- tolmasky 14y ago
  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()) { }
  - scott_s 14y ago
    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.
    - tolmasky 14y ago
      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.
pjmlp 14y ago
Some people seem to enjoy more hacking than doing what makes business sense. Every hour spent converting JavaScript to CoffeeScript code, could have been spent improving Dropbox. Doing the math of salary per hour that each Dropbox coder involved in such conversion earns, what is the cost of converting the code to CoffeeScript?
- lazerwalker 14y ago
  In this specific situation, the conversion was done as part of a Dropbox hackweek. There are almost certainly other projects they could have worked on for that week that would have resulted in a more tangible business gain for Dropbox as a company, but the point of teamwide hackweeks/hackathons/etc is more employee morale than anything else. It seems to me that it succeeded pretty well at that goal.
  - MatthewPhillips 14y ago
    Rewriting working production code is not something to be done for fun at a hackweek. It's a very serious thing. And since it took a week they had a significant amount of code to rewrite. What new bugs were introduced by the rewrite? Did they open the door to any XSS attacks? Who knows.
    - btilly 14y ago
      Did you read the article? A lot of that week was spent testing that there were no regressions in the code, and not actually rewriting. I'd be comfortable that no new attack vectors were opened.
    - gfodor 14y ago
      You really seem to be on a crusade to convince people that this was a reckless, short-sighted, waste of time. Clearly these developers are professionals because they went into detail how they prevented regressions. I wouldn't be surprised if they inadvertently fixed a number of bugs due to the fact those bugs are impossible to make in CoffeeScript, or because they filled in gaps in their test coverage. Porting JS code to CoffeeScript is not very hard to do safely. I've done it myself for fairly large pieces of code (not this big.) In this case, it was for a hack week project and was a modest amount of code. It sounds like they got buy-in from the rest of the team that using CoffeeScript is a net win. It sounds like they are moving forward, it was a good decision and use of time, and they are happy with the result. Why do you think you can make arguments that it is in fact not any of these things, when the people who did it are stating otherwise, and the organization is acting otherwise? Why do you think you can make arguments against re-writes that suggest avoiding them because they never ship, when this project has, in fact, shipped, and did so in a week? Either you are missing something, or Dropbox is deluding themselves and are just falling for hype. What do you think is more likely?
deleted 14y ago
[deleted]
lowboy 14y ago
> The Dropbox devs apparently didn't want to go through that learning curve That's not a fair statement. I'm a competent js developer, having trudged up that curve, and I still love cs. Not for lack of learning, but because I value brevity and reduced keystrokes.
- MatthewPhillips 14y ago
  Yeah, I'm not anti-CoffeeScript, but from the article this sounds like a big reason why they switched, which is a perfectly valid reason.
  - lowboy 14y ago
    I didn't come away with that impression - what sections of the article made you lean that way?
    - deleted 14y ago
      [deleted]
  - cnp 14y ago
    Ummm... i'm pretty sure that the devs over at DropBox know their JavaScript inside and out. These "rules to master" are in no way complex to understand.
gfodor 14y ago
First, it's not a matter of just learning to do something and moving on. There is incremental mental baggage that comes with every one of these "tricks". Since we are both Javascript developers, I won't list any, but I think we both know that some of the things you need to remember to do go beyond adding an additional equals sign. The sum of this is you can often find yourself falling into one of these traps, even after many years of experience, because there are just so many places you can be tripped up. Second, I'm going to disagree with you on having a polygot codebase. If the developers decided that CoffeeScript is a better environment than Javascript (which you may disagree with), then I think it's clear the ideal scenario for them is their entire codebase is in a single language. Since it was tractable for them to convert the existing code, it seems logical to do that (not withstanding concerns like version control history, etc, which seems like an academic concern not really that important in practice.) In fact, converting an existing code base is a common way to learn CoffeeScript and come to a judgement if it is suitable for future development. Such seems to have been the case here.

scott_s 14y ago

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.

MatthewPhillips 14y ago
> 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 http://www.joelonsoftware.com/articles/fog0000000069.html
- scott_s 14y ago
  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.
  - MatthewPhillips 14y ago
    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.
    - scott_s 14y ago
      The scope is so small that it's on par with any other feature.
      - deleted 14y ago
        [deleted]
- jsight 14y ago
  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.
  - btilly 14y ago
    Read the article. Their first step was to run their existing JavaScript through a js2coffeescript converter.
- btilly 14y ago
  That essay is a classic. It is also wrong. See http://www.perlmonks.org/?node_id=115511 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."
- georgemcbay 14y ago
  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).
adgar 14y ago
> 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.
- rimantas 14y ago
  And the price will be about zero.
tolmasky 14y ago
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()) { }
- scott_s 14y ago
  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.
  - tolmasky 14y ago
    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.

pjmlp 14y ago

Some people seem to enjoy more hacking than doing what makes business sense. Every hour spent converting JavaScript to CoffeeScript code, could have been spent improving Dropbox. Doing the math of salary per hour that each Dropbox coder involved in such conversion earns, what is the cost of converting the code to CoffeeScript?

lazerwalker 14y ago
In this specific situation, the conversion was done as part of a Dropbox hackweek. There are almost certainly other projects they could have worked on for that week that would have resulted in a more tangible business gain for Dropbox as a company, but the point of teamwide hackweeks/hackathons/etc is more employee morale than anything else. It seems to me that it succeeded pretty well at that goal.
- MatthewPhillips 14y ago
  Rewriting working production code is not something to be done for fun at a hackweek. It's a very serious thing. And since it took a week they had a significant amount of code to rewrite. What new bugs were introduced by the rewrite? Did they open the door to any XSS attacks? Who knows.
  - btilly 14y ago
    Did you read the article? A lot of that week was spent testing that there were no regressions in the code, and not actually rewriting. I'd be comfortable that no new attack vectors were opened.
  - gfodor 14y ago
    You really seem to be on a crusade to convince people that this was a reckless, short-sighted, waste of time. Clearly these developers are professionals because they went into detail how they prevented regressions. I wouldn't be surprised if they inadvertently fixed a number of bugs due to the fact those bugs are impossible to make in CoffeeScript, or because they filled in gaps in their test coverage. Porting JS code to CoffeeScript is not very hard to do safely. I've done it myself for fairly large pieces of code (not this big.) In this case, it was for a hack week project and was a modest amount of code. It sounds like they got buy-in from the rest of the team that using CoffeeScript is a net win. It sounds like they are moving forward, it was a good decision and use of time, and they are happy with the result. Why do you think you can make arguments that it is in fact not any of these things, when the people who did it are stating otherwise, and the organization is acting otherwise? Why do you think you can make arguments against re-writes that suggest avoiding them because they never ship, when this project has, in fact, shipped, and did so in a week? Either you are missing something, or Dropbox is deluding themselves and are just falling for hype. What do you think is more likely?

deleted 14y ago

[deleted]

lowboy 14y ago

> The Dropbox devs apparently didn't want to go through that learning curve That's not a fair statement. I'm a competent js developer, having trudged up that curve, and I still love cs. Not for lack of learning, but because I value brevity and reduced keystrokes.

MatthewPhillips 14y ago
Yeah, I'm not anti-CoffeeScript, but from the article this sounds like a big reason why they switched, which is a perfectly valid reason.
- lowboy 14y ago
  I didn't come away with that impression - what sections of the article made you lean that way?
  - deleted 14y ago
    [deleted]
- cnp 14y ago
  Ummm... i'm pretty sure that the devs over at DropBox know their JavaScript inside and out. These "rules to master" are in no way complex to understand.

gfodor 14y ago

First, it's not a matter of just learning to do something and moving on. There is incremental mental baggage that comes with every one of these "tricks". Since we are both Javascript developers, I won't list any, but I think we both know that some of the things you need to remember to do go beyond adding an additional equals sign. The sum of this is you can often find yourself falling into one of these traps, even after many years of experience, because there are just so many places you can be tripped up. Second, I'm going to disagree with you on having a polygot codebase. If the developers decided that CoffeeScript is a better environment than Javascript (which you may disagree with), then I think it's clear the ideal scenario for them is their entire codebase is in a single language. Since it was tractable for them to convert the existing code, it seems logical to do that (not withstanding concerns like version control history, etc, which seems like an academic concern not really that important in practice.) In fact, converting an existing code base is a common way to learn CoffeeScript and come to a judgement if it is suitable for future development. Such seems to have been the case here.