Live data from Hacker News

Open Source SQL Parsers

tokern.io

101–103 of 103 posts

Re: Open Source SQL Parsers

#101
post #99

Earlier quoted context omitted.

And in the case of SQL, that is precisely the problem.

So the problem is that SQL can be picked up fairly easily by English speaking population? How's that the problem and not advantage?

Because "speaking SQL" [even before SQL as such was even invented, hence the scare quotes] was intended as a skill to be practiced only by those who also grasped the [mathematical] logic of what they were doing when "speaking SQL". None of the people who "speak SQL" these days fit that bill.

And FWIW, what I wrote was in reply to "mental model". It was *you* who apparently equated that with "speaking English". The "mental model" I described as "exactly the problem" is the "mental model" *of the corresponding logic*, which, though mathematically consistent, is hopelessly unintuitive. Being English-speaking or not has nothing to do with understanding a particular logic underpinning the behaviour of a particular Data Manipulation Language.

Re: Open Source SQL Parsers

#102

Earlier quoted context omitted.

With one single exception : you cannot use a CHECK clause to check that a table must be nonempty, because the semantics of the CHECK clause are that it must be satisfied by all rows in the table, and therefore the empty table trivially satisfies any CHECK clause.

Huh! That makes sense, thanks! It's standard univ. quantifier behaviour, I hadn't made the link. Also that's bloody odd because date or darwen (or both) explicitly called out this behaviour as flawed in SQL when in fact it's obviously logically consistent, and they know logic and SQL, so... why are they critising it? How very strange. Again, thanks for pointing this out. How did I never realise this?

What they "called out as flawed" was the impossibility to declare any such rule with SQL as it stood. What they were "criticizing" was precisely the fact that a data language that was supposed to be "expressively complete" was *unable* to express such a rule. You can't claim "expressive completeness" for a language if there is demonstrably a case where said language's expressiveness fails to meet the mark. It's not the "behaviour of the language" they were criticizing in all/any of those use cases that were supported by the language as it stood. They were criticizing the fact that there was a use case [and a relatively reasonable one on the face of it] that the language couldn't support.

Re: Open Source SQL Parsers

#103
post #99

Earlier quoted context omitted.

So the problem is that SQL can be picked up fairly easily by English speaking population? How's that the problem and not advantage?

Because "speaking SQL" [even before SQL as such was even invented, hence the scare quotes] was intended as a skill to be practiced only by those who also grasped the [mathematical] logic of what they were doing when "speaking SQL". None of the people who "speak SQL" these days fit that bill. And FWIW, what I wrote was in reply to "mental model". It was *you* who apparently equated that with "speaking English". The "m…

Having a language that already educated and skilled group of people can pick up fast is advantage. Targeting and working with people who grasp logic is good. Not bad. There's ever-repeating notion present that we need to invent tools that people, who are far from skilled, should be able to use to produce high quality results. Having a tool like SQL that's perfectly usable for a group of highly skilled people is excellent, not bad.

> None of the people who "speak SQL" these days fit that bill.

You can't prove this. This is what you believe is true.

> And FWIW, what I wrote was in reply to "mental model". It was you who apparently equated that with "speaking English"

Isn't it odd how we have the gift of being able to communicate, yet all we do is think we can wield telepathy and not use words to express ourselves. Unless you accurately express what it is you're thinking about, I can't fill in the gaps since I'm not telepathically enabled.

> Being English-speaking or not has nothing to do with understanding a particular logic underpinning the behaviour of a particular Data Manipulation Language.

Of course it does.

Post reply on HN