Hacker News Reader

Comment by sametmax | Hacker News Reader

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/

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.

View on HN

> 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.

keyword being "easy"

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?

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.

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.

> 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/

This validates at compile time.

  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'

He means Python 3.

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.

Reply on news.ycombinator.com