8 ms·
This sounds so much like some geeks wanting to hack. That's it. There isn't really a good reason to convert a codebase with tens of thousands of lines of code f
by jlongster 14y ago
This sounds so much like some geeks wanting to hack. That's it. There isn't really a good reason to convert a codebase with tens of thousands of lines of code from js to CoffeeScript.
Not that there's anything wrong with that. But seriously, every single problem with javascript they mention is never a problem for javascript developers. You simply learn what's broken, and deal with it. Dealing with it is usually one line of code (or even less), making sure you just use ===, etc. It's really not a problem.
These kinds of posts smell a little like FUD to me, which is what I have a problem with.
- gfodor 14y agoTo a lot of people CoffeeScript promotes the intangible benefit of happiness. (Similar to ruby.) If working in CoffeeScript makes everyone's work much more enjoyable (for whatever reason), with minimal cost, isn't it worth it? I, for one, want to minimize the amount of things I need to "deal with" at work, be it shoddy programming language workarounds or a half-broken coffee machine.
- MatthewPhillips 14y agoNo, 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 agoHow 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 agoJoel'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 agoThe 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 agoThe scope is so small that it's on par with any other feature.
- deleted 14y ago[deleted]
- pjmlp 14y agoSome 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 agoIn 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 agoRewriting 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 agoDid 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 agoYou 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 agoYeah, I'm not anti-CoffeeScript, but from the article this sounds like a big reason why they switched, which is a perfectly valid reason.
- gfodor 14y agoFirst, 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.
- mibbitier 14y agoIf you're unable to deal with broken, buggy, or poorly designed things, that makes you a bad developer. 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.
- prospero 14y agoNice false dichotomy you got there.
- mibbitier 14y agoI'm just saying... Good developers concentrate on building things. Bad developers concentrate on how much they like their tools. 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.
- Yahivin 14y agoAnd then to buy a better bike.
- scott_s 14y agoThat's a curious metaphor, because the best cyclists - the ones who win professional races - have very expensive bikes.
- bicknergseng 14y agoSeriously... if I were to pick something I'd pick music. Miles Davis on a $100 trumpet could make better music than almost anyone else with a $10k one.
- smokeyj 14y agoThis is like saying people should avoid jquery because everything jquery does can be done with javascript. Some of us enjoy the convenience of not dealing with hacks.
- MatthewPhillips 14y agoCan you give an example of a javascript hack that you have to deal with?
- jcampbell1 14y agoI don't like having to manually check for globals. Other people's code tends to be loaded with missing 'vars'.
- MatthewPhillips 14y agoCoffeeScript won't fix other people's code for you.
- jcampbell1 14y agoIt does fix that specific issue.
- smokeyj 14y agoDealing with inconsistent API's across browsers.
- scott_s 14y ago"Dealing with it" adds cognitive load. Both when programming, and when reading code others wrote, or you wrote a while ago. Eliminating that cognitive load may (note, again, I said "may", not "will") be worth it.
- arturadib 14y agoI like it that it partially solves the callback hell problem - at least you don't have to routinely align/indent closing }); }; )}; ); }); etc... Everything else, like being easier on the eyes, having built-in classes, not having to spell "function" a million times, etc, is a welcome bonus.
- jlongster 14y agoHonestly, it makes it much worse for me. With brackets, I can place my cursor over the end one and my editor highlights the beginning one. While I'm coding that lets me double-check where I am while I'm working inside a callback.
- deleted 14y ago[deleted]
- bestest 14y agoSeriously. You're doing it all wrong if you're lost in the callback hell.
- denysonique 14y agoThere is a good reason: If they offered me a job and it was in JS I wouldn't take it. If they offered it in CoffeeScript: I would probably say yes.
- untog 14y agoBut how many are the reverse? I'd wager a lot, given the number of people out there that code in JS vs CS.
- oinksoft 14y agoI refuse to use CoffeeScript and I avoid using libraries that are written in the language.
- lttlrck 14y agoThis is what I was thinking. Convert to CS and then struggle to find developers in a few years when the guys that's thought this was a great idea have moved onto the next big thing.
- gfodor 14y agoHonestly I've been hearing this argument about CoffeeScript for what feels like a long time. I don't think it's going anywhere.
- lttlrck 14y agoexcept you'd still be touching JS every single day during debugging... what nonsense. CS is a preprocessor, hardly a language.
- doublerebel 14y agoI've been writing JS for over a decade and never had a problem with it. I put off CoffeeScript for ages, because nothing was wrong with my JS code. "Besides," I thought, "CoffeeScript compiles to JS, it can't do anything JS can't do." And that is true. Nothing is exactly wrong with JS. In fact many things are great about JS, which is how we end up with ClojureScript and CoffeeScript and x86 emulators. JS is very powerful -- maybe too powerful. There are a million ways to accomplish the same task, which means that during an initial look at a new JS codebase, the program flow is not obvious. Some developers hate semicolons, some always put commas at the end of the line and some at the beginning, some always use braces and some don't use braces with single-line statements. One can never be sure where a statement ends, or what constitutes a code block, unless one hunts down all the trailing braces, parentheses, and semicolons. I'm not even going to mention all the possible inheritance patterns. CoffeeScript is not nearly as flexible in syntax. There is one way to make a code block, one inheritance method. It doesn't need semicolons, braces, or parentheses because of its strict style. Therefore there is less to think about. There is less to go wrong. No one needs to use a CoffeeScriptLint, because CoffeeScript is not full of non-obvious 'gotchas'. CoffeeScript code is more concise and more intuitive, because it reads more like an English sentence. When I read another developer's CoffeeScript I can begin understanding the meaning instantly, rather than having to spend time determining the structure and programming technique. List comprehensions, ranges, and other functional programming tools simply don't exist in pure JavaScript -- the JS equivalent is much more verbose and much less obvious. CoffeeScript encourages creating small flexible code blocks, which together make a powerful structure. This all leads to fewer opportunities for bugs to appear. The only thing I don't like about CoffeeScript, is that I didn't keep an open mind and start using it sooner. I think anyone who considers themselves a serious JS developer should give CoffeeScript a try. It's a much more relaxing, simple way to write powerful JS. (Credit goes to Spine.js switching to CoffeeScript to finally push me into it.) EDIT: Of course it is possible to write ambiguous, unclear code in any language. CoffeeScript is an opportunity to let go of old habits and find a fresh perspective on problem-solving: Maybe there is a better way to do things. (I had to let go of semicolons!) CoffeeScript's functional programming style has changed the way I approach programming. My code is now more robust and less complicated. Less bugs and less keystrokes mean I ship faster. CoffeeScript is a better language because it's a tool which makes me a better developer.
- ilaksh 14y agoThe reason to use CoffeeScript over JavaScript is because it is better software engineering. Number of lines of code has been shown to be one of the few good indicators for predicting defects. CoffeeScript significantly reduces the number of lines of code in a project and therefore the number of defects. CoffeeScript is cleaner and easier to read, which is better software engineering. CoffeeScript solves many of the issues with JavaScript. The fewer warts and plumbing people have to deal with related to the language, the more they can focus on the actual problems they wanted to solve. This is a little bit like the architectural decision to program user applications in languages and platforms with garbage collection and built-in frameworks rather than using a language like C or C++ with manual memory management and minimal standard libraries. Sure you get less control over the lower-level details such as allocation and deallocation of memory, but those lower level details actually are distracting from the application domain and were actually repetitive and could be automated. So the best way to solve those problems is to move to a platform that abstracts them away or handles them for you. The reason that developers don't like CoffeeScript (other than the fact that they haven't learned it yet, and don't want to take the time) is simple, psychological rather than logical, and its the same reason that they don't like platforms like the ones I was talking about above: it makes things significantly easier, and that is problematic psychologically for programmers for two reasons: 1) The whole point of being a programmer is that you are mastering complex ASCII codes that other people can't decipher. Making things less complex takes away part of your identity as a programmer (not for everyone obviously, but for many). 2) Many programmers instinctively and falsely believe that any system which makes their job significantly easier must automatically come with compensatory trade-offs in things like performance or flexibility. This is intuitive, but false. CoffeeScript improvements: indenting two spaces and using -> plus no closing parens and curly braces makes nested callbacks much easier to read and write, fat arrow binds this making it easier to use classes, class and extends provide a standard, simple way to create and extend classes, iterating over arrays and objects is much easier and cleaner, control flow and function definition is cleaner, better variable scoping, simplified closer wrapper in loops, more straightforward boolean operators, existential operator for cleanly and simply checking for variable existence. Thought of one other explanation for not liking CoffeeScript: plain old status quo bias. http://en.wikipedia.org/wiki/Status_quo_bias http://en.wikipedia.org/wiki/Status_quo_bias
- malandrew 14y agoLinting provides the same benefits with more edification instead of sweeping language nuance under the rug.