Index
> Programming Language Design > Plain English ProgrammingGoto page Previous 1, 2, 3, 4, 5 Next |
| Author |
|
|
AsmGuru62 12 Apr 2015, 13:19
I agree with randall.
|
|||
12 Apr 2015, 13:19 |
|
|
HaHaAnonymous 12 Apr 2015, 14:43
Quote:
:O OK, but in case of algorithms I think I will find the "Plain English" form easier to understand what is being done, and faster. Not yet tested! D: Another plus, is that "Plain English" encourages to write more readable code... Not sure. |
|||
|
12 Apr 2015, 14:43 |
|
|
Mike Gonta 12 Apr 2015, 15:14
Gerry Rzeppa wrote: (a) that some of your own Plain English SudoCode IFs span more than one line, Quote: (b) that it is impossible on GitHub to insure that every documented topic will fit exactly on a single printed page, Quote: and (c) that producing output that requires a post-compiler is contrary to the "stand alone" and "minimalist" I'm more interested in making a small toy OS written in Plain English called simpleOS. I'll be using my aeBIOS – a 32bit protected mode BIOS extender (which I'll be renaming "simpleBIOS" to take care of the hardware interface. I've been working on a low level FAT32 driver. I'll be integrating some of the MikeOS32 kernel (re-written in Plain English) for the OS services. I'll start by modifying the compiler ever so slightly to output a flat binary file (a Plain English cross compiler). The typical hobby OS has a kernel which is loaded at 1Meg by the boot sector with a jump table for the OS services at the beginning. The cross compiler will allow the load address to be specified (applications are loaded by the kernel at 4 Meg for example) and a jump table will be blurted first for the kernel file. To simplify the application loading the "~initialize before run and run and finalize after run" routine will be blurted first for the applications. |
|||
|
12 Apr 2015, 15:14 |
|
|
Gerry Rzeppa 12 Apr 2015, 16:41
Mike Gonta wrote: What difference would it make if one or one thousand people distributed bastard versions? The analogy isn't perfect, but in my mind, it's the difference between (a) giving an extra shovel I've got in the garage to a neighbor when he asks, and (b) letting anyone in the neighborhood come into my garage anytime they want and take any extra shovels they happen to see. In the former case, there's a normal interpersonal relationship between the parties: one asks, one gives, and there's an implied understanding that the shovel will be used as intended and not to hit someone over the head, etc. The latter case strikes me not only as impersonal, but chaotic. Mike Gonta wrote: How can you prevent others from modifying my modified version? I can't. If you want to let the whole neighborhood rummage around in your garage for extra shovels, that's your choice. I'm hoping, of course, that the way you and I have dealt with each other will have had a deeper effect -- by osmosis, as it were. But it's your choice. Mike Gonta wrote: You may wish to consider retracting your permission (which I of course will be morally obligated to comply with). No need. I'm trusting you, Mike. I'm betting you're the kind of person who will use the thing wisely and creatively. And I'm all in favor of you passing it on to others who will use it wisely and creatively as well. Go for it! |
|||
|
12 Apr 2015, 16:41 |
|
|
Gerry Rzeppa 12 Apr 2015, 17:22
randall wrote: I don't understand how for example: It's clearer to the average person, the ordinary "man on the street" (ie, the vast majority of people on the planet). See for yourself. Go down to Walmart and ask the first ten people who come out what "number += 1" means. Then ask them what "Add 1 to a number" means. randall wrote: For me, reading Plain English code is much harder than reading C code But only because you know how to read C code. What about the billions of ordinary people who don't know (and don't want to know) how to read C code? Or people like me, who can read C code, but would rather say, "Clear the screen" than something like "system("cls");". randall wrote: Plain English is to verbose for me, sentences are to long. Mathematical formulas will of course be shorter in standard mathematical notation (which was specifically designed for brevity) than the equivalent thoughts expressed in English. But most of most programs are not mathematical in nature (see my post above on the topic). So let's consider some other kinds of operations. In most programming languages, to draw some colored text in a particular font with a specific alignment at a given location on the screen, I would say something like: substring.draw ( box, color, source.text.font, source.text.alignment ) ; Which is 10 words and 11 punctuation marks: 21 total elements. The Plain English equivalent would be: 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 (it's difficult to say exactly how many since traditional coders put spaces in different places); but we think that's a small price to pay for not having to learn (or think in) an artificial syntax. Here's another example: if ( ! source.colorized ( ) ) color = black ; Which is 5 words and 8 punctuation marks: 13 total elements. Compared with the Plain English: If the source is not colorized, put black into the color. Which is 11 words and 2 punctuation marks: 13 total elements. Again, it's mostly a matter of whether you like to type words or punctuation. 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. Personally, I wonder why anyone would think that "if (!source.colorized())" is a good way of saying anything. randall wrote: I don't think we should talk with computers in the same way as we talk with humans. If that's true, why has talking to computers as we talk to people been a common dream of humans the world over since (and even before) computers existed? The HAL 9000, the computer on Star Trek, Apple's SIRI, Microsoft's CORTANA, Amazon's ECHO, Wolfram's ALPHA, are just a few examples of fictional and real systems that suggest that's what people really want to do. randall wrote: Many details that are important for humans are not important for computers (and vice versa). See the colored examples above. Both humans and computers need the same facts to faithfully execute commands. Artificial languages simply substitute punctuation marks and other symbols where articles, conjunctions, and prepositions would normally appear. Plain English isn't for everyone; and (as I mentioned in an earlier post) we think the future of programming is hybrid languages, where the most appropriate syntax for each thought can be used. But the general framework, we believe, should be a natural language. After all, that's how we normally communicate with each other: every math book, every technical paper, and every post on this forum is an example of a natural language framework with specialized syntax where necessary. |
|||
|
12 Apr 2015, 17:22 |
|
|
Gerry Rzeppa 12 Apr 2015, 17:33
HaHaAnonymous wrote: OK, but in case of algorithms I think I will find the "Plain English" form easier to understand what is being done, and faster... Another plus, is that "Plain English" encourages to write more readable code... Not sure. Yes! The overall idea and goal of natural language programming is to keep the code as close to the natural language description of the algorithm as possible. Let's see what happens, for example, when we begin with a natural language description of the Sieve of Eratosthenes and attempt to convert it directly to Plain English. Here's the description from Wikipedia: To count all the prime numbers less than or equal to a given integer n by Eratosthenes' method: 1. Create a list of consecutive integers from 2 through n: (2, 3, 4, ..., n). 2. Initially, let p equal 2, the first prime number. 3. Starting from p, enumerate its multiples by counting to n in increments of p, and mark them in the list (these will be 2p, 3p, 4p, etc.; the p itself should not be marked). 4. Find the first number greater than p in the list that is not marked. If there was no such number, stop. Otherwise, let p now equal this new number (which is the next prime), and repeat from step 3. 5. When the algorithm terminates, all the numbers in the list that are not marked are prime. And here's a Plain English equivalent (actual code): To get a count of prime numbers less than or equal to a number: Create a list of consecutive integers from 2 to the number. \ wikipedia's step 1 Get an entry from the list. \ wikipedia's step 2 Loop. Mark higher multiples of the entry. \ wikipedia's step 3 Get the entry for the next lowest possible prime. If the entry is not nil, repeat. \ wikipedia's step 4 Get the count of prime numbers in the list. \ wikipedia's step 5 We're trying to program at a level where we say what needs to be done, rather than how to do it. |
|||
|
12 Apr 2015, 17:33 |
|
|
Gerry Rzeppa 12 Apr 2015, 17:42
Mike Gonta wrote: I'm more interested in making a small toy OS written in Plain English called simpleOS. I would also like to get Windows out from under our stuff, and to demonstrate that an OS can be written in Plain English. But I wouldn't call it a "toy" if it's able to both reproduce and document itself. Mike Gonta wrote: I'll be using my aeBIOS – a 32bit protected mode BIOS extender (which I'll be renaming "simpleBIOS" to take care of the hardware interface. I've been working on a low level FAT32 driver. I'll be integrating some of the MikeOS32 kernel (re-written in Plain English) for the OS services. Sounds reasonable. Mike Gonta wrote: I'll start by modifying the compiler ever so slightly to output a flat binary file (a Plain English cross compiler). You won't see me shedding any tears when you delete all that PE-style executable stuff. Here's my specification for a decent executable format: "Execution begins with the first byte of the file." End of specification. Mike Gonta wrote: The typical hobby OS has a kernel which is loaded at 1Meg by the boot sector with a jump table for the OS services at the beginning. The cross compiler will allow the load address to be specified (applications are loaded by the kernel at 4 Meg for example) and a jump table will be blurted first for the kernel file. To simplify the application loading the "~initialize before run and run and finalize after run" routine will be blurted first for the applications. Again, sounds good. Please keep me up to date on your progress and/or write with further details, or if you just want to talk about the thing, etc. ( gerry.rzeppa@pobox.com ) As I said, I'd really like to see something like this happen. Hopefully one day soon I'll be asking you for permission to use your code! Last edited by Gerry Rzeppa on 12 Apr 2015, 23:44; edited 2 times in total |
|||
|
12 Apr 2015, 17:42 |
|
|
TmX 12 Apr 2015, 18:02
Gerry Rzeppa wrote:
Sounds like declarative programming But then, reading Haskell/Prolog programs typically requires a significant amount of brain power :p |
|||
|
12 Apr 2015, 18:02 |
|
|
Gerry Rzeppa 12 Apr 2015, 19:33
TmX wrote:
I'm afraid I wasn't specific enough in that statement. (I do get a bit carried away in my enthusiasm at times!) Plain English routines are primarily imperative, though algorithms are divided up into enough levels of abstraction so they often appear to be declarative. In other words, at the top level you find very general commands, like: Create a list of consecutive integers from 2 to the number. But as you chase that down, the "what" quickly turns into a "how": To create a list of consecutive integers from a number to another number: Privatize the number. Loop. If the number is greater than the other number, exit. Create an entry for the number. Append the entry to the list. Add 1 to the number. Repeat. Note that the lower "how" levels, when well designed, are typically re-usable; the language thus gets bigger and better simply by being used (eg, there's nothing in the compiler itself about making lists of consecutive numbers, but once the above routine is coded, the Plain English command to "create a list of consecutive integers between this and that" will be understood). Note also that this really isn't ground-breaking stuff; any imperative language can be used in much the same way. The differences, however, are two: (1) due to the Plain English syntax, it is impossible to distinguish built-in from user-defined routines; and (2) more importantly, we actually encourage programmers to include synonymous routine definitions with alternative wordings (so that any reasonable wording of a "command" that later pops into his head is likely to be understood). For example, our standard library understands the command: Clear the screen. But a programmer might, without much thought, enter something like this instead: Erase the screen. We thus include a synonymous definition so that both wordings will be understood: To erase a screen: employ clear a screen. And the version under development will allow an even more convenient way of extending the vocabulary of the language via explicit synonym definitions: Clear, erase, and wipe off are synonyms. TmX wrote: But then, reading Haskell/Prolog programs typically requires a significant amount of brain power :p Yes, and we don't think that's the right direction. For centuries, hard-copy procedure manuals, written in plain English, have done a fine job of getting things done just by describing the steps that need to be taken. We're thinking programs should simply be a digital extension of that grand tradition. |
|||
|
12 Apr 2015, 19:33 |
|
|
TmX 13 Apr 2015, 10:46
Hi Gerry,
By any chance, have you ever stumbled upon Linoleum? It's an attempt to make an assembly programming language which is English like, although probably as not verbose as your Plain English. Folks who are already deeply familiar with MASM/NASM/FASM etc should consider Linoleum weird 
Sadly, it's been stagnant and not surprisingly many external links about it are dead already. But the official forum is still alive and you can dig many informations there.  |
|||
|
13 Apr 2015, 10:46 |
|
|
Gerry Rzeppa 13 Apr 2015, 19:44
TmX wrote: Hi Gerry, By any chance, have you ever stumbled upon Linoleum? It's an attempt to make an assembly programming language which is English like, although probably as not verbose as your Plain English. Folks who are already deeply familiar with MASM/NASM/FASM etc should consider Linoleum weird Thanks for pointing that out; I had not seen Linoleum before. But I'm afraid it's quite different from Plain English in that it's really "just another" artificial syntax, ie, something that needs to be learned. For example, I need to learn when (and when not to) put double-quotes around things, what the "-->" operator is for, and what an obscure statement like "? B = 0 -> finished;" does, etc. Plain English, on the other hand, attempts to use everyday syntax -- words, phrases, and sentences that naturally occur in English -- to express ideas to the computer. For example, if a programmer has a number somewhere in memory and he wants to put it into the eax register, he simply says: Put the number into eax. Admittedly, the routine that is called when the above statement is executed is somewhat above assembly level since the compiler generates a bit of code to handle the call, and the routine has to fetch the number from memory, thus: To put a number into eax: Intel $8B9D08000000. \ mov ebx,[ebp+8] \ the number Intel $8B03. \ mov eax,[ebx] But I hope the idea, syntax-wise, is nevertheless clear. In a Plain English assembler -- if such a thing were to be developed -- the last statement above (mov eax,[ebx]) would be written more like this: Copy ebx's target into eax. Or even: Copy 4 bytes from wherever ebx is pointing into eax. Or whatever natural language "thought" the programmer has in his head when he thinks about what that line of assembler code actually does. Perhaps something like: Stick that thing ebx is pointing to into good ol' eax. I know that's the kind of stuff I think when I'm programming. We didn't include such statements in the current version of Plain English because, first of all, we didn't see the need; but mostly because Plain English tries to get to as high a level of expression as possible, as quickly as possible. Thus, to see if a number is less than another number, we need hybrid code like this: To decide if a number is less than another number: Intel $C7C001000000. \ mov eax,1 \ assume true Intel $8B9D08000000. \ mov ebx,[ebp+8] \ the number Intel $8B1B. \ mov ebx,[ebx] Intel $8B8D0C000000. \ mov ecx,[ebp+12] \ the other number Intel $3B19. \ cmp ebx,[ecx] Intel $0F8C06000000. \ jl over the next 1 statement Intel $C7C000000000. \ mov eax,0 \ now it's false But once we've got that kind of stuff in there (and there's not a whole lot of it), we can work exclusively all the way up at the top, Plain English level, saying things like: To decide if a number is between another number and a third number: If the number is less than the other number, say no. If the number is greater than the third number, say no. Say yes. I hasten to add that this is really nothing revolutionary; any high-level language with "inline assembler" can do similar things. The difference is that our high-level language uses a syntax that the programmer has been using all day everyday since he was two years old; a syntax that mirrors the natural-language thoughts that are actually in his head when he is thinking about what he wants the computer to do. It's pseudocode that runs (my dictionary defines pseudocode as "statements outlining the operation of a computer program, written in something similar to computer language but in a more understandable format.") |
|||
|
13 Apr 2015, 19:44 |
|
|
codestar 15 Apr 2015, 10:08
Finally sober. Just wanted to start a conversion.
COPY & PASTE? I have my own assemblers, compilers and literally 1,000s of programs (contributed 170+ examples to this community alone). So, I do NOT want credit or blame for anyone else's work. I only look for inspiration. In this case, I was hoping that some language creator's would come here and respond to John and revolution, they are obsessive control freaks who think they know what everyone else needs to be doing with their lives. JohnFound is the type of person who would steal your code and take credit for it. He doesn't care if you have a (C) or patent, he'll take it anyway. FreshLib contains a lot of code written by vid (FASMLIB) who was a good programmer. Poor vid got robbed by John in the most ruthless way. All vid could do is watch in horror as his code slowly devolves before his eyes. This may be one of the reasons why vid disappeared. PROGRAMMING = RELIGIOUS? revolution is the one who makes programming into this religious cult: Memorize and repeat scriptures, never think for yourself, doesn't matter if you're good or not. Since he has been a moderator, he has always used divisive methods of control to restrict thinking, stop creativity and prevent evolution. I'm a free-thinker programmer who encourages everyone to write code however they want. I've wasted too much time and gotta get to work and make $ (visual artist). I'll return in about 2 weeks. |
|||
|
15 Apr 2015, 10:08 |
|
|
randall 15 Apr 2015, 10:53
codestar
Please, stop those silly personal attacks. What's the point? |
|||
|
15 Apr 2015, 10:53 |
|
|
vid 15 Apr 2015, 11:05
codestar wrote: JohnFound is the type of person who would steal your code and take credit for it. He doesn't care if you have a (C) or patent, he'll take it anyway. FreshLib contains a lot of code written by vid (FASMLIB) who was a good programmer. Poor vid got robbed by John in the most ruthless way. All vid could do is watch in horror as his code slowly devolves before his eyes. This may be one of the reasons why vid disappeared. I'm not sure if this was meant to be ironic or what. Just to make things clear for posterity, JohnFound is free and welcome to do whatever he likes to do with FASMLIB (as is also stated in FASMLIB license). I'm glad if it serves anyone. Reason for my inactivity here (except when prompted by someone) is that I have moved on to other fields of interest. |
|||
|
15 Apr 2015, 11:05 |
|
|
Gerry Rzeppa 15 Apr 2015, 18:20
Let's try to get back on topic. Perhaps this will help.
My native tongue is English, but in high school they wanted me to learn French. I was never any good at it because I kept thinking in English and trying to translate as I spoke. I've met people, however, who appear to be able to "think" in either language, and are thus fluent in both. It seems the same thing happens with computer languages. You think about what you want to do, and then you figure out how to say it. And if you say it in a particular way often enough, you might just start thinking in that way as well. Now, time for a little self-examination. Three questions: 1. Let's say you're writing a routine in assembler that iterates some number of times; the plan is to put the count in ecx. At the time when the plan first forms in your mind do you: (a) Think "mov ecx,[count]" immediately? or (b) Think something like "put the count into ecx" and then translate? 2. How about when you're working with an assembler whose syntax is unfamiliar to you? Do you: (a) Think "mov ecx,[count]" and then translate? or (b) Think something like "put the count into ecx" and then translate? 3. How about when you're working on a larger problem? Do you: (a) Think about the entire solution in assembler and type it in? or (b) Think about the solution in natural language (or mixed) terms then translate (the parts) that need translating? |
|||
|
15 Apr 2015, 18:20 |
|
|
Sean4CC 18 Apr 2015, 00:42
Just don't give them your e-mail address, dude. Anyway if you do you will quickly find it uninteresting.
|
|||
|
18 Apr 2015, 00:42 |
|
|
codestar 19 Apr 2015, 09:26
Quote: Now, time for a little self-examination. Three questions: 1. Let's say you're writing a routine in assembler that iterates some number of times; the plan is to put the count in ecx. At the time when the plan first forms in your mind do you: Code: let r1 equal count ; I think this put into r1 the count ; or this copy to r1 the count ; or this assign r1 to the count ; or this Quote: 2. How about when you're working with an assembler whose syntax is unfamiliar to you? Do you: Quote: 3. How about when you're working on a larger problem? Do you: Quote: If anyone here would be interested in helping to develop that Plain English operating system, please let me know (gerry.rzeppa@pobox.com). Perhaps you, Codestar? Surely you'd be happier working on something positive * Abakis AI is the best that I have now, by far, the most advanced macro language ever created in FASM with several examples. I challenge anyone to improve it. As far as syntax, Abakis destroys all languages at RosettaCode, technically more efficient by the numbers: try p=allocate 16*KB | class COLOR = byte a, r, g, b ; but it's kind of "hard" compared to C and there's no type safety. * Z, the most comprehensive Intel Windows library that I have. Minimal language. Last version was in ARM Visual Disassembler (unfinished). * For ARM, check my older language+compiler Magic-ARM with 12+ bare-metal examples (PL110 LCD with Angel Interrupts). * For ARM Windows, see my Windows Mobile/CE template. * My Z-IDE demo. My best library design |
|||
|
19 Apr 2015, 09:26 |
|
|
nyrtzi 20 Apr 2015, 18:31
When someone speaks of programming in natural language all I hear is Cobol and SQL. I like the concepts behind relational databases but SQL although being useful is a poor implementation of those ideas and one of its faults is trying to look like natural language. Who was Cobol written for? For people who code or those who don't? In the end it's all about communicating meaning, intent, etc.
As far as I'm concerned programming language might as well try becoming more math-like. I'm not against natural language as far as easier readability goes but does programming in plain old english allow for better readability? Programming languages aiming at being more like english usually seem to just end up being verbose. If the parser skips what it considers redundant filler words and concentrates on some subset of the language it considers meaningful then programmers will still have to learn what that subset is in order to understand and to be able to be sure about what they've written actually means and how it is understood by the mechanisms which implement what the text says. Natural language is fuzzy and inexact unless you are prepared to be verbose enough to explicitly spell out the whole darn context in enough detail to make everything absolutely exact which is what the machine executing the program requires. But if so and you need to learn the underlying rules of "simplified programming english" anyway then why not simply do what other languages do and make the programmer learn a simplified artificial language which doesn't bother trying to hide context? I just fail to see the benefits of programming in plain english. Why not chinese instead? |
|||
|
20 Apr 2015, 18:31 |
|
|
Gerry Rzeppa 20 Apr 2015, 20:20
codestar wrote:
Thanks for responding. It seems to me that your thinking has been influenced by a couple of things. I suspect, for example, that only someone previously introduced to standard mathematical verbiage (let x=1, etc) would think of the first alternative. And I think the second and third have been influenced by working with assembly languages ("Put, in the drawer, the socks" is not the way we normally speak English). The fourth seems the closest to a "natural" thought, but I believe "Put the count into r1" is the obvious thought here. codestar wrote: My time is limited. What I can do is offer my primary languages and libraries for reference, I use them to make real programs, games and bare-metal examples (mini OSs, templates, included). Lots of interesting stuff there. You've been busy. Thanks. Though a little deep on the nested IFs in some places for my way of thinking. For example: Code: if state<>SS.STAND if state<>SS.ATTACK if state<>SS.JUMP if state<>SS.HIT if state<>SS.FALL .stand: if [player.combo]=0 animate player, STAND, 0, stand.a, 0, 0 end end end end end end "Two deep is too deep," I always say. |
|||
|
20 Apr 2015, 20:20 |
|
| Goto page Previous 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|