CoffeeScript for TypeScript | Hacker News Reader

CoffeeScript for TypeScript

civet.dev

162 pointspaulsb135 comments

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.

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.

The problem is, the entirety of the javascript ecosystem is built for large teams doing multi-year enterprise projects, and so unless you're launching a social media startup or something, you have to wade through a swamp of unnecessary complexity.

Try again with Vite and useReducer and prepare to have your socks blown off.

Even vite is slow. Just use esbuild directly. Jotai is much better for global state management.

Yeah, I like a lot of the language features here, especially:

- Everything is an expression

- Pattern matching

- Spread in any position

- Dedented strings/templates

However, I wouldn't use it, because the chance of it becoming abandonware that I just have to migrate off of later is way too high. I'll write a few extra TypeScript characters here and there for the stability.

Unless civet's compiled output is hard to read you could always just check in the compiled Typescript source and continue from there if it gets abandoned. Not much of a risk when the migration is built in by the way the tool works in normal use.

The compiled output seems pretty clean, but isn’t necessarily what you’d write by hand. e.g. adds things like anonymous functions called immediately, when you’d probably just write a named private function, that sort of thing.

CoffeeScript did end up winning though, all of its important features ended up in the next Javascript spec. It was a bit sad to transition into the slightly less aesthetic next Javascript release, but it also felt triumphant. To me it feels like the CoffeeScript community won. Every time I type some Javascript that's actually not fragile and not absolute garbage, I remember it's because we as a community backed CoffeeScript, and that led to the browsers listening and adding its features to Javascript.

I am certain we're doing the same thing now with Typescript.

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.

Yea but Go's solution to errors is a straight jacket. There's nothing in say Java that prevents returning a Result type with an error or value and writing code that way.

I guess you can panic/recover in go but it's very very unwieldy and not quite the same.

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 crates like `thiserror` for defining error types, and `anyhow` for easily converting them when you don't care about the details.

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.

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

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

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.

I don't know how much you actually tried coffeescript but I find your opinion strange. Coffee wasn't ever like J or anything crazy terse. Its appeal came not merely from making things shorter (it did that, but not by a crazy margin), but from adding a lot of useful things to the language like ? operator, spread operator, destructuring, classes, ranges, better iteration, etc. Almost every coffeescript feature was ultimately added to Javascript (and with very similar syntax) which made coffee somewhat obsolete. Coffee's lack of brackets and semicolons everywhere and @foo instead of this.foo, as well as usage of other features certainly didn't take away any readability or explicitness, if anything - they made it better; the same way those same features make Javascript better and more readable (and, ekhm. "easier to reason about") as long as you _know_ them.

Coffee added really nice and productive language features to what at the time still was a very primitive and simplistic Javascript. It also offered a different syntax to existing and new features.

The first part was great and deserves credit for pushing the language to evolve. The second part made it a terrible dev experience. My experience was identical to the gp: writing it was fast and intuitive, but reading it was much, much worse. Not just reading other people's code, but even my own: my ability to understand my own code degraded not in weeks or months, but mere days. It was so bad, the overall result was a net negative and I quickly stopped using it. I say this as someone who has enjoyed writing code in over a dozen languages, from assembly all the way to Haskell.

I think you're talking about two separate things here,

1) Having to learn an entirely new syntax just to save on a few characters (it "decompresses" directly to the original thing)

2) Explicitness vs implicitness/inference

I wholly agree with you about #1 (superficial brevity isn't a very important goal and doesn't justify a whole new language), but #2 is much more of an "it depends"

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!

\tangent Things stated by implication are harder to understand because of the cognitive load.

But I wonder, if the compiler can get by without it, perhaps we can too? With a different mental model/abstraction, that simply does not need that information - not even by implication. If there is one, probably not easy to come up with.

Like kinematics omitting force (e.g. high school physics, x = x_0 + vt + 1/2at^2). https://wikipedia.org/wiki/Kinematics

We also had same experience with cofeescript. It was a not a nice experience. Later we move with JS because of maintenance issues.

Reading CoffeeScript, and this Civit language, feels like reading prose that doesn't have any punctuation. Slightly quicker to write, much harder to read.

> Being terse is good, up to a point. Same with being explicit.

I'm thinking of using Civet for an upcoming project, I specially want `do` expressions. Even with how much noise an IIFE (`(() => {doStuff(); return ...;})()`) introduces, it's such a natural idea to me that I end up using them very often.

But what makes me question the idea is having to learn a new syntax that is close enough to the JS I already know that I'm going to get confused constantly.

Why would I care about writing `export a, b from "./cool.js"` instead of `export { a, b } from "./cool.js"`? I don't mind those curly braces, I may actually like them a bit; I do very much mind the overhead of remembering these details when I change languages, and there's no way I can remove JS/TS from my life.

Finally, there's expressions like `value min ceiling max floor`. Is that readable at all? You have to actually read each word to know which are operators, which functions, which vars... It seems to me much worse than `max(min(value, ceiling), floor)` or a Lispy alternative like `(max (min value ceiling) floor).

Even the pipeline operator this supports seems easier to read for this particular example: value |> Math.min(&, ceiling) |> Math.max(&, floor)

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.

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?

Yes and no.

A good example would be the behavior of the tilde operator. Another would be the current drafting process of keyword generics.

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

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.

Have you considered https://github.com/squint-cljs/squint ?

Personally I couldn't let go of Clojure's other advantages but at least using the syntax would let you step off the syntax churn bus

No, unfortunately the greener pastures I found have type annotations. I miss the parentheses like hell, and I miss the actual state semantics of Clojure even more. But I wouldn’t give up static types for any of that. If I explore lisps again I’m going to start with Typed Racket.

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

Nice! Wasn't aware of that at all.

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 anything TC39 leaves on the table (rest parameters in any position, etc.)

Given than in JS an empty string is a falsy value you can go even shorter:

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

The original ternary "fixes" the cases where `x` is "wrong" (e.g., is not a string - `x.length` does not fail, but evaluates to false, and thus you still get `<empty>`).

This even more terser code will fail if `x.toUpperCase()` fails with an exception (such as when x is not a string).

Given the example I think it is reasonable to assume it is always an string; otherwise if there is any possibility that x is not a string you can just use optional chaining:

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

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Good point. I often forget that there's option chaining in javascript (now-a-days).

Your version doesn't correspond to the code written on the left side.

You are right, I did not realise it was the compiled code.

I thought it was the comparable hand written JS.

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.

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.

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.

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

Do you like writing this everywhere?

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

Back when there was no async/await and no promises, passing callbacks like this was extremely tedious, and node.js had a lot. CoffeeScript was worth using for the fat arrows alone.

CoffeeScript didn't die. JavaScript (ES3/5) died and we are all using CoffeeScript now!

Oh God, that = this made my heart jump a little. Is this what it's like to feel old? :)

was function() { .. }.bind(this) not around yet?

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

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

Help me come up with a better slogan and I'll use it.

A Modern Way to Write Javascript?

A Great Way to Write TypeScript

A Concise and Powerful Dialect of TypeScript. (my favourite but some might argue that Civet is more than a dialect. I think it's a dialect.)

TypeScript, Streamlined

Write Less, Do More

Expressive Syntax and Faster Coding. (there's already two slogans, and this one is great, plus you don't have to repeat the name of the project in the title section)

Expressive Syntax, Fast Coding. (feels a bit crisper to my ears)

I think there's many ways you can say, "this is an awesome, fast, concise way to write web code that compiles to TS/JS" without suggesting it's _the_ way to write _modern_ TypeScript.

"In my opinion, not to offend, acknowledging diveristy, a modern way he/she/they write typescript"

For what's worth, I think your current slogan is fine.

Civet: If You Like Stubbing Your Toes, You'll Love Our Switch Statements

Switch Statements: if it ain't break, keep going.

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.

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

A distinction between invisible character X and invisible character Y is a terrible idea. But indentation is very much visible; it's generally more significant to the reader than braces are, so it should be that significant to the computer too.

Civets, they're nature's transpilers.

> I'm not sure the connotation is desirable.

You'd think not, and yet ...

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.

Maybe because ToffeeScript is prior art? https://github.com/jiangmiao/toffeescript

Wasn't super popular, but wasn't unknown either.

+1 for FP family tree languages that compile to JS.

This might be a good stepping stone though to sway skeptics.

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.

I used to use CoffeeScript because the syntax was more convenient. I could do the same thing with less code. Less code can mean less maintenance (although some people have said CoffeeScript can overdo this...)

Now I use TypeScript to get the benefit of type-checking. It really helps catch silly little mistakes.

I would use Civet just to be able to use the new pipe operator syntax.

There are even compilers that compile future versions of JS into the current version of JS so future language features can be used in current browsers.

I've heard JS is the new assembly language.

Hello! I created Civet ask me anything.

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

I've got 99 problems but the tersity in TypeScript isn't one of them. Can't wait to groan that a random project we depend on uses this and I have to learn new syntax to make a 1 line change.

Whenever I saw coffeescript I just felt like the developers fancied a change for change sake and doesn't have real problems to solve.

It's clever though to create a new syntax, I'll give you that

I like the documentation that TypeScript types provide but I'm always running into lots of small quality of life issues that wear me down.

- Rest in any position

- Dedented block strings

- Default to const in for loops

- Lack of -> function shortand

- Everything is an expression

- Implicit returns

- Chained comparisons

- Nested unbraced object literals

- Optional trailing commas in arrays

- Optional trailing commas in objects

- x.map .name function shorthand

Each one is a fairly minor concern but they all add up. I'm sure different people will have a different list of favorite features as well. One of my goals in creating Civet was to fix my top 100 issues with TS syntax while being 99% backward compatible. The ultimate goal being: TS with my top 100 issues fixed will be the best language I have ever used.

Hey Yahivin! I love the idea and would love to use it and spread it. I think the best way to jumpstart that is a VS Code extension that allows Civet to be used as an Emmet style tool for the modern developer - write code really quickly and have it convert to production grade typescript following all your eslint / prettier rules, and use it as a personal speed up tool for just writing. When your coworkers start asking how you're moving so fast you tell them about Civet!

Thanks! Sounds like a good idea and a nice way to make it easier for people to get started playing around with Civet.

Sorry, a slightly offtopic question: who drew the mascot? :)

DALL-E 2

I guess an animal that poops out coffee is strangely fitting for this project.

Super nicely done! Thank you so much for contributing with this.

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?

Civet aims to be 99% compatible with existing TypeScript so it could be considered an experimental TypeScript. With any luck Civet catches on and does to TS what CoffeeScript did to ES and all the best features trickle into the standard eventually.

The difficult part for TS/JS is they can't easily opt into some of the more whitespace/context sensitive features without breaking changes to existing code or forcing people to opt in with a "jsNext" directive or something.

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

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

I recognized his face from MIT 6.006 Introduction to Algorithms course [1]

[1] https://www.youtube.com/playlist?list=PLUl4u3cNGP61Oq3tWYp6V...

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.

That's awesome to hear! There's still a lot of improvements we want to add to the LSP so it's only going to get better from here.

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.

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.

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

Good news! Civet fixes several of the more contentious design decisions from CoffeeScript by trying to be more in line with ES semantics. You need to declare variables by default in Civet. You can opt in to CoffeeScript's automatic var if you need to migrate from a CoffeeScript codebase by using the "civet autoVar" directive.

More info: https://civet.dev/cheatsheet#variable-declaration

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

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.

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.

As someone else, it does in Clojure (which is what I wrote most of the time). But even if it didnt, does it matter? If there is a better way, the way is better, no matter if it exists in other languages or not.

If all languages tried to be the same, most of them would be boring.

Cool idea, we might do that!

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.

Oh no it's back :D

Immediately getting ptsd of abandoned coffescript codebases

If you take "Modern" in the same vein as "Modern Art", then yes, I guess you could say it's "The Modern Way to write Typescript".

Maybe even postmodern :)

Oooh, that should be the motto!

If you don't want to make the same mistake as me: don't ever choose to use a language whose syntax doesn't distinguish between variable assignment and variable declaration. Yes this includes coffeescript. This seems optional in civet [1].

[1] https://civet.dev/cheatsheet#variable-declaration

We trust people to make their own mistakes :)

The greatest thing about this thread is that I realize I'm not alone in my nostalgia for coffeescript.

There are dozens of us! :)

Ah **, here we go again

I kinda like it.

I wouldn't use it in a team project subjecting my teammates to learn "yet another thing" but can see myself using this for personal projects

If you like that, there's coconut, based on python. Similar syntactic feel and ideas. Types aside.

Hard pass on the switch statement.

please just use rescript it addresses every problem with js/ts and is simpler and you get a sound type system please.

The compilation speed of ReScript is also great

I took a look at rescript's facillities for migration from JS and at step 1 (https://rescript-lang.org/docs/manual/latest/converting-from...), it tells you:

> First, copy the entire file content over to a new file called src/Main.res by using our %%raw JS embedding trick: > %%raw(`const school = require('school'); etc. `)

I stopped reading there - I'm sorry but that is horrifying. Wrapping JS in in a big backtick string?! No. That's even worse that Dart-JS interop.

That is not how you normally do interop in Rescript.

Reply on news.ycombinator.com