3 ms·

This is an interesting article. However, it makes one important error. It compares the cost of hand translation with the cost of auto translation, but fails to

This is an interesting article. However, it makes one important error. It compares the cost of hand translation with the cost of auto translation, but fails to account for any time developing the translation tool, as it was done "in my own time". Clearly not a valid comparison. The author has also done lots of free ot-of-hours work for his company which he doesn't seem to realise. In quite a few companies this would also cause problems with IP ownership, particularly due to alignment between in-work and outside-work work.

alangpierce 9y ago
(Author here.) > fails to account for any time developing the translation tool There are (at least) two ways of looking at it: 1.) If you're an open source project or a company with a large amount of CoffeeScript that you want to move to JavaScript, should you convert it by hand, use decaffeinate, or take some other approach, and how long should you expect it to take? This is the viewpoint I was focusing on because that's the real situation people are in today now that decaffeinate exists and is stable. Hopefully the article convinced you that decaffeinate is the best tool for this job, but that you should still expect tens or even hundreds of hours of investment, depending on the size of your codebase, the level of code quality you're targeting, and the amount of risk you can accept. 2.) If you're a project or company with a codebase in language A and you want to convert it to language B, should you develop an in-house translation tool for that purpose? I think that in most cases, the answer is "no", unless you're a very large company, and this case is no exception. (Really, it depends on many factors, and tools like jscodeshift are a great way to lower the barrier to entry for large-scale codebase changes.) Not only did decaffeinate take a long time to develop, it was unclear how well it would work and how safe it would be. And, frankly, CoffeeScript to JavaScript is one of the easiest programming language conversions you can do. I mostly worked on decaffeinate because it was fun, rewarding, and educational, not because it was meant to be an efficient use of time for my company in particular. But given the number of people who have said "thank you" and the number of open source projects and companies that have already used it, hopefully it's a net benefit for the world.
RubenSandwich 9y ago
Not just IP problems, but also encourages bad work habits. His company should of sponsored this work if they felt it was in their best interest. This type of hero behavior burns people out and keeps open source projects with very limited resources. Edit: To the author because he replied once to this thread: I hope in the future you feel comfortable in the future asking for time to work on open source projects during company time and realizing that you doing work that benefits your company for free is not in your or your companies best interest long term. If you feel that they would be unwilling to do this during work hours then push for something like this: https://futurice.com/culture/sponsoring-free-time-open-source-activities https://futurice.com/culture/sponsoring-free-time-open-sourc....
- alangpierce 9y ago
  Thanks for the link, that Futurice policy is really cool. I certainly felt comfortable working on decaffeinate a little bit during work hours, and my company was fine with it, but I think the amount of time it needed was more than a small startup should be willing to invest. I would have pushed back if someone wanted me to work on it full time until it was done, and I wouldn't have worked on it if it was only an internal tool. Agreed that having a more formalized company position on open source work would be nice. For now it's just "use good judgement". I think in an ideal world, there would be lots of companies that each explicitly invest a little bit into these types of projects. It's already happening to some extent, but I think the incentives are hard to get right (especially for projects with a high chance of failure), and plenty of popular projects probably don't get enough attention, especially from companies that rely on them.

alangpierce 9y ago

(Author here.) > fails to account for any time developing the translation tool There are (at least) two ways of looking at it: 1.) If you're an open source project or a company with a large amount of CoffeeScript that you want to move to JavaScript, should you convert it by hand, use decaffeinate, or take some other approach, and how long should you expect it to take? This is the viewpoint I was focusing on because that's the real situation people are in today now that decaffeinate exists and is stable. Hopefully the article convinced you that decaffeinate is the best tool for this job, but that you should still expect tens or even hundreds of hours of investment, depending on the size of your codebase, the level of code quality you're targeting, and the amount of risk you can accept. 2.) If you're a project or company with a codebase in language A and you want to convert it to language B, should you develop an in-house translation tool for that purpose? I think that in most cases, the answer is "no", unless you're a very large company, and this case is no exception. (Really, it depends on many factors, and tools like jscodeshift are a great way to lower the barrier to entry for large-scale codebase changes.) Not only did decaffeinate take a long time to develop, it was unclear how well it would work and how safe it would be. And, frankly, CoffeeScript to JavaScript is one of the easiest programming language conversions you can do. I mostly worked on decaffeinate because it was fun, rewarding, and educational, not because it was meant to be an efficient use of time for my company in particular. But given the number of people who have said "thank you" and the number of open source projects and companies that have already used it, hopefully it's a net benefit for the world.

RubenSandwich 9y ago

Not just IP problems, but also encourages bad work habits. His company should of sponsored this work if they felt it was in their best interest. This type of hero behavior burns people out and keeps open source projects with very limited resources. Edit: To the author because he replied once to this thread: I hope in the future you feel comfortable in the future asking for time to work on open source projects during company time and realizing that you doing work that benefits your company for free is not in your or your companies best interest long term. If you feel that they would be unwilling to do this during work hours then push for something like this: https://futurice.com/culture/sponsoring-free-time-open-source-activities https://futurice.com/culture/sponsoring-free-time-open-sourc....

alangpierce 9y ago
Thanks for the link, that Futurice policy is really cool. I certainly felt comfortable working on decaffeinate a little bit during work hours, and my company was fine with it, but I think the amount of time it needed was more than a small startup should be willing to invest. I would have pushed back if someone wanted me to work on it full time until it was done, and I wouldn't have worked on it if it was only an internal tool. Agreed that having a more formalized company position on open source work would be nice. For now it's just "use good judgement". I think in an ideal world, there would be lots of companies that each explicitly invest a little bit into these types of projects. It's already happening to some extent, but I think the incentives are hard to get right (especially for projects with a high chance of failure), and plenty of popular projects probably don't get enough attention, especially from companies that rely on them.