181–190 of 237 posts
Civet reminds me of Coffeescript but now in TypeScript. This has made me even more convinced that the future of JavaScript is JavaScript. We will be seeing JavaScript (natively) having all the types, features and proposals that TypeScript has and the industry will eventually move on from TypeScript.
We need a language that compiles to js with strong typing not another ts!
Earlier quoted context omitted.
I'll pass on the pipe operator, but it's not particularly objectionable. Agree there's some good ideas. Pattern matching looks like a great idea with the wrong syntax - let's just get a match statement similar to the switch statement - if we can't reuse switch. String dedent and chained comparisons look nice. Though I think the latter is a breaking change if it were done in js. I'd also be fine with default const for…
Using the pipe operator in Elixir is very nice, even more so for building up complex multi operations and such
Earlier quoted context omitted.
I should have referenced compiling to Wasm as well, which is what languages with very different semantics to JS (like Rust, the CLR family, and the JVM family) all do.
Working with WASM isn’t really that good for interactive pages with dynamic DOM. If you don’t mind I guess you could just render to a canvas but then you lose a ton of functionality provided by the browser. (Eg: making a responsive page in WASM seems hard) It seems to me for most web applications JS is the only real alternative as of now
It’s completely fine. At present you’ll need to trampoline via JS to make the actual DOM calls, but that’s not typically a performance bottleneck; and such bindings can give you exactly the same API, if you choose.
Yes, work is just about done in browsers for giving you direct access to these things without the JS trampolining, and lots of people are hanging out for that to be dependable, but in practical terms it changes nothing. Nothing. No change in expressiveness; it only gets you probably slightly better performance, and a simpler technique for binding (which is typically immaterial for end users, as libraries were handling that for them).
Additionally having the integration of Microsoft's AOT experiments with Typescript in MakeCode.
Earlier quoted context omitted.
> 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…
> 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…
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.
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 great except for a few fatal mistakes. The biggest was implicit variable declarations, which meant that to write maintainable code, you had to reintroduce explicit declarations via iifes. Otherwise, you’d risk a future code change introducing shadowing which would have consequences that were super painful to debug. The other big one, which unfortunately Civet seems to be doing too, is implicit return…
Hang on, how can you have “everything is an expression” without implicit return? If I’m correctly understanding what you’re talking about, implicit return isn’t actually a thing—it’s just that the function body is an expression too.
(Never dealt with CoffeeScript, but I’ve been writing Rust for over a decade now, and learned to love expression-orientation there.)
I really, really dislike the Elixir/Ruby style of optional parentheses. Explicit is better than implicit! I also absolutely cannot parse this, and while I'm open to the idea that eventually this would become readable, right now this just looks like word salad: value min ceiling max floor
That being said; regular written language (like in a book) has optimal readability. Therefore it makes sense for programming languages to lean towards that. If you could write code like: `draw 600 by 600 graph_of intersection_of data_set1 data_set2 in blue` it would be very easy for basically anybody to tell what the code does. This not only makes it easier for beginners and onboarding, it also reduces cognitive load, even for senior level engineers. In real terms this means less fatigue, less bugs, less time spent reviewing code, higher productivity.
That being said I also prefer the explicitness of parentheses, but I think that's because I'm used to needing that level of explicitness. But maybe there's some paradigm out there that makes it so we don't need that crutch
Earlier quoted context omitted.
C is syntactic sugar on top of assembly
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.