Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Civet: A Superset of TypeScript

civet.dev

Post reply on HN
Print view View original

191–200 of 237 posts

Re: Civet: A Superset of TypeScript

#191

Post by p2edwards »

edemaine wrote: post #66
smilekzs wrote: post #32

I know this hasn't been updated, and I know it's a fork of CoffeeScript, but https://livescript.net/ has had a lot of the "magic" syntax here for quite a while.

Yes, Civet has taken a lot of syntactic inspiration from LiveScript. At this point, I think we have most of the good features, but we might be missing some. Let us know what you think! The big difference, of course, is that Civet fully supports TypeScript, and is up-to-date with the latest JavaScript and TypeScript features.

I do miss 2 features from LiveScript:

1. `wxyz = [ 2 8 -5 5 ]` (commas optional for non callables)

2. `console.log \hello` (backslash strings)

Don't know how hard/compatible #1 is, but for #2 I had a tested PR that I could bring around.

(#3 was bulleted lists, but you already added that!)

Re: Civet: A Superset of TypeScript

#192

Post by legacynl »

c0balt wrote: post #5

That looks interesting but imo the syntax is too terse. Coming from Rust and Golang I very much appreciate the use of sigils and syntax sugar in moderation but especially the pipe operators look like they could lead to hard to debug code very easily.

The pipe operator just flips the order of execution. In my experience this doesn't really impact debugging at all.

without the pipe operator you would write ` fun1(fun2(fun3(fun4(fun5(x, y), z, w), u), v)) `

The order of operations in this line is actually from right to left. Also it's not immediately obvious to which function the u parameter belongs to.

With the pipe operate you would write it in the order that the functions are actually called and you have the arguments in the same location as the function they belong to. So this would be written something like

` fun5(x, y) |> fun4(z, w) |> fun3(u) |> fun2(v) |> fun1() `

Re: Civet: A Superset of TypeScript

#193

Post by no_wizard »

vivzkestrel wrote: post #86

Its not about how concise or short your code looks, its how about much time the new intern coming tomorrow needs to understand those 1000 line files. I find the syntax very hard to remember and confusing

I sure hope they see it and realize it is most likely in desperate need of refactor

Re: Civet: A Superset of TypeScript

#194

Post by jmull »

legacynl wrote: post #190
jmull wrote: post #154

Earlier quoted context omitted.

That’s part of what C does, but it’s not the only thing. Assembly adds mnemonics and a logical structure to machine code. C largely does the same, but adds a cross-platform abstraction, mechanisms for organizing and sharing source code, a standard library, and various other things.

Syntactic sugar is such a broad and vague term that those features you mentioned could also technically be considered syntactic sugar. Instead of having to write harder longer code you can write easier and less code.

I think we can understand syntactic sugar as an alternative (hopefully more convenient, elegant, or pleasing) syntax for expressing something that can already be expressed.

That is, something that works the same but looks better (hopefully).

A cross-CPU abstraction, a preprocessor, a standard library all have certain elements of syntax in them, but go well beyond alternative syntax.

Re: Civet: A Superset of TypeScript

#195

Post by shermantanktop »

donatj wrote: post #187
danpalmer wrote: post #43

Earlier quoted context omitted.

> CoffeeScript made writing and reading things much easier My point is that it kinda didn't. It looked prettier on the surface, but didn't actually solve any of the deeper problems of writing JavaScript. To write CoffeeScript you had to still know JavaScript and all its oddities. TypeScript solved those problems, and that's why it has taken off and had a meteoric rise to the point that it's practically synonymous wit…

My biggest gripe with CoffeeScript, beyond it's scoping being madness [1], is it made writing very inefficient JavaScript much easier. The language was full of footguns. Many times something would look perfectly reasonable in CoffeeScript but when you would actually read the JS it would be iterating the same dataset multiple times to grab individual items that could have and should have been a single loop. 1. https:/…

It's the Hibernate problem all over again. Any time one language is layered on another, the user is totally unaware of the degenerate cases that they are triggering, and the higher language is usually blocked from fixing those. Similar to C++ preprocessors which generated poor C.

Re: Civet: A Superset of TypeScript

#197

Post by root_axis »

danpalmer wrote: post #6

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

CoffeeScript was amazing. It was only a dead-end because flow and subsequently typescript made an offer the ecosystem couldn't refuse. Unfortunately, I doubt that Civet will have much future momentum because even though typescript is the state of the art for front-end dev, it's a much less stable foundation to build on top of than ES was for CoffeeScript.

Re: Civet: A Superset of TypeScript

#199

Post by hosh »

sciolistse wrote: post #175
brianshaler wrote: post #172

Earlier quoted context omitted.

> And then it ruined us with implicit returns What was so ruinous about implicit returns? That's one of the things I missed most when leaving CoffeeScript. ECMAScript only partially adopted it (single statement fat arrow functions) which probably muddies the waters for people trying to learn and understand the language's behavior. Since it's optional for the caller to use or assign the return value of a function, I d…

probably gets better with use but having to remember not to put a loop as the last statement of a function, because it would make it return an array of the last statement of the loop body, caught me off guard enough times to get annoying. easy enough to add an extra line with just 'undefined' as the last statement of the function of course. but then you do need to remember that.

I came from Ruby and Elixir. It is always implicit returns. When I started writing TypeScript, having to have explicit returns was my number 1 bug.

People can adapt either way. You can write more concise code with implicit returns and "everything is an expression".

Re: Civet: A Superset of TypeScript

#200

Post by hosh »

jakub_g wrote: post #168
dgoldstein0 wrote: post #49

Earlier quoted context omitted.

Coffeescript had some great features: classes, array comprehensions, default parameter values, arrow functions, optional chaining. Many of these eventually made it to ecmascript. And then it ruined us with implicit returns, optional parentheses and brackets, and the isnt vs is not fiasco. I worked a lot with Python and coffeescript at the same time back in the day. In Python you mess up your whitespace and 95% of the…

> implicit returns Oh man, that brings memories. When I joined a coffee-shop (pun intended), and learnt about implicit returns, I was screaming internally until we got rid of all the coffee (which was massive long team-wide migration effort that took like 2y to finish). Once the migration was finished, everyone was so tired, that at the mere proposal of using TypeScript instead of JS the whole team would just roll th…

In Ruby and Elixir, it is implicit returns. That's always been like that, and people working with those languages don't have a problem with it. When I started writing Typescript, I was screaming internally at the explicit returns.

So I think this has more to do with how people are used to thinking with the languages they are fluent in.

Post reply on HN