On Fri, 10 Apr 2015 14:15:43 -0700 Roger Binns <rogerb at rogerbinns.com> wrote:
> On 04/10/2015 01:51 PM, Simon Slavin wrote: > > With a cursory glance I do see important incompatibilities with > > SQLite. > > I use JSON as the data format for $work stuff (startups) for years, > and these JSON schemas etc miss why some of us use JSON. If you are > using a statically typed language like Java or C++, then arbitrary > data is very difficult to deal with. XML is very popular in that > world because DTDs mean you can make it statically typed. The mindset > is that if everything can be specified and constrained in advance, > then successfully compiling the code means it is mostly correct. I beg to differ, Roger. The programming language of choice doesn't affect the correctness of a function. A function has preconditions and postconditions. They define the domain of the input and the range of the output. Failure to meet a precondition invalidates the function, irrespective of the language used. Lack of a compiler doesn't change that. It's not a matter of "mindset", and type-correctness isn't eliminated by uncompiled languages. I program in Python and C++. In both languages, if I try to take the substring of an integer, I get an error. The difference is that in C++ the error comes from the complier. I suspect lack of compilation in popular languages like Python is driving the current mania for test-driven development. Instead of letting the compiler find type errors systematically, we use an ad-hoc framework to discover them manually. This we call "progress". > JSON like several other languages (eg Python, Ruby) is dynamically > typed. You can stick anything you want in variables/fields, since the > type is associated with the value, not the variable name. That's fine as far as it goes. If your language lets you use variable foo to refer to value X in one place and to value Y somewhere else, that's OK with me. C lets you do the same, by the way, in a limited sense. One difference is that in C the name denotes storage, and C won't let you re-use a name within the same scope to refer to different storage. Another difference is that C checks to ensure the storage (i.e. value) is used consistently according to its declared type *before* the program is executed. In Python, that work is left to the interpreter, and errors are consequently discovered later. I don't see why name-value association and static type-checking are necessarily related. I see that static type-checking in Python is difficult, but not why it's undesirable. > Importing code does not mean it is correct - running it is how you > figure that out. Exactly. > This allows for far greater flexibility, and especially means you do > not have to decide in advance exactly what you will do with data. I think you know better. When you write a program, you *have* decided "in advance" (of running it) "exactly what you will do" with the data. What you have not done, in a language like Python, is use the computer to verify to any extent the correctness of your program before you run it. There are two contradictory language trends in our industry today, one scientific and one not. Rooted in computer science are languages like Haskell that enforce type-checking rigorously and, to a limited extent, let the programmer write programs that are provably correct. At the other end of the spectrum are lightweight languages like Python and Javascript that offer no typechecking and rely on programmer discipline and testing to reduce the error count to an acceptable nonzero number. Coming back to SQLite and JSON, the issues of type, domain, and range continue to be relevant regardless of storage format and rule enforcement. JSON won't enforce uniqueness constraints or referential integrity. Lack of such support places the burden of correctness on the programmer, precisely the situation that the relational model was invented to obviate. Any apparent "flexibility" afforded by lack of constraint enforcement is a chimera. The constraints must be met; it's only a question of who will make sure they are, and when, and how. --jkl
