OK, I accept that SQL isn't really English, and it can get pretty hard to follow, but it's a lot closer to English than are most regular computer languages, with their heavy reliance on symbols and constructs that are impenetrable to the uninitiated.
Once you get away from the basic form, even English isn't always understandable by English speakers. Legal jargon, for example. We'll never get a true universal language, and I'd never advocate one. In spite of my enthusiasm for English-like scripting languages I don't regard them as a universal panacea, but never underestimate how far plain speaking can take you.
Too much language is used in part to exclude those who don't match the author's idea of who is able to appreciate the revelations contained therein, and my desire is to see tools that will give the lie to the claim that obtuse language is always necessary. Two books on any given subject can present what is essentially the same content in very different ways, one accessible and the other impenetrable, and I would like to see more of the former. Having the language with which to do it is a good start.
There is a similar question going around, but it just got the same old answers that people always give about Regex syntax, but that's not the point here, so please try to not knee jerk the same old answers about regex syntax. Try to be a little more original and…
Interesting discussion, that shows Regex to be a good example of the limitations of plain speaking. Sometimes there really is no alternative to out-and-out "code". Elsewhere, though, plain language is better than dense code, for the same reason we avoid one-letter variable names. It's all to do with human comprehension. As a rule of thumb I'd say if it can be described clearly in English then perhaps it ought to be coded in English - or as close as you can get to that.
Well the uncanny valley is the idea that the closer you are to realism, or in this case English, the harder it is for people to believe it when things are still inaccurate. (You mentioned a compiler, maybe some synthetic examples could help in this discussion.)
Let's consider Javascript and some of its evaluation.
if(4=="4")
if 4 equals "4" begin
That is nice but why not
when 4 is equal to "4" execute
Clearly we would want a subset of the English language.
if(4==="4")
if 4 same as "4" do
It is not like Javascript is clear on by its choice but does follow some really really normal emphasis convention. But I don't even know where to go with English. Sure maybe Javascript should have use like in the first one, but hindsight is 20/20.
What about some bash
if 5 -gt 9 then
if 5 greater than 9 start
It could be argued that gt is close enough, but that isn't English what if it means 'goes into'
if 3 gt 9 run
Sure we don't know of a language with this semantics, but if someone wants that maybe that is what they believe 'gt' to stand for.
And while we're at it, what are these quotes and what is a string.
if the writing "foo" is the same writing as "bar" follow these steps
But I've included 'as' after 'writing' how does the language know which articles to expect when? Maybe we don't need the articles.
if writing "foo" same writing "bar" steps
Well that isn't English. We've hit the uncanny valley. If we don't handle all of English we will come up with our own language which looks like English but does not live by English rules.
When theory shows a thing to be X, practice often demonstrates it's Y. I'm not a theoretician, just an old-fashioned engineer who makes things that work. In this case, user interfaces, which today mostly means websites. Any website that can't be described clearly in English probably can't be used by human beings, so I code them entirely using my own formal English-like imperative syntax originally inspired by Apple's HyperTalk. Like English, this is unambiguous if coded sensibly and it can be used by any person with an understanding of what the UI is for and what it does, whether their native tongue is English, French, German or whatever. Devising a clear and unambiguous syntax and then writing a compiler for it are not trivial tasks, and the future can come along and bite you, as the authors of JavaScript have found. But that's no reason for not doing what works best now.
A typical example might be "while Count is less than the json count of TheDataArray gosub to AddAnotherRow". One might argue about its linguistic purity but ten years down the road it will still be instantly readable while a React or Angular solution will have the reader diving into the discarded book pile to find out where to locate and how to set up the IDE, never mind changing the code. I exaggerate, perhaps, but not by much.
And that's what lies behind the articles I write on the subject of appropriate language - real-world experience of something that works now and goes on working indefinitely while the rest of the world changes. And I have satisfied customers able to testify to the effectiveness of the approach.
It's the head of a 'while' loop that counts from the current value of Count up to the number of elements in a string that's a JSON-encoded array (held in a variable called TheDataArray). Each time through the loop it executes a statement, which might be a single command or a block (these use begin...end); here it's a subroutine call; the code assumes Count will be incremented there. (I'm not saying I would actually code like that; it's just an artificial one-liner.) All variables are global but there are rarely more than a few dozen in any one script. The language allows scripts to invoke other scripts and share variables with them; unshared variables remain private.
I originally wrote the compiler and runtime in Java some 20 years ago. Last year I rewrote it in JavaScript as a website coding engine, and I'm now doing a version in Python (as a learning exercise). None of them have ever been widely used by anyone but myself, but that's the fate of most custom languages. The performance is quite good, especially when complicated functionality is wrapped up as script objects (as happens in English). I accept it breaks all sorts of conventions regarding the 'right' way to do things but I'm only interested in what works. Most importantly I can return years later and quickly pick it up again, something I struggle to do even with my own code written in Java or PHP, for example.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
OK, I accept that SQL isn't really English, and it can get pretty hard to follow, but it's a lot closer to English than are most regular computer languages, with their heavy reliance on symbols and constructs that are impenetrable to the uninitiated.
Once you get away from the basic form, even English isn't always understandable by English speakers. Legal jargon, for example. We'll never get a true universal language, and I'd never advocate one. In spite of my enthusiasm for English-like scripting languages I don't regard them as a universal panacea, but never underestimate how far plain speaking can take you.
Too much language is used in part to exclude those who don't match the author's idea of who is able to appreciate the revelations contained therein, and my desire is to see tools that will give the lie to the claim that obtuse language is always necessary. Two books on any given subject can present what is essentially the same content in very different ways, one accessible and the other impenetrable, and I would like to see more of the former. Having the language with which to do it is a good start.
I would claim that the issue is the same as the uncanny valley except for code.
It is what I was actually going for in my response to regex.
Why do people defend the regex syntax?
There is a similar question going around, but it just got the same old answers that people always give about Regex syntax, but that's not the point here, so please try to not knee jerk the same old answers about regex syntax. Try to be a little more original and…
Interesting discussion, that shows Regex to be a good example of the limitations of plain speaking. Sometimes there really is no alternative to out-and-out "code". Elsewhere, though, plain language is better than dense code, for the same reason we avoid one-letter variable names. It's all to do with human comprehension. As a rule of thumb I'd say if it can be described clearly in English then perhaps it ought to be coded in English - or as close as you can get to that.
Well the uncanny valley is the idea that the closer you are to realism, or in this case English, the harder it is for people to believe it when things are still inaccurate. (You mentioned a compiler, maybe some synthetic examples could help in this discussion.)
Let's consider Javascript and some of its evaluation.
That is nice but why not
Clearly we would want a subset of the English language.
It is not like Javascript is clear on by its choice but does follow some really really normal emphasis convention. But I don't even know where to go with English. Sure maybe Javascript should have use
like
in the first one, but hindsight is 20/20.What about some bash
It could be argued that
gt
is close enough, but that isn't English what if it means 'goes into'Sure we don't know of a language with this semantics, but if someone wants that maybe that is what they believe 'gt' to stand for.
And while we're at it, what are these quotes and what is a string.
But I've included 'as' after 'writing' how does the language know which articles to expect when? Maybe we don't need the articles.
Well that isn't English. We've hit the uncanny valley. If we don't handle all of English we will come up with our own language which looks like English but does not live by English rules.
When theory shows a thing to be X, practice often demonstrates it's Y. I'm not a theoretician, just an old-fashioned engineer who makes things that work. In this case, user interfaces, which today mostly means websites. Any website that can't be described clearly in English probably can't be used by human beings, so I code them entirely using my own formal English-like imperative syntax originally inspired by Apple's HyperTalk. Like English, this is unambiguous if coded sensibly and it can be used by any person with an understanding of what the UI is for and what it does, whether their native tongue is English, French, German or whatever. Devising a clear and unambiguous syntax and then writing a compiler for it are not trivial tasks, and the future can come along and bite you, as the authors of JavaScript have found. But that's no reason for not doing what works best now.
A typical example might be "while Count is less than the json count of TheDataArray gosub to AddAnotherRow". One might argue about its linguistic purity but ten years down the road it will still be instantly readable while a React or Angular solution will have the reader diving into the discarded book pile to find out where to locate and how to set up the IDE, never mind changing the code. I exaggerate, perhaps, but not by much.
And that's what lies behind the articles I write on the subject of appropriate language - real-world experience of something that works now and goes on working indefinitely while the rest of the world changes. And I have satisfied customers able to testify to the effectiveness of the approach.
"while Count is less than the json count of TheDataArray gosub to AddAnotherRow"
Any chance you could explain what this is checking?
It's the head of a 'while' loop that counts from the current value of Count up to the number of elements in a string that's a JSON-encoded array (held in a variable called TheDataArray). Each time through the loop it executes a statement, which might be a single command or a block (these use begin...end); here it's a subroutine call; the code assumes Count will be incremented there. (I'm not saying I would actually code like that; it's just an artificial one-liner.) All variables are global but there are rarely more than a few dozen in any one script. The language allows scripts to invoke other scripts and share variables with them; unshared variables remain private.
I originally wrote the compiler and runtime in Java some 20 years ago. Last year I rewrote it in JavaScript as a website coding engine, and I'm now doing a version in Python (as a learning exercise). None of them have ever been widely used by anyone but myself, but that's the fate of most custom languages. The performance is quite good, especially when complicated functionality is wrapped up as script objects (as happens in English). I accept it breaks all sorts of conventions regarding the 'right' way to do things but I'm only interested in what works. Most importantly I can return years later and quickly pick it up again, something I struggle to do even with my own code written in Java or PHP, for example.