16 ms·

> ...but humans will never actually write SQL. They will instead ask questions about data in a natural language. Wasn't that the promise of SQL in the first pl

by janpot 7y ago

> ...but humans will never actually write SQL. They will instead ask questions about data in a natural language. Wasn't that the promise of SQL in the first place? I don't believe it, why would people (only) want to access structured data with something as ambiguous as natural language?

mudlus 7y ago
Agreed, this sounds like the pontificating of someone who has not studied language and culture. As soon as the machine can understand any "natural language" say to it, the language is dead. Before you teach your database to interpret upper class out of sight "White" English, try teaching it "Ebonics." I guess my point is, there's nothing "natural" about language.
- deleted 7y ago
  [deleted]
The_rationalist 7y ago
It's easy to produce unambiguous sentences in english.
- binarytox1n 7y ago
  A good way to do it is to use a "structured" subset of the "language" for "querying" purposes.
- transpostmeta 7y ago
  Then why aren't we programming in English? Why aren't we expressing mathematical expressions in English?
  - cortesoft 7y ago
    I have to assume GP is being sarcastic
  - BOBOTWINSTON 7y ago
    Exactly. My initial thought is highly specific human language is actually harder to write than most code, and always more verbose. Well written philosophy comes to mind. I'd argue that this is part of the reason ORMs gained so much prominence. They solve the problem that SQL introduces by trying to emulate natural language. Most developers will gladly risk sacrificing some specificity of the query in exchange for reducing the verbosity of a SQL query. Obviously if the dev knows their ORM/SQL well, there is no lost precision.
  - squiggleblaz 7y ago
    tldr (or boring)? skip to the last pragraph. "the product of pi and the square of r" is no less clear than the mathematical transcription of it. 3245 is perhaps English, but there's nothing wrong with "three thousand, two hundred and forty-five". Some more examples taken from Wikipedia: The sum of zero and zero. Five less than the product of eight and some value. Seven times the square of some value plus four times the aforesaid value minus ten. I mean I could go on; these are either not ambiguous, or they're ambiguous only because of a lack of convention. We don't do it because our attention span doesn't last long enough. We need to keep looking back at what we've already read to really understand what we're reading. Mathematical formulae give us the ability to do that quickly, since the graphical, multidimensional concise layout quickly allows us to find the place we're looking for.
  - The_rationalist 7y ago
    Because nobody has been able to implement a computable implementation of English. It's an orthogonal issue to ambiguity. I'm pretty sure controlled attempto English or lojban (zero ambiguity natural languages) have no computable implementations either.
- microcolonel 7y ago
  Unambiguous? Maybe. Specific enough to execute as programs? not nearly so much. I mean, humans regularly misinterpret verbal commands, and we're effectively the best thing at understanding and language that exists in nature. Half of the disagreements on HN result from misinterpretation of very specific, rather unambiguous statements.
  - blotter_paper 7y ago
    > Half of the disagreements on HN result from misinterpretation of very specific, rather unambiguous statements. Disagree, it's almost certainly more or less than half; it's incredibly unlikely that these statements would account for exactly half of disagreements. Furthermore the statements in question are rather specific and very unambiguous, not the other way around.
    - microcolonel 7y ago
      > Furthermore the statements in question are rather specific and very unambiguous, not the other way around. Or rather, the ambiguity is around how specific the statements are.
- vbezhenar 7y ago
  Like "select name from users where age > 15"?
- discreteevent 7y ago
  About 25 years ago a mathematician I knew who didn't have much time for computers said to me: "In fairness there is one thing you can say for programming: It forces you to be precise"
- jimbokun 7y ago
  You need to take an introductory natural language processing course.
  - The_rationalist 7y ago
    I'm an NLP scientist trying to implement a software that take english as input and parse it into a queryable data structure that has zero semantic loss. I'm aware more than anybody on this thread, of the challenges of coreference resolution, word sense disambiguation, semantic parsing, etc... I didn't say that usual language is free of ambiguity. I just said humans are perfectly able to output clear, unambiguous English in a systematic manner. I just needs a little more mental energy.
- js8 7y ago
  Anyone who thinks otherwise should be sentenced to death!
- unfunco 7y ago
  There's at least two different ways to read this comment.
- apocalypstyx 7y ago
  My go-to (or goto, if you will) quote: We are not here concerned with so-called computer 'languages', which resemble human languages (English, Sanskrit, Malayalam, Mandarin Chinese, Twi or Shoshone etc.) in some ways but are forever totally unlike human languages in that they do not grow out of the unconscious but directly out of consciousness. Computer language rules ('grammar') are stated first and thereafter used. The 'rules' of grammar in natural human languages are used first and can be abstracted from usage and stated explicitly in words only with difficulty and never completely. --Walter Ong [Orality And Literacy]
reaperducer 7y ago
Wasn't that the promise of SQL in the first place? Lots of companies and organizations have made that promise. Even legendary game company Infocom way back in 1985. So far, none have delivered. https://en.wikipedia.org/wiki/Cornerstone_(software) https://en.wikipedia.org/wiki/Cornerstone_(software)
- baroffoos 7y ago
  I think the reason its so hard is when we ask something we are missing out huge bits of information about exactly what we want. Another human knows from experience and context what the person actually wants. When I say I want a webstore for selling keyboards A web dev already has a pretty good idea what I want because they know what a web store does and how it functions and they know how keyboards work so they will know to add search filters for things like switch types even though none of this information was in the original request. Explaining exactly what we want and covering all of the edge cases is just as hard as using a regular programming language. Until we can have full back and conversation with computers that have a deep understanding of what people want from a program and can ask the user questions like "But what should happen when x happens?".
  - pilsetnieks 7y ago
    Using natural language for stuff like that would be just like writing legalese, except being even more specific about everything.
    - afarrell 7y ago
      How would you write automated tests for it? How would you keep those tests from being really flakey?
    - Enginerrrd 7y ago
      That actually sounds way worse than just using queries.
- Endy 7y ago
  The fact that it didn't respond to commands as well as Zork or A Mind Forever Voyaging didn't help the case. Infocom had a pretty solid engine for "natural language" input. Too bad they couldn't adapt it well.
yamrzou 7y ago
"Remember that code is really the language in which we ultimately express the requirements. We may create languages that are closer to the requirements. We may create tools that help us parse and assemble those requirements into formal structures. But we will never eliminate necessary precision—so there will always be code", Robert C. Martin, Clean Code.
- epicureanideal 7y ago
  Right. Most people simply are not in the habit of expressing themselves with enough precision, and might even be missing some essential training. Whenever precision is required, we end up with methodologies like technical writing, or specialized language like legalese, to provide the necessary precision. If we didn't have "programming languages", we'd end up with some sort of "computerese" analogous to legalese, and it would still take years to become proficient in using it, and there would still be either people or AI who would translate natural language into "computerese" (but we'd likely prefer human oversight over the AI anyway, given that a human that needs an AI to convert their language into something more precise is likely not capable of judging whether the output is precisely what they meant).
  - blotter_paper 7y ago
    > Most people simply are not in the habit of expressing themselves with enough precision, and might even be missing some essential training. I agree with this, I don't think we'll be programming in natural languages until the computer is intelligent enough to pick out unintended ambiguity and ask clarifying questions. What I'm unsure about is whether or not the computer will be that intelligent in 50 years. Whenever it is that intelligent, I expect us to transition quickly.
    - afarrell 7y ago
      A problem is: How many clarifying questions do we want the computer to ask? How many much judgement do we want the computer to exercise? There are going to be many tasks for which we don't want any independent judgement to be exercised by the machine. And for those tasks, we're going to still want a highly structured language.
zozbot234 7y ago
Not "natural language" per se, but some database frontends support building queries step-by-step via a GUI wizard, generally known as "Query by example" (QBE). Even LibreOffice Base can do this.
crimsonalucard 7y ago
I think even before we get there, one of the big issues with SQL is how we write optimized queries. It's basically involves memorizing a bunch of hacks and hoping that those hacks compile into something that is performant. Before we use these 5th generation languages to write natural language queries we need an API that is sufficiently high level and possible to logically optimize without resorting to hacks.
- Pxtl 7y ago
  Exactly. I always say SQL servers are kernel of beautiful relational theory wrapped in about 4 feet of duck-tape and bubble gum. The SQL server presents itself as a black box, saying "just say what you want and I'll figure out how to get it" and then completely fails to deliver on this and you have to open up the black box and find that its insides are dark and scary and full of jagged sharp ends.
  - richardwhiuk 7y ago
    All layers of abstraction are leaky when you care about performance sufficiently.
    - crimsonalucard 7y ago
      To an extent. Some layers are significantly more leaky than others. Rust vs. SQL for example.
streetcat1 7y ago
No. SQL was invented (in system-R) in order to have a decelerative way to query a relational database [tables and relations] (as a front end to the query optimizer).
Zenst 7y ago
Was also the time of 4GL and how everything could be reduced to a form based language front-end to a database https://en.wikipedia.org/wiki/Fourth-generation_programming_language#Database_query_languages https://en.wikipedia.org/wiki/Fourth-generation_programming_... and other wondrous promises of overselling dreams and delivering something that many have now forgotten ever existed. Let's be fair, C is still alive and kicking despite the promises of that 4GL era.
fastball 7y ago
I think the idea is more that querying will be "higher level", and still just as performant as writing the raw SQL. So instead of specifying a lot of JOINs and such, you just ask for the data you need and it delivers it optimally. GraphQL seems like the first iteration of this, but in its current form you do lose performance.
afpx 7y ago
Complex SQL takes a lot of time to write, and some of us don’t have the money to pay someone.
xiaodai 7y ago
Hyper Anna
jiggawatts 7y ago
The closest I've seen anyone come to this "dream" scenario is PowerBI. It's very visual and drag & drop, with practically no coding or query language skills required. Yet, it can automatically generate insanely complex queries that even a seasoned developer would struggle to write manually.
- Discombulator 7y ago
  PowerBI is an interesting case. As long as you do “run of the mill” business analytics (Star or snowflake tables, “simple” aggregations) it is like you say. But once you need something different, you’re in for some serious rethinking and coding. I have this article printed out in a drawer for these cases: http://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax-cross-table.html http://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax... With DAX, Microsoft has extended the PivotTable model (instead of the relational model), and they deserve full respect for trying something new in this space. Is it a simpler model? I kinda like it, but don’t think it is simpler.
cryptica 7y ago
I had the same thought. Human language is ambiguous precisely because there are so many synonyms, expressions and nuances which are open to interpretation. Sometimes in negotiations, you can say one thing which has two different intents/meanings and you just watch the other person's reaction to decide which path to take the conversation. Sometimes the counterparty needs to know what you're thinking in order to know what you really mean. It wouldn't make sense to ask a machine to guess what the author is thinking when it's faced with ambiguous instructions. It would make debugging impossible.

by janpot 7y ago

mudlus 7y ago

Agreed, this sounds like the pontificating of someone who has not studied language and culture. As soon as the machine can understand any "natural language" say to it, the language is dead. Before you teach your database to interpret upper class out of sight "White" English, try teaching it "Ebonics." I guess my point is, there's nothing "natural" about language.

deleted 7y ago
[deleted]

The_rationalist 7y ago

It's easy to produce unambiguous sentences in english.

binarytox1n 7y ago
A good way to do it is to use a "structured" subset of the "language" for "querying" purposes.
transpostmeta 7y ago
Then why aren't we programming in English? Why aren't we expressing mathematical expressions in English?
- cortesoft 7y ago
  I have to assume GP is being sarcastic
- BOBOTWINSTON 7y ago
  Exactly. My initial thought is highly specific human language is actually harder to write than most code, and always more verbose. Well written philosophy comes to mind. I'd argue that this is part of the reason ORMs gained so much prominence. They solve the problem that SQL introduces by trying to emulate natural language. Most developers will gladly risk sacrificing some specificity of the query in exchange for reducing the verbosity of a SQL query. Obviously if the dev knows their ORM/SQL well, there is no lost precision.
- squiggleblaz 7y ago
  tldr (or boring)? skip to the last pragraph. "the product of pi and the square of r" is no less clear than the mathematical transcription of it. 3245 is perhaps English, but there's nothing wrong with "three thousand, two hundred and forty-five". Some more examples taken from Wikipedia: The sum of zero and zero. Five less than the product of eight and some value. Seven times the square of some value plus four times the aforesaid value minus ten. I mean I could go on; these are either not ambiguous, or they're ambiguous only because of a lack of convention. We don't do it because our attention span doesn't last long enough. We need to keep looking back at what we've already read to really understand what we're reading. Mathematical formulae give us the ability to do that quickly, since the graphical, multidimensional concise layout quickly allows us to find the place we're looking for.
- The_rationalist 7y ago
  Because nobody has been able to implement a computable implementation of English. It's an orthogonal issue to ambiguity. I'm pretty sure controlled attempto English or lojban (zero ambiguity natural languages) have no computable implementations either.
microcolonel 7y ago
Unambiguous? Maybe. Specific enough to execute as programs? not nearly so much. I mean, humans regularly misinterpret verbal commands, and we're effectively the best thing at understanding and language that exists in nature. Half of the disagreements on HN result from misinterpretation of very specific, rather unambiguous statements.
- blotter_paper 7y ago
  > Half of the disagreements on HN result from misinterpretation of very specific, rather unambiguous statements. Disagree, it's almost certainly more or less than half; it's incredibly unlikely that these statements would account for exactly half of disagreements. Furthermore the statements in question are rather specific and very unambiguous, not the other way around.
  - microcolonel 7y ago
    > Furthermore the statements in question are rather specific and very unambiguous, not the other way around. Or rather, the ambiguity is around how specific the statements are.
vbezhenar 7y ago
Like "select name from users where age > 15"?
discreteevent 7y ago
About 25 years ago a mathematician I knew who didn't have much time for computers said to me: "In fairness there is one thing you can say for programming: It forces you to be precise"
jimbokun 7y ago
You need to take an introductory natural language processing course.
- The_rationalist 7y ago
  I'm an NLP scientist trying to implement a software that take english as input and parse it into a queryable data structure that has zero semantic loss. I'm aware more than anybody on this thread, of the challenges of coreference resolution, word sense disambiguation, semantic parsing, etc... I didn't say that usual language is free of ambiguity. I just said humans are perfectly able to output clear, unambiguous English in a systematic manner. I just needs a little more mental energy.
js8 7y ago
Anyone who thinks otherwise should be sentenced to death!
unfunco 7y ago
There's at least two different ways to read this comment.
apocalypstyx 7y ago
My go-to (or goto, if you will) quote: We are not here concerned with so-called computer 'languages', which resemble human languages (English, Sanskrit, Malayalam, Mandarin Chinese, Twi or Shoshone etc.) in some ways but are forever totally unlike human languages in that they do not grow out of the unconscious but directly out of consciousness. Computer language rules ('grammar') are stated first and thereafter used. The 'rules' of grammar in natural human languages are used first and can be abstracted from usage and stated explicitly in words only with difficulty and never completely. --Walter Ong [Orality And Literacy]

reaperducer 7y ago

Wasn't that the promise of SQL in the first place? Lots of companies and organizations have made that promise. Even legendary game company Infocom way back in 1985. So far, none have delivered. https://en.wikipedia.org/wiki/Cornerstone_(software) https://en.wikipedia.org/wiki/Cornerstone_(software)

baroffoos 7y ago
I think the reason its so hard is when we ask something we are missing out huge bits of information about exactly what we want. Another human knows from experience and context what the person actually wants. When I say I want a webstore for selling keyboards A web dev already has a pretty good idea what I want because they know what a web store does and how it functions and they know how keyboards work so they will know to add search filters for things like switch types even though none of this information was in the original request. Explaining exactly what we want and covering all of the edge cases is just as hard as using a regular programming language. Until we can have full back and conversation with computers that have a deep understanding of what people want from a program and can ask the user questions like "But what should happen when x happens?".
- pilsetnieks 7y ago
  Using natural language for stuff like that would be just like writing legalese, except being even more specific about everything.
  - afarrell 7y ago
    How would you write automated tests for it? How would you keep those tests from being really flakey?
  - Enginerrrd 7y ago
    That actually sounds way worse than just using queries.
Endy 7y ago
The fact that it didn't respond to commands as well as Zork or A Mind Forever Voyaging didn't help the case. Infocom had a pretty solid engine for "natural language" input. Too bad they couldn't adapt it well.

yamrzou 7y ago

"Remember that code is really the language in which we ultimately express the requirements. We may create languages that are closer to the requirements. We may create tools that help us parse and assemble those requirements into formal structures. But we will never eliminate necessary precision—so there will always be code", Robert C. Martin, Clean Code.

epicureanideal 7y ago
Right. Most people simply are not in the habit of expressing themselves with enough precision, and might even be missing some essential training. Whenever precision is required, we end up with methodologies like technical writing, or specialized language like legalese, to provide the necessary precision. If we didn't have "programming languages", we'd end up with some sort of "computerese" analogous to legalese, and it would still take years to become proficient in using it, and there would still be either people or AI who would translate natural language into "computerese" (but we'd likely prefer human oversight over the AI anyway, given that a human that needs an AI to convert their language into something more precise is likely not capable of judging whether the output is precisely what they meant).
- blotter_paper 7y ago
  > Most people simply are not in the habit of expressing themselves with enough precision, and might even be missing some essential training. I agree with this, I don't think we'll be programming in natural languages until the computer is intelligent enough to pick out unintended ambiguity and ask clarifying questions. What I'm unsure about is whether or not the computer will be that intelligent in 50 years. Whenever it is that intelligent, I expect us to transition quickly.
  - afarrell 7y ago
    A problem is: How many clarifying questions do we want the computer to ask? How many much judgement do we want the computer to exercise? There are going to be many tasks for which we don't want any independent judgement to be exercised by the machine. And for those tasks, we're going to still want a highly structured language.

zozbot234 7y ago

Not "natural language" per se, but some database frontends support building queries step-by-step via a GUI wizard, generally known as "Query by example" (QBE). Even LibreOffice Base can do this.

crimsonalucard 7y ago

I think even before we get there, one of the big issues with SQL is how we write optimized queries. It's basically involves memorizing a bunch of hacks and hoping that those hacks compile into something that is performant. Before we use these 5th generation languages to write natural language queries we need an API that is sufficiently high level and possible to logically optimize without resorting to hacks.

Pxtl 7y ago
Exactly. I always say SQL servers are kernel of beautiful relational theory wrapped in about 4 feet of duck-tape and bubble gum. The SQL server presents itself as a black box, saying "just say what you want and I'll figure out how to get it" and then completely fails to deliver on this and you have to open up the black box and find that its insides are dark and scary and full of jagged sharp ends.
- richardwhiuk 7y ago
  All layers of abstraction are leaky when you care about performance sufficiently.
  - crimsonalucard 7y ago
    To an extent. Some layers are significantly more leaky than others. Rust vs. SQL for example.

streetcat1 7y ago

No. SQL was invented (in system-R) in order to have a decelerative way to query a relational database [tables and relations] (as a front end to the query optimizer).

Zenst 7y ago

Was also the time of 4GL and how everything could be reduced to a form based language front-end to a database https://en.wikipedia.org/wiki/Fourth-generation_programming_language#Database_query_languages https://en.wikipedia.org/wiki/Fourth-generation_programming_... and other wondrous promises of overselling dreams and delivering something that many have now forgotten ever existed. Let's be fair, C is still alive and kicking despite the promises of that 4GL era.

fastball 7y ago

I think the idea is more that querying will be "higher level", and still just as performant as writing the raw SQL. So instead of specifying a lot of JOINs and such, you just ask for the data you need and it delivers it optimally. GraphQL seems like the first iteration of this, but in its current form you do lose performance.

afpx 7y ago

Complex SQL takes a lot of time to write, and some of us don’t have the money to pay someone.

xiaodai 7y ago

Hyper Anna

jiggawatts 7y ago

The closest I've seen anyone come to this "dream" scenario is PowerBI. It's very visual and drag & drop, with practically no coding or query language skills required. Yet, it can automatically generate insanely complex queries that even a seasoned developer would struggle to write manually.

Discombulator 7y ago
PowerBI is an interesting case. As long as you do “run of the mill” business analytics (Star or snowflake tables, “simple” aggregations) it is like you say. But once you need something different, you’re in for some serious rethinking and coding. I have this article printed out in a drawer for these cases: http://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax-cross-table.html http://mdxdax.blogspot.com/2011/03/logic-behind-magic-of-dax... With DAX, Microsoft has extended the PivotTable model (instead of the relational model), and they deserve full respect for trying something new in this space. Is it a simpler model? I kinda like it, but don’t think it is simpler.

cryptica 7y ago

I had the same thought. Human language is ambiguous precisely because there are so many synonyms, expressions and nuances which are open to interpretation. Sometimes in negotiations, you can say one thing which has two different intents/meanings and you just watch the other person's reaction to decide which path to take the conversation. Sometimes the counterparty needs to know what you're thinking in order to know what you really mean. It wouldn't make sense to ask a machine to guess what the author is thinking when it's faced with ambiguous instructions. It would make debugging impossible.