3 ms·

I must respectfully disagree. I work with web-based systems and find the dynamic typing of Python to be its biggest strength. The ability to just throw another

by scott_w 15y ago

I must respectfully disagree. I work with web-based systems and find the dynamic typing of Python to be its biggest strength. The ability to just throw another property onto an object before sending it to the template-engine saves so much engineering work, it totally overcomes the downsides of not annotating required types. I can see where it may be an issue, but I think the documentation should focus on what function calls need to be supported, as opposed to type-checking i.e. "This function takes an object with the read() and update() methods."

softbuilder 15y ago
"I must respectfully disagree. I work with web-based systems" Web-based systems tend toward smallness and/or flatness, with fairly straight execution paths through the system. You're not going to run into the limitations being discussed.
- njharman 15y ago
  Yeah and big systems architects should really learn from that. A bunch of small services connected by well defined interfaces is the flipping bomb!
  - softbuilder 15y ago
    When possible, I totally agree. It's great when you can get it. Most of the work I do is just like what you describe. Sometimes it's not, and that's when I really feel the utility of types.
skymt 15y ago
That's essentially how Go handles polymorphism. http://golang.org/doc/go_spec.html#Interface_types http://golang.org/doc/go_spec.html#Interface_types
pranjalv123 15y ago
I think the proper way to do this is through the use of interfaces (Java), abstract superclasses (C++), or typeclasses (Haskell, etc.). These give you the benefits of polymorphism, e.g. you can pass anything that implements "read" to a function that processes input in a given way, but also gives you the compile time typechecking that helps you avoid bugs.
- scott_w 15y ago
  Using interfaces is nice, in theory, but I find them cumbersome in practice. Say you have a function that takes a IAmReadable object, with the method read(). You implement it, and all is well with the world. Then, you encounter a function that also uses read(), but requires an IAmAlsoReadable object. Again, this function only uses read(), but IAmAlsoReadable requires you to implement random(), silliness() and 4 other methods that you'll never use. Java's interfaces require you to implement all of those methods, even if it's just to stub them out (or return 0, 0f, or null). Blame poorly designed interfaces, but ultimately we have to live with them. And yes, you can get your IDE to generate them, but that's just working round the basic problem which is that the type system sucks. Personally, I think the answer, if you're using a static language, is to analyse the code to see what methods are actually required. This would reduce the interface system to merely providing "hints", but would keep you from cluttering up your code with meaningless method definitions. That's my two cents on the matter, at least. I'm sure someone more qualified will point out a glaring hole in my logic :-)

by scott_w 15y ago

softbuilder 15y ago

"I must respectfully disagree. I work with web-based systems" Web-based systems tend toward smallness and/or flatness, with fairly straight execution paths through the system. You're not going to run into the limitations being discussed.

njharman 15y ago
Yeah and big systems architects should really learn from that. A bunch of small services connected by well defined interfaces is the flipping bomb!
- softbuilder 15y ago
  When possible, I totally agree. It's great when you can get it. Most of the work I do is just like what you describe. Sometimes it's not, and that's when I really feel the utility of types.

skymt 15y ago

That's essentially how Go handles polymorphism. http://golang.org/doc/go_spec.html#Interface_types http://golang.org/doc/go_spec.html#Interface_types

pranjalv123 15y ago

I think the proper way to do this is through the use of interfaces (Java), abstract superclasses (C++), or typeclasses (Haskell, etc.). These give you the benefits of polymorphism, e.g. you can pass anything that implements "read" to a function that processes input in a given way, but also gives you the compile time typechecking that helps you avoid bugs.

scott_w 15y ago
Using interfaces is nice, in theory, but I find them cumbersome in practice. Say you have a function that takes a IAmReadable object, with the method read(). You implement it, and all is well with the world. Then, you encounter a function that also uses read(), but requires an IAmAlsoReadable object. Again, this function only uses read(), but IAmAlsoReadable requires you to implement random(), silliness() and 4 other methods that you'll never use. Java's interfaces require you to implement all of those methods, even if it's just to stub them out (or return 0, 0f, or null). Blame poorly designed interfaces, but ultimately we have to live with them. And yes, you can get your IDE to generate them, but that's just working round the basic problem which is that the type system sucks. Personally, I think the answer, if you're using a static language, is to analyse the code to see what methods are actually required. This would reduce the interface system to merely providing "hints", but would keep you from cluttering up your code with meaningless method definitions. That's my two cents on the matter, at least. I'm sure someone more qualified will point out a glaring hole in my logic :-)