5 ms·

I recall when we first adopted Coffeescript, the engineers who did it touted that we had about 20% fewer lines of code as an example of coffeescript being bette

I recall when we first adopted Coffeescript, the engineers who did it touted that we had about 20% fewer lines of code as an example of coffeescript being better - a lot of which was probably just the removal of lines that only had curly-braces. In hindsight, this wasn't a good metric to judge the language on. As a larger engineering organization, what we've definitely learned over time is that we need to prioritize readability (and maintainability) over writability - as our code is going to last a long time and the original engineer who wrote it, will likely move on to another project, team, or even company. And while maybe they train their replacement, after a second or third iteration of that, the knowledge can easily end up lost. Coffeescript, as a language, definitely prioritizes terseness, often at the expense of readability. And we didn't have internal coding standards that pushed back on this. But even if we had done a better job using coffeescript, we're still better off in typescript today, due to the stronger community and stronger set of available open source tools to work with the language.

blitmap 6y ago
I think it does depend on how familiar the syntax feels to each individual. To me Coffeescript is the right balance. I absolutely love writing Literate Coffeescript. I am _not_ a fan of strictly typed languages but I do hope Coffeescript finds a friendly syntax for gradual typing like TS in the future. I usually prototype in a 'ducky' way and then lock down type expectations when I'm polishing.
- dgoldstein0 6y ago
  this is totally fair, but these days you are far more likely to find engineers to hire who know JavaScript or Typescript, than Coffeescript. This certainly matters more to larger projects and larger companies.
  - jessaustin 6y ago
    I can understand that people don't prefer coffeescript, but if someone "knows" JS or TS they could surely use coffeescript if they needed to do so... since we're still calling them "engineers" anyway.
    - dgoldstein0 6y ago
      Sure, but if there majority of your customers want a different language? You should probably listen. That's what happened here, and we are way happier for it. You might even guess that the "old guard" could have been against such a migration. As someone who should have been a member of that, I wasn't a fan of changing... But then got a few rude reminders from debugging coffeescript that didn't mean what I meant to write. At which point I started thinking that maybe everyone else had a point.
      - jessaustin 6y ago
        Your comment above seemed to refer to constraints in the other direction: "we can't use Lisp because the only coders available to hire only know Java!" The point is, coffeescript and javascript are much more similar than that, especially now that javascript has imperfectly copied some of coffeescript's improvements.
        dgoldstein0 6y ago
        It's not we can't use it, but rather using it for everything would make hiring, onboarding, and retention tougher, as well as maintenance. Apologies if I have the wrong impression in the earlier post.
erikw 6y ago
I see readability as a key advantage of TS. Once you are able to comfortably read type signatures, it is trivial to see what a function is supposed to do, or what a library is supposed to provide. When things don't work as expected, then it's just a matter of hopping into the debugger to inspect data inflight to find where the typings aren't matching up with reality.
- dgoldstein0 6y ago
  yup, types are a huge advantage, especially in large codebases where you probably don't know all the people who may write code to interact with your code. Readability of types can become an issue over time, but with the right naming of interfaces and useful type aliases, that can be mitigated to some extent. And as the typescript language and community evolve together, there are new ways to make some types even more readable - I've seen generics for getting the return type of a function, which seems potentially really useful (and some people swear by; I haven't used them extensively, but it looks like a promising idea).
  - momokoko 6y ago
    After ten years of JavaScript and after working on TypeScript apps that have now been around for 5+ years, I can assure you TypeScript is less maintainable long term than most languages. Did you know that TypeScript’s type system is turing complete? Good luck figuring out literal bespoke type frameworks in TypeScript. Did you know you can have a TypeScript application that takes more than 8GB of memory to compile? TypeScript is literally a Microsoft play to regain Visual Studio market share they lost by creating a language that much like C# and Java, practically speaking, requires a massive feature rich IDE for most developers to write software efficiently with. You all fell for it, and at this point it’s too late. Millions of extra development hours will wasted maintaining legacy TypeScript apps for years due to a Microsoft marketing stroke of genius.
    - d3nj4l 6y ago
      If genuine developer satisfaction from everyone I know IRL who's used typescript is due to Microsoft's marketing, I say they deserve to win this one.
baddox 6y ago
In my view, the primary advantage of CoffeeScript was to provide ways to avoid JavaScript footguns. I think that a combination of ES 2015 and wider propagation of best practices have made many such footguns avoidable in practice without using CoffeeScript.
- city41 6y ago
  But it brought along its own footguns. The article has one example > For example, we had a major production bug in the fall of 2013 due to a misplaced space character.
  - agency 6y ago
    Definitely my experience. Implicit returns are just a breathtakingly bad idea and I have personally witnessed them cause countless bugs.
    - city41 6y ago
      I think they can be ok in a language where it’s been well thought out. Like implicit return in clojure has never bugged or surprised me.
    - sullyj3 6y ago
      Interesting, I've never heard complaints about implicit returns before. I really enjoy them in languages like rust. What kind of bugs?
      - agency 6y ago
        I recall several resulting from the fact that lodash's _.forEach terminates iteration early if the function you pass it returns a falsey value for any element. Most people (myself included) weren't aware of this functionality and thought of the callback as a void function and weren't even thinking of what the last expression in it would evaluate to.
        6y ago

blitmap 6y ago

I think it does depend on how familiar the syntax feels to each individual. To me Coffeescript is the right balance. I absolutely love writing Literate Coffeescript. I am _not_ a fan of strictly typed languages but I do hope Coffeescript finds a friendly syntax for gradual typing like TS in the future. I usually prototype in a 'ducky' way and then lock down type expectations when I'm polishing.

dgoldstein0 6y ago
this is totally fair, but these days you are far more likely to find engineers to hire who know JavaScript or Typescript, than Coffeescript. This certainly matters more to larger projects and larger companies.
- jessaustin 6y ago
  I can understand that people don't prefer coffeescript, but if someone "knows" JS or TS they could surely use coffeescript if they needed to do so... since we're still calling them "engineers" anyway.
  - dgoldstein0 6y ago
    Sure, but if there majority of your customers want a different language? You should probably listen. That's what happened here, and we are way happier for it. You might even guess that the "old guard" could have been against such a migration. As someone who should have been a member of that, I wasn't a fan of changing... But then got a few rude reminders from debugging coffeescript that didn't mean what I meant to write. At which point I started thinking that maybe everyone else had a point.
    - jessaustin 6y ago
      Your comment above seemed to refer to constraints in the other direction: "we can't use Lisp because the only coders available to hire only know Java!" The point is, coffeescript and javascript are much more similar than that, especially now that javascript has imperfectly copied some of coffeescript's improvements.
      - dgoldstein0 6y ago
        It's not we can't use it, but rather using it for everything would make hiring, onboarding, and retention tougher, as well as maintenance. Apologies if I have the wrong impression in the earlier post.

erikw 6y ago

I see readability as a key advantage of TS. Once you are able to comfortably read type signatures, it is trivial to see what a function is supposed to do, or what a library is supposed to provide. When things don't work as expected, then it's just a matter of hopping into the debugger to inspect data inflight to find where the typings aren't matching up with reality.

dgoldstein0 6y ago
yup, types are a huge advantage, especially in large codebases where you probably don't know all the people who may write code to interact with your code. Readability of types can become an issue over time, but with the right naming of interfaces and useful type aliases, that can be mitigated to some extent. And as the typescript language and community evolve together, there are new ways to make some types even more readable - I've seen generics for getting the return type of a function, which seems potentially really useful (and some people swear by; I haven't used them extensively, but it looks like a promising idea).
- momokoko 6y ago
  After ten years of JavaScript and after working on TypeScript apps that have now been around for 5+ years, I can assure you TypeScript is less maintainable long term than most languages. Did you know that TypeScript’s type system is turing complete? Good luck figuring out literal bespoke type frameworks in TypeScript. Did you know you can have a TypeScript application that takes more than 8GB of memory to compile? TypeScript is literally a Microsoft play to regain Visual Studio market share they lost by creating a language that much like C# and Java, practically speaking, requires a massive feature rich IDE for most developers to write software efficiently with. You all fell for it, and at this point it’s too late. Millions of extra development hours will wasted maintaining legacy TypeScript apps for years due to a Microsoft marketing stroke of genius.
  - d3nj4l 6y ago
    If genuine developer satisfaction from everyone I know IRL who's used typescript is due to Microsoft's marketing, I say they deserve to win this one.

baddox 6y ago

In my view, the primary advantage of CoffeeScript was to provide ways to avoid JavaScript footguns. I think that a combination of ES 2015 and wider propagation of best practices have made many such footguns avoidable in practice without using CoffeeScript.

city41 6y ago
But it brought along its own footguns. The article has one example > For example, we had a major production bug in the fall of 2013 due to a misplaced space character.
- agency 6y ago
  Definitely my experience. Implicit returns are just a breathtakingly bad idea and I have personally witnessed them cause countless bugs.
  - city41 6y ago
    I think they can be ok in a language where it’s been well thought out. Like implicit return in clojure has never bugged or surprised me.
  - sullyj3 6y ago
    Interesting, I've never heard complaints about implicit returns before. I really enjoy them in languages like rust. What kind of bugs?
    - agency 6y ago
      I recall several resulting from the fact that lodash's _.forEach terminates iteration early if the function you pass it returns a falsey value for any element. Most people (myself included) weren't aware of this functionality and thought of the callback as a void function and weren't even thinking of what the last expression in it would evaluate to.
      - 6y ago