4 ms·

While I believe 'plain English' type programming languages are a great concept, the reality is that it just introduces far more ambiguity into the mix, and you

While I believe 'plain English' type programming languages are a great concept, the reality is that it just introduces far more ambiguity into the mix, and you are just left trying to guess what the language designer's vagaries are. I came across this years ago when trying to get to grips with the then new fangled Ruby language. I kept having to go back to the documentation to remember the best way to convert a string to all uppercase... was it: str.upper str.uppercase str.ucase str.upcase str.capitalize (<- Don't even get me started on the regional differences of 'ise' vs 'ize' between US and UK English variants) ??? Even here, I would probably start using Avail, then in a few weeks I would be scratching my head and asking, was it: Print 1 to 10, as a comma-separated list or Display 1-10, in CSV format

yorwba 8y ago
The language could include all of the possible expressions as valid alternatives. There are good reasons why most programming languages don't do that (it really helps comprehension if there's only one standardized way to do something), but if a language wants to be as close to English as possible, it will have to include the whole kitchen sink of synonyms. It might have to educate the users about the difference between a minus and a dash, though, if "1-10" and "1–10" (that's an en-dash) should evaluate to a number and a list, respectively.
- markvangulik 8y ago
  Some of the keywords and operators (punctuation) of Avail methods are “completely optional”, in that the caller’s choice to include it or not (or alternative prepositions in some cases) is solely to improve readability of the result. For example, the ordinary field-getter has the form “_’s??thing”. The double-question-mark should actually be a single Unicode character (I’m on my phone). The question-mark makes the “s” optional, so you can say “cat’s thing” or “Jess’ thing”. But there’s nothing stopping you from saying “cat’ thing”, other than the derisive laughter of your peers. :-)
tambourine_man 8y ago
Yeah, that was my problem with AppleScript. It’s a read-only language to me. It took me years to try other languages and discover I could actually write code.
- mpweiher 8y ago
  "The experiment in designing a language that resembled natural languages (English and Japanese) was not successful." -- William Cook Any programming language that tries to do "natural language" should at least reference the AppleScript HOPL Paper[1] and say how they are doing things differently to address the (now) obvious problems. (Oh, and there is a LOT of good stuff in the paper, definitely worth a read). [1] http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
  - ontologiae 8y ago
    I think all experiments of languages that resembled natural languages will never work until one will try to ascend to a more high-level paradigm. Actuals programming language are based on a "forklift paradigm" : you describe the path of a forklift in a virtual warehouse where data's are in some places and your forklift move them from places to places. So a natural language isn't design to express this kind of semantic. In PPIG ( Psychology of Programming Interest Group ) 2006 was published a very interesting paper where is studied the metaphors which was shared by the core java library authors, the mental model said in another way. It reaveals very interesting facts : Programmers tend to think the world in term of Belief-Intention agents. Agent are members of a society who trade and own datas and are subject to legal constraints. A method calls is a speech act. The execution is mentalized as a journey in a a spatial world. Etc. There's a lot of metaphors like that, and it reveals tracks to conceive a more high level language. So there's a lot of work in this field (Behavior-Tree based language, time dimension include inside the semantics, etc.). Note that it is also possible to express non ambiguigous semantics in natural language : Attempto Controlled English is an exemple [2]. Here an toy example of what you could do with this language : "MyWebPage is a webpage. MyWebPage contains a textfield which a logical name is-named NameTextField. His label is "Name". MyWebPage contains a button which a logical name is-named SubmitButton. His label is "Submit". If User clicks on Submit and NameTextField is empty then NameTextField ' s css class becomes AlertEmptyInput. " [1] http://www.ppig.org/sites/default/files/2006-PPIG-18th-blackwell.pdf http://www.ppig.org/sites/default/files/2006-PPIG-18th-black... [2] http://attempto.ifi.uzh.ch/site/ http://attempto.ifi.uzh.ch/site/
_bxg1 8y ago
"an efficient compiler that concurrently explores all possible parses in pursuit of a semantically unambiguous interpretation." This suggests they have a solution to the ambiguity problem
- cyberferret 8y ago
  Thanks for the clarification. I missed that on the initial skim of the article. (And yes, I appreciate the irony of me introducing the 'ambiguity' arguments into a topic which deals specifically with the removal of such) :)
  - _bxg1 8y ago
    It's still arguable that there could be some ambiguity. The compiler makes sure the statement is interpreted in an unambiguous way on the computer's end, but the writer might still not know which of a number of ways to express what she wants to state.
- tzahola 8y ago
  This sounds extremely dangerous. Millions of dollars are wasted each year on mistyped ==/= operators, but this is some next level evil.
  - markvangulik 8y ago
    Very true. The core Avail language uses “_=_” for comparison, “_:_” to declare a variable, “_:=_” got assignment, and “_::=_” for constants (think “final”). It also has “_:_:=_” for the case when you want to declare a variable of a general type, but initialize it with something more specific (say a counter that starts at 1). But yes. There’s a lot of deeply evil things that can be done in Avail, right down to the lexical scanning. Like forbidding certain variable names, or manufacturing a run of tokens every time a certain emoji is encountered. There are also a lot of safeties, like sealing methods to prevent someone overriding “_+_” for [3’s type, 4’s type]->9’s type. Oh, and writing “x = x + 1;” as a statement will be flagged as a syntax error, because it would produce a Boolean value which is not allowed to be silently discarded like in Java or C. “Discard:_” makes these rarely needed situations absolutely obvious.
sehugg 8y ago
Inform 7 thoroughly explored this space: http://inform7.com/ http://inform7.com/
- megaman22 8y ago
  I've tried several times to figure out Inform 7, and I always go back to the old C-ish Inform 6 instead. I think my brain is damaged by prolonged exposure to traditional programming languages.
  - royjacobs 8y ago
    I had the exact same experience. I really wanted to like Inform 7 (and plenty of people do) but it feels completely counter-intuitive because it wants to feel like natural language but it's still "just" a programming language. It still has a fairly rigid syntax - it's just more verbose than a regular programming language. That is probably an oversimplification, but that's how it felt to me at least.
curun1r 8y ago
I'm hopeful that these sorts of languages can enjoy a renaissance in the form of suggestive interfaces similar to the ones that Android/iPhone users get when typing. It'd be much easier to program in Applescript if I had an editor that was letting me choose from a list of valid words rather than me having to remember the perfect incantation to do what I want.
Retra 8y ago
>While I believe 'plain English' type programming languages are a great concept I will refute that notion and suggest that 'plain English' type languages are an incredibly foolish diversion into a world where we pretend formal languages don't exist, are unimportant, or that English is one, or that it somehow can be laboriously contorted into a useful approximation of one.
marklgr 8y ago
> I kept having to go back to the documentation to remember the best way to convert a string to all uppercase... was it: Wouldn't you have the same issue with just any programming language?
- cyberferret 8y ago
  Point taken. But in the above example, why does Ruby do it as 'upcase' instead of the more English-y and popular 'uppercase' as most other languages use? Take a more esoteric example - to capitalise just the first letter of a string. By definition, this is called 'proper case', and most other languages I know use .proper() to achieve this. Except Ruby, which decided to use .titleize() (and there is that 'ize' again just to confound me further). If a language is going to be 'English-y', then sticking to actual English words for things such as uppercase, proper case etc. would be handy. Going outside of those constraints just increases the guessing game workload for the programmer.
  - vidarh 8y ago
    Pascal uses upcase, and so does many others, so it has a very long history. .titleize() is from ActiveSupport, not Ruby. But proper() would have confused me much more. First time I've ever heard it called that. 'proper' would sound ambiguous to me, because it doesn't indicate to me it's about case at all. But of course this just reinforces the point that naming is hard.
  - irishsultan 8y ago
    Except titleize changes not the first letter of a string, but the first letter of every word. That's title case (https://en.wiktionary.org/wiki/title_case https://en.wiktionary.org/wiki/title_case). Capitalize (https://ruby-doc.org/core-2.2.0/String.html#method-i-capitalize https://ruby-doc.org/core-2.2.0/String.html#method-i-capital...) on the other hand does something even weirder from your perspective, as it also changes letters to lower case.
  - 33degrees 8y ago
    The rule they’re following is that method names should be verbs, and upcase / downcase are shorter than alternatives like to_upper etc. So while it’s an unusual choice it’s not an arbitrary one
swoorup 8y ago
Perhaps lojban would have been a better choice.
tzahola 8y ago
Exactly my thoughts whenever I have to touch AppleScript.
klibertp 8y ago
> I kept having to go back to the documentation to remember 1. Why would you want to remember this? It's in the docs. If you use it often, you'll learn it eventually. If you don't, you have no need to remember this. Don't burden your memory unnecessarily. 2. A well written and searchable documentation adds very little overhead anyway, on the order of a few seconds. Yeah, writing from memory is faster, but not by that much, and that advantage disappears almost completely if you have good auto-completion and docs support in your editor. 3. There are hundreds of languages out there, even if you learn the library of one language, it doesn't help with other languages at all. Learning to quickly search reference docs, along with learning some basic concepts/assumptions of each language, is much more sustainable if you're thinking of becoming polyglot. EDIT: please, don't turn HN into Reddit, write a comment if you disagree, instead of downvoting.
- cyberferret 8y ago
  I agree with you in principle. Over the past 4 decades, I have programmed in dozens of programming languages, and remembering things like FOR or CASE loop structures is almost impossible for me now, and I constantly refer to docs. However, as a starting point for me, it would be easier if the languages all used a common naming convention for things like .upper() etc. Common mistake for me is to try .upper(), then .uppercase(), then have to leave my code and refer to the docs after repeated runtime errors. If I can make a reasonably intelligent guess within 2 or 3 tries, then it bodes well for me. Otherwise it is a productivity hit. To extrapolate this - the corollary to .upcase() is, to my mind .lowercase(), but it is in fact .downcase(). Makes sense logically ('down' is the opposite of 'up'), but syntax wise, I never say to anyone "You need to write your username in down case...". If the naming conventions for functions followed the English language definitions, then my hit/miss ration will improve, and so will my productivity. NB: I didn't downvote you (I can't anyway as I don't have the necessary karma to downvote immediate child answers to my posts). I thought you raised a valid point worthy of discussion.
  - klibertp 8y ago
    > it would be easier if the languages all used a common naming convention for things like .upper() etc. Well, it would definitely be easier if all the languages used the same conventions. The problem here, I think, is that all the possible conventions are arbitrary and objectively as good as any other, so there are many of them and settling on a single one across languages is not going to happen. It's much more important to choose one convention for a language and to follow it everywhere - this improves guessability of identifiers in that language. The convention chosen may be familiar to you or not, but that doesn't mean the more familiar one is any better. So, I think, it's more important for a language to follow a single convention consistently, while choosing which convention to follow is less important. That being said, I agree that it would be easier to learn new languages if they all followed a single standard for naming things, I just don't think it's going to happen. > If I can make a reasonably intelligent guess within 2 or 3 tries, then it bodes well for me. Otherwise it is a productivity hit. Agreed, but note that the 2-3 tries are informed by your experiences to date - someone with a different history of programming languages could find your guesses weird and would have completely different ones themselves. Another thing, I agree on the productivity hit in principle, just want to note that there are ways of mitigating it. I use many languages regularly (I'm a hobbyist-polyglot, I learned at least 30-40 languages to varying degrees) and I think that a good editor integration (most notably "semantic auto-complete" and "inline docs") can make up for a lot of cases like the `upcase`. For example, if I write this (`|` is cursor position): a = "asd" a.up| and hit <tab>, I get a popup with the suggestion of a correct name (`upper`) along with a bit of documentation. The level of support for this obviously varies a lot across languages, but where it's available I find it mostly fixes the problem of having to hit the docs too often. > NB: I didn't downvote you It's impossible to downvote immediate child posts, no matter the karma level, so it obviously couldn't be you :)
pure-awesome 8y ago
Thing is, Avail actually is not a 'plain English' type programming language. The website states things very confusingly. But look at the FAQ: http://www.availlang.org/about-avail/documentation/faq.html http://www.availlang.org/about-avail/documentation/faq.html Commenter dcw303 in this thread puts it better than I can.

yorwba 8y ago

The language could include all of the possible expressions as valid alternatives. There are good reasons why most programming languages don't do that (it really helps comprehension if there's only one standardized way to do something), but if a language wants to be as close to English as possible, it will have to include the whole kitchen sink of synonyms. It might have to educate the users about the difference between a minus and a dash, though, if "1-10" and "1–10" (that's an en-dash) should evaluate to a number and a list, respectively.

markvangulik 8y ago
Some of the keywords and operators (punctuation) of Avail methods are “completely optional”, in that the caller’s choice to include it or not (or alternative prepositions in some cases) is solely to improve readability of the result. For example, the ordinary field-getter has the form “_’s??thing”. The double-question-mark should actually be a single Unicode character (I’m on my phone). The question-mark makes the “s” optional, so you can say “cat’s thing” or “Jess’ thing”. But there’s nothing stopping you from saying “cat’ thing”, other than the derisive laughter of your peers. :-)

tambourine_man 8y ago

Yeah, that was my problem with AppleScript. It’s a read-only language to me. It took me years to try other languages and discover I could actually write code.

mpweiher 8y ago
"The experiment in designing a language that resembled natural languages (English and Japanese) was not successful." -- William Cook Any programming language that tries to do "natural language" should at least reference the AppleScript HOPL Paper[1] and say how they are doing things differently to address the (now) obvious problems. (Oh, and there is a LOT of good stuff in the paper, definitely worth a read). [1] http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
- ontologiae 8y ago
  I think all experiments of languages that resembled natural languages will never work until one will try to ascend to a more high-level paradigm. Actuals programming language are based on a "forklift paradigm" : you describe the path of a forklift in a virtual warehouse where data's are in some places and your forklift move them from places to places. So a natural language isn't design to express this kind of semantic. In PPIG ( Psychology of Programming Interest Group ) 2006 was published a very interesting paper where is studied the metaphors which was shared by the core java library authors, the mental model said in another way. It reaveals very interesting facts : Programmers tend to think the world in term of Belief-Intention agents. Agent are members of a society who trade and own datas and are subject to legal constraints. A method calls is a speech act. The execution is mentalized as a journey in a a spatial world. Etc. There's a lot of metaphors like that, and it reveals tracks to conceive a more high level language. So there's a lot of work in this field (Behavior-Tree based language, time dimension include inside the semantics, etc.). Note that it is also possible to express non ambiguigous semantics in natural language : Attempto Controlled English is an exemple [2]. Here an toy example of what you could do with this language : "MyWebPage is a webpage. MyWebPage contains a textfield which a logical name is-named NameTextField. His label is "Name". MyWebPage contains a button which a logical name is-named SubmitButton. His label is "Submit". If User clicks on Submit and NameTextField is empty then NameTextField ' s css class becomes AlertEmptyInput. " [1] http://www.ppig.org/sites/default/files/2006-PPIG-18th-blackwell.pdf http://www.ppig.org/sites/default/files/2006-PPIG-18th-black... [2] http://attempto.ifi.uzh.ch/site/ http://attempto.ifi.uzh.ch/site/

_bxg1 8y ago

"an efficient compiler that concurrently explores all possible parses in pursuit of a semantically unambiguous interpretation." This suggests they have a solution to the ambiguity problem

cyberferret 8y ago
Thanks for the clarification. I missed that on the initial skim of the article. (And yes, I appreciate the irony of me introducing the 'ambiguity' arguments into a topic which deals specifically with the removal of such) :)
- _bxg1 8y ago
  It's still arguable that there could be some ambiguity. The compiler makes sure the statement is interpreted in an unambiguous way on the computer's end, but the writer might still not know which of a number of ways to express what she wants to state.
tzahola 8y ago
This sounds extremely dangerous. Millions of dollars are wasted each year on mistyped ==/= operators, but this is some next level evil.
- markvangulik 8y ago
  Very true. The core Avail language uses “_=_” for comparison, “_:_” to declare a variable, “_:=_” got assignment, and “_::=_” for constants (think “final”). It also has “_:_:=_” for the case when you want to declare a variable of a general type, but initialize it with something more specific (say a counter that starts at 1). But yes. There’s a lot of deeply evil things that can be done in Avail, right down to the lexical scanning. Like forbidding certain variable names, or manufacturing a run of tokens every time a certain emoji is encountered. There are also a lot of safeties, like sealing methods to prevent someone overriding “_+_” for [3’s type, 4’s type]->9’s type. Oh, and writing “x = x + 1;” as a statement will be flagged as a syntax error, because it would produce a Boolean value which is not allowed to be silently discarded like in Java or C. “Discard:_” makes these rarely needed situations absolutely obvious.

sehugg 8y ago

Inform 7 thoroughly explored this space: http://inform7.com/ http://inform7.com/

megaman22 8y ago
I've tried several times to figure out Inform 7, and I always go back to the old C-ish Inform 6 instead. I think my brain is damaged by prolonged exposure to traditional programming languages.
- royjacobs 8y ago
  I had the exact same experience. I really wanted to like Inform 7 (and plenty of people do) but it feels completely counter-intuitive because it wants to feel like natural language but it's still "just" a programming language. It still has a fairly rigid syntax - it's just more verbose than a regular programming language. That is probably an oversimplification, but that's how it felt to me at least.

curun1r 8y ago

I'm hopeful that these sorts of languages can enjoy a renaissance in the form of suggestive interfaces similar to the ones that Android/iPhone users get when typing. It'd be much easier to program in Applescript if I had an editor that was letting me choose from a list of valid words rather than me having to remember the perfect incantation to do what I want.

Retra 8y ago

>While I believe 'plain English' type programming languages are a great concept I will refute that notion and suggest that 'plain English' type languages are an incredibly foolish diversion into a world where we pretend formal languages don't exist, are unimportant, or that English is one, or that it somehow can be laboriously contorted into a useful approximation of one.

marklgr 8y ago

> I kept having to go back to the documentation to remember the best way to convert a string to all uppercase... was it: Wouldn't you have the same issue with just any programming language?

cyberferret 8y ago
Point taken. But in the above example, why does Ruby do it as 'upcase' instead of the more English-y and popular 'uppercase' as most other languages use? Take a more esoteric example - to capitalise just the first letter of a string. By definition, this is called 'proper case', and most other languages I know use .proper() to achieve this. Except Ruby, which decided to use .titleize() (and there is that 'ize' again just to confound me further). If a language is going to be 'English-y', then sticking to actual English words for things such as uppercase, proper case etc. would be handy. Going outside of those constraints just increases the guessing game workload for the programmer.
- vidarh 8y ago
  Pascal uses upcase, and so does many others, so it has a very long history. .titleize() is from ActiveSupport, not Ruby. But proper() would have confused me much more. First time I've ever heard it called that. 'proper' would sound ambiguous to me, because it doesn't indicate to me it's about case at all. But of course this just reinforces the point that naming is hard.
- irishsultan 8y ago
  Except titleize changes not the first letter of a string, but the first letter of every word. That's title case (https://en.wiktionary.org/wiki/title_case https://en.wiktionary.org/wiki/title_case). Capitalize (https://ruby-doc.org/core-2.2.0/String.html#method-i-capitalize https://ruby-doc.org/core-2.2.0/String.html#method-i-capital...) on the other hand does something even weirder from your perspective, as it also changes letters to lower case.
- 33degrees 8y ago
  The rule they’re following is that method names should be verbs, and upcase / downcase are shorter than alternatives like to_upper etc. So while it’s an unusual choice it’s not an arbitrary one

swoorup 8y ago

Perhaps lojban would have been a better choice.

tzahola 8y ago

Exactly my thoughts whenever I have to touch AppleScript.

klibertp 8y ago

> I kept having to go back to the documentation to remember 1. Why would you want to remember this? It's in the docs. If you use it often, you'll learn it eventually. If you don't, you have no need to remember this. Don't burden your memory unnecessarily. 2. A well written and searchable documentation adds very little overhead anyway, on the order of a few seconds. Yeah, writing from memory is faster, but not by that much, and that advantage disappears almost completely if you have good auto-completion and docs support in your editor. 3. There are hundreds of languages out there, even if you learn the library of one language, it doesn't help with other languages at all. Learning to quickly search reference docs, along with learning some basic concepts/assumptions of each language, is much more sustainable if you're thinking of becoming polyglot. EDIT: please, don't turn HN into Reddit, write a comment if you disagree, instead of downvoting.

cyberferret 8y ago
I agree with you in principle. Over the past 4 decades, I have programmed in dozens of programming languages, and remembering things like FOR or CASE loop structures is almost impossible for me now, and I constantly refer to docs. However, as a starting point for me, it would be easier if the languages all used a common naming convention for things like .upper() etc. Common mistake for me is to try .upper(), then .uppercase(), then have to leave my code and refer to the docs after repeated runtime errors. If I can make a reasonably intelligent guess within 2 or 3 tries, then it bodes well for me. Otherwise it is a productivity hit. To extrapolate this - the corollary to .upcase() is, to my mind .lowercase(), but it is in fact .downcase(). Makes sense logically ('down' is the opposite of 'up'), but syntax wise, I never say to anyone "You need to write your username in down case...". If the naming conventions for functions followed the English language definitions, then my hit/miss ration will improve, and so will my productivity. NB: I didn't downvote you (I can't anyway as I don't have the necessary karma to downvote immediate child answers to my posts). I thought you raised a valid point worthy of discussion.
- klibertp 8y ago
  > it would be easier if the languages all used a common naming convention for things like .upper() etc. Well, it would definitely be easier if all the languages used the same conventions. The problem here, I think, is that all the possible conventions are arbitrary and objectively as good as any other, so there are many of them and settling on a single one across languages is not going to happen. It's much more important to choose one convention for a language and to follow it everywhere - this improves guessability of identifiers in that language. The convention chosen may be familiar to you or not, but that doesn't mean the more familiar one is any better. So, I think, it's more important for a language to follow a single convention consistently, while choosing which convention to follow is less important. That being said, I agree that it would be easier to learn new languages if they all followed a single standard for naming things, I just don't think it's going to happen. > If I can make a reasonably intelligent guess within 2 or 3 tries, then it bodes well for me. Otherwise it is a productivity hit. Agreed, but note that the 2-3 tries are informed by your experiences to date - someone with a different history of programming languages could find your guesses weird and would have completely different ones themselves. Another thing, I agree on the productivity hit in principle, just want to note that there are ways of mitigating it. I use many languages regularly (I'm a hobbyist-polyglot, I learned at least 30-40 languages to varying degrees) and I think that a good editor integration (most notably "semantic auto-complete" and "inline docs") can make up for a lot of cases like the `upcase`. For example, if I write this (`|` is cursor position): a = "asd" a.up| and hit <tab>, I get a popup with the suggestion of a correct name (`upper`) along with a bit of documentation. The level of support for this obviously varies a lot across languages, but where it's available I find it mostly fixes the problem of having to hit the docs too often. > NB: I didn't downvote you It's impossible to downvote immediate child posts, no matter the karma level, so it obviously couldn't be you :)

pure-awesome 8y ago

Thing is, Avail actually is not a 'plain English' type programming language. The website states things very confusingly. But look at the FAQ: http://www.availlang.org/about-avail/documentation/faq.html http://www.availlang.org/about-avail/documentation/faq.html Commenter dcw303 in this thread puts it better than I can.