Gulp Introduction
From Computer Tyme Support Wiki
m |
m |
||
| Line 11: | Line 11: | ||
== Under the Hood == | == Under the Hood == | ||
| - | This language has two parts to it. The run time part is similar to Forth. It's an RPN engine that uses a lot of stacks. The interpreter/compiler takes pretty source code and turns it into nasty Forth like RPN code that tokenizes small and runs reasonably fast. | + | This language has two parts to it. The run time part is similar to Forth. It's an RPN engine that uses a lot of stacks. The interpreter/compiler takes pretty source code and turns it into nasty Forth like RPN code that tokenizes small and runs reasonably fast. As an interpreter the system interprets the text stream and runs it. As a compiler the text stream is turned into a file of tokens that represents the RPN like execution sequences. Either way should be easy to code because the interpreter builds the tokens in memory. The compiler just saves the tokens to disk and eliminates the initial preprocessing of the text. |
Revision as of 06:12, 2 October 2005
A little History
My first programming language was binary - leterally! In 1979 I had an IMSAI computer with 8k of ram and only EPROMS for storage. I started programming it from the front panel switches one byte at a time. Eventually I wrote an operating system. Got a keyboard and screen working - then tape - and eventually disk. Managed to convert two languages to run on it. Had a 5k Basic and a Forth compiler. Then I learned Pascal.
Forth was elegant in the way it ran but sucked in the way it read. The inventor of Forth - Chuck Moore - wrote a ver kool little Basic like compiler in Forth that was extremely impressive and later becames the basis for my MarxMenu compiler. Marxmenu is long gone as DOS has faded - but there doesn't exist any languages today that is anywhere near as elegant as MarxMenu is to program in. Today's programmers just don't get it - so I'm posting this in hopes to get something going.
Languages Done Right
Cumputer exist to serve humans and they get faster but not necessarilly easier to use. My idea of a good programming language is one that is intuitive so that the programmer/user can script something together quickly and get code running. Readability is the most important aspect of this language. Nothing else really matters. If it's too slow - get a faster computer. As long as it runs reasonably fast - that's good enough.
Under the Hood
This language has two parts to it. The run time part is similar to Forth. It's an RPN engine that uses a lot of stacks. The interpreter/compiler takes pretty source code and turns it into nasty Forth like RPN code that tokenizes small and runs reasonably fast. As an interpreter the system interprets the text stream and runs it. As a compiler the text stream is turned into a file of tokens that represents the RPN like execution sequences. Either way should be easy to code because the interpreter builds the tokens in memory. The compiler just saves the tokens to disk and eliminates the initial preprocessing of the text.
