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

CoffeeScript for TypeScript

civet.dev

Post reply on HN
Print view View original

31–40 of 143 posts

Re: CoffeeScript for TypeScript

#31

Post by eyelidlessness »

ezekg wrote: post #23
capableweb wrote: post #17

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

Of course it is, at least conceptually. See various lisps’ threading macros (which are of course functions over code; but they correspond exactly to mapping over a series of functions, each one supplying input to the next).

Re: CoffeeScript for TypeScript

#32

Post by eyelidlessness »

askonomm wrote: post #29
ezekg wrote: post #23

Earlier quoted context omitted.

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) `->` is a threading-first macro, and `->>` is a threading last macro. More here: https://clojure.org/guides/threading_macros

Beat me to it while I was typing! Alas, I’m on mobile and your example is a better illustration of the point.

Re: CoffeeScript for TypeScript

#33

Post by cglong »

hsn915 wrote: post #26

Way 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…

Go's error handling pattern is a great example of being overly explicit IMO. I personally like it, but I can understand why it causes so much controversy.

Re: CoffeeScript for TypeScript

#34

Post by hsn915 »

technion wrote: post #30
hsn915 wrote: post #26

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

Is it? I find most of the "winning" tech deeply unproductive. Have you tried developing in a project with Webpack and Redux? It's kind of its own little hell. Everything is way too slow and complicated. Tasks that should take 20 minutes take 3 hours.

Re: CoffeeScript for TypeScript

#35

Post by hsn915 »

cglong wrote: post #33
hsn915 wrote: post #26

Way 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…

Go's error handling pattern is a great example of being overly explicit IMO. I personally like it, but I can understand why it causes so much controversy.

I find that Go errs way too strongly on the explicit side, but overall it's still better than many other alternatives.

For error handling I tend to write in a style where errors are either asserted out or "folded". If I do several operations in sequence any of them could err, I code in a way where I don't check every single op: instead I make some kind of "error accumulator", or write the code in a style such that if the previous operation failed the next operation will become effectively noop. I then check for errors at the end of the process.

That said, Go is actually right about treating errors as values and not giving special language constructs to throw/catch them.

Re: CoffeeScript for TypeScript

#36

Post by notShabu »

hsn915 wrote: post #26

Way 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…

Same, even though a lot of syntax is theoretically unnecessary, they chunk the code into patterns that help navigate the complexity.

Otherwise it's like improving the efficiency of a closet by ripping out the shelves, drawers, dividers, coat hangers, etc... so that it's just one big volume-maximized empty room.

Re: CoffeeScript for TypeScript

#37

Post by smt88 »

Klathmon wrote: post #5
vore wrote: post #2

I'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.

JS is flexible enough that you can get 90% of the sugar from CoffeeScript without leaving the language.

That said, I always found CoffeeScript to be a worse language (syntactically) than JS.

Re: CoffeeScript for TypeScript

#39

Post by statictype »

hsn915 wrote: post #34
technion wrote: post #30

Earlier quoted context omitted.

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.

Is it? I find most of the "winning" tech deeply unproductive. Have you tried developing in a project with Webpack and Redux? It's kind of its own little hell. Everything is way too slow and complicated. Tasks that should take 20 minutes take 3 hours.

“Winning tech” may be less productive for a one-off single person project.

But “losing tech” is unproductive when you have to maintain/upgrade your code over many years and onboard new developers into the team.

It is unfortunate that the tech industry’s choice of tools is largely fashion-driven but that is the reality.

Post reply on HN