Coffeescript had some great features: classes, array comprehensions, default parameter values, arrow functions, optional chaining. Many of these eventually made it to ecmascript.
And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco.
I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the time it's an indentation error. In coffeescript it's a valid program that means something completely different than what you intended. Combined with the optional punctuation, which the community encouraged leaning into, it was far too easy to write ambiguous code that you and the compiler would come to different interpretations of.
In case you wondered how Civet compared to CoffeeScript in these regards:
* `is not` is the textual equivalent of `!==`. You can use `isnt` if you turn on the feature explicitly (or even the weird CoffeeScript `is not` behavior if you want it, mainly for legacy code)
* Implicit returns are turned on by default. They are really useful, most of the time, and don't get in the way much if you use `void` return annotations (which turns them off). But if you don't like them, you can turn them off globally with a compiler flag.
* Civet's compiler is built on very different technology from CoffeeScript's (PEG parsing, similar to Python), and it is much more strict about indentation. None of those weird bugs anymore.
* We do have implicit parentheses and braces and such, but you're free to use explicit parentheses and braces as you like. We encourage people to rename their .ts files into .civet (which mostly just works without any converison) and just embrace the features/syntax they like.
> but you're free to use explicit parentheses and braces as you like
I’ve been eying Civet and I quite like it so far, but I dislike having this option because it means I’ll have to see it in other peoples code. I prefer strict rules for readability.
What was so ruinous about implicit returns? That's one of the things I missed most when leaving CoffeeScript. ECMAScript only partially adopted it (single statement fat arrow functions) which probably muddies the waters for people trying to learn and understand the language's behavior.
Since it's optional for the caller to use or assign the return value of a function, I don't see much problem with functions defaulting to returning something. Maybe it just fits with my personal preference of functions returning a value and not having side-effects..
probably gets better with use but having to remember not to put a loop as the last statement of a function, because it would make it return an array of the last statement of the loop body, caught me off guard enough times to get annoying.
easy enough to add an extra line with just 'undefined' as the last statement of the function of course. but then you do need to remember that.
Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish).
Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll their eyes and silently say "nope" in terror. Which was a shame, because large JS codebases are difficult to maintain and explore.
In Ruby and Elixir, it is implicit returns. That's always been like that, and people working with those languages don't have a problem with it. When I started writing Typescript, I was screaming internally at the explicit returns.
So I think this has more to do with how people are used to thinking with the languages they are fluent in.
And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco.
I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the time it's an indentation error. In coffeescript it's a valid program that means something completely different than what you intended. Combined with the optional punctuation, which the community encouraged leaning into, it was far too easy to write ambiguous code that you and the compiler would come to different interpretations of.