[deleted]
CoffeeScript for TypeScript
21–30 of 143 posts
Re: CoffeeScript for TypeScript
#22If I were going to do this, I’d probably go all the way to using ReScript, but it’s a nice idea. I’m quite surprised it’s not called ToffeeScript though.
+1 for tofeescript. 'Civet' certainly implies your code is being processed, but I'm not sure the connotation is desirable. And all IMHO of course, but significant-whitespace is the worst idea ever.
> significant-whitespace is the worst idea ever
Hear hear! I never heard a single argument for significant invisible characters that makes sense, ever.
Who would want to have a program that fails because you used invisible character X instead of invisible character Y?
Re: CoffeeScript for TypeScript
#23Not the first time I see the proposed pipe operator syntax but oh my god, did they have to make it so messy? data |> Object.keys |> console.log when you could have done |> data Object.keys console.log Or even better, don't introduce new syntax and just make it a simple function instead |>(data, Object.keys, console.log)) Yes yes, I know "|>" is not a legal variable/function name right now, but also, why not?!
Because that's not how the pipe operator works in any other language.
Re: CoffeeScript for TypeScript
#24Finally. I miss coffeescript everyday.
It really is one of my favorite languages. Elegant and expressive. One of my all time favorite projects was an Electron-based React app written in CoffeeScript.
Re: CoffeeScript for TypeScript
#25Under "Everything is an Expression": items = (() => { const results = []; for (const item of items) { if (item.length) { results.push(item.toUpperCase()); } else { results.push(" "); } } return results; })(); Seems like they are purposely making the JS version extra long. It could be: items = items.map(x => x.length > 0 ? x.toUpperCase() : ` `) Edit: Just realised the code on the right is the compiled code, not the "…
My kingdom for "everything is an expression" in JS/TS, but that would likely require an entirely new language.
If you’re willing to accept a little bit of extra syntax/ceremony, the `do` expressions proposal[1] is pretty much this (but it’s only stage 1 so who knows when/if it’ll land).
Re: CoffeeScript for TypeScript
#26Way back in the early 2010s I was very "excited" about coffee script and similar projects. They sounded like they should be great for productivity.
When I actually tried to write a project in coffee script, the results were the opposite of what I expected.
The code was harder to read, harder to modify, harder to understand, harder to reason about.
There's something about removing stuff from syntax that makes programming harder. My hypothesis is this: your brain has to spend extra effort to "decompress" the terse syntax in order to understand it, and this makes reading code unnecessarily difficult.
So I fundamentally disagree with the underlying premise of these projects, which seems to be based on PG's concept of "terse is power".
My experience suggests the opposite: there's power in being explicit. Type declaration is an example of such a feature: it makes explicit something about the code that was implicit.
Type declarations add more to the parse tree, and require you to type more, but they actually give you more power.
The same can be said about being explicit in the language constructs.
There of course has to be a balance. If everything is way too explicit (more so than needed) then your brain will do the opposite of what it needs to do with terse code: it has to spend more effort to remove the extra fluff to get to the essence of what the code is doing.
Being terse is good, up to a point. Same with being explicit.
Languages that try to bias too strongly towards one extreme or the other tend to miss the mark. Instead of aiming for balance, they start to aim for fulfilling some higher telos.
Re: CoffeeScript for TypeScript
#27Earlier quoted context omitted.
My kingdom for "everything is an expression" in JS/TS, but that would likely require an entirely new language.
At some point you might as well just use lisp, right? :D
I love me some lisp, but I definitely prefer my JS-hosted code to be as close to JS language and semantics as possible (and that’s after a few years working in ClojureScript). Then again I’m commenting in a thread about an article with CoffeeScript in the title so I’m probably the weird one here.
Re: CoffeeScript for TypeScript
#28I'm not sure if getting some extra syntactic sugar is worth adopting a whole other language into a codebase: at least, that seemed to be one of the lessons from CoffeeScript.
Eh, as long as the team is on board, and the sugar is simple enough and maps well to the underlying language without a ton of extra code, then I have no issues with it. If it ever becomes a liability, you just check in the "transformed" code and it's gone.
You check in the transformed code and it’s gone, except for the Ghost of Syntactic Sugar which will haunt your codebase forever and make the juniors wonder why all the code is so awful.
Re: CoffeeScript for TypeScript
#29Not the first time I see the proposed pipe operator syntax but oh my god, did they have to make it so messy? data |> Object.keys |> console.log when you could have done |> data Object.keys console.log Or even better, don't introduce new syntax and just make it a simple function instead |>(data, Object.keys, console.log)) Yes yes, I know "|>" is not a legal variable/function name right now, but also, why not?!
Because that's not how the pipe operator works in any other language.
In Clojure it does:
(-> "Hello, World"
string/uppercase
(string/split #",")
first
string/trim)
Re: CoffeeScript for TypeScript
#30Way back in the early 2010s I was very "excited" about coffee script and similar projects. They sounded like they should be great for productivity. When I actually tried to write a project in coffee script, the results were the opposite of what I expected. The code was harder to read, harder to modify, harder to understand, harder to reason about. There's something about removing stuff from syntax that makes programm…
I didn't mind the coffeescript experience, but it's deeply hurtful to productivity to dev in a platform that doesn't end up winning.