> You can pass a LoggedInUser to a thing expecting a URL in a dynamic language if the LoggedInUser has the same methods as defined in the interface of an URL. It called ducktyping. In the same line of thought, you should even actively avoid checking if LoggedInUser is of the type URL because a different type sharing the same interface as URL should be equally accepted as URL.
You can do that in statically typed languages as well (though not in every). See C++.
Rust actively decided against it, and makes it the users responsibility to say "yes I indeed want to give this type to this function, because it satisfies the trait like this".
Is a type, as defined above, required for all programming? No. Interfaces? Yes. Interfaces are also more similar to customer requirements in that they define behavior. Do the object has an absolute path method. Do it has an UUID property. Can it be used to call open on. Those questions are not type questions, and so I do not think about type when answering them.
Interfaces in TypeScript just describe sets of types, so yes you are still thinking about types (about types of types).
I'd like to know why you think either one is (syntactically) required for programming (as we know ASM doesn't have either of those)
Further, I'd like to know how you don't think about basic types in JS.
Finally, I'd like to know why you couldn't fall back to (mostly) duck typing in statically typed langauges.
> I'd like to know why you think either one is (syntactically) required for programming
Taking the concept of interface, it would be difficult to program something with objects if you did not know the methods, properties, events. Just knowing the type name without any of the knowledge about the interface of the object would make programming close to impossible. The opposite however, knowing the methods and properties but not the type, is enough information to write a program.
In one python program I wrote I created a proxy object for a third-party library. The library only supported a single process, and I needed multiprocessing. The proxy object allowed me to take every call to the object from process B to be pickled and forwarded to process A, with the return value being sent back to B. No function needed to be made aware of the proxy object, the third-party library behaved just as it was a single process program and everything just worked. The proxy object did not need to have any information about the call signatures or method names of the third-party library objects.
It would be interesting to see such proxy object being written in a statically typed language that maintain the type checks when the proxy object get used inside a third-party library. Requirements would be that the proxy object should be independent implemented without being effect by the call signatures and method names in the third-party library. It sounds a bit fun trying to get the compiler to resolve what the type and signature should exist at compile time, through that might just be implementing a dynamic-like language through macros and compiler tricks.
What you'd end up doing is copying and pasting a lot of code. You'd need to define one kind of proxy object for one type in the third-party library, and another kind for another type, and so on. Each would need to implement all the methods, with correct type signatures.
Perhaps you could parse the source code to the third-party library and generate matching proxy objects from that.
No number of compiler tricks would allow you to define a single object that can be a proxy for anything using a statically-typed language.
> You can pass a LoggedInUser to a thing expecting a URL in a dynamic language if the LoggedInUser has the same methods as defined in the interface of an URL. It called ducktyping. In the same line of thought, you should even actively avoid checking if LoggedInUser is of the type URL because a different type sharing the same interface as URL should be equally accepted as URL.
You can do that in statically typed languages as well (though not in every). See C++. Rust actively decided against it, and makes it the users responsibility to say "yes I indeed want to give this type to this function, because it satisfies the trait like this".
Is a type, as defined above, required for all programming? No. Interfaces? Yes. Interfaces are also more similar to customer requirements in that they define behavior. Do the object has an absolute path method. Do it has an UUID property. Can it be used to call open on. Those questions are not type questions, and so I do not think about type when answering them.
Interfaces in TypeScript just describe sets of types, so yes you are still thinking about types (about types of types). I'd like to know why you think either one is (syntactically) required for programming (as we know ASM doesn't have either of those) Further, I'd like to know how you don't think about basic types in JS. Finally, I'd like to know why you couldn't fall back to (mostly) duck typing in statically typed langauges.