flat assembler
Message board for the users of flat assembler.
Index
> Programming Language Design > Plain English Programming Goto page 1, 2, 3, 4, 5 Next |
Author |
|
Mike Gonta 09 Apr 2015, 17:38
Plain English Programming wrote: Imagine a programming language that: |
|||
09 Apr 2015, 17:38 |
|
codestar 10 Apr 2015, 01:31
IMO, natural languages are fun, educational, useful to express certain algorithms, and good to have for reference in addition to my compact procedural code. An English programming language with semantics may seem a little impractical and redundant for bigger real-life programs involving expressions and parameters (p[3]= "the fourth parameter"), but I guess it's only as hard as you make it.
Here's a heated discussion with arguments on Plain English, 16+ pages started by Gerry Rzeppa (main author?). Let's invite him here to talk about it (HL forum?). A similar language could be implemented with FASMG (. may be ok to end sentence, but ' and ; will need to be substituted with like ^ and : "the polygon^s vertices"). I love this abstraction and extensibility: Code: to append a thing to some things: if the thing is nil, exit. put the things' last into the thing's previous. if the things are not empty, put the thing into the things' last's next. if the things are empty, put the thing into the things' first. put the thing into the things' last. ; my interpretation? ; append(things[], thing) { ... } Code: A compiler is a preprocessor, assembler and linker. To make a compiler: To make an os: Code: to divide a ratio by a number: multiply the ratio's denominator by the number. reduce the ratio. to add a string to some string things: create a string thing given the string. append the string thing to the string things. to append a byte to a string: put the string's length into a saved length. reassign the string's first given the string's length plus 1. put the string's first plus the saved length into the string's last. put the byte into the string's last's target. to rotate a polygon: if the polygon is nil, exit. put the polygon's center into a center spot. loop. get a vertex from the polygon's vertices. if the vertex is nil, exit. rotate the vertex's spot around the center. repeat. Code: to add a number to another number: intel $8B8508000000. \ mov eax,[ebp+8] \ the number intel $8B00. \ mov eax,[eax] intel $8B9D0C000000. \ mov ebx,[ebp+12] \ the other number intel $0103. \ add [ebx],eax to add a number to a byte: intel $8B8508000000. \ mov eax,[ebp+8] \ the number intel $8B00. \ mov eax,[eax] intel $8B9D0C000000. \ mov ebx,[ebp+12] \ the byte intel $0FB60B. \ movzx ecx,[ebx] intel $03C8. \ add ecx,eax intel $880B. \ mov [ebx],cl |
|||
10 Apr 2015, 01:31 |
|
Gerry Rzeppa 10 Apr 2015, 03:08
codestar wrote: Here's a heated discussion with arguments on Plain English, 16+ pages started by Gerry Rzeppa (main author?). Let's invite him here to talk about it (HL forum?). I think it's all been said in the forum mentioned above, but I"m always glad to talk about Plain English Programming. So here I am. |
|||
10 Apr 2015, 03:08 |
|
Gerry Rzeppa 10 Apr 2015, 03:12
To Mike Gonta:
Please contact me directly (gerry.rzeppa@pobox.com). I have some questions regarding your SudoCode version of our Plain English compiler. Gerry |
|||
10 Apr 2015, 03:12 |
|
revolution 10 Apr 2015, 05:11
I big turn-off for me is the forced full-screen. No program gets to take over my entire screen for anything.
Gerry Rzeppa: You appear to be trying to do many things at once. -Introduce a different way to write programs. -Introduce a new paradigm in menu/UI layout. -Pretend nothing else is worth doing or using other than your system. -Pretend that the only thing holding back programmers now is the languages they use. I was prepared to try out a novel language but when you are forcing all those other things at the same time then it feels very much like evangelising rather than normal promotion. |
|||
10 Apr 2015, 05:11 |
|
codestar 10 Apr 2015, 05:18
Gerry: Am I speaking to the creator himself? Much respect for Plain English. Pure genius. I myself make assemblers and compilers for various CPUs and may be interesting in helping but have no time now (drinking too much Budweiser tonight).
So, I'll post my latest macro code and let it speak to you in a mysterious way You will never find code like this anywhere on Earth. There is no human like me, 1 in 7+ billion: Code: ; draw bit/byte function draw.bit, n, x, y if n draw.image bit1.i, x, y else draw.image bit0.i, x, y end endf function draw.byte, n, x, y locals i . i=8 loop i, r0=n, r1=i, r1--, r0>>cl, r0&1 draw.bit r0, x, y . x+BIT.W endl endf ; draw pixel function draw.pixel, x, y, c alias p=r0, z=r1 try clip.pixel x, y vga.xy x, y . z=c, (u32) *p=z endf 1 ; draw horizontal line function draw.line.h, x, y, n, c alias p=r0, z=r1, w=r2 . p=&x, z=&y, w=&n try clip.line 0, p, z, w vga.xy x, y . z=c loop n, (u32) *p++=z, endl endf 1 ; draw solid rectangle function draw.box, x, y, w, h, c locals i try visible x, y, w, h . i=y, i-- loop h, i++ draw.line.h x, i, w, c endl endf 1 ; draw scanline function draw.scanline, pixels, x, y, w alias p=r0, s=r1 vga.xy x, y . s=pixels loop w, (u32) *p++=*s++, endl endf 1 ; draw 8BPP scanline/bitmap with palette function draw.scanline.8, pixels, x, y, w alias p=r0, s=r1, c=r2, q=r3 vga.xy x, y . s=pixels loop w, q=*s++, q*4, q+palette.p . (u32) c=*q, (u32) *p++=c endl endf 1 function draw.bitmap.8, pixels, x, y, w, h locals i, p try visible x, y, w, h . i=y, i--, p=pixels loop h, i++ draw.scanline.8 p, x, i, w . r0=w, p+r0 endl endf 1 function draw.my.numbers locals i, n, y . i=bits.h, y=404 loop i, r0=my.numbers, r0+i, r0-- . r0=*r0, n=r0 draw.byte n, 4, y . y-BIT.H endl endf function draw.title.scene draw.text help.t, 16, 130 draw.byte magic.n, 50, 300 endf function draw.play.scene draw.board draw.my.numbers endf function draw.pause.scene draw.text pause.t, 16, 130 draw.byte magic.n, 50, 300 endf function draw.game.over print t, game.over.t, score draw.text t, 44, 170 draw.byte magic.n, 50, 300 endf ; convert 32BIT binary number to text function b2t, n, t alias p=r0, x=r1 . p=t if n=0, *p++='0', *p=0 return end while n, x=n, x&1, x+'0' . *p++=x, n>>>1 endw, *p=0 text.reverse t endf ; text.copy a, b - standard copy with ; 0 after. return advanced address function text.copy, a, b alias p=r0, s=r1, c=r2 . p=a, s=b, c=1 while c, c=*s++, *p++=c, endw, p-- endf ; text.copy.n a, b, n - copy with maximum ; size specified. return & function text.copy.n, a, b, n alias p=r0, s=r1, c=r2 . p=a, s=b loop n, c=*s++, *p++=c if c=0, break, end endl, p-- endf ; text.go t, n - advance to line # function text.go, t, n loop n try t=text.find t, 0Dh . t+2 endl endf t ; text.skip.0 a - skip 0s, return address or 0 function text.skip.0, a alias p=r0, c=r1 . p=a, c='0' while c='0', c=*p++, endw, p-- if c=0, return 0, end endf ; convert text to 32BIT binary function t2b, t alias p=r0, c=r1, n=r2 try text.skip.0 t . n=0 loop, c=*p++ if c=0, return n, end . n<<1, n-'0', n+c endl endf function draw.my.text, t, x, y locals p, n get n=text.n t . p=t loop n, r0=p, r0=*r0 draw.my.c r0, x, y, WHITE . x+r0, x+4, p++ endl endf function randomize.puzzle locals q, n alias p=r0, x=r1 . q=puzzle, n=(MAP.W*MAP.H) loop n get x=get.random . p=q, (u32) *p=x, q+4 endl endf function is.solved locals n alias p=r0, x=r1 . p=puzzle, n=(MAP.W*MAP.H) loop n, (u32) x=*p++ if x<>NORMAL, return 0, end endl endf 1 function draw.puzzle locals x, y . y=0 while y<8, x=0 while x<8 . r0=x, r0*TILE.W, r0+MAP.X . r1=y, r1*TILE.H, r1+MAP.Y draw.piece x, y, r0, r1 . x++ endw . y++ endw endf function on.key if key.event='c' if scene=SCENE.TITLE . scene=SCENE.PLAY go .draw end if scene=SCENE.GAME.OVER go .reset end if key='r' .reset: reset.game go .draw end if key='p' .pause: if scene=SCENE.PLAY . scene=SCENE.PAUSE else.if scene=SCENE.PAUSE . scene=SCENE.PLAY end go .draw end .draw: render end endf function on.mouse locals r if mouse.event='c' . r0=&close.i.x if.select r0 exit end if scene=SCENE.TITLE reset.game . scene=SCENE.PLAY go .draw end if scene=SCENE.PLAY if.select puzzle.box get.select.xy get r=get.piece.rotate \ select.x, select.y . r++ set.piece.rotate \ select.x, select.y, r go .draw end end if scene=SCENE.SOLVED reset.game . scene=SCENE.TITLE go .draw end .draw: render end endf |
|||
10 Apr 2015, 05:18 |
|
Gerry Rzeppa 10 Apr 2015, 06:52
revolution wrote: I big turn-off for me is the forced full-screen. No program gets to take over my entire screen for anything. The basic idea was to get ourselves out of the Windows environment (which takes over the whole screen) and into something else entirely -- with the ultimate goal of discovering just how simple an interface could be without being unnecessarily cumbersome to use. The interface we ended up with, that you've seen, fit the bill for us. We found that we were able to conveniently and efficiently write our whole system -- interface, file manager, text editor, hex dumper, compiler/linker, and wysiwyg page layout facility (for documentation) -- without overlapping windows, title bars, sizing frames, grow boxes, scroll bars, radio buttons, check boxes, tool bars, removable palettes, etc. It's admittedly not perfect, but it did convince us that much of the clutter that makes systems hard to learn and use is really just that: unnecessary clutter. In any case, our program can be minimized using the Minimize command (conveniently located under the "M" menu), or you can switch between our application and others using the standard Windows window-flipping keyboard shortcut, ALT-TAB. revolution wrote: You appear to be trying to do many things at once. -Introduce a different way to write programs. -Introduce a new paradigm in menu/UI layout. It's true, we had numerous goals in mind. As we say in our release notes: "The product is intentionally different - [l]iconoclastic[/i] is the term we use. It was designed to make the programmer question almost every preconceived notion a modern practitioner might have. Are installation programs necessary? Can a high-level language like English be used to conveniently write low-level programs like compilers? Is it really easier to program in English? Can a workable interface be designed without icons, scroll bars, radio buttons, and a wide variety of other widgets? Can complex programs be clearly and concisely written without nested ifs and loops? Can a polymorphic drawing program be effectively programmed without objects? And so forth." So yes, lots going on here. revolution wrote: -Pretend nothing else is worth doing or using other than your system. Sorry if it comes across that way. We think all creative endeavors are laudable, and we have the greatest respect for a wide variety of approaches to programming: FORTH, LOGO, and OBERON are just three that come immediately to mind. revolution wrote: -Pretend that the only thing holding back programmers now is the languages they use. On the contaray, the things that are holding back programmers, in our way of thinking, are things like extreme complexity, unnecessary obscurity, and a pitiful lack of standardization at the fundamental levels. revolution wrote: I was prepared to try out a novel language... We went further than just the language because we thought that other things could bear some scrutiny and improvement as well. The problems listed above -- extreme complexity, unnecessary obscurity, and a pitiful lack of standardization at the fundamental levels -- cannot be resolved at the language level alone. revolution wrote: ...but when you are forcing all those other things at the same time then it feels very much like evangelising rather than normal promotion. You make it sound like "evangelizing" is a bad thing. My dictionary defines evangelizing as the spreading of good news -- and the good news that we're trying to spread is that programming doesn't have to be as hard as it is. That significant programs (like effective IDEs with native-code generating compilers, and elegant multi-featured page-layout facilities) can be written with relative ease and unusual efficiency. |
|||
10 Apr 2015, 06:52 |
|
Gerry Rzeppa 10 Apr 2015, 07:29
codestar wrote: Am I speaking to the creator himself? My elder son Dan and I wrote the Plain English system. We sat, side by side, at a single computer with two monitors (both displaying the same thing). One of us would run the mouse while the other typed. Every line was thus agreed to before it was run, and we rarely wrote more than a few lines without testing. It took us about six months to complete the project, including the page-layout facility and the documentation we wrote using that program. codestar wrote: Much respect for Plain English. Pure genius. Thanks. codestar wrote: I myself make assemblers and compilers for various CPUs I've looked, somewhat briefly, at your site. Nice work. I too am a programmer/artist. I think the artist part sometimes makes us see things that other programmers (more strongly left-brained and mathematically inclined), sometimes miss. For example, almost everyone on programming sites tells me we got the precedence rules wrong in Plain English (ours is left-to-right only). Yet when I ask almost any native English speaker (who is not a trained programmer) what "3 plus 2 times 5" is, they always say, 25 (not 13). codestar wrote: ...and may be interesting in helping but have no time now (drinking too much Budweiser tonight). My son is currently busy writing ugly code in ugly languages to support his wife and four kids, so we don't get to work on Plain English much at present. Ultimately, I'd like to put the whole thing -- together with a minimal Plain Engish operating system -- on a thumb drive that would run on Chrome machines (minus the Chrome) so we could teach kids how to program top to bottom -- all the way from English to machine code, from application to compiler to operating system -- without ever leaving our simple and friendly environment. codestar wrote: So, I'll post my latest macro code and let it speak to you in a mysterious way. You will never find code like this anywhere on Earth. I get it. Very nicely done. And undoubtedly very fast. The style of the loops is a little C-like for my taste, but at least you stayed away from those ubiquitious "squigglies"! codestar wrote: There is no human like me, 1 in 7+ billion: Don't you have to check all the others to really be sure? |
|||
10 Apr 2015, 07:29 |
|
JohnFound 10 Apr 2015, 07:30
Gerry Rzeppa wrote: ...programming doesn't have to be as hard as it is. Who said programming is hard? _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
10 Apr 2015, 07:30 |
|
codestar 10 Apr 2015, 07:39
Quote: Don't you have to check all the others to really be sure? Smile |
|||
10 Apr 2015, 07:39 |
|
revolution 10 Apr 2015, 07:46
Gerry Rzeppa wrote: The basic idea was to get ourselves out of the Windows environment ... |
|||
10 Apr 2015, 07:46 |
|
Gerry Rzeppa 10 Apr 2015, 07:48
JohnFound wrote: Who said programming is hard? Sorry, I should have said something like, "...as hard as programming can be." See, for example, here: https://coronalabs.com/products/corona-is-10x-faster/ It seems to me that programming with something like Corona is way easier than programming in Objective-C or Java, and that those latter approaches, by comparison, could reasonably be called "hard". |
|||
10 Apr 2015, 07:48 |
|
Gerry Rzeppa 10 Apr 2015, 08:22
revolution wrote:
Because that's what researchers do. Experiment. Try new and different things. Think outside the box. Push things to the extreme to see where (and why) they break. To see what works, and what doesn't. revolution wrote: You are pulling people away from their comfort zones in too many ways. Many ways, yes. Too many ways? Don't know about that. After all, our job, as iconoclasts, is to challenge, not comfort. revolution wrote: If you backed off and instead introduced your language first and get people interested, then in a separate path try to convince others about the evils of Windows etc. then you might have more success. Possibly, but I don't think so. When I was young I made millions selling a database design course I developed to companies like Oracle and Microsoft, General Motors and Ford (see www.era-sql.com). I'm now almost 62 years old now and I've spent those millions over the last three decades trying all kinds of things with all kinds of people in all kinds of endeavors. I've tried selling "revolutionary" ideas in art, music, architecture, electronics, programming, and a number of other fields, both a nibble at a time, and whole hog. And my consistent experience has been that, in the end, people either like where you're headed, and want to go along, or they don't. Giving it to them slowly just costs more and takes longer. revolution wrote: ...with everything happening all at once you create a lot of resistance for no good reason. Unless, of course, the reason is to quickly weed out the merely curious to make room (time- and money-wise) for those who "see the light" and want to pursue it wholeheartedly ( https://www.youtube.com/watch?v=lX5tfRdkoY0 ). |
|||
10 Apr 2015, 08:22 |
|
JohnFound 10 Apr 2015, 09:09
Gerry Rzeppa wrote: It seems to me that programming with something like Corona is way easier than programming in Objective-C or Java, and that those latter approaches, by comparison, could reasonably be called "hard". Hm, it seems that you make troubles for yourself and then successfully solve them, feeling great. Simply learn assembly and all these difficulties will disappear like a mist in a hot summer day. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
10 Apr 2015, 09:09 |
|
Gerry Rzeppa 10 Apr 2015, 09:53
JohnFound wrote: Simply learn assembly and all these difficulties will disappear like a mist in a hot summer day. Nicely poetic. But I've been programming in various assembly languages (and writing assemblers) for decades (System 370, 6502, Z80, 68000, x86, etc) and have found that it is often more effective to communicate in a higher-level language. Take this post, for example. When I want to express my thoughts to you, I don't do it with machine code or algebraic formulas, but with natural language sentences. There are, of course, places where such specialized modes of communication are necessary and appropriate; but most of the time, most of what we have to say is most easily expressed in our natural tongues. See the attached photo for an example of how Einstein naturally communicated with others; note the mix of natural language, formulas, and graphics. It is our belief that the ideal programming language would allow the programmer to write as Einstein did in the aforementioned sample; as the author of a technical paper or a math book might write: a natural language framework with snippets of specialized syntax (and even graphics) where appropriate. There are places in our Plain English system where we already take steps in the direction of this ideal. Consider, for example, this routine: To add a number to another number: intel $8B85080000008B008B9D0C0000000103. Here we have the highest (English) and lowest (machine code in hex) of expressions combined in a single sentence: the high because that's what we want to say, in the way we would most naturally say it; the low only because it's necessary to get the idea across to the machine. Future version of Plain English will be extended along these lines. With things like this, perhaps: To convert a fahrenheit temp to a celsius temp: c=(f-32)*5/9 But we're convinced that most of most of our future programs will be just plain English, because the kind of things that most programs do most of the time are most naturally expressed in that way. Consider, for instance, our compiler -- a sophisticated Plain-English-to-Executable-Machine-Code translator. It has 3,050 imperative 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 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 expressed in a natural language. 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!
|
||||||||||
10 Apr 2015, 09:53 |
|
JohnFound 10 Apr 2015, 11:44
@Gerry Rzeppa - also I would suggest to express the algebra theorems in "plain english", this way the mathematics will be really easy.
But there is one catch - how about the internationalization? For example "Plain Chinese Programming", "Plain Bulgarian Programming" and "Plain Russian Programming" languages? Do you think they have some future? |
|||
10 Apr 2015, 11:44 |
|
revolution 10 Apr 2015, 11:46
Plain Assembly Programming.
Plain Machine Code Programming. Plain C Programming. |
|||
10 Apr 2015, 11:46 |
|
codestar 10 Apr 2015, 18:48
Sorry, drinking too much last night, getting lonely and emotional. Fell asleep on the floor and awoke with Budweiser bottles everywhere This is kind of a random forum anyway.
Wrote this last night: Code: define_types \ void(dd,'p','v'),\ uint1(db,'i','u'), int1(db,'i','s'),\ uint2(dw,'i','u'), int2(dw,'i','s'),\ uint4(dd,'i','u'), int4(dd,'i','s'),\ uint8(dq,'i','u'), int8(dq,'i','s'),\ real4(dd,'f',0), real8(dq,'f',0) alias \ byte=uint1, char=int1,\ ushort=uint2, short=int2,\ int=int4, uint=uint4,\ long=int8, ulong=uint8,\ float=real4, double=real8 Code: make.game(...) How can "we" (language creators) copy when no one else writes code in our languages? PS: My favorite language designer is Niklaus Wirth. |
|||
10 Apr 2015, 18:48 |
|
Gerry Rzeppa 10 Apr 2015, 19:15
JohnFound wrote: But there is one catch - how about the internationalization? For example "Plain Chinese Programming", "Plain Bulgarian Programming" and "Plain Russian Programming" languages? Do you think they have some future? We've already got people in South America working on Plain Spanish, a guy in Portugal looking into Plain Portuguese, and a Russian friend of mine thought that Plain Russian would be a good idea but he doesn't have time to pursue it at the moment. So yes, we like the thought that people everywhere can program as they naturally think, in their native tongues. |
|||
10 Apr 2015, 19:15 |
|
Goto page 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.