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

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 corrupt your code.

- Not being able to distinguish an assignment from a variable definition: causes identifier typos to become new variables.

This implicitness makes programs error prone in ways that are hard to verify and work with. Plus, needs to be transpiled and you will need sourcemaps.

In the end, the benefits are not worth it, even back during the time it was created.

> Rust has a standard testing facility that most Rust crates use, and Rust has a standard repository of Rust crates in crates.io. GitHub further contains repositories of Rust crates that are not published to crates.io.

> These factors allow us to treat the entire world of open source Rust code as our test suite.

> As new nightlies and betas are published, we use the cargobomb tool to test this corpus of Rust code (as of 2017/07/10 over 13,000 crates) against both the stable release and a nightly or beta release, comparing the results for regressions.

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 my projects has paid off massively whenever I took post-delivery maintenance and support contracts.

That's only because JS is literally the only language allowed inside the browser (back in the day you had at least two other possibilities: ActionScript and Java. However, both Java applets and Flash-based sites fell out of favor (for good reasons)). No matter how well designed a language there's always going to be a particular combination of problem domain + programmer type for which the language does a poor job. And that's assuming the language is well designed in the first place, which is at least debatable with JS.

It's also worth noting that the JS itself tends to be transpiled to itself with Babel or other tools. There's nothing inherently bad about transpilation, and source maps solve the most serious problems with them.

> As many things in JS world, they tend to end up as an abandonware.

That's not really the case. After initial development, once a transpiled language implements all the features an author wanted, there is little more to do with it. New features of JS, which would have to be implemented in a transpiled language, are few and far between. The last such features were generators, and most of the "abandoned" transpiled languages had them quickly implemented.

In other words, there's a difference between "abandoned" and "feature complete and in maintenance mode". While some transpiled languages are indeed abandoned, others are not - there's simply not that much to do with them, aside from fixing bugs.

> This all make long-term mainainability of large JS + "featurelang" projects hard.

Why? Most of the "featurelangs" are stable and were stable for a couple of years at least. You can reasonably expect CoffeeScript code from 2011 to get properly transpiled today. What exactly makes it hard to maintain the code written in such languages, compared to pure JavaScript?

> [TypeScript] had initial burst of interest, but seem to be waning now.

I believe TS is here to stay, even if its popularity diminishes a bit. There are programmers who want their languages statically typed and that's one thing you cannot, in any way, emulate in pure JS. TS is only going to get replaced once the Web gets first-class support for other languages, but that's not happening anytime soon.

> no featurelangs in my projects has paid off massively whenever I took post-delivery maintenance and support contracts.

Again, what problems did you have with long-term maintenance of transpiled code bases? I never had any and, if anything, updating JS code over time to take advantage of its new features was a bigger pain than having all those features available since 2009.