JavaScript already has the best use of C syntax I’ve seen. Destructuring, JSON, functions. It’s so easy.
Civet: A Superset of TypeScript
21–30 of 237 posts
Re: Civet: A Superset of TypeScript
#22This just looks like it's trying to remove as much syntax as possible and as a consequence makes it harder for me to follow what's going on. Kind of like a write-only language.
Re: Civet: A Superset of TypeScript
#23Civet. Kopi luwak coffee. It's CoffeeScript. I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though.…
I think everyone mostly agrees that CoffeeScript was a dead end, but I think it drove at lot of innovation at the time. Hopefully Civet can do the same, even if it ends up being another dead end.
CoffeScript was really good at driving innovation in JavaScript. The arrow operator, string literals, and for...in/for...of seemed to be driven specifically from CoffeeScript's innovations.
Re: Civet: A Superset of TypeScript
#24Civet. Kopi luwak coffee. It's CoffeeScript. I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though.…
Considering it's not just a grab-bag of TC39 proposals (e.g. removing braces), I suspect rejected TC39 proposals will just... linger.
I agree a research language feels potentially useful — and in fact that's what CoffeeScript's real legacy is (arrow functions, splats, destructuring assignments, and ES6 classes among others are direct ports of CoffeeScript syntax features, and many of the original JS class proposals that CoffeeScript-style classes replaced were quite bad) — but I'd be similarly leery of using this to ship much.
Re: Civet: A Superset of TypeScript
#25Am I the only one that really dislikes the syntax choices here?
Having worked in Rust I love the pattern matching proposal. Having dabbled in Swift I like the single argument function part (though keep the brackets, please) Much of the rest I could take or leave… but then is that just because I’m not familiar with them? Stuff like the pipe operator makes sense to me but it reminds me of .reduce(): there are a few legitimate uses of it but the vast majority will be entirely-too-sm…
I fell in love with pattern matching the first time I used Haskell. Having the feature is great, but I really don't like the syntax used here.
Re: Civet: A Superset of TypeScript
#26Civet. Kopi luwak coffee. It's CoffeeScript. I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight, and a language dead end. The language was only syntactic sugar, and by not bringing anything else to the table, was unconvincing for ports and support in other ecosystems. It now seems that most codebases have been decaffeinated though.…
> I wrote a bunch of CoffeeScript back in the day, and everyone I've spoken to about it feels the same, that it was a bad idea in hindsight
I don't think it was a bad idea in hindsight.
JS of the era was a pain to use; CoffeeScript made writing and reading things much easier, which is the reason it took off. Since then things changed and many "CoffeeScript features" are now "JavaScript features". Only with knowledge of that future would it be a "bad idea", but it was absolutely not clear that was going to happen back in 2010 and in alternative universes we're all writing CoffeeScript today.
I also think CoffeeScript was probably helpful in getting some of these features adopted in the first place.
The same applies to TypeScript – maybe typing will be added to JavaScript, and TypeScript will become redundant – I think there was some proposal and who knows what will happen. In 15 years we can say the same about TypeScript, but that doesn't mean TypeScript wasn't useful today, with the current state of JavaScript and uncertainty what the future may or may not bring.
Re: Civet: A Superset of TypeScript
#27Just dont….
Re: Civet: A Superset of TypeScript
#28This just looks like it's trying to remove as much syntax as possible and as a consequence makes it harder for me to follow what's going on. Kind of like a write-only language.
I do not particularly like the lack of brackets everywhere. I think it is hard to know precedence perfectly and brackets ensure you do not make stupid mistakes.
Also there is the classic issue where you take an if statement that has a line one expression and you add a second line, but now because it didn't have brackets (and you are not using indentation style), you just introduced a bug. Or you have an if statement with an expression and you comment out the expression but not the if, then your next statement is now the if conditional expression, which is not obvious.
Re: Civet: A Superset of TypeScript
#29The pattern matching (TC39 stage 1) and pipeline operators (TC39 stage 2) look great, and I'd love to have those in TypeScript. It will probably take a loooong while for those features to be available in JavaScript, but I feel like I can live without those for now :-).
Fwiw it seems a lot of people really like the concept of "significant indentation". I'm thinking Python, YAML, Godot's GDScript. Not a lof of languages implement it but those that do seem to get a lot of users.
Interestingly, it seems like Erik Demain [1] is one of the contributors [2] of this project.
--
1: https://github.com/DanielXMoore/Civet/graphs/contributors
Re: Civet: A Superset of TypeScript
#30Pattern matching: yes, it's needed and maybe the only useful feature in here.
The syntax and some other features, no. Some are even anti-features or "magic" that takes the actual semantics away from the developer.