4 ms·

> One advantage is that you don't have to adhere to a rigid class structure and be forced to refactor or create a new class every-time you need add a new proper

> One advantage is that you don't have to adhere to a rigid class structure and be forced to refactor or create a new class every-time you need add a new property or method. I wouldn't qualify this as an advantage; it encourages bad code and it precludes a lot of good tooling (including tooling which would automate the sort of refactoring you'd like to avoid).

goatlover 9y ago
Well this sort of argument has been going on for several decades between the dynamic and static proponents.
- weberc2 9y ago
  The gradual typing movement is a concession from the dynamic community that there is indeed value in formalism. BTW, I'm a professional Python developer.
  - BerislavLopac 9y ago
    Just like introduction of generics and interfaces to static languages is a concession that there is value in "informalism" (if that's a word). Basically, there are values in both. There is no silver bullet, these are all different tools in our belt, and some work better in some situations and others in others -- hammers and screwdrivers. One thing I love about Python is that it allows a lot of different tools and methods, allowing you to select what works in a given situation. Many of those tools are far from perfect, but they get the job done in a very satisfying manner, more often than not.
    - weberc2 9y ago
      > Just like introduction of generics and interfaces to static languages is a concession that there is value in "informalism" (if that's a word). You have it exactly backwards. Generics and interfaces are commitments to formalism and the promises of static typing. Before that there was ‘void’, the canonical dynamic type. ‘void’ (or ‘Object’ in Java and other static OOPs) became less common, not more. If there is value in dynamic types, I’ve scarcely seen it, (and I use Python every day). I’m told that dynamic typing really shines through Clojure and other lisps, but I haven’t gotten to that level yet. > One thing I love about Python is that it allows a lot of different tools and methods, allowing you to select what works in a given situation. Many of those tools are far from perfect, but they get the job done in a very satisfying manner, more often than not. This is a nice property when you want to play around with a new paradigm without learning a new syntax and toolchain, but when you’re working on a team, agreeing about the paradigm and features and style quickly becomes tedious.
      - bunderbunder 9y ago
        One spot where I think that dynamic typing shines is dealing with anything from the schema-on-read approach to things, including reading JSON. In Python, for example, you can just parse your JSON or XML into a dict and start grabbing what you need, typically with fairly minimal hassle involved in dealing with things like missing values or some clown sticking a string into a field you thought could only contain ints. In Java, by contrast, ugh. You can laboriously litter your code with a whole mess of bean classes and have Jackson take care of the parsing. But if you want to obey Postel's Law, this quickly turns into a foamy quagmire of beans and annotations and whatnot that's at least an order of magnitude larger than the code that actually interacts with the input, and still throws an exception the moment someone populates the timestamp field with ISO 8601 instead of seconds since 1970/01/01. Or leaves it unpopulated. Or alternatively you can ask for a Map<String, Object>. That approach isn't actually any more strongly typed than what a dynamic language offers, but it does have the advantage of justifying the price of that fancy ergo keyboard. I'm not a big dynamic typing fan overall, but I do think that the .NET folks were on to something when they added the DLR extensions to .NET and gave us ExpandoObjects.
        weberc2 9y ago
        I actually disagree here. I can't speak to Java, but dealing with JSON in Python is actually pretty tedious compared to Go. For example, with Go, if I have a type `Person struct { Name string, Age int}`, I can pass that to `json.Marshal()` (the Go equivalent of `json.dumps()` in Python) and it will render the expected JSON. In Python, we have to marshal everything explicitly (with a `to_dict()` method or equivalent). And Go isn't even a particularly good example of JSON handling in statically typed languages; OCaml, for instance, does a much better job.
      - weberc2 9y ago
        Oh grief. Just noticed the asterisk after ‘void’ became formatting.
      - BerislavLopac 9y ago
        > You have it exactly backwards. Generics and interfaces are commitments to formalism and the promises of static typing. Before that there was ‘void’, the canonical dynamic type. ‘void’ (or ‘Object’ in Java and other static OOPs) became less common, not more. This has nothing to do with dynamic/static typing and everything to do with weak/strong typing.
jack9 9y ago
> it encourages bad code That's a matter of opinion, not a fact. It can be thought of as a shortcut for an applied mixin, without the needless pollution and boilerplate.
- weberc2 9y ago
  It’s a matter of opinion insofar as code quality is subjective and loosely defined, but we do have a general consensus about what code ought to look like, and the discussed features get us farther from that ideal far more often than they get us closer.

goatlover 9y ago

Well this sort of argument has been going on for several decades between the dynamic and static proponents.

weberc2 9y ago
The gradual typing movement is a concession from the dynamic community that there is indeed value in formalism. BTW, I'm a professional Python developer.
- BerislavLopac 9y ago
  Just like introduction of generics and interfaces to static languages is a concession that there is value in "informalism" (if that's a word). Basically, there are values in both. There is no silver bullet, these are all different tools in our belt, and some work better in some situations and others in others -- hammers and screwdrivers. One thing I love about Python is that it allows a lot of different tools and methods, allowing you to select what works in a given situation. Many of those tools are far from perfect, but they get the job done in a very satisfying manner, more often than not.
  - weberc2 9y ago
    > Just like introduction of generics and interfaces to static languages is a concession that there is value in "informalism" (if that's a word). You have it exactly backwards. Generics and interfaces are commitments to formalism and the promises of static typing. Before that there was ‘void’, the canonical dynamic type. ‘void’ (or ‘Object’ in Java and other static OOPs) became less common, not more. If there is value in dynamic types, I’ve scarcely seen it, (and I use Python every day). I’m told that dynamic typing really shines through Clojure and other lisps, but I haven’t gotten to that level yet. > One thing I love about Python is that it allows a lot of different tools and methods, allowing you to select what works in a given situation. Many of those tools are far from perfect, but they get the job done in a very satisfying manner, more often than not. This is a nice property when you want to play around with a new paradigm without learning a new syntax and toolchain, but when you’re working on a team, agreeing about the paradigm and features and style quickly becomes tedious.
    - bunderbunder 9y ago
      One spot where I think that dynamic typing shines is dealing with anything from the schema-on-read approach to things, including reading JSON. In Python, for example, you can just parse your JSON or XML into a dict and start grabbing what you need, typically with fairly minimal hassle involved in dealing with things like missing values or some clown sticking a string into a field you thought could only contain ints. In Java, by contrast, ugh. You can laboriously litter your code with a whole mess of bean classes and have Jackson take care of the parsing. But if you want to obey Postel's Law, this quickly turns into a foamy quagmire of beans and annotations and whatnot that's at least an order of magnitude larger than the code that actually interacts with the input, and still throws an exception the moment someone populates the timestamp field with ISO 8601 instead of seconds since 1970/01/01. Or leaves it unpopulated. Or alternatively you can ask for a Map<String, Object>. That approach isn't actually any more strongly typed than what a dynamic language offers, but it does have the advantage of justifying the price of that fancy ergo keyboard. I'm not a big dynamic typing fan overall, but I do think that the .NET folks were on to something when they added the DLR extensions to .NET and gave us ExpandoObjects.
      - weberc2 9y ago
        I actually disagree here. I can't speak to Java, but dealing with JSON in Python is actually pretty tedious compared to Go. For example, with Go, if I have a type `Person struct { Name string, Age int}`, I can pass that to `json.Marshal()` (the Go equivalent of `json.dumps()` in Python) and it will render the expected JSON. In Python, we have to marshal everything explicitly (with a `to_dict()` method or equivalent). And Go isn't even a particularly good example of JSON handling in statically typed languages; OCaml, for instance, does a much better job.
    - weberc2 9y ago
      Oh grief. Just noticed the asterisk after ‘void’ became formatting.
    - BerislavLopac 9y ago
      > You have it exactly backwards. Generics and interfaces are commitments to formalism and the promises of static typing. Before that there was ‘void’, the canonical dynamic type. ‘void’ (or ‘Object’ in Java and other static OOPs) became less common, not more. This has nothing to do with dynamic/static typing and everything to do with weak/strong typing.

jack9 9y ago

> it encourages bad code That's a matter of opinion, not a fact. It can be thought of as a shortcut for an applied mixin, without the needless pollution and boilerplate.

weberc2 9y ago
It’s a matter of opinion insofar as code quality is subjective and loosely defined, but we do have a general consensus about what code ought to look like, and the discussed features get us farther from that ideal far more often than they get us closer.