4 ms·
A sufficiently good static type system won't make generic operations harder to implement. It can even make them easier to implement in terms of guiding you towa
by wyager 10y ago
A sufficiently good static type system won't make generic operations harder to implement. It can even make them easier to implement in terms of guiding you towards good generalization techniques.
You can also do full Python-style "duck typing" statically. It's called structural typing, with native support from languages like typescript, purescript, etc. It's used a lot in web dev because it works well with Javascript's object model.
- catnaroek 10y agoOCaml-style structural typing cannot handle deciding at runtime what fields an object has. Arguably it's best to know this statically, but dynamic language users make extensive use of the ability to dynamically add fields to an object.
- nine_k 10y ago...which, of course, make it easier to assume the presence of a particular field and crash. Using an explicit map for dynamic attributes at least makes you aware what is guaranteed and what is optional. This removes much of the neat magic that such a dynamic approach affords to languages like Ruby, JavaScript, and, to a lesser extent, Python.
- jon_smark 10y agoIn the case of OCaml, the structural subtyping of object fields can never cause a crash, because it is verified at compile-time.
- duaneb 10y ago> A sufficiently good static type system won't make generic operations harder to implement. This is true for the JVM definition of 'generics', but it doesn't mean that arbitrary operations on a collection of types can be easily expressed with a given (static) type system. Run time type information + a dynamic type can ameliorate some of this, but that's shoehorning optional types into a static type system, and I don't think that's quite what you meant. Think about a generic operation to diff two data structures: you need access to the members of the struct in a generic way. I don't think this is easily solved with static types.
- wyager 10y agoCan you give a specific example where you think you need dynamic types? The diff operation you described sounds like it could be made generic pretty easily, but I may be misunderstanding the goal.
- duaneb 10y ago> Can you give a specific example where you think you need dynamic types? The diff operation you described sounds like it could be made generic pretty easily. How do you figure? This would require macros or runtime type introspection. A specific example might be "serialize this json type without having to annotate the fields with how to serialize them".
- wyager 10y ago> This would require macros or runtime type introspection. Not if you structure your data using an appropriate data structure, like a map. After all, this is all structs in dynamic languages are. > A specific example might be "serialize this json type without having to annotate the fields with how to serialize them". Aeson does this safely and statically using Haskell's powerful static Generics. data Foo = Bar Int String deriving (Generic) instance FromJSON Foo instance ToJSON Foo You can get named fields like data Foo = Bar {baz :: Int, qux :: String}
- duaneb 10y agoMost static typing systems have no parallel to 'deriving', which is to my understanding compile-time computation (aka a macro).
- dllthomas 10y ago"deriving" is compile time; "Generic" is runtime inspection of the shape of a value (in terms of constructor applications). Something (at least vaguely) similar to Generic exists in many statically typed languages - including (IIRC, IIUC) Java and Go.
- Roboprog 10y agoThanks, the OCaml stuff looks interesting (Wikipedia examples for structural types). It feels like type inference meets duck typing, but that's a good thing.