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

121–130 of 143 posts

Re: CoffeeScript for TypeScript

#121

Post by nine_k »

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…

All natural languages have a little bit of redundancy. It helps solve ambiguities more easily, especially when solving it in a strictly minimal grammar would require re-parsing the entire text from start. Having both opening and closing parens / brackets / braces is a good example.

Redundancy also helps when transmission is imperfect. And you do have imperfect transmission when writing code (typos), and even when reading (skimming text, missing a character).

CoffeScript makes every character count, especially punctuation. It's really, really easy to make a small typo in these. But CoffeeScript eschews redundancy, so the typo becomes another valid grammatical construction, with an entirely different meaning. At best, you get a cryptic translation error elsewhere. At worst, it gets accepted but works differently than you had intended.

APL has this property, too. But an APL program is very terse, you pay attention to every character in a short string of them. It does not feel like Javascript which is traditionally lax in the punctuation and whitespace department, catching you off guard.

CoffeeScript was an interesting experiment, but I'd say its result is negative.

Re: CoffeeScript for TypeScript

#122

Post by iends »

CoffeeScript solves the wrong problem. You never want to trade long term maintainability for writing code faster and more concisely. Maybe if you’re a solo developer and smarter than me there are benefits, but on a team, CoffeeScript was a detriment.

I spent years writing enterprise scale CoffeeScript with a sizable team and it was pretty rough. We converted to ES5 and now TypeScript (well mostly) and that solved a lot of our problems.

Re: CoffeeScript for TypeScript

#123

Post by jacknews »

chowells wrote: post #77
jacknews wrote: post #18

Earlier quoted context omitted.

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

Wait, what's wrong with making sure indentation and code structure are always the same? Lying indentation structure is always wrong.

It's easy to auto-format according to character syntax, not so easy when the format is the syntax.

Simple copy/paste is enough to break significant-whitespace, let alone space-vs-tabs, etc, etc.

But again, all IMHO, I realise it has it's fans.

Re: CoffeeScript for TypeScript

#124

Post by [deleted] »

Yahivin wrote: post #70
eyelidlessness wrote: post #25

Earlier quoted context omitted.

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). 1: https://github.com/tc39/proposal-do-expressions

We often add promising TC39 proposals into Civet so people can experiment without waiting. We've added https://github.com/tc39/proposal-pipeline-operator , a variant of https://github.com/tc39/proposal-pattern-matching , a variant of https://github.com/tc39/proposal-string-dedent and others. Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anythin…

[deleted]

Re: CoffeeScript for TypeScript

#127

Post by altun »

feeela wrote: post #104

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?

The real joke, I guess, is that hundreds of people are talking about this.

Re: CoffeeScript for TypeScript

#128

Post by selfmodruntime »

nine_k wrote: post #121
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…

All natural languages have a little bit of redundancy. It helps solve ambiguities more easily, especially when solving it in a strictly minimal grammar would require re-parsing the entire text from start. Having both opening and closing parens / brackets / braces is a good example. Redundancy also helps when transmission is imperfect. And you do have imperfect transmission when writing code (typos), and even when rea…

I agree. The Rust foundation (or Mozilla's Rust Team in the early stages) tried out a sigil heavy approach in the beginning, but they ultimately made the decision to steer Rust away from being overloaded with single character keywords of differing significance.

Sadly, with Steve Klabnik's withdrawal from the core Team, the current maintainers are on a path to repeat these mistakes.

Re: CoffeeScript for TypeScript

#129

Post by nequo »

selfmodruntime wrote: post #128
nine_k wrote: post #121

Earlier quoted context omitted.

All natural languages have a little bit of redundancy. It helps solve ambiguities more easily, especially when solving it in a strictly minimal grammar would require re-parsing the entire text from start. Having both opening and closing parens / brackets / braces is a good example. Redundancy also helps when transmission is imperfect. And you do have imperfect transmission when writing code (typos), and even when rea…

I agree. The Rust foundation (or Mozilla's Rust Team in the early stages) tried out a sigil heavy approach in the beginning, but they ultimately made the decision to steer Rust away from being overloaded with single character keywords of differing significance. Sadly, with Steve Klabnik's withdrawal from the core Team, the current maintainers are on a path to repeat these mistakes.

> the current maintainers are on a path to repeat these mistakes

Do you recall specific RFCs that are leaning in this direction?

Re: CoffeeScript for TypeScript

#130

Post by ezekg »

eyelidlessness wrote: post #31
ezekg wrote: post #23

Earlier quoted context omitted.

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

I totally agree, I shouldn't have been so absolute in my statement. But JS is not a lisp. The |> foo bar baz syntax doesn't jive with any other syntax in JS, but foo |> bar |> baz does.
Post reply on HN