3 ms·

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As fo

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmallow.readthedocs.io/en/latest/ https://marshmallow.readthedocs.io/en/latest/ It will validate everything, including nested recursive data with cross references in fields and a need for sanitation and casting. But you don't need a lot of code to do so. Static languages are good to enforce safe practices at scale . That's why they are popular in big IT structures. Dynamic languages are fantastic when you have a lot of external data manipulations. Hence their popularity for the Web, banking, biology, geography, etc.

fnord123 9y ago
> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. >>> (1,2) > {1: 2} True >And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust: https://serde.rs/ https://serde.rs/ This validates at compile time.
- nooorofe 9y ago
  In [60]: (1,2) > {1: 2} --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-60-f9d83a4c8f73> in <module>() ----> 1 (1,2) > {1: 2} TypeError: '>' not supported between instances of 'tuple' and 'dict'
- nicwolff 9y ago
  He means Python 3.
- sametmax 9y ago
  I said "modern". Python 2 is not modern. Python 3 is. And the keyword in my schema validation sentence is "easy". I love rust, but a low level language cannot be compared in productivity to a high level language for this stuff. They are much, much easier. That's the whole purpose. You trade easiness for rigor.
seanwilson 9y ago
> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. You mean a dynamic check? It's better than nothing but I don't exactly want my e.g. scheduled data import process crashing because it was sent some bad data. I'd much rather have static checking and have all the possibilities accounted for before the code runs. > As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Why couldn't you write this with static checks? Statically checked functional languages for example are great for writing compilers.
- sametmax 9y ago
  keyword being "easy"
  - seanwilson 9y ago
    I just don't find that personally. Having to run the code over and over again to manually check for errors or having to write unit tests to gain confidence it's working is more difficult to me than getting help from static type checking. I mean why do you think it's always going to be more difficult with static types? Because you have to write type annotations?
    - sametmax 9y ago
      External data are never perfectly documented or known. You usually have huge and painful experimentation phase with parsing it. Experimenting is way easier with dynamic languages. You type less. Changing your mind has a lower cost. You don't need to think about doing the right things as much.
      - seanwilson 9y ago
        So in a statically typed language, if all I know is that I'm getting a string as input, it'll force me to deal with all the possibilities. Is it a number in the form of a string? A null value? A string that isn't a number? The type system will guide me through handling all the possibilities and enforce that I handle all of them. With dynamic typing, there's always a chance you've missed a case and next time the data comes in it'll trigger an exception. If you have decent type inference there isn't extra typing and any time you think you're saving with dynamic languages gets eaten up having to manually fix things when errors happen at runtime. I'd much rather spend time fixing predictable compile time errors than unpredictable runtime errors.

fnord123 9y ago

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. >>> (1,2) > {1: 2} True >And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust: https://serde.rs/ https://serde.rs/ This validates at compile time.

nooorofe 9y ago
In [60]: (1,2) > {1: 2} --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-60-f9d83a4c8f73> in <module>() ----> 1 (1,2) > {1: 2} TypeError: '>' not supported between instances of 'tuple' and 'dict'
nicwolff 9y ago
He means Python 3.
sametmax 9y ago
I said "modern". Python 2 is not modern. Python 3 is. And the keyword in my schema validation sentence is "easy". I love rust, but a low level language cannot be compared in productivity to a high level language for this stuff. They are much, much easier. That's the whole purpose. You trade easiness for rigor.

seanwilson 9y ago

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. You mean a dynamic check? It's better than nothing but I don't exactly want my e.g. scheduled data import process crashing because it was sent some bad data. I'd much rather have static checking and have all the possibilities accounted for before the code runs. > As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Why couldn't you write this with static checks? Statically checked functional languages for example are great for writing compilers.

sametmax 9y ago
keyword being "easy"
- seanwilson 9y ago
  I just don't find that personally. Having to run the code over and over again to manually check for errors or having to write unit tests to gain confidence it's working is more difficult to me than getting help from static type checking. I mean why do you think it's always going to be more difficult with static types? Because you have to write type annotations?
  - sametmax 9y ago
    External data are never perfectly documented or known. You usually have huge and painful experimentation phase with parsing it. Experimenting is way easier with dynamic languages. You type less. Changing your mind has a lower cost. You don't need to think about doing the right things as much.
    - seanwilson 9y ago
      So in a statically typed language, if all I know is that I'm getting a string as input, it'll force me to deal with all the possibilities. Is it a number in the form of a string? A null value? A string that isn't a number? The type system will guide me through handling all the possibilities and enforce that I handle all of them. With dynamic typing, there's always a chance you've missed a case and next time the data comes in it'll trigger an exception. If you have decent type inference there isn't extra typing and any time you think you're saving with dynamic languages gets eaten up having to manually fix things when errors happen at runtime. I'd much rather spend time fixing predictable compile time errors than unpredictable runtime errors.