Programming TypeScript has a section on “Simulating Nominal Types” [1]. You define a type that’s impossible to create naturally, and provide a function that asserts something is of that type.
type CompanyID = string & {readonly brand: unique symbol}
type OrderID = string & {readonly brand: unique symbol}
type UserID = string & {readonly brand: unique symbol}
type ID = CompanyID | OrderID | UserID
function CompanyID(id: string) {
return id as CompanyID
}
...
TypeScript can be very confusing sometimes, and given the learning curve I’d caution someone trying to learn modern JS away from starting out with it. But in even small codebases it’s an amazing improvement in safety, especially for refactoring.
That's not good. A type system should be crystal clear, predictable and reliable.
> and given the learning curve
Types should not be a complex thing with a steep learning curve. If you know Assembler and C it's pretty clear what types are about. Added complexity to your codebase is what you should try to avoid at all times. We have a limited capacity of things we can think of at a time, developers should therefore focus on things that really matter. In my daily work I see highly complex piles of spaghetti in TS that are 'type safe' and easy to refactor..
I don't follow how knowing C and Assembler makes types clear and I'd love it if you could clarify.
Nominal types are really a compile time only thing: if you have two structs (or classes) with the exact same fields, I'd expect them to be stored the same way in memory. And as a result I'd expect any function to work on them just fine, as long as they find semantically valid data at the right offsets.
> That's not good. A type system should be crystal clear, predictable and reliable.
The purpose of TypeScript is to provide static types to JavaScript without just turning it into a compile target. TypeScript type system is only confusing because it's modeling real-life ultimately type-less JavaScript code. It's not it's own language with it's own rules -- it lives and dies as JavaScript.
> Types should not be a complex thing with a steep learning curve.
Types can be as simple or complex as needed. Assembler and C have very simple type systems with very few features and can only model very simple situations. Types in TS don't have to be complicated -- blame JavaScript programmers for their crazy designs.
At runtime, TypeScript is JavaScript, so depending on your perspective either encapsulation is impossible (because you don't have types to defend you) or easy (because you use the patterns that JS has to defend encapsulation at runtime, without types).
You can use private to do it OO/Java style, but you don't need typescript for that: ES6 modules let you encapsulate stuff just fine without any type features.
At compile time? It's very simple–use an interface and provide constructor functions that upcast object instances to the interface. Now, only the interface-defined members i.e. the public members are accessible.
At runtime? You can't, it's JavaScript, everything is public (for now at least).
I miswrote. Rotation calculations are represented (in quaternions and in geometric algebra calculations) as a 3D subspace of R^4, with the "extra" dimension accounted for by constraining quaternions to the unit hypersphere.
Rotations do involve magnitudes when interpreted as an axis (2 dimensional manifold embedded in R^3) and a magnitide (0 to 2pi)
The space of rotors and rotation quaternions are both three dimensional because the coordinates are restricted to unit magnitude.
Quaternions and rotors are exactly the same in practice, but the intuitions are very different. The intuition behind rotors involves planes and lines in 3D, whereas the intuition behind quaternions typically involves a unit hypersphere; there's a 3B1B video on quaternions where you can learn more about them.
You're right that the space of rotations is 3-dimensional. When I said 4, I meant without restricting to the unit hypersphere. This causes no problem for rotations because replacing q by a multiple tq leaves the formula x --> qxq^(-1) unchanged --although of course q^(-1) invloves dividing by the square of the norm so it's nice if the norm is 1.
Note that even if you do restrict q to have unit norm, q and -q still denote the same rotation! (In other words, the space of rotations isn't really S^3, but projective space RP^3.)
I'll be sure to check out the 3B1B video, I keep seeing them recommended and I think they might a good resource to recommend to my students.
Yep, Stack has an atrocious UX that does nothing but cause progressively increasing amounts of pain. I wish someone would just write the Cargo or NPM of Haskell already.
> Rust and go eventually will be facing same issues
Isn't Rust's workaround their "edition" system? It seems to be working pretty well for them, but it sounds like it could end up being a massive maintenance headache.
The age, gender, etc. distributions of the people who visit your website. I don't know anything about GA, but I'm guessing they'd know this from the currently signed in Google account.
That line is extremely simple to me. What makes it seem like a "mix-match" of symbols to you?
The equivalent in Haskell would be "compose :: (a -> a) -> (a -> a) -> a -> a", which lacks "impl" because it boxes all closures (each closure in Rust has its own type), and lacks "Fn" because it doesn't care about what kind of access the closure needs to its context (Rust distinguishes between Fn, FnMut and FnOnce). Still, the Rust is only a tiny bit more complicated than the Haskell.
