3 ms·
Pretty interesting topic. I am all for composability. However, I don't necessarily agree with particular benefits of pure data literals. I feel more secure when
by A-Train 6y ago
Pretty interesting topic. I am all for composability. However, I don't necessarily agree with particular benefits of pure data literals. I feel more secure when I wrap even simple types like Strings so that ItemId, UserId is a String but I cannot interchange them.
Similar level of composability with objects and structs can be achieved with generics and traits. I have a code that operates on arrays and matrices however particular implementations depend on the context - it is a DSL embedded into the application. For example I have `lazy matrices` that don't own the matrix or I can have matrices with owned data.
- SatvikBeri 6y agoFor sure. You can think of static types as deliberately preventing composability in cases where you definitely don't want it (e.g. passing in a user_id when dollars are expected), and that's often worth it. The point about matrix types is interesting, because Julia does have a huge host of matrix types, which are primarily used for efficiency via multiple dispatch. Some examples are upper triangular, symmetric, diagonal etc. One cool case is UniformScaling, which is an almost-matrix representing the identity times a constant. It's stored as just that constant, and can be used in 90% of the places a matrix can be used. Implementing these sorts of partial interfaces is one of the tricky parts of static typing, especially when you have multiple partial interfaces for one main interface. You can get around this with typeclasses a la Haskell, but that's a lot of overhead, especially if you have just one example of each partial interface.