Live data from Hacker News

From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

benchling.engineering

11–20 of 31 posts

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#11
post #9

Other types of businesses choose to maintain large chunks of code in a "legacy language" and paying people to maintain it overtime, at a cost (e.g., banks and COBOL). Let's say there's a COBOL -> C/C++/Rust/someotherfancylang transpiler. Maybe there is one, maybe not. Would it make sense for a bank to invest in something like that, or is there really no incentive to do so? Why would there be an incentive for a startu…

I have no specific knowledge, so take this with a grain of salt.

The article comments "Yuck. It works, but it certainly wouldn’t pass code review. Here’s what we really want:"

This shows that what's needed isn't simply a transpiler, which only needs to be technically correct according to the language semantics, but rather a transpiler which generates maintainable source code.

The "--loose" option gives another example of how maintainability might be important enough as to prefer a possibly incorrect transformation.

CoffeeScript and JS are semantically quite similar languages. COBOL is nowhere near as close to C/C++/Rust/etc. This makes it much harder to generate maintainable transpiled code.

Finally, the author's company developed "tools to help biologists coordinate experiments, analyze and work with DNA". A bug in this sort of environment has less severe consequences than (say) in the banking industry, where there are laws and regulations to follow, and where people's money might be on the line.

That is, banking has a lower risk tolerance for the sorts of errors that might sprout up in large-scale automated source code conversion.

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#12
post #8

There are many transpiled languages working on-top of js. As many things in JS world, they tend to end up as an abandonware. This all make long-term mainainability of large JS + "featurelang" projects hard. The liveliest JS add-on lang today is typescript, but even it gets seen less and less, despite Microsoft's backing. It had initial burst of interest, but seem to be waning now. My insistence on no featurelangs in…

Typescript seems healthy every way I can see. E.g. https://trends.google.com/trends/explore?date=today%205-y&q=...

It seems that a project like TS that restricts itself to adding future JS features and types should be different. To strip the types, and be left with plain javascript, just run it through typescript.

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#13
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.

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#14
When I had to convert a CoffeeScript project to plain JS, I basically took the output from the coffeescript compiler, formatted it using prettify/standard and fixed up any obviously stupid things that the coffeescript compiler does by hand. Took only a few days, but it wasn't a large project either.

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#15
post #7

Earlier quoted context omitted.

Another pain is (was?) debugging. This might have changed since but back when I tried and rejected using it. But back then, if you had an error at line X it would report the (compiled) JavaScript line rather than the CoffeeScript line - meaning you'd need to figure out which CS code generated what line of JS code in order to hunt down and fix issues.

Would source maps not help in this case? http://gunnariauvinen.com/using-source-maps-with-coffeescrip...

Yup sourcemaps works fine for this, at least in browsers

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#17
The JS tools/libs ecosystem really reminds me of crypto currencies. There's a million of them to choose from and if you jump on one during the height of its popularity you just end up losing a bunch in the crash that inevitably follows the pump. Should have just stuck with plan JS / those 50 bitcoins you had back in 2012...

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#18
post #16

I think it is quite funny how a tool to turn proper code into the mess that is ESxx can become so popular. I'm still using Coffeescript 2, it's awesome :)

I don't feel like ES6 gives me the concision or expressiveness of Coffeescript either.

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#19
post #16

I think it is quite funny how a tool to turn proper code into the mess that is ESxx can become so popular. I'm still using Coffeescript 2, it's awesome :)

I am using an even more minimal subset of CoffeeScript 2, basically classless, and love it. I can't find a sane reason to hand-write ESxx.

I complement it with Rust as needed, which is the only language that justifies having a verbose syntax.

Those two couldn't be farther apart, but their combination covers an extremely wide spectrum of programming tasks. From prototyping, to incrementally improving the robustness and performance as needed.

jashkenas did a great job, and CS2 is a very elegant and ongoing effort.

Re: From 200K lines of CoffeeScript to zero: making decaffeinate super-stable

#20

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…

(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.

Post reply on HN