Comment by dboreham | Hacker News Reader

Comment by dboreham | Hacker News Reader

Parent Full thread

This is an example of a general (imho) fallacy pattern that also shows up with FP:

There's some branch of mathematics. Some people become familiar with that and like it for psychological reasons. Makes them feel good that they grokked it. Now, some subset of those people end up in positions where they can write software and academic papers. They notice that some problem space relevant to computing is kind of like that branch of mathematics they liked. They embark on a zealous mission to apply that branch of mathematics strictly in the context of the problem space.

Reason I think this is a fallacy is that there's nothing god-given about some branch of mathematics that makes it somehow pristine and golden and "better" than some adhoc solution hacked together by a hacker. Mathematics was also "hacked together", just it was done before computers existed.

So these people are really on a kind of circular journey -- they're taking someone's definition of a VM that is called Mathematics, that typically was derived from ordinary principles present in the natural world, and having the bright idea that they can implement that VM in code and that they will be much more "proper" than if someone else had instead begun with those same ordinary principles and gone straight to software.

Put another way: SQL doesn't need relational algebra. You could just as well derived relational algebra from SQL than the other way around. They both come from the ordinary need to filter and reason about collections of records about things.

The useful thing about mathematics is that it gives you tools to prove that your solution will work for all problems of a certain class. Hacked together code usually doesn't have that property, and if it does then it just is mathematics, whether you want to call it that or not.

The problem with SQL is it is based on relational algebra, just not consistently.

SQL allows you to insert a duplicate row or update a row such that it becomes similar to another row. But then it is not possible to delete or change the row again without changing or deleting all the duplicates, because the query language assumes rows are unique. This is obviously a footgun and not useful behavior.

Yes. After shooting off nine of my toes, I decided to save the last one by always adding a unique something to every table, an auto_increment if nothing else seemed appropriate.

Sure, you don't need a mathematical theory of your software, if you don't care if your results are correct, and only want your software to meet the bar of "all reported bugs have been fixed and tests passed."

Meanwhile, most of the stuff people actually love (and don't want to understand) about their software was invented by people pursuing the mathematical approach.

And those people get away with hacky code because most of the software core is rock-solid and mathematically valid, leaving an "error budget" for sloppy hacks.

But if it were just sloppy hacks all the way down, your gigabytes of source code would not work at all.

You have the luxury of not knowing what I know; that algebraic rigor, while frustrating, probably prevented bugs. And mathematics, while arcane and incomprehensible to you, prevents bugs. You don't want the truth because in places you don't talk about at standup, you want mathematicians writing on that chalkboard. You need them at that chalkboard. We use words like monad, monoid, endofunctor. We use these words as the backbone of a life spent proving something. You use them as a punchline.

"A Few Good Monads" -- coming to theaters soon!

Starring Jack Nicholson as Kernel Jessup

the problem with SQL isn't that it doesn't hew to this or that mathematical framework. the problem with sql is that its irregular, doesn't compose well, and has a very baroque semantics due to the inclusion of NULLs among other things.

using a well-thought out model eases or eliminates some of these very real human problems.

you've got it backwards

we who use these databases for real problems need LEFT OUTER JOIN and to use LEFT OUTER JOIN you need NULL.

There are other ways, like having a null with more regular semantics and better composeability (like Rust's option type).

Or imagine this data:

Students:

Name: Bob

Name: Alice

StudentsClasses

Student: Bob, class: cryptography.

Student: Bob, class: databases

If you can have arrays (or relations) as a field in your result set, then

Students left outer join StudentsClasses

Could return

Student: Bob, classes: [ cryptography, databases]

Student: Alice, classes: []

This violates first normal form. So if you want to query this result further you need a more complex language than relational algebra because you need to be able to query nested structures.

1nf is surprisingly tricky to define.

If you consider it as a single atomic list then it is still in 1nf.

It's only not in 1nf with respect to future queries IF you want to subselect from within the list values.

1NF is defined as eliminating nested relations. I assumed "[ cryptography, databases]" in the example represent a nested relation.

1NF is not defined in terms of what you want to do with the the data, it is defined in terms of domains, i.e data types. If a column allows nested tables, it violates 1NF.

"Atomic" in the context of 1NF means atomic wrt. the relational algebra.

Eg. if we have:

   Student: Bob, classes: [ cryptography, databases]
   Student: Alice, classes: []

Is it possible to select from this all students which has cryptography as a class, using the standard relational operators (project, filter, join)?

I think we're mostly in agreement!

You're right, it's not possible to select from this all students which has cryptography as a class. No more than if we did concat('cryptography', ',', 'databases').

The normal forms are about how data is stored, rather than how it looks after a query. After all, most joins will violate second normal form.

But yes, SQL doesn't work well with this solution.

what if I gave you a nice little language where you could easily define transforms on tables and explicitly specify 'a where a.key != b.key'. and a type system that would let you define null and all its various arithmetics.

sure, you'd say, but SQL already does all that

but you've have well thought out type construction, and a standard way of defining abstractions and transformations on data. maybe it would be general enough that you would be tempted to go full-on stored procedure and forget about having to juggle two languages and their interface

still no?

Paraphrasing the complaint doesn't negate its criticisms.

Tradeoffs were made, as always. Although it is fun to remind people that since SQL isn't relational that SQL databases are NoSQL databases.

Reply on news.ycombinator.com