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.<p>When I actually tried to write a project in coffee script, the results were the opposite of what I expected.<p>The code was harder to read, harder to modify, harder to understand, harder to reason about.<p>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.<p>So I fundamentally disagree with the underlying premise of these projects, which seems to be based on PG's concept of "terse is power".<p>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.<p>Type declarations add more to the parse tree, and require you to type more, but they actually give you more power.<p>The same can be said about being explicit in the language constructs.<p>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.<p>Being terse is good, up to a point. Same with being explicit.<p>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.
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.<p>[0] <a href="https://medium.com/hackernoon/the-first-typescript-demo-905ea095a70f" rel="nofollow">https://medium.com/hackernoon/the-first-typescript-demo-905e...</a>
Under "Everything is an Expression":<p><pre><code> items = (() => {
const results = [];
for (const item of items) {
if (item.length) {
results.push(item.toUpperCase());
} else {
results.push("<empty>");
}
}
return results;
})();
</code></pre>
Seems like they are purposely making the JS version extra long. It could be:<p><pre><code> items = items.map(x => x.length > 0 ? x.toUpperCase() : `<empty>`)
</code></pre>
Edit: Just realised the code on the right is the compiled code, not the "equivalent 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".<p>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.<p>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.
"The Modern Way to Write TypeScript."<p>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.<p>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.<p>What problem ist actually solved by being able to compile pseudo-languages like Coffeescript or Typescript into each other?
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.<p>Can this all not be done as experimental typescript though, rather than a new language?
The maintainer - Erik Demaine - seems very talented[0].<p>[0] <a href="https://github.com/edemaine">https://github.com/edemaine</a>
Everything old is new again.<p>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.<p>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.<p>I think Civet would success better if it addressed those issues by making the syntax a bit more familiar and consistent.<p>Keep the python/ruby-like significant indentation and everything-is-expression approach, but add little more verbosity for clarity, for example:<p><pre><code> - require and reserve {} for objects
- require () in function calls
- require explicit var/let/const
</code></pre>
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 <i>terrifying</i> 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.<p>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.
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.<p>I like to think I helped lead people away from CoffeeScript.<p><a href="https://donatstudios.com/CoffeeScript-Madness" rel="nofollow">https://donatstudios.com/CoffeeScript-Madness</a>
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.<p>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?<p><pre><code> data
|> Object.keys
|> console.log
</code></pre>
when you could have done<p><pre><code> |> data
Object.keys
console.log
</code></pre>
Or even better, don't introduce new syntax and just make it a simple function instead<p><pre><code> |>(data,
Object.keys,
console.log))
</code></pre>
Yes yes, I know "|>" is not a legal variable/function name right now, but also, why not?!
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".
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].<p>[1] <a href="https://civet.dev/cheatsheet#variable-declaration" rel="nofollow">https://civet.dev/cheatsheet#variable-declaration</a>
I kinda like it.<p>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