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

    if err != nil {
        return err
    }

It’s funny - when we were first designing TypeScript - I often described it as "TypeScript is to CoffeeScript as C#/C++/Java is to Ruby" often adding "and there are 50x more of the former developers than the latter" [0]. And CoffeeScript’s approach of transpiling down to clean JavaScript was a big inspiration for TypeScript. In the 10 years since then, some of the Ruby/CoffeeScript aesthetic has become more mainstream in other programming languages (Swift, Rust), and gradual type systems have become more of an expectation even in dynamic languages like Ruby (Sorbet), Python (mypy) and PHP (Hack). So it does seem very natural to bring these back together now like Civet is doing.

[0] https://medium.com/hackernoon/the-first-typescript-demo-905e...

Under "Everything is an Expression":

        items = (() => {
          const results = [];
          for (const item of items) {
            if (item.length) {
              results.push(item.toUpperCase());
            } else {
              results.push("<empty>");
            }
          }
          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() : `<empty>`)

Edit: Just realised the code on the right is the compiled code, not the "equivalent hand written JS".

     items = items.map(x => x.toUpperCase() || `<empty>`)

It might be me but "expressive syntax" does not automatically translate to any metric of productivity or "fun". Especially not in a job, where we put most of our work time into reading, researching, searching, conception and discussions. Only a fraction of my work time consists of "actually typing in some form of syntax".

I for one appreciate simplicity and would prefer Clojure anytime over Scala. The further comes with barely any syntax, has a couple of quick-to-grep concepts and once you trained your brain to read it and your editor to juggle the parens it is a lot of fun. The latter looks very nice and casual in the beginning but to me feels like a rabbit hole of complex concepts that were always heavier than the domain I was using it for. YMMV.

Tho civet code examples look nice I'm afraid it adds much more complexity than needed, both the concepts you have to keep in your brain's working memory and the whole TS toolchain which is already kind of horrible these days.

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.

    var that = this;
    function() {
      ...
    }

"The Modern Way to Write TypeScript."

I feel like this is exactly the right kind of slogan for a project like this. Smug and opinionated, disregarding anyone who might not feel the same.

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

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?

Hello! I created Civet ask me anything.

Or just curse me for keeping the dream of CoffeeScript alive :P

Very tastefully done. Every one of these items is a huge improvement. This one in particular drives me crazy: `x.map(($) => $.name)`, `x.map .name` is almost Haskell level terseness.

Can this all not be done as experimental typescript though, rather than a new language?

The maintainer - Erik Demaine - seems very talented[0].

[0] https://github.com/edemaine

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.

Just started using Civet and it's really impressive, works well with TypeScript, understands my tsconfig.json, & has a working language server.

I liked CoffeeScript back in the days. However, it had its problems, the biggest being too terse / too much optional syntax.

I think Civet would success better if it addressed those issues by making the syntax a bit more familiar and consistent.

Keep the python/ruby-like significant indentation and everything-is-expression approach, but add little more verbosity for clarity, for example:

  - require and reserve {} for objects
  - require () in function calls
  - require explicit var/let/const

Also, because CoffeeScript got so controversial reputation, I would not ride on its legacy. Just market Civet as "TypeScript with modern syntax".

"Experimental Typescript" is a nice way to look at this. There are some great ideas (opinions?) in there and some terrifying ones (imho). I can literally see the bear traps waiting to take the legs off of our junior/mid devs. But if this sparks TS to up its game I think some of the sharpest edges in Civet might be left safely as opinionated experiments while the best edges make it into the lang. +1 @Yahivin great project.

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.

Finally. I miss coffeescript everyday.

I'm slightly surprised no one has commented on the custom infix operators. I think if I encountered the example in the wild, I'd understand it was a clamp function based purely on the names, but if it were used for anything else I'd have to spend quite a lot of time puzzling over it. Perhaps they make more sense to Haskell people, though!

I wrote this 10 years ago, it's made the rounds. I stand by it even if it's a little long in the tooth. I would word it a little differently these days, but it stands on it's own.

I like to think I helped lead people away from CoffeeScript.

https://donatstudios.com/CoffeeScript-Madness

Given that JavaScript syntax evolution seems to have stalled again (a decade of proposals for bind operator?) I feel like I know why languages like this are appearing, having written quite a bit of swift and kotlin recently, JavaScript really would benefit from shipping bind syntax.

I feel like this would be great as another Emmet style tool for the modern day - write code really quickly and have it convert to production grade typescript following all eslint / prettier rules, and use it as a personal speed up tool for writing instead of reading.

Maybe its being a former haskeller, but the engineer in me absolutely loves this.

The CTO in me is horrified at the idea of writing a whole bunch of civet code for it to die a coffeescript style slow death. If it catches on I'll be all over it though.

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

Oh no it's back :D

Immediately getting ptsd of abandoned coffescript codebases

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.

> If it ever becomes a liability, you just check in the "transformed" code and it's gone.

I've done this and regretted it - CS transpires to ES3 and specifically null chaining is completely unreadable.

From a backend perspective it's no biggie to instead keep the CS dependency and gradually convert files manually when you have to make changes anyway, or when you have 15 minutes to spare between meetings.

You become fluent enough to not even need tests after a while (yikes!).

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.

Because that's not how the pipe operator works in any other language.

    (-> "Hello, World"
        string/uppercase
        (string/split #",")
        first
        string/trim)
        

Implementation looks dead simple for this too:

    $ = (f, x) => f(x)
    flip = f => (x, y) => f(y, x)
    |> = (x, ...fs) => fs.reduce(flip($), x)

However, |> in typescript is quite hard to type (no recursive types). The best approximation you can get is to manually insert

   |> = <A, B1>(x:A, f1:(a:A)=>B1)
   |> = <A, B1, B2>(x:A, f1:(a:A)=>B1, f2:(b1:B1)=>B2)

At that point, a simpler binary function will make more sense

   |> = flip($)

And tsc will interpret the types in the pipe more correctly. Of course, the compiler can allow functions to be called without parentheses to avoid a macro for pipe calls, which will bring our definitions to

     $ = (f, x) => f x
     flip = f => (x, y) => f y x
     |> = (x, f) => (flip $) x f

It might also help to add a simpler function composition function too, as it will greatly help reuse without requiring you to write lambdas

     $ = (f, x) => f x
     flip = f => (x, y) => f y x
     . = (f, g) => x => $ f (g x)
     |> = . flip $

It could also help to remove those pesky parentheses from lambda definitions too, maybe with simpler declarations like `f x y =` converting to `f = (x, y) =>` and enabling automatic currying:

     $ f x = f x
     flip f x y = f y x
     . f g x = $ f (g x)
     |> = . flip $

But, have you noticed that we mostly have binary functions? We could greatly improve readability by making our "modifier" functions (aka combinators or adverbs) into operators. So civet could implement a special syntax for operator definition, and then we would write for definitions like

     ($) f x = f x
     flip f x y = f y x
     (.) f g x = f $ (g x)
     (|>) = flip . $

(Oh wait, does this look like something else?) So we would be able to express `console.log(Object.keys(data))` like

    data
      |> Object.keys
      |> console.log

or equivalently

   (console.log . Object.keys) $ data

without having to special case for pipes! But more importantly, if you enjoy the Clojure method of piping, you can define

    |>> x f ...fs = f ? |>> (f x) ...fs : x

which would give you the syntax you like. And I have a feeling the types will compile just right in a language that looks like this...

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.

Cool idea, we might do that!