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.
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.
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".
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
data Foo = Bar {baz :: Int, qux :: String}But that's what I would do (at least in Java) for this kind of transient transfer object, if left to my own devices.
https://plus.google.com/110981030061712822816/posts/KaSKeg4v...
(I would put myself in the "moderate liberal" camp, even if the languages Steve Yegge lists for that group are not my choice languages)
Sure—but it's in spite of static typing, not because of it. You certainly give up any guarantees of avoiding runtime errors by detecting typing issues at compile time.
https://manosnikolaidis.wordpress.com/2015/08/25/jackson-wit...
That is a property of the library not of the language.
Java generics seem easy enough to instantiate and use, but the mess when you implement one really discourages people from trying, usually. And if you do, the result is often a poster child for FUGLY code. Try declaring a java 8 lambda parameter that works with collections some time, and using that in a few places - serious COBOL-fingers and eye-burn time. Even a Pascal style "type" or C style "typedef" mechanism would have greatly reduced clutter when trying to create code that implements (java) generic operations.
Die, Java, die :-)
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.
It feels like type inference meets duck typing, but that's a good thing.