Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

benchling.engineering

Post reply on HN
Print view View original

21–30 of 31 posts

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

#21

Post by [deleted] »

gunn wrote: post #12
baybal2 wrote: 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.

[deleted]

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

#22

Post by DiThi »

badminton1 wrote: post #4

I found CoffeeScript to be a pain to work with. CoffeeScript added some useful features, like destructuring assignments, and some syntax sugar for objects, loops, etc... but it also made some choices that in my opinion are bad: - Making delimiters optional like parentheses, brackets, semicolons... in addition to implicit return statements: makes programs hard to read if abused. Makes code formatters get confused and…

The first problem is easily avoided with a few style guidelines. If a feature exists it doesn't mean it must be used. You can configure CoffeeLint to avoid confusing constructs.

The second problem didn't turn out to be as big as I thought. I was bitten by it about a couple times a year, and every time it was symptom of too long functions or too many closure nesting.

Transpiling and source maps are not a problem. Small changes in my code takes 200 ms to recompile with source maps, with webpack in watch mode (projects are ~20k lines). And when I start a new project I just copy the webpack config from the previous one (with cli switches for several features).

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

#23

Post by alangpierce »

wereHamster wrote: post #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.

Makes sense, I've certainly heard of people taking that approach. When I started working on decaffeinate, Prettier didn't exist and ESLint autofixing could only handle very simple cases.

Out of curiosity, were you using CoffeeScript 2? As I was doing research for this post, I noticed that the CoffeeScript 2 output was pretty good compared to what I had seen with CoffeeScript 1, although I think decaffeinate still gives better results in many cases. CoffeeScript 2 also had some small breaking changes, whereas with decaffeinate I needed to stay true to the exact language semantics, so arguably decaffeinate is safer than CS2 when run on a CS1 codebase.

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

#24

Post by DiThi »

jononor wrote: post #15
teh_klev wrote: post #7

Earlier quoted context omitted.

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

It works with node --inspect as well.

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

#25

Post by RubenSandwich »

time4tea wrote: post #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…

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

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

#26

Post by ecshafer »

sebcat wrote: 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 believe microfocus iirc has a cobol to java transpiler. But when we looked at it, it was decided it was too high of risk. At the millions loc level automated tools add another level of risk.

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

#27

Post by stevefan1999 »

CoffeeScript is a match in the heaven with JSX IMO. You for example no longer have to face the bracket and semicolon hell. (Unless you have StandardJS or ESLint, which is pretty much default for all devs)

There’s also implicit return, so the code pattern is prettier, no more return ()-ish thingy, and it feels closer to a template, but it is a boon and a bane at a same time since some devs got used to return like that.

Before CS2, we have to stick with coffee-react-transform, which is hacky and unmaintained and old. It transpile JSX to createElement directly, not good.

With CS2, you can write JSX expressions directly. A large subset of JSX is parsed, and only bracket/property expression will be transformed by the compiler, then processed with Babel. This is safer, more spec-conforming, and I could do some tricks like babel-preset-react-optimised.

CSX gets even better if you have MobX! It feels like PHP+Rails all the way while you’re also enjoying the MVVM ride. I'm already loving it and using it in my production heavily.

CoffeeScript is great, man. It is influential to ES6. Don't give up on CS yet. The ecosystem, however, is already shifted to JS. It took years to revive CS I guess.

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

#28

Post by alangpierce »

RubenSandwich wrote: post #25
time4tea wrote: post #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…

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…

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.

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

#29

Post by rmrfrmrf »

nimbix wrote: post #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...

I think you mean “should have stuck with Java applets”. They’ll be back in 10 years and you’ll all be sorry! /s

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

#30

Post by badminton1 »

DiThi wrote: post #24
jononor wrote: post #15

Earlier quoted context omitted.

Yup sourcemaps works fine for this, at least in browsers

It works with node --inspect as well.

Most likely you will like to set a breakpoint at the entrypoint. You can do this with --inspect-brk rather than --inspect.

Then you can see all debugging sessions in Chrome using chrome://inspect

Post reply on HN