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

101–110 of 143 posts

Re: CoffeeScript for TypeScript

#101

Post by dontlaugh »

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.

The problem is that it doesn’t compose, not the verbosity.

Re: CoffeeScript for TypeScript

#103

Post by realharo »

rjh29 wrote: post #92
realharo wrote: post #88

Earlier quoted context omitted.

Rust is one of the few languages I've seen that really does error handling right. Errors are still values in Rust - usually as part of the `Result` type - but unlike Go, it actually has tools to let you deal with them in a convenient way, like the `?` propagation operator ( https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi... ), or the functions on the `Result` type like `map`, `and_then`, `map_err`, or cr…

The fact that the anyhow/thiserror crates are basically required, or you have to make a bespoke enum for your crate's errors and write conversion functions for them, is not great. The try operator and Result type is amazing though.

Many languages have this discussion about what functionality belongs in the standard library and what is best left to external libraries - to avoid being stuck with a bad design forever because of backwards compatibility, etc.

I don't see a problem with relying on a few super popular basic libraries for almost every project.

Re: CoffeeScript for TypeScript

#104

Post by feeela »

Is this an April fools joke? You compile Coffeescript to Typescript to JavaScript to bytecode.

What problem ist actually solved by being able to compile pseudo-languages like Coffeescript or Typescript into each other?

Re: CoffeeScript for TypeScript

#106

Post by ocimbote »

Everything old is new again.

I have had a non-trivial experience with CoffeeScript. Maybe one can find the syntax easier on the eye, but it is always at the cost of added ambiguity, both for the parser and the reader.

After one too many parsing error debug session in CS, I just moved back to plain JS (later, TS), only to be happy with it ever after. to the point that after this comment, I won’t even consider trying Civet further than their homepage.

Re: CoffeeScript for TypeScript

#107

Post by dagw »

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.

As someone who used to be a big CoffeeScript advocate, I agree that adopting CoffeeScript over modern JavaScript isn't worth it. However adopting CoffeeScript when it came out over what JavaScript looked like at the time was a much bigger win.

That being said, as much as I liked using CoffeeScript in my own personal projects, adopting it for a non-trivial project at work probably turned out to be a net mistake all things considered. The only positive was that the .js output files where clean any easy enough to work with that we could quite easily just drop CoffeeScript and continue developing directly with those .js file

Re: CoffeeScript for TypeScript

#108

Post by frou_dh »

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.

The thing about:

    if err != nil {
        return err
    }
...is that it's not even Error Handling. It's "Error Shovelling" (manual work to move the error from one place to another).

Re: CoffeeScript for TypeScript

#109

Post by jeroenhd »

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?!

I think the pipe operator makes more sense this way. It behaves like shell pipes (grep |> sort |> uniq |> cut |> echo) rather than the Clojure equivalent.

I wouldn't put every method on a new line, though.

Re: CoffeeScript for TypeScript

#110

Post by aerhardt »

Throw999999 wrote: post #72
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…

As terse as possible for me, I think you underestimate the human brain.

I don't underestimate the human brain - however, I know as a fact, through ample empirical evidence, that implicit or dynamic typing makes my head hurt and has me scrambling through multiple code panes trying to understand the input or return types for code that I wrote five days ago.

I also know as a fact that programmers 100x my caliber have nevertheless written great large-scale software without types.

So I don't make generalizations on the human condition and just do what works for me!

Post reply on HN