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
}
if x in map:
# x is in map, process it
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:
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.
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."
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).
Quick example of how you're wrong: their version history is now trashed. They're going to pay the price for that for years.
if (map.find(x) != map.end()) {
}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.
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?
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.
What new bugs were introduced by the rewrite? Did they open the door to any XSS attacks? Who knows.
I'd be comfortable that no new attack vectors were opened.
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?
That's not to say that you can't lose a lot of money refactoring working code — I dislike rewrites, they always cause unforeseen problems. But great software isn't a function of how many hours you've put into it. It's a complex result of developer morale, time, energy, experience, and skills, and there's a huge benefit to "hey I can think in a language that makes sense to me, instead of remembering weird bugs I have to work around." It's thinking on a higher plane. It lets you more easily load the program into your head. [1] And it can be all the difference if you want a truly exceptional product. [2]
The authors' arguments were correct and showed an understanding of their tools' histories.
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.
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.
Just deal with it and move on. It's really not worth trying to achieve some sort of "Wow I love this language the best it's brilliant" state. It's far better to achieve a "I'm creating some cool stuff that solves a problem" state.
Language syntax is simply not very important. Every single language has quirks. Learn them, and move on.
If you're unhappy working in a particular language, maybe you're not cut out to be a software developer. You should be happy you're creating things that solve problems - if you're not, reconsider your career choice.
You see it in everything in life though. The best way to become a fantastic cyclist say, isn't to buy the best bike out there. It's to buy a crappy cheap bike, and learn how to get the most out of it.
Which makes me realize I have no idea who the world's best programmer is.
For example, obsessing over the use of a semi-colon to signify the end of a statement in your language syntax.
In other words, why would anyone use Emacs?
serious lol