Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0

    Natural Language Programming


    It says this is the place for "some friendly debate," so let's get to it.

    Having programmed for many years in many languages, I often find myself thinking in a kind of
    natural language pseudo-code, then translating it into whatever I'm working with at that time. So
    one day I thought, Why not simply code at a natural language level and skip the translation step?
    I talked it over with my elder son, also a programmer, and we decided to test the theory.
    Specifically, we wanted to know:

    1. Is it easier to program when you don’t have to translate your natural-language thoughts into an
    alternate syntax?

    2. Can natural languages be parsed in a relatively “sloppy” manner (as humans apparently parse
    them) and still provide a stable enough environment for productive programming?

    3. Can low-level programs (like compilers) be conveniently and efficiently written in high level
    languages (like English)?

    And so we set about developing a "plain english" compiler in the interest of answering those
    questions. And we are happy to report that we can now answer each of those three questions,
    from direct experience, with a resounding “Yes!” Here are some details:

    Our parser operates, we think, something like the parsing centers in the human brain. Consider, for
    example, a father saying to his baby son:

    “Want to suck on this bottle, little guy?”

    And the kid hears,

    “blah, blah, SUCK, blah, blah, BOTTLE, blah, blah.”

    But he properly responds because he’s got a “picture” of a bottle in the right side of his head
    connected to the word “bottle” on the left side, and a pre-existing “skill” near the back of his neck
    connected to the term “suck”. In other words, the kid matches what he can with the pictures
    (types) and skills (routines) he’s accumulated, and simply disregards the rest. Our compiler does
    very much the same thing, with new pictures (types) and skills (routines) being defined -- not by
    us, but -- by the programmer, as he writes new application code. The vocabulary and grammar of Plain English thus grows, for each individual programmer, simply as he uses it. We might say, "It learns the 'local dialect' just by hearing it."

    A typical type definition looks like this:

    A polygon is a thing with some vertices.

    Internally, the name “polygon” is now associated with a dynamically-allocated structure
    that contains a doubly-linked list of vertices. “Vertex” is defined elsewhere (before or after this definition) in a similar fashion; the plural is automatically understood.

    A typical routine looks like this:

    To append an x coord and a y coord to a polygon:
    Create a vertex given the x and the y.
    Append the vertex to the polygon’s vertices.


    Note that formal names (proper nouns) are not required for parameters and variables. This, we
    believe, is a major insight. My real-world chair and table are never (in normal conversation) called
    “c” or “myTable” -- I refer to them simply as “the chair” and “the table”. Likewise here: “the
    vertex” and “the polygon” are the natural names for such things.

    Note also that spaces are allowed in routine and variable “names” (like “x coord”). This is the 21st
    century, yes? And that “nicknames” are also allowed (such as “x” for “x coord”). And that
    possessives (“polygon’s vertices”) are used in a very natural way to reference “fields” within
    “records”.

    Note, as well, that the word “given” could have been “using” or “with” or any other equivalent
    since our sloppy parsing focuses on the pictures (types) and skills (routines) needed for
    understanding, and ignores, as much as possible, the rest.

    At the lowest level, things look like this:

    To add a number to another number:
    Intel $8B85080000008B008B9D0C0000000103.


    Note that in this case we have both the highest and lowest of languages -- English and machine
    code (in hexadecimal) -- in a single routine. The insight here is that (like a typical math book) a
    program should be written primarily in a natural language, with appropriate snippets in more
    convenient syntaxes as (and only as) required. We hope someday soon to extend the technology to include Plain Spanish, and Plain French, and
    Plain German, etc.

    Anyway, if you're interested, you can download the whole shebang here:

    osmosian.com/cal-4700.zip

    It’s a small Windows program, less than a megabyte in size. No installation necessary; just unzip and execute.
    But it's a complete development environment, including a unique interface, a simplified file
    manager, an elegant text editor, a handy hexadecimal dumper, a native-code-generating
    compiler/linker, and even a wysiwyg page layout facility (that we used to produce the
    documentation). If you start with the "instructions.pdf" in the “documentation” directory, before
    you go ten pages you won't just be writing "Hello, World!" to the screen: you’ll be re-compiling the
    whole thing in itself (in less than four seconds on a bottom-of-the-line machine from
    Walmart).

    Take a look. Then let us know what you think here on the forum.

    Thanks,

    Gerry Rzeppa
    Grand Negus of the Osmosian Order of Plain English Programmers

    Dan Rzeppa
    Prime Assembler of the Osmosian Order of Plain English Programmers

    Chuckles Rzeppa
    Precocious Padawan of the Osmosian Order of Plain English Programmers
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2015
    Posts
    50
    Rep Power
    2
    Is it easier to program when you don’t have to translate your natural-language thoughts into an alternate syntax?
    Probably not. Is it easier to type when the keyboard is QWERTY over DVORAK? Would be interested in the data on this.

    Update: studies say no/

    Can natural languages be parsed in a relatively “sloppy” manner (as humans apparently parse them) and still provide a stable enough environment for productive programming?
    I don't understand the question. Are you asking whether human languages can be parsed by computers in a way that allows them to be translated into deterministic programs? Answer: no.

    If you want proof, consider how many ways "cool" or "set" can be used.

    Or how the decision to teach AAVE along side SAE provoked a moral outrage. Should a compiler reject double negatives? Or habitual bes?

    Can low-level programs (like compilers) be conveniently and efficiently written in high level languages (like English)?
    Human languages resolve disambiguation via context, culture, class, bias, etc (see above, cool cat (which is not cold feline)). Consider how much work goes into finding the best way to pronounce things.

    You're focusing a lot on syntax parsing, but ignoring how we deriving meaning from sounds and symbols. I can make up words in a sentence and the listeners can derive meaning from many arbitrary things. Can a computer do this?

    To append an x coord and a y coord to a polygon:
    Create a vertex given the x and the y.
    Append the vertex to the polygon’s vertices.
    To bleeblah a sandwich:
    Get Turkey and manaise
    Append meet to the sauce

    Makes sense to us, even if it is weird.
    Last edited by oakleaf; February 20th, 2017 at 06:45 PM.
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by oakleaf
    Probably not. Is it easier to type when the keyboard is QWERTY over DVORAK?
    Depends on what you know. "User friendly is what the user is used to."

    Originally Posted by oakleaf
    Would be interested in the data on this.
    I'm not sure what "this" refers to: QWERTY vs DVORAK or programming in artificial vs natural syntax. Our first-hand experiences with both kinds of programming have led us to prefer natural-language programming.

    Originally Posted by oakleaf
    I don't understand the question. Are you asking whether human languages can be parsed by computers in a way that allows them to be translated into deterministic programs? Answer: no.
    We were asking, when we first started writing our compiler, how exacting we would need to be in our parsing in order to produce a reliable compiler. Turns out, not so much.

    Originally Posted by oakleaf
    If you want proof, consider how many ways "cool" or "set" can be used.
    Indeed. We use those words in lots of ways when we program.

    Originally Posted by oakleaf
    Or how the decision to teach AAVE along side SAE provoked a moral outrage.
    If you want to program in Ebonics, our compiler is ready and waiting. Most of the vocabulary and grammar of Plain English is determined, not by the compiler itself, but by the programmer who is using it in his TYPE, VARIABLE and ROUTINE definitions.

    Originally Posted by oakleaf
    Should a compiler reject double negatives? Or habitual bes?
    A compiler should interpret things, as much as possible, as the programmer expects it to.

    Originally Posted by oakleaf
    Human languages resolve disambiguation via context, culture, class, etc (see above, cool cat (which is not cold feline)).
    We consider an imperative sentence understood when it is matched to an appropriate routine. The matching process takes into account the immediate context (which libraries the programmer has included in his project directory), and the culture, class, etc, of the programmer (and the others who coded up those libraries). As I mentioned above, most of the vocabulary and grammar of Plain English is defined, not by the compiler itself, but in the types, variables, and routines that the user has defined. See below for an example.

    Originally Posted by oakleaf
    Consider how much work goes into finding the best way to pronounce things.
    Yeah. Our compiler pronounces things the way the built-in text-to-speech routines in Windows decide.

    Originally Posted by oakleaf
    You're focusing a lot on syntax parsing, but ignoring how we deriving meaning from sounds and symbols.
    Again, "meaning" or "understanding" for us simply means proper execution. So when an imperative sentence is matched with a routine that does what the programmer intended, that, to us, means the sentence was understood.

    Originally Posted by oakleaf
    I can make up words in a sentence and the listeners can derive meaning from many arbitrary things. Can a computer do this?

    To bleeblah a sandwich:
    Get Turkey and manaise
    Append meet to the sauce

    Makes sense to us, even if it is weird.
    Here's some Plain English code to deal with that situation. First a (partial) type definition:

    A sandwich is a thing with...

    Then a (partial) global variable definition:

    The sauce is a thing with...

    And finally, some routine headers (with comments indicating where the "meaning" of those prototype sentences is described by the programmer):

    To bleeblah a sandwich:
    \ imperative and conditional sentences describing exactly how to do that go here

    To get Turkey and manaise:
    \ imperative and conditional sentences describing exactly how to do that go here

    To append meat to the sauce;
    To append meet to the sauce:
    \ imperative and conditional sentences describing exactly how to do that go here

    Note the multiple headers for the latter routine (allowing "meat" to be spelled either way). Get the idea? The compiler "understands" what you've explained to it, using YOUR vocabulary and YOUR grammar. And once you get to know each other, it's like talking to an old friend.
    Last edited by Gerry Rzeppa; February 22nd, 2017 at 06:51 PM. Reason: minor formatting changes
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2006
    Posts
    2,616
    Rep Power
    1766
    I have to admire you for giving this a try, but for me, personally, it's not going to work! Not just as I spent 30 or so years in IT working with a wide variety of languages already (though there is a part of that - yay for COBOL, etc., boo for Java!). I have come across natural language compilers before in the form of one called Inform (version 7) and apart from the fact that it is a language I found nothing natural about it; there was nearly always sentence constructions that are stilted and awkward and non obvious. The 'basics' such as the "The X is a thing" style approach is actually one I quite like. For most of my 50-plus years I have been an avid reader of almost anything and that is where my main 'complaints' hail from; my love of the language means that almost anything beyond a linear progression in the program (meaning conditionals and loops) things can, and do, get 'messy'. Apologies for all the quotes, I am trying to emphasise that it is ME who, for example, has found conditional coding to be messy and others may not.
    To be honest it probably does not matter what the language looks like so long as it does the job and that whoever is using it (developing and debugging) finds it intuitive - I am sure there is someone out there who likes coding in Java and perl ...
    The moon on the one hand, the dawn on the other:
    The moon is my sister, the dawn is my brother.
    The moon on my left and the dawn on my right.
    My brother, good morning: my sister, good night.
    -- Hilaire Belloc
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by SimonJM
    I have to admire you for giving this a try, but for me, personally, it's not going to work! Not just as I spent 30 or so years in IT working with a wide variety of languages already (though there is a part of that - yay for COBOL, etc., boo for Java!).
    It seems that programming in a natural language has to be a re-acquired taste, especially for those who know other programming languages.

    One of our users wrote us (note the PS): "An astonishing work, genius! I was looking for something like this for many years. Congratulations! Keep it up. PS: Now I have to 'deprogram' my thinking when writing code. I'll have to relearn how to think normally!"

    Originally Posted by SimonJM
    I have come across natural language compilers before in the form of one called Inform (version 7) and apart from the fact that it is a language I found nothing natural about it; there was nearly always sentence constructions that are stilted and awkward and non obvious. The 'basics' such as the "The X is a thing" style approach is actually one I quite like.
    I'm familiar with Inform, which is a remarkable product, but our approach is nothing like that. We let the programmer himself develop the vocabulary and grammar of the thing, just by coding. For example, once he says something like,

    A banana is a thing with...

    He can then talk about doing things with bananas, like so:

    To peel a banana:
    \ description of how to do that goes here

    To eat a banana;
    To devour a banana;
    To consume a banana:
    \ description of how to do that goes here


    Note that alternative wordings are not only allowed, but encouraged in each routine header.
    Our compiler thus "learns the local dialect" and "learns to think as you do" as you write more code.
    After a while, you can just type what you're thinking, and it works.

    Originally Posted by SimonJM
    For most of my 50-plus years I have been an avid reader of almost anything and that is where my main 'complaints' hail from; my love of the language means that almost anything beyond a linear progression in the program (meaning conditionals and loops) things can, and do, get 'messy'. Apologies for all the quotes, I am trying to emphasise that it is ME who, for example, has found conditional coding to be messy and others may not.
    Conditionals and loops don't get messy in Plain English because we don't allow nesting of either.
    We deal with conditionals like ordinary people do in real life, specifically (1) eliminate exceptions, (2) do the usual stuff. Here's a comparison for you: first, nested pseudocode, then in Plain English:

    Code:
    To capitalize any selected rows in a text:
    If the text is not nil then
            Loop.
                    Get a row from the text's rows.
                    If the row is not nil then
                                 If the row of the text is selected then
                                             If the row is not blank then
                                                        Capitalize the row's string.
                                             end
                                 end
                    end
             repeat until we run out of rows.
    end
    To capitalize any selected rows in a text:
    If the text is nil, exit. \ exception
    Loop.
    Get a row from the text's rows.
    If the row is nil, exit. \ exception
    If the row of the text is not selected, repeat. \ exception
    If the row is blank, repeat.\ exception
    Capitalize the row's string. \ usual
    Repeat.


    Originally Posted by SimonJM
    To be honest it probably does not matter what the language looks like so long as it does the job and that whoever is using it (developing and debugging) finds it intuitive - I am sure there is someone out there who likes coding in Java and perl ...
    "User friendly is what the user is used to." Our aim, on the other hand, is to try to discover how people ordinary people would naturally code if they didn't need to learn how.

    Thanks for writing.
    Last edited by Gerry Rzeppa; February 22nd, 2017 at 06:51 PM. Reason: topic focus
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2006
    Posts
    2,616
    Rep Power
    1766
    I agree that it will/would take a degree of reprogramming the programmer to go to start using a different style of language. I'm probably just too stuck in the mud to want to have to perform the adjustment, especially as I still tinker in 'ordinary' languages.
    There is one caveat I have though, as you say the developer builds the syntax and grammar as they go along, to suit their own needs. That would potentially making debugging and maintaining the code by anyone else a real nightmare, or worse still done incorrectly with invalid assumptions about the underlying grammar! It's still a great piece of work, though I do have doubts about the inability to nest things, especially loops. Non-nested conditionals is not so bad, but 'stylistically' I am not a fan of the 'if not, then stop' method.
    The moon on the one hand, the dawn on the other:
    The moon is my sister, the dawn is my brother.
    The moon on my left and the dawn on my right.
    My brother, good morning: my sister, good night.
    -- Hilaire Belloc
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by SimonJM
    I agree that it will/would take a degree of reprogramming the programmer to go to start using a different style of language. I'm probably just too stuck in the mud to want to have to perform the adjustment, especially as I still tinker in 'ordinary' languages.
    "Ordinary" programming languages are anything but ordinary. They all betray their artificial and mathematical roots and assume, we believe incorrectly, that most of the things most programs do are mathematical in nature, and that a mathematical-like syntax is therefore appropriate. On the other hand, we're convinced that most of the things that most programs do are simple things like "move this over there" and "draw that on the screen" -- things that can be conveniently expressed in a natural language.

    Let's consider an example we can examine in detail. Our compiler, a sophisticated Plain-English-to-Executable-Machine-Code translator, has 3,050 Plain English sentences in it.

    1,306 of those (about 42%) are conditional statements, and at least half of those are trivial things like these:

    If the item is not found, break.
    If the compiler's abort flag is set, exit.


    The remainder of those conditional statements are slightly more complex, but all of them fit on a single line. Here are a couple of the longer ones:

    If the length is 4, attach $FF32 to the fragment's code; exit.
    If the rider's token is any numeric literal, compile the literal given the rider; exit.


    Of the remaining sentences:

    272 (about 9%) are simple assignment statements:

    Put the type name into the field's type name.

    202 (about 7%) are just the infrastructure for various loops:

    Loop.
    Get a field from the type's fields.
    [ other stuff here]
    Repeat.


    183 (6%) simply add something to the end of this or that list, like so:

    Add the field to the type's fields.

    164 (about 5%) are trivial statements used to return boolean results, start and stop various timers, show the program's current status, and write interesting things to the compiler's output listing.

    Say no.
    Say yes.
    Set the variable's compiled flag.
    Start the compiler's timer.
    Stop the compiler's timer.
    Show status "Compiling...".
    List the globals in the compiler's listing.


    119 (about 4%) advance the focus in the source code, sentences like:

    Bump the rider.
    Move the rider (code rules).


    92 (about 3%) are used to create, destroy and keep internal indexes up to date, sentences like:

    Create the type index using 7919 for the bucket count.
    Index the type given the type's name.
    Destroy the type index.


    58 (about 2%) are used to find things in various lists:

    Find a variable given the name.

    37 (about 1%) are calls to various conversion routines:

    Convert the rider's token to a ratio.

    31 (about 1%) are used to generate actual machine code (plus those that appear in conditional statements, as above):

    Attach $E8 and the address to the fragment.

    And that accounts for 80% of the code in our compiler.

    Only 57 of the remaining sentences (less than 2% of the whole) are mathematical in nature, a line here and there like these:

    Add 4 to the routine's parameter size.
    Subtract the length from the local's offset.
    Multiply the type's scale by the base type's scale.
    Calculate the length of the field's type.
    Round the address up to the nearest multiple of 4096.


    And the rest are not formulaic at all. Stuff like:

    Copy the field into another field.
    Append the fragment to the current routine's fragments.
    Abort with "I was hoping for a definition but all I found was '" then the token.
    Initialize the compiler.
    Remove any trailing backslashes from the path name.
    Reduce the monikette's type to a type for utility use.
    Eliminate duplicate nicknames from the type's fields.
    Prepend "original " to the term's name.
    Extend the name with the rider's token.
    Unquote the other string.
    Read the source file's path into the source file's buffer.
    Generate the literal's name.
    Extract a file name from the compiler's abort path.
    Write the compiler's exe to the compiler's exe path.
    Swap the monikettes with the other monikettes.
    Skip any leading noise in the substring.
    Scrub the utility index.
    Fill the compiler's exe with the null byte given the compiler's exe size.
    Position the rider's token on the rider's source.
    Pluralize the type's plural name.
    Link.
    Finalize the compiler.
    Check for invalid optional info on the type.


    And that's why we say that most of what most programs do is easy stuff, stuff that can be conveniently and unambiguously expressed in a natural language, without nesting. And that, in turn, is why we like programming in Plain English: the thoughts in our heads are typed in as Plain English "pseudo code" and, with a tweak here and there, that pseudo code actually compiles and runs. And is self-documenting, to boot.
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by SimonJM
    There is one caveat I have though, as you say the developer builds the syntax and grammar as they go along, to suit their own needs. That would potentially making debugging and maintaining the code by anyone else a real nightmare, or worse still done incorrectly with invalid assumptions about the underlying grammar!
    It's not really that different from what is normally done. For example, here's a little helper function I once wrote in JavaScript:

    function removeLeadingSpaces(s) { if (!s) return ""; for (pos=0; pos < s.length && s[pos]==" "; pos++); return s.substring(pos) }

    And here's the equivalent in Plain English:

    To remove any leading spaces from a string:
    If the string is blank, exit.
    If the string does not begin with the space byte, exit.
    Remove the first byte from the string.
    Repeat.


    Now in both cases, the "vocabulary" and "grammar" of the respective language has been extended. The JavaScript programmer can now say things like:

    removeLeadingSpaces(myTitleString);

    And the Plain English programmer can likewise say things like:

    Remove any leading spaces from the title.

    Personally, I think both the call and the called routine would be easier to debug in the Plain English form.

    Originally Posted by SimonJM
    It's still a great piece of work, though I do have doubts about the inability to nest things, especially loops. Non-nested conditionals is not so bad, but 'stylistically' I am not a fan of the 'if not, then stop' method.
    Well, if you're used to nesting things,
        if you're not a fan of eliminating exceptions simply,
            if you're not inclined to eliminate exceptions early,
                if you prefer to have your "normal" processing buried inside several levels of conditionals,
                     if you've said as much on this very forum,
                          there's not much I can say in response
                     otherwise
                          there's nothing for me to respond to.

    Is that clear?
    Last edited by Gerry Rzeppa; February 23rd, 2017 at 08:26 AM.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2006
    Posts
    2,616
    Rep Power
    1766
    Nested conditionals have, in my view, a useful purpose, but we all see things differently. Nesting for nesting's sake I do not agree with, but there are times when (I feel) it is needed. One problem I have is dealing with all the 'noise words' that natural language coding introduces as, to me, they just make things harder to follow: I find "if x = y" easier to understand than "if the value of is the same as y" as I don't have to spend additional time parsing the language to get to the meaning. It may be just how my brain works (with it's training over the years?) but I do what your language does automatically in my mind as I read and write code, so you are, for me, adding another layer of complexity to the system - instead of thinking of what I want, writing source, submitting to the great compiler in the sky and getting machine code I would need to thing of what I want, mentally push that through a 'pre-compiler' to get the needed syntax/grammar, write the code, submit to the great compiler, get machine code. And, of course, the inverse (less the machine code/compiler stage): I'd need to pre-process the code to work out what it is trying to do so I could put it in terms that I would understand!
    The moon on the one hand, the dawn on the other:
    The moon is my sister, the dawn is my brother.
    The moon on my left and the dawn on my right.
    My brother, good morning: my sister, good night.
    -- Hilaire Belloc
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by SimonJM
    Nested conditionals have, in my view, a useful purpose, but we all see things differently. Nesting for nesting's sake I do not agree with, but there are times when (I feel) it is needed.
    An example would be helpful. Have you got one?

    Originally Posted by SimonJM
    One problem I have is dealing with all the 'noise words' that natural language coding introduces as, to me, they just make things harder to follow: I find "if x = y" easier to understand than "if the value of is the same as y" as I don't have to spend additional time parsing the language to get to the meaning.
    You're imagining something other than Plain English.  "if the value of x is the same as y" is not something you'd say in Plain English.

    First of all, you wouldn't have artificial names (that need to be translated in your head); rather, you'd have real-world names consisting of an article and a type name. In everyday life, for example, I don't call the thing I'm sitting at "t", I call it "the table".

    So let's compare apples to apples. Let's say x is the width of a box, and y is the height, and we need a conditional statement to determine if our box is square or not. So you say,

    If x = y ...

    and have to remember that "x" means "the width" and that "y" means the height, and that "=" means equal and not assignment. While we say:

    If the width equals the height ...

    which is exactly what we were trying to say.

    Originally Posted by SimonJM
    It may be just how my brain works (with it's training over the years?)...
    No doubt. Almost all programmers have been trained in extraordinary and unnatural modes of thought. Part of our research is finding out what ordinary people naturally think so they can write that when they're programming.

    Originally Posted by SimonJM
    ...but I do what your language does automatically in my mind as I read and write code, so you are, for me, adding another layer of complexity to the system...
    We're not adding a layer, we're removing the "translation" layer that's taking place in your mind (both when you write and when you read).

    Originally Posted by SimonJM
    ...instead of thinking of what I want, writing source...
    More accurately, "Instead of thinking of what [you] want (in your native tongue), then translating it into some arbitrary and artificial syntax, then writing the encoded version down as source..."

    Originally Posted by SimonJM
    I'd need to pre-process the code to work out what it is trying to do so I could put it in terms that I would understand!
    Nonsense! By the time you write, "If x = y", you've already "worked out what it is trying to do", or you wouldn't be writing it down; you've already thought, "x is the width, y is the height, if the width equals the height then it's a square." It seems you've gotten so good at the translation step that you don't notice it's there anymore.
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2006
    Posts
    2,616
    Rep Power
    1766
    Being sensible I'd use proper variable names, I was using x and y as simple examples, so I'd use if width = height, bu that is just semantics, and yes, to me that is a lot simpler to deal with than if the width equals the height. All I have to do is parse 4 items, all critical - 'if': we are doing a test; 'width': involving the width; '=': the condition being equality; 'height': and we are testing against height. To me the adding of the two occurrences of the 'noise word' "the" makes that line less obvious and requiring not just longer to read and process, but reading, at least, twice.

    To try and give an example of the use of nested conditions ... I cannot lay my hands on one directly (I no longer work so no easy access to my old COBOL, ADS, Clist, Rexx, etc., source code ..!), but I have needed to construct code equivalent to the following:
    Code:
    If a  = b
      do A
      if c < d
        do B
      elseif c = d
         do C
      else
        do D
      endif
    else
      do E
    endif
    The moon on the one hand, the dawn on the other:
    The moon is my sister, the dawn is my brother.
    The moon on my left and the dawn on my right.
    My brother, good morning: my sister, good night.
    -- Hilaire Belloc
  22. #12
  23. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by SimonJM
    Being sensible I'd use proper variable names, I was using x and y as simple examples, so I'd use if width = height, but that is just semantics, and yes, to me that is a lot simpler to deal with than if the width equals the height. All I have to do is parse 4 items, all critical - 'if': we are doing a test; 'width': involving the width; '=': the condition being equality; 'height': and we are testing against height. To me the adding of the two occurrences of the 'noise word' "the" makes that line less obvious and requiring not just longer to read and process, but reading, at least, twice.
    Ah, but you have to be familiar and practiced in two different kinds of reading (and writing and thinking) to do things your way.

    Let's consider a couple of other examples, thinking about both reading and writing. First, a typical call in a typical programming language:

    substring.draw ( box, color, source.text.font, source.text.alignment ) ;

    Which is 10 words and 11 punctuation marks: 21 total elements.

    Then the Plain English version:

    Draw the substring in the box with the color and the source's text's font and alignment.

    Which is 16 words and 3 punctuation marks: 19 total elements.

    Admittedly, the Plain English version requires a few more easy-to-type alphabetic characters, but that's a small price to pay for not having to learn (or think in) an artificial syntax.

    Another example:

    if ( ! source.colorized ( ) ) color = black ;

    Which is 5 words and 8 punctuation marks: 13 total elements.

    Compared with the Plain English, which is:

    If the source is not colorized, put black into the color.

    Which is 11 words and 2 punctuation marks: 13 total elements.

    Seems to me it's mostly a matter of whether you like to type words or punctuation. And whether or not you think "( ! source.colorized ( ) )" is a reasonable way to say anything! And whether you like to think in two different syntactical and grammatical forms simultaneously. And whether you want your code to be self-documenting. And whether you want code that's friendly for beginners. And whether you want to code in a language (like English) that will still be in common use 100 years from now.

    Originally Posted by SimonJM
    To try and give an example of the use of nested conditions ... I cannot lay my hands on one directly (I no longer work so no easy access to my old COBOL, ADS, Clist, Rexx, etc., source code ..!), but I have needed to construct code equivalent to the following:
    Code:
    If a  = b
      do A
      if c < d
        do B
      elseif c = d
         do C
      else
        do D
      endif
    else
      do E
    endif
    Can't help you there; it's a ridiculous hypothetical. I need some real names to work with. Please try again.
    Last edited by Gerry Rzeppa; February 23rd, 2017 at 09:33 PM.
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2006
    Posts
    2,616
    Rep Power
    1766
    Originally Posted by Gerry Rzeppa
    Draw the substring in the box with the color and the source's text's font and alignment.
    And that, there is one reason that I do not do well with these languages - 'with the color', colour of what? I don't want to have to read the next bits to find out it may be linked to a source's font. To me, and I will stress again, this is all for me; my opinion, etc., that is not natural language.

    Can't help you there; it's a ridiculous hypothetical. I need some real names to work with. Please try again.
    Sorry you can't deal with a simple hypothetical example.
    Let's try again ...
    Code:
    if current_level > alert_red
      set icon = red
      if device_name matches "%disk%"
        if logical_path matches "/dev/dsk/md%"
          set mail_subject = "RAID array"
        else
          set mail_subject = "JBOD device"
        endif
      elseif device_name matches "%network%"
        if top_octet = 192
          set mail_subject = "Internal network"
        else
          set mail_subject = "External network"
        endif
      endif
    elseif current_level > alert_amber
      set icon = amber
    else
      set icon = green
    endif
    The moon on the one hand, the dawn on the other:
    The moon is my sister, the dawn is my brother.
    The moon on my left and the dawn on my right.
    My brother, good morning: my sister, good night.
    -- Hilaire Belloc
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2017
    Posts
    19
    Rep Power
    0
    Originally Posted by SimonJM
    And that, there is one reason that I do not do well with these languages - 'with the color', colour of what? I don't want to have to read the next bits to find out it may be linked to a source's font. To me, and I will stress again, this is all for me; my opinion, etc.
    I don't think you're being fair. You didn't complain about the "color" variable in the "traditional" code:

    substring.draw ( box, color, source.text.font, source.text.alignment ) ;

    "The color", in both cases, is taken from the context, most likely a parameter or a local variable.

    Originally Posted by SimonJM
    that is not natural language.
    Draw the substring in the box with the color and the source's text's font and alignment.

    Sure it is. Run it through a spell checker. Or a grammar checker. It's English. 

    Originally Posted by SimonJM
    Sorry you can't deal with a simple hypothetical example.
    Let's try again ...
    Code:
    if current_level > alert_red
      set icon = red
      if device_name matches "%disk%"
        if logical_path matches "/dev/dsk/md%"
          set mail_subject = "RAID array"
        else
          set mail_subject = "JBOD device"
        endif
      elseif device_name matches "%network%"
        if top_octet = 192
          set mail_subject = "Internal network"
        else
          set mail_subject = "External network"
        endif
      endif
    elseif current_level > alert_amber
      set icon = amber
    else
      set icon = green
    endif
    Wow. Do you really consider that "good" code? I found it very difficult to decipher. Here's how I would code that in Plain English (no "deciphering" necessary, because it's not written as a cipher):

    [unspecified routine]
    If the current level is greater than the red level, put the red icon into the icon; handle red alert; exit.
    If the current level is greater than the amber level, put the amber icon into the icon; exit.
    Put the green icon into the icon.
    [end of unspecified routine]

    To handle red alert:
    If the device name matches "%disk%", handle red alert (disk); exit.
    If the device name matches "%network%", handle red alert (network).

    To handle red alert (disk):
    If the logical path matches "/dev/dsk/md%", put "RAID array" into the mail subject; exit.
    Put "JBOD device" into the mail subject.

    To handle red alert (network):
    If the top octet equals 192, put "Internal network" into the mail subject; exit.
    put "External network" into the mail subject.


    I'm pretty sure most people would find the Plain English solution much easier to read and to modify, extend or debug. The Plain English solution has only 12 lines (compared to your original 20) and requires no indenting or special formatting for clarity. It's a matter of properly factoring code. As much as possible, routines should be small, single-purpose, and independent of one another, with each routine name clearly specifying its purpose. By disallowing ELSEs and ELSEIFs and plain old nested IFs, Plain English forces the programmer to properly fact his code.
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2006
    Posts
    2,616
    Rep Power
    1766
    Yeah, just gonna have to agree to disagree on this, so stepping out of the discussion. So-called natural language code gives me the heebie-jeebies. We agree on some things such as the purpose and use of routines, at least! Good luck with it's development, I'll just trundle along with my 30+ years of programming experience and try to manage with indenting!
    The moon on the one hand, the dawn on the other:
    The moon is my sister, the dawn is my brother.
    The moon on my left and the dawn on my right.
    My brother, good morning: my sister, good night.
    -- Hilaire Belloc
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo