4 ms·

Can't say I agree on the notion that dynamic languages doesn't gain anything with strict typing. I have written a lot of PHP over the years and PHP has gradual

by tored 5y ago

Can't say I agree on the notion that dynamic languages doesn't gain anything with strict typing. I have written a lot of PHP over the years and PHP has gradually introduced type hints for function parameters and return values. For me this has reduced the number of type errors I have to almost zero and with that data errors. The thing is with type errors in dynamic languages is that it usually hides an error branch. Example, we open a file handle with fopen(), it can return a handle or false on fail. If that would fail (false) with old style PHP you could continue pass that false file handle to other file functions like fread(), fwrite() etc without knowing they all failed. So in this case there would be no data at all either to be transformed, mangled or inserted, it wouldn't exist at all because it couldn't be written, that is also a form of data pollution (fopen() can swapped with sqlite equivalent for the same argument) How about types and preventing data pollution? Take dates as a good example. In old MySQL you could insert zero dates (0000-00-00) or invalid dates (2004-04-31), with better sql modes you can prevent that for happening, a type enforcement. Having non existing dates in your database will give trouble in the future, how should you handle them for calculating something like time periods for subscriptions? Do you really take into account when writing your SQL query that some dates are not valid dates at all? Having inherited lots of old PHP project I can't say enjoy the non-strict typing in both code and database, database columns are usually filled with all sorts of garbage, like 0,1, -1, 2, true, false, null, "NULL", "Yes", "No" or even localized strings "Ja", "Nej". This will always lead to more complicated SQL queries or code logic down the line. The article argues that you can easily spot data pollution in a column, that assumes that the developer actually looks at it, but if everything "works" why should they? I want to do the opposite and create my own types, assume that we accept user input and to make sure that the user input doesn't contain garbage I can create my own types, like MultiByteText255, AsciiText64, HtmlFragment etc and that should be enforced both in code and storage. These types can both enforce the contents of it and also make sure to properly store and output it. And if I want I can inherit to specialized types like UserName extends MultiByteText255. Everyone using functions that takes a UserName type is forced to adhere to it.

12thwonder 5y ago
but do you want, for example, a file system where you have to define what kind of files you can store? This folder can only contain JPEG and PNG files, this folder can contain only A or B ....etc. useful in some cases but I don't think this is not what you want as a default.
- tored 5y ago
  Interesting concept, but a guess that a file system is at a lower abstraction level than a database. Only argument that I can sort of understand for flexible types is that it is easier to get started or for smaller projects, like some batch script, but as soon as you have a large system you want strict control of what data you write to the database. Otherwise your schema migrations will be a nightmare.
  - 12thwonder 5y ago
    I think what you are saying makes sense for a lot of projects. but point I was trying to make is that there are projects that have to deal with highly dynamic and complex data structures. I used file system as an example but any trees/graphs are pretty hard to express as a simple type.
    - tored 5y ago
      I guess another scenario could be if you need to import massive amount of schemaless data, like csv imports, then types can be a problem if the sender does not have clear definition of what type the data has, common problem when dealing with non-engineers that hands you something from excel. Thus too much of strict types can be a problem, if I compare PHP to Java, Java has a tendency to become type bureaucracy, where I find PHP to be a sane middle ground where you specify types on your functions , i.e. your api, but not within. But writing data is not equivalent of passing data around in your application, as soon you have stored something it is hard to go back and change it because you have usually lost all context from when you wrote it, where as changing type in program code can almost always be done. As a frequent user of sqlite I'm looking forward to try out STRICT tables, it will be interesting if that actually improves anything from an application perspective or if it becomes more cumbersome.

by tored 5y ago

12thwonder 5y ago

but do you want, for example, a file system where you have to define what kind of files you can store? This folder can only contain JPEG and PNG files, this folder can contain only A or B ....etc. useful in some cases but I don't think this is not what you want as a default.

tored 5y ago
Interesting concept, but a guess that a file system is at a lower abstraction level than a database. Only argument that I can sort of understand for flexible types is that it is easier to get started or for smaller projects, like some batch script, but as soon as you have a large system you want strict control of what data you write to the database. Otherwise your schema migrations will be a nightmare.
- 12thwonder 5y ago
  I think what you are saying makes sense for a lot of projects. but point I was trying to make is that there are projects that have to deal with highly dynamic and complex data structures. I used file system as an example but any trees/graphs are pretty hard to express as a simple type.
  - tored 5y ago
    I guess another scenario could be if you need to import massive amount of schemaless data, like csv imports, then types can be a problem if the sender does not have clear definition of what type the data has, common problem when dealing with non-engineers that hands you something from excel. Thus too much of strict types can be a problem, if I compare PHP to Java, Java has a tendency to become type bureaucracy, where I find PHP to be a sane middle ground where you specify types on your functions , i.e. your api, but not within. But writing data is not equivalent of passing data around in your application, as soon you have stored something it is hard to go back and change it because you have usually lost all context from when you wrote it, where as changing type in program code can almost always be done. As a frequent user of sqlite I'm looking forward to try out STRICT tables, it will be interesting if that actually improves anything from an application perspective or if it becomes more cumbersome.