171–180 of 217 posts
This article shows the kind of overthinking that I hate when it comes to typescript usage. This is also the reason why I'm falling in love with Go. Don't get me started on how this is so unnecessary on the browser (so the utility on this kind of stuff is actually for library development; maybe). Am I the only one that thinks that Typescript waste your time on minutia like this?
the cool thing about Typescript is that you never have to know any of this to deliver highly performant enterprise scale software
For example, a naive engineer might think, ah, databases have this oFFSET clause, good, I'll use, unaware that is a foot gun for real world performance.
Or they may think the DELETE operation on DBs is a normal thing, unaware that in most cases it should NOT be used at all.
Or they might think loops are idiomatic, unaware that when you are writing large software you should and can probably almost eliminate loops (unless you are using a DSL like SQL extensions, config languages, etc)
Or they may be unaware of the thorny issues around queues (or even why they might be necessary in the first place) and concurrent access to data.
Or they might not understand why the dogma of separating content and presentation is nonsensical in many situations.
Etc.
Earlier quoted context omitted.
The fact that there can be runtime type errors that were proven impossible at compile time is why I will never enjoy TypeScript.
If Typescript is javascript with types bolted on, Rescript is javascript with types the way it should have been. Sound types with low complexity. https://rescript-lang.org/
Earlier quoted context omitted.
No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.
> No tool is perfect. What matters is if a tool is useful Some tools are more perfect and more useful than others. Typescript's type system is very powerful, but without strict compile-time enforcement you still spend a lot of effort on validating runtime weirdness (that the compiler ought to be able to enforce).
That's something that you own and control, though. Just because TypeScript allows developers to gently onboard static type checking by disabling or watering down checks, that does not mean TypeScipt is the reason you spend time validating your own bugs.
Earlier quoted context omitted.
Not really, I provided these examples a couple weeks ago on another HN thread. TypeScript is simply unsound. https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAllApg... https://www.typescriptlang.org/play/?#code/DYUwLgBAHgXBB2BXA...
Aren't these bugs that could be "simply" reported and fixed? Or maybe those would get a label "not a bug" attached by the TS creators for some reason?
TypeScript designers insist they're ok with it being unsound even on the strictest settings. Which I'd be ok with if the remaining type errors were detected at runtime, but they also insist they don't want the type system to add any runtime semantics.
Earlier quoted context omitted.
Pushing everything to types like this creates a different burden where you're casting between types all over the place just to use the same underlying data. You could just clamp velocity to 200 in the callee and save all that hassle.
Casting? Not really - i think you’d only need a couple type checks. Imo this is mostly useful for situations where you want to handle input validation (and errors) in the UI code and this function lives far away from ui code. Your point about clamping makes sense, and it’s probably worth doing that anyway, but without it being encoded in the type you have to communicate how the function is intended to be used some ot…
> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…
> ask someone to write a signature for array flat Out of curiosity - what do you think is a satisfactory answer here? My answer would vary wildly based upon more details, but at the most basic all I can think you could guarantee is Array => Array ?
IRL I'd be happy with someone at least searching for a definition and trying to learn from it.
I've asked this question multiple times as implementing array flatten used to be our go to ice breaker question, and many devs had no issues reasoning and finding an okay type definition.
Earlier quoted context omitted.
I couldn't care less about mathematics, but I do care about making impossible state impossible and types documenting the domain. If you type some state as: isLoading: boolean result: Foo hasError: boolean errorMessage: string | null then you're creating a giant mess of a soup where the state of your program could have a result, be loading and an error at the same time. If you could recognise that the state of your pr…
You can encode that "correctly" in pure JS class LoadingState extends State {} class ResultState extends State {} class ErrorState extends State {} const state: State = new LoadingState Generally it's a bad pattern to have dependant fields like your example, but you don't need TS to solve it.
But you can't reason on the different cases aided by the type checker.
Also, using classes or POJOs is merely an implementation detail.
Earlier quoted context omitted.
I couldn't care less about mathematics, but I do care about making impossible state impossible and types documenting the domain. If you type some state as: isLoading: boolean result: Foo hasError: boolean errorMessage: string | null then you're creating a giant mess of a soup where the state of your program could have a result, be loading and an error at the same time. If you could recognise that the state of your pr…
>encoding that a number is between 2 and 200 What’s the point of this level of autism when you still have to add run time checks?
> TypeScript is a wonderfully advanced language though it has an unfortunately steep learning curve An extremely steep one. The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. Too many really stop at…
> Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail. To be clear, an array flat type: type FlatArr = Arg extends [infer First, ...(infer Rest)] ? First extends unknown[] ? [...First, ...FlatArr ] : [First, ...FlatArr ] : []; is far from basic Typescript. The average Typescript dev likely doesn't need to understand recursive conditional types. It's a level of typescript one…
function flat() { // type FlatArr =
let [first, ...rest] = this;
return (this.length > 0) ? // Arg extends [infer First, ...(infer Rest)] ?
Array.isArray(first) ? // First extends unknown[] ?
[...first, ...flat(rest)] : // [...First, ...FlatArr] :
[first, ...flat(rest)] : // [First, ...FlatArr] :
[]; // [];
}
function flat() {
if (this.length > 0) {
let [first, ...rest] = this;
if (Array.isArray(first)) {
return [...first, ...flat(rest)];
} else {
return [first, ...flat(rest)];
}
} else {
return [];
}
}
Now in reality, Array.prototype.flat has a more complex definition, partly because (like most of Array’s methods) the method is generic (it works on array-like objects that have a length property and numeric indexing), and partly because of the depth parameter. From lib.es2019.array.d.ts:
type FlatArray = {
done: Arr;
recur: Arr extends ReadonlyArray ? FlatArray
: Arr;
}[Depth extends -1 ? "done" : "recur"];
interface ReadonlyArray {
// [Snipped: flatMap, and flat’s doc comment]
flat(
this: A,
depth?: D,
): FlatArray[];
}
// [And repeated for interface Array.]