81–90 of 143 posts
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.
This might be a good stepping stone though to sway skeptics.
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
[0] https://medium.com/hackernoon/the-first-typescript-demo-905e...
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 programm…
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
Earlier quoted context omitted.
Given than in JS an empty string is a falsy value you can go even shorter: items = items.map(x => x.toUpperCase() || ` `)
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 ` `). This even more terser code will fail if `x.toUpperCase()` fails with an exception (such as when x is not a string).
items = items.map(x => x?.toUpperCase() || ``)
Earlier quoted context omitted.
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 ` `). 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() || ` `) See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Earlier quoted context omitted.
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…
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.
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 programm…
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 ulti…
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.
"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.