Old school BASIC was pretty crappy. But it did have an amazing power. A kid could type:
10 PRINT "SOMETHING VERY RUDE"
20 GOTO 10
Preferably on a machine on prominent display in a store in the mall. And the run out chuckling.
Very simple. For many that is as far as it went. For a few it sparked that curiosity, "What else can this thing do?"
In the modern world there is no such simple and immediate hook to pull young minds into the idea of programming.
That is basically the motivation for the guys why built the Raspberry Pi. They want to get to the point that a youngster can turn it on and immediately do something. The Pi guys want to do this with Python and/or Scratch. We will see how that works out but it's worth a shot.
And yet, the only means you have of defending the idea that a computer language is a 'real' language, and not a semiotic sub-set is to revert to English... a real 'real' language.
Perhps true but also perhaps also I don't know what you are getting at.
Looks to me as if "real" languages, like English, are very powerful and expressive and general purpose. Such languages are also full of subsets. For example there is a subset of English used by doctors, with a lot of latin thrown in, which most English speakers might not understand. There is a subset used by the lawyers and the legal system. There is a subset use by pilots and air traffic control.
These subsets are domain specific with the aim of being clear, concise, efficient and accurate in that domain.
I will make the bold claim that the C programming language, for example, is a such a subset of English. With the express purpose of clearly stating the intent of a program/algorithm.
C is obviously not much use at some normal everyday things like "How are you today?" or higher level things like discussing the meaning of language. But it is pretty good at expressing a particular subset of ideas that humans have.
For fun, have a listen to Chompsky speaking about linguistics and you will start to wonder what language he is speaking. Could be English but I don't understand a word of it.
Old school BASIC was pretty crappy. But it did have an amazing power. A kid could type:
Preferably on a machine on prominent display in a store in the mall. And the run out chuckling.
Very simple. For many that is as far as it went. For a few it sparked that curiosity, "What else can this thing do?"
In the modern world there is no such simple and immediate hook to pull young minds into the idea of programming.
That is basically the motivation for the guys why built the Raspberry Pi. They want to get to the point that a youngster can turn it on and immediately do something. The Pi guys want to do this with Python and/or Scratch. We will see how that works out but it's worth a shot.
Python would be an excellent way to do this. It has an immediate mode so simple experimentation could be done without firing up a full-blown IDE. Unfortunately, it is probably impractical to run Python in a P1 and may even be too much for a P2. However, I imagine that either one could run a Python-like language if they had access to relatively large external memory.
I've looked at Forth and similar languages many times over the years. I quite like RPN, no problem with that. I was very familiar with TI calculators back at school when somebody came in with a HP calculator. I was hooked immediately and borrowed it whenever there was a spare moment.
But whenever I try Forth or something similar I am forced to use an environment which does not anymore fit with how I do programming. Won't go too much into that, so I'll try to sum it up like so:
I like interactive debugging tools. Dumping memory, inspecting registers and code etc.
I like non-interactive programming. I want to see my code in a big editor where I can look at everything up and down at all times. XEmacs style..
I don't like building up my program interactively. Doesn't work for me. That time is past. I wrote basic programs that way back in the dawn of the microcomputer era. I moved on to a better way and can't go back.
I *think* in modules and building elements from elements, but my mental way of doing it doesn't fit with using an interactive language.
Then comes file handling (or the lack of) etc.
As an example, I like writing debuggers.. interactive debuggers. But I would never write the debugger interactively! The joy is in using an editor, a compiler, a Makefile, and update my debugger source code whenever I need one more feature. Build it, then use the new debugger interactively.
Is it so that Forth, or at least very Forth like language, is the only way to do what Forth can do?
Regardless of any language merits what we have in Forth is a way for people to:
1) Talk to their machine in a somewhat higher level than binary or HEX or assembler.
2) Poke around and see what the machine does.
3) Enter programs and data into the machine.
4) Edit those programs and data.
5) Run those programs.
6) Have results output.
Well of course that sound like any operating system and many language systems. Those requirements could be met using languages like BASIC, Python, PHP, JavaScript, Lua, Scheme, Lisp and many others.
So let's throw some more requirements on there:
7) Must be small, fitting into the few K Bytes of space on a typical MCU or such system.
8) Must run code reasonably efficiently.
That pretty much rules out Python, JavaScript, in fact probably all the languages I might have listed above, their implementations are just too big. Except possibly BASIC.
So we are left with Forth because it is the only one with any hope of meeting the requirements.
Why is that?
Well, seems to me for the language implementation to be small the language itself must be very simple with a minimum of syntax to parse or semantics to implement.
And that leads to the stack based, post fix style of Forth.
So my question is: Is it so that Forth is not just another language syntax chosen at random but actually necessary to solve the problem as stated above?
Is it the only solution? Is there somewhere a language that can achieve similar functionality in similar small spaces without the stack based approach that gives so many problems.
A small Python on the Propeller would certainly be interesting. I am not saying that Forth has to be the defacto standard of interpreted languages for the Propeller.
I just don't know what might be more suitable, or even equally suitable.
=============
@Heater,
Since 1994 I have been teaching English as a 2nd language, and studying Mandarin Chinese and Taiwanese. I even studied graduate classes via distance learning with the University of Edinburgh.
I have had a lot of Taiwanese students that have pursued the study of English as if it were a compuer language, but generally with poor results. They attempt to enforce rigorous logic to justify what they needed to learn and retain, the often seek only one good answer for everything (language tends to never have just one answer), and they expect to achieve results in a very short period of time.
What I have observed is that since 1994, my knowlege of language has expanded vastly and is still doing so. And, the topic is forever changing with new trends. Meanwhile, that crowd of students that thought an actual language could be mastered in the same way as a computer language have disappeared.
I started with programing to create a phonological program to represent English to Chinese students with clues on how to pronunounce English in spite fo a huge mess in how actual spelling represents a word (We have 5 vowels, that represent about 25 sounds, that are combined in about 125 combinations -- the odds are against the learner ever learning to read phonology accurately through the popular Phonics).
That was really too much for me in MS Windows. It became obvious I had to master the Windows GUI, the fonts, and much more. But it got me started with BasicStamps.
Computer programming languages are only languages in the analogous or metaphorical sense. And yet, there are still a lot of computer programmers that won't admit that. Just show me how to debate meaning in Python or C and I will back down from my position.
...Therefore I posit that programming languages are as much "real" language as English or Chinese or the notation of mathematics.
The computer language is for talking to computers, and can be use for humans to talk to each other about what computers do (maybe), but we say different things in natural language versus computer language versus mathematics versus x. The primary issue is the ability of the writer/speaker to express the idea. If the write babbles, or over condenses with jargon and acronyms, or just doesn't understand the concept, communication will be hindered. These are the cause of most issues with computer programs as with human communication. So there are simillarities , but these are tools for different applications.
Is it so that Forth, or at least very Forth like language, is the only way to do what Forth can do?
So my question is: Is it so that Forth is not just another language syntax chosen at random but actually necessary to solve the problem as stated above?
This is entirely possible. The folks that know the most about computer languages, and have a detailed knowledge of the suitability of one tool versus another for a specific application, often reach this exact conclusion.
Forth is a open computer system, nearly everyone else has tried to provide a closed system that in some way protects itself from the end user, and in some cases from the programmer. So I suppose that makes it not just another language and something more than an operating system.
It tends to not impose authority on the user. It tries to empower the user to learn what really can and cannot be done.
@Heater
It seems you are headed towards asserting that all computer languages are a sub-set of English, and that mathematics might even be a sub-set of English.
Subjects, such a mathematics, medicine, engineering do have their own ways of creating precise meaning, but none of them are a sub-set of a language. They are subjects, no language components. Computer programing is a subject. The fact that we use the alphabet and other keyboard symbols to create a 'programing language (system?)' is just due to a whim of history. A lot of innovations result in having a default to the language of origin. Airplanes have accepted English as the prime language of airports due to the Wright Brothers; post offices and passports still use a French lexicon due to their origins.
I don't thing C is any more a language than algebra is or chemistry.
Forth confuses the issue even more as it often looks like real words, but it doesn't have too.
My college required that we take a programming languages course in our sophomore year. Nobody blinked at Lisp, C, or Snobol, but APL was feared. Not only were programs unreadable, but they could only be entered on a terminal with APL keys on it. So it was physically harder to program in a language that everyone hated. I think APL was included in the course only because Brainf**k hadn't been invented yet.
Compared to APL, FORTH is a model of usability and clarity. Actually compared to APL everything is a model of clarity and usability.
Forth is a open computer system, nearly everyone else has tried to provide a closed system that in some way protects itself from the end user, and in some cases from the programmer. So I suppose that makes it not just another language and something more than an operating system.
It tends to not impose authority on the user. It tries to empower the user to learn what really can and cannot be done.
That seems a pretty good summary of why Forth holds much appeal for some. The interactive programming environment is certainly part of it. Likewise, the almost blank slate and freedom that goes with that. Forth is unique, really difficult to pigeonhole: a seemingly primitive language that can do some very high-level things. While I'm convinced of its utility, I don't think Forth is something you can just dabble in and truly be productive. You have to commit to it.
I posted updates to the Spinix and pfth threads, which allows pfth to be run seamlessly under Spinix. A Forth program can be developed under Spinix using one of it's editors, such as vi, ed or ted, and then run under pfth by typing "pfth file.fth". The file could be edited further by using ted under pfth, or exiting back to Spinix with the BYE command. Try it out if you have a chance. I think it makes for a fairly nice development system.
The latest version of pfth supports sub-directories and two opened files at the same time. The sub-directories makes it easier to keep Forth code in it's own directory so that all the Forth and Spinix files are mixed in the root directory. The working directory is changed by using the CD command.
Having two files opened at the same time makes file I/O more flexible. It allows implementing the CP command by reading from one file and writing to another file, instead of first copying the entire file into memory before writing it out. It also allows for including Forth files from another file.
A Linux-like Propeller OS -- pfth 1.00 with SDcard
So, I am thinking, I have a Demo Board, VGA monitor, keyboard, and I purchase a Parallax memory card, can I get a stand alone system running, with the VGA monitor displaying in the old fashioned 80 x 24 format (at least something pleasing to the eye)?
So, I am thinking, I have a Demo Board, VGA monitor, keyboard, and I purchase a Parallax memory card, can I get a stand alone system running, with the VGA monitor displaying in the old fashioned 80 x 24 format (at least something pleasing to the eye)?
Ray
I actually use 2 Propellers -- one for a dumb terminal with VGA, and the other for Forth setup with SDcard. They interconnect via RS232 or RS422.
This allows me to swap freely between various versions of Forth on the Propeller as I have several boards with Forth installed... Tachyon, PropForth, and pfth.
Right now I am mostly enjoying pfth with SDcard in one of my Demo boards without the video and keyboard, but it is the ideal board to include video and keyboard. The SDcard slot fits nicely. The mouse port might be used for a barcode reader to make things even more interesting.
We have had systems with everything in one Propeller, like PropForth v3.5. I think it gets a bit crowded. If you don't need lots of unused cogs, it is feasible.
And Dave Hein has been pondering providing an 'all-in-one' setup. Did v1.02 accomplish that?
Peter J. has Tachyon Forth that may have already put it all together. But I am trying to learn more about ANSI Forth and haven't kept of with what the others have to offer.
==============
After thinking over the above, the real issue is that the video uses quite a bit of hubram, and the Forth dictionary also uses the hubram. Having one Propeller provide video, keyboard, and other i/o services, while another provides the Forth machine and GPIO seems to make a great deal of sense to me as hubram resources are not in conflict, and video has the chance to do more well.
Having it all fit in the Propeller Demo Board or a C3 is very appealing as both boards seem to offer the infrastructure to do so, but the fit is tight.. constrained.
Andre LeMothe's Hydra seemed to try to work around such constraints by additional SRAM. Nobody has yet to try to make a Forth with video on the Hydra with an add-on SRAM card.
It looks like the Propeller2 may arrive in September. All of the Forths on Propeller have promised ot provide code for it. With that chip, video, keyboard, and a full Forth system may be much more comfortable.
I haven't done the all-in-one setup yet. I've played around with a few display drivers, but they've used up a bit more memory than I would like to spare for them. Memory space is getting pretty tight in Spinix. However, an all-in-one setup might work OK for pfth. I'll have to try it out sometime.
I like the idea of using a second Prop serving as a dumb terminal, or even some other black box that can provide that functionality.
I haven't done the all-in-one setup yet. I've played around with a few display drivers, but they've used up a bit more memory than I would like to spare for them.
I've been searching for something reasonable too. The high-res vga driver is great with more than 80 columns, and a blinking cursor but it uses two cogs and around 6KB of hub-ram.
There is a way to get more lines and columns out of the standard vga_text.spin driver though, and I'm pretty happy with it so far. The driver will do 32 columns by 30 rows (vs about 15x13 for normal vga_text.spin) and uses only one COG.
Seems like the only real change to doing a 32x30 VGA display using normal VGA_Text.spin and VGA.spin is to set cols=32 and rows=30. Make sure vga_hx and vga_vx are both set to 1.
The 32x30 VGA display sounds interesting. I do have a 32x15 version of VGA_Text that is interfaced to Spinix. It uses a little over 1K of memory. I haven't spent much time on it, but maybe I'll look at it some more and try the 32x30 mode.
I haven't done the all-in-one setup yet. I've played around with a few display drivers, but they've used up a bit more memory than I would like to spare for them. Memory space is getting pretty tight in Spinix. However, an all-in-one setup might work OK for pfth. I'll have to try it out sometime.
I like the idea of using a second Prop serving as a dumb terminal, or even some other black box that can provide that functionality.
Very early on I purchased 3 Propeller Demo Boards with big expectations of a complete system within one free-standing device. Then I bought 10 Propeller Proto Boards, will similar expectations because of the VGA, Keyboard, and Mouse support. Forth came along much later. Nothing really jelled the way that I had hoped for, but Jeff Ledger and others did see that an ANSI terminal was an obvious Propeller project and got that working.
At this point, I like and am comfortable with the 2 Propeller solution... as development work and learning progess, Forth boards may become headless in actual service. Often, I just use the USB to my notebook and have no reason to use a dumb terminal. But if the project demands its own full-time video, I built the dumb terminnal to do it, and with RS422 I can have the remote be 4000 feet away. (I am thinking argricultural support items, monitoring greenhouses and pig farms, or home-automation networks.)
We are in for a 'sea change' with the Propeller2, it may easily do all-in-one, with the added capacity and/or added SRAM. But I still have that nagging feeling that as I begin to actually deploy Forth into real applications, even the Propeller2 will fare better as a headless application with RS232/rs422 interface for any servicing that is required.
Video is a rather gluttonous application that will always fare best with all it can get. Forth has similar appetites. The all-in-one Forth is likely to be a way stop on the path to more sophisticated systems. I do admit that it does make an excellent educational package for kids... eliminates a lot of loose wires and tangles.
Just consider, the video display itself is the major cost and seems to demand the best it can get to justify the cost.
I am not sure if that means the future will just jump to a two Propeller2 solution with a really powerful dumb terminal, or a combo of a Propeller1 and Propeller2.
And I still wonder if I need to back-track to an all-in-one Forth on a Propeller 1. It seems a distraction at this point. (BTW, I could; be wrong)
I have this gut feeling that we are not going to see a Prop2 chip until some time in 2014, and that is if everything is still working OK. That means that you probably will not see any support materials, like a Demo board with a Prop2 driving it, until probably a year from now. So I am thinking that you might as well start putting to good use the materials that you have right now.
My Demo board has been collecting dust for quite some time now, would be nice to have it used as a stand alone, with maybe a functional XBee, running maybe Spinix, to do some home automation with XBee modules? With the Parallax memory card for the Demo board, maybe my idea has good chance at becoming functional. Still not sure about it, though.
I agree that Prop 2, with support anywhere close to the abundance of HW & SW tools we currently have on Prop 1 is a good ways off. Meanwhile, we have 3 great Forths that are ready for real development NOW. Let's go! Let the early adopters work out the kinks and dev. on Prop 2. Put things into perspective; what we have right now is way beyond what we had a year ago, and light years ahead of anything out there 10-20-30 years ago.
I used to jump on every new SW beta and HW gadget only to pay the early adopter dues... and now it's old hat. At least that's what I tell myself: I do admit to lurking in on the Prop2 updates, but have to remind myself that what we have is pretty great, and ready to be productive with now.
I agree that Prop 2, with support anywhere close to the abundance of HW & SW tools we currently have on Prop 1 is a good ways off. Meanwhile, we have 3 great Forths that are ready for real development NOW...
I can't help thinking this is right, from a practical POV at least. The Prop 1 has constraints that the Prop 2 will presumably address - hopefully without creating new ones - but that's a ways off and plenty can be done here and now with Prop 1. (I wish they had aimed at a more modest, incremental upgrade; but perhaps that's only me.)
As Loopy points out, VGA consumes a LOT of resources. If the app is a display, then VGA is called for.
On the other hand, forth inherently allows "just a display & keyboard" as interface to the command line. For under $10, we can add HC05/HC06 and have a wireless connection to to the command line, and use any generic blue tooth terminal. ANY application can be made both stand alone, headless, and have an "at will" terminal interface. Using the ANSI extensions, we can do pretty sophisticated color and graphics, pretty much for free. The ANSI support on the propforth page has all you need, this can easily be ported to pfth if its not directly compatible. (Propforth is not 100% compatible with the standard, but its 99% compatible with common sense). The clear screen and row-column placement work on android, I didn't try the color and font yet but they should be ok.
The bluetooth + Android option pretty much gives you a compete retro forth system. Using an android app for all the user interface fucntion add on is very powerful. Please check this out.
My college required that we take a programming languages course in our sophomore year. Nobody blinked at Lisp, C, or Snobol, but APL was feared. Not only were programs unreadable, but they could only be entered on a terminal with APL keys on it. So it was physically harder to program in a language that everyone hated. I think APL was included in the course only because Brainf**k hadn't been invented yet.
Compared to APL, FORTH is a model of usability and clarity. Actually compared to APL everything is a model of clarity and usability.
I took an APL course as well and rather enjoyed it. Found the interactive nature and lack of punch cards and long waits for output a big plus. Even considered the special keyboard and symbols that made for such short and concise programs a big bonus.
I took an APL course as well and rather enjoyed it. Found the interactive nature and lack of punch cards and long waits for output a big plus. Even considered the special keyboard and symbols that made for such short and concise programs a big bonus.
That's the about programming languages, one man's meat is another man's poison.
However, it might also have been the era where we first encountered it. By the time I went to college in '83 interactive programming languages using CRT's were the norm. So I judged APL against languages like Basic, Logo and Lisp. Compared to them it seemed unnecessarily arcane.
I took an APL course about 40 years ago, so I've forgotten a lot of the details about it. I do recall that the language has nice features for doing matrix operations. The keyboard was interesting because it would lock up when running a program, and by "lock up" I mean that the keys would not go down. I suppose it was a way to prevent transmitting characters while the computer was busy running the program, but it seemed odd to me.
I can't help thinking this is right, from a practical POV at least. The Prop 1 has constraints that the Prop 2 will presumably address - hopefully without creating new ones - but that's a ways off and plenty can be done here and now with Prop 1. (I wish they had aimed at a more modest, incremental upgrade; but perhaps that's only me.)
I don't think the Propeller2 will provide an internal video font, but the Propeller 1 does. I am a bit uncertain how that will play out for an 'all-in-one' solution.
One item on my personal wish list would be for a Unicode dumb terminal that would display Chinese. The Propeller 2 might be able to do that. And if the Forth accepts 8-bit Unicode for dictionary use, you could actually program in native Chinese. But, this also requires a rather challenging keyboard conversion for input as there are about 7000 characters that need to be accessed. (There is an input system called Zang Jie that wil represent any character in 5 or less bytes/keystrokes -- but it obvious requires a rather large lookup table).
ANSI dumb terminal on the Propeller 2 may not be too demanding as ASCII requires less than 255 visual characters at the most. So, it may be optimal for an all-in-one regardless.
Personally, I prefer the Propeller (with X-Bee) over an Android + Bluetooth solution. Can one have a Propeller + Bluetooth linked to a PC + Bluetooth? (I have to admit I am ignoring Bluetooth for personal reasons.)
I do have an Android 4.xx system on a Cubieboard, but with a limited GPIO and a different OS it becomes another level of study and maintence. I am trying to figure out a 'best-use' for the Cubieboard, maybe as a 24/7 internet radio. Most of us already have a Windows or Linux system that can do Bluetooth, but I guess that I am not keeping up with new users that may start out with an Android.
I suppose that another reason I am not using the Android is that I'd have to assign another monitor and keyboard (and I already have three of each in use.) Too many projects means I get nothing done... the Propellers are adequate and cost effective for me.
APL, Lisp, Logo and such... back in the day of fast and furious expansion of computer languages. Thank heavens we have settled down from then. It all reminds of attempting to learn, Esperanto. Esperanto is a language that belongs to no one in particulary, so I doubts that anyone really can learn it well.
The Prop II has no font in ROM like the Prop I.
That only means you have to include the font table in your program.
Downside is that it eats RAM.
Upside is you can define your own fonts without wasting any more space.
No idea about Chinese and other complex symbols. Looks like you need a higher resolution screen for those than an ASCII screen. Perhaps the PII can handle the resolution required as well.
I guess in UTF-8 the Chinese characters will all be two or three bytes long so programs could end up somewhat bigger. But again the PII has more RAM.
The archive contains five fonts, and the number of times each scan line is displayed can be set in the driver, so this one driver provides the following text modes:
I haven't done the all-in-one setup yet. I've played around with a few display drivers, but they've used up a bit more memory than I would like to spare for them. Memory space is getting pretty tight in Spinix. However, an all-in-one setup might work OK for pfth. I'll have to try it out sometime.
I like the idea of using a second Prop serving as a dumb terminal, or even some other black box that can provide that functionality.
It looks like the Propeller2 may arrive in September. All of the Forths on Propeller have promised ot provide code for it. With that chip, video, keyboard, and a full Forth system may be much more comfortable.
I ported pfth to the Propeller 2 way back in December of last year. It was the first high-level language to run on the Propeller 2 as far as I know. My port of pfth predates my port of PropGCC. Of course, I'm sure Dave has made many changes in the Propeller 1 version since then so it will need to be ported again.
Comments
Preferably on a machine on prominent display in a store in the mall. And the run out chuckling.
Very simple. For many that is as far as it went. For a few it sparked that curiosity, "What else can this thing do?"
In the modern world there is no such simple and immediate hook to pull young minds into the idea of programming.
That is basically the motivation for the guys why built the Raspberry Pi. They want to get to the point that a youngster can turn it on and immediately do something. The Pi guys want to do this with Python and/or Scratch. We will see how that works out but it's worth a shot.
Perhps true but also perhaps also I don't know what you are getting at.
Looks to me as if "real" languages, like English, are very powerful and expressive and general purpose. Such languages are also full of subsets. For example there is a subset of English used by doctors, with a lot of latin thrown in, which most English speakers might not understand. There is a subset used by the lawyers and the legal system. There is a subset use by pilots and air traffic control.
These subsets are domain specific with the aim of being clear, concise, efficient and accurate in that domain.
I will make the bold claim that the C programming language, for example, is a such a subset of English. With the express purpose of clearly stating the intent of a program/algorithm.
C is obviously not much use at some normal everyday things like "How are you today?" or higher level things like discussing the meaning of language. But it is pretty good at expressing a particular subset of ideas that humans have.
For fun, have a listen to Chompsky speaking about linguistics and you will start to wonder what language he is speaking. Could be English but I don't understand a word of it.
It includes the interactive prompt. It would require extended memory...
But whenever I try Forth or something similar I am forced to use an environment which does not anymore fit with how I do programming. Won't go too much into that, so I'll try to sum it up like so:
- I like interactive debugging tools. Dumping memory, inspecting registers and code etc.
- I like non-interactive programming. I want to see my code in a big editor where I can look at everything up and down at all times. XEmacs style..
- I don't like building up my program interactively. Doesn't work for me. That time is past. I wrote basic programs that way back in the dawn of the microcomputer era. I moved on to a better way and can't go back.
- I *think* in modules and building elements from elements, but my mental way of doing it doesn't fit with using an interactive language.
Then comes file handling (or the lack of) etc.As an example, I like writing debuggers.. interactive debuggers. But I would never write the debugger interactively! The joy is in using an editor, a compiler, a Makefile, and update my debugger source code whenever I need one more feature. Build it, then use the new debugger interactively.
-Tor
Regardless of any language merits what we have in Forth is a way for people to:
1) Talk to their machine in a somewhat higher level than binary or HEX or assembler.
2) Poke around and see what the machine does.
3) Enter programs and data into the machine.
4) Edit those programs and data.
5) Run those programs.
6) Have results output.
Well of course that sound like any operating system and many language systems. Those requirements could be met using languages like BASIC, Python, PHP, JavaScript, Lua, Scheme, Lisp and many others.
So let's throw some more requirements on there:
7) Must be small, fitting into the few K Bytes of space on a typical MCU or such system.
8) Must run code reasonably efficiently.
That pretty much rules out Python, JavaScript, in fact probably all the languages I might have listed above, their implementations are just too big. Except possibly BASIC.
So we are left with Forth because it is the only one with any hope of meeting the requirements.
Why is that?
Well, seems to me for the language implementation to be small the language itself must be very simple with a minimum of syntax to parse or semantics to implement.
And that leads to the stack based, post fix style of Forth.
So my question is: Is it so that Forth is not just another language syntax chosen at random but actually necessary to solve the problem as stated above?
Is it the only solution? Is there somewhere a language that can achieve similar functionality in similar small spaces without the stack based approach that gives so many problems.
I just don't know what might be more suitable, or even equally suitable.
=============
@Heater,
Since 1994 I have been teaching English as a 2nd language, and studying Mandarin Chinese and Taiwanese. I even studied graduate classes via distance learning with the University of Edinburgh.
I have had a lot of Taiwanese students that have pursued the study of English as if it were a compuer language, but generally with poor results. They attempt to enforce rigorous logic to justify what they needed to learn and retain, the often seek only one good answer for everything (language tends to never have just one answer), and they expect to achieve results in a very short period of time.
What I have observed is that since 1994, my knowlege of language has expanded vastly and is still doing so. And, the topic is forever changing with new trends. Meanwhile, that crowd of students that thought an actual language could be mastered in the same way as a computer language have disappeared.
I started with programing to create a phonological program to represent English to Chinese students with clues on how to pronunounce English in spite fo a huge mess in how actual spelling represents a word (We have 5 vowels, that represent about 25 sounds, that are combined in about 125 combinations -- the odds are against the learner ever learning to read phonology accurately through the popular Phonics).
That was really too much for me in MS Windows. It became obvious I had to master the Windows GUI, the fonts, and much more. But it got me started with BasicStamps.
Computer programming languages are only languages in the analogous or metaphorical sense. And yet, there are still a lot of computer programmers that won't admit that. Just show me how to debate meaning in Python or C and I will back down from my position.
The computer language is for talking to computers, and can be use for humans to talk to each other about what computers do (maybe), but we say different things in natural language versus computer language versus mathematics versus x. The primary issue is the ability of the writer/speaker to express the idea. If the write babbles, or over condenses with jargon and acronyms, or just doesn't understand the concept, communication will be hindered. These are the cause of most issues with computer programs as with human communication. So there are simillarities , but these are tools for different applications.
This is entirely possible. The folks that know the most about computer languages, and have a detailed knowledge of the suitability of one tool versus another for a specific application, often reach this exact conclusion.
It tends to not impose authority on the user. It tries to empower the user to learn what really can and cannot be done.
It seems you are headed towards asserting that all computer languages are a sub-set of English, and that mathematics might even be a sub-set of English.
Subjects, such a mathematics, medicine, engineering do have their own ways of creating precise meaning, but none of them are a sub-set of a language. They are subjects, no language components. Computer programing is a subject. The fact that we use the alphabet and other keyboard symbols to create a 'programing language (system?)' is just due to a whim of history. A lot of innovations result in having a default to the language of origin. Airplanes have accepted English as the prime language of airports due to the Wright Brothers; post offices and passports still use a French lexicon due to their origins.
I don't thing C is any more a language than algebra is or chemistry.
Forth confuses the issue even more as it often looks like real words, but it doesn't have too.
Compared to APL, FORTH is a model of usability and clarity. Actually compared to APL everything is a model of clarity and usability.
The latest version of pfth supports sub-directories and two opened files at the same time. The sub-directories makes it easier to keep Forth code in it's own directory so that all the Forth and Spinix files are mixed in the root directory. The working directory is changed by using the CD command.
Having two files opened at the same time makes file I/O more flexible. It allows implementing the CP command by reading from one file and writing to another file, instead of first copying the entire file into memory before writing it out. It also allows for including Forth files from another file.
Ray
I actually use 2 Propellers -- one for a dumb terminal with VGA, and the other for Forth setup with SDcard. They interconnect via RS232 or RS422.
This allows me to swap freely between various versions of Forth on the Propeller as I have several boards with Forth installed... Tachyon, PropForth, and pfth.
Right now I am mostly enjoying pfth with SDcard in one of my Demo boards without the video and keyboard, but it is the ideal board to include video and keyboard. The SDcard slot fits nicely. The mouse port might be used for a barcode reader to make things even more interesting.
We have had systems with everything in one Propeller, like PropForth v3.5. I think it gets a bit crowded. If you don't need lots of unused cogs, it is feasible.
And Dave Hein has been pondering providing an 'all-in-one' setup. Did v1.02 accomplish that?
Peter J. has Tachyon Forth that may have already put it all together. But I am trying to learn more about ANSI Forth and haven't kept of with what the others have to offer.
==============
After thinking over the above, the real issue is that the video uses quite a bit of hubram, and the Forth dictionary also uses the hubram. Having one Propeller provide video, keyboard, and other i/o services, while another provides the Forth machine and GPIO seems to make a great deal of sense to me as hubram resources are not in conflict, and video has the chance to do more well.
Having it all fit in the Propeller Demo Board or a C3 is very appealing as both boards seem to offer the infrastructure to do so, but the fit is tight.. constrained.
Andre LeMothe's Hydra seemed to try to work around such constraints by additional SRAM. Nobody has yet to try to make a Forth with video on the Hydra with an add-on SRAM card.
It looks like the Propeller2 may arrive in September. All of the Forths on Propeller have promised ot provide code for it. With that chip, video, keyboard, and a full Forth system may be much more comfortable.
I like the idea of using a second Prop serving as a dumb terminal, or even some other black box that can provide that functionality.
There is a way to get more lines and columns out of the standard vga_text.spin driver though, and I'm pretty happy with it so far. The driver will do 32 columns by 30 rows (vs about 15x13 for normal vga_text.spin) and uses only one COG.
Seems like the only real change to doing a 32x30 VGA display using normal VGA_Text.spin and VGA.spin is to set cols=32 and rows=30. Make sure vga_hx and vga_vx are both set to 1.
Very early on I purchased 3 Propeller Demo Boards with big expectations of a complete system within one free-standing device. Then I bought 10 Propeller Proto Boards, will similar expectations because of the VGA, Keyboard, and Mouse support. Forth came along much later. Nothing really jelled the way that I had hoped for, but Jeff Ledger and others did see that an ANSI terminal was an obvious Propeller project and got that working.
At this point, I like and am comfortable with the 2 Propeller solution... as development work and learning progess, Forth boards may become headless in actual service. Often, I just use the USB to my notebook and have no reason to use a dumb terminal. But if the project demands its own full-time video, I built the dumb terminnal to do it, and with RS422 I can have the remote be 4000 feet away. (I am thinking argricultural support items, monitoring greenhouses and pig farms, or home-automation networks.)
We are in for a 'sea change' with the Propeller2, it may easily do all-in-one, with the added capacity and/or added SRAM. But I still have that nagging feeling that as I begin to actually deploy Forth into real applications, even the Propeller2 will fare better as a headless application with RS232/rs422 interface for any servicing that is required.
Video is a rather gluttonous application that will always fare best with all it can get. Forth has similar appetites. The all-in-one Forth is likely to be a way stop on the path to more sophisticated systems. I do admit that it does make an excellent educational package for kids... eliminates a lot of loose wires and tangles.
Just consider, the video display itself is the major cost and seems to demand the best it can get to justify the cost.
I am not sure if that means the future will just jump to a two Propeller2 solution with a really powerful dumb terminal, or a combo of a Propeller1 and Propeller2.
And I still wonder if I need to back-track to an all-in-one Forth on a Propeller 1. It seems a distraction at this point. (BTW, I could; be wrong)
My Demo board has been collecting dust for quite some time now, would be nice to have it used as a stand alone, with maybe a functional XBee, running maybe Spinix, to do some home automation with XBee modules? With the Parallax memory card for the Demo board, maybe my idea has good chance at becoming functional. Still not sure about it, though.
Ray
I used to jump on every new SW beta and HW gadget only to pay the early adopter dues... and now it's old hat. At least that's what I tell myself: I do admit to lurking in on the Prop2 updates, but have to remind myself that what we have is pretty great, and ready to be productive with now.
As Loopy points out, VGA consumes a LOT of resources. If the app is a display, then VGA is called for.
On the other hand, forth inherently allows "just a display & keyboard" as interface to the command line. For under $10, we can add HC05/HC06 and have a wireless connection to to the command line, and use any generic blue tooth terminal. ANY application can be made both stand alone, headless, and have an "at will" terminal interface. Using the ANSI extensions, we can do pretty sophisticated color and graphics, pretty much for free. The ANSI support on the propforth page has all you need, this can easily be ported to pfth if its not directly compatible. (Propforth is not 100% compatible with the standard, but its 99% compatible with common sense). The clear screen and row-column placement work on android, I didn't try the color and font yet but they should be ok.
The bluetooth + Android option pretty much gives you a compete retro forth system. Using an android app for all the user interface fucntion add on is very powerful. Please check this out.
I took an APL course as well and rather enjoyed it. Found the interactive nature and lack of punch cards and long waits for output a big plus. Even considered the special keyboard and symbols that made for such short and concise programs a big bonus.
That's the about programming languages, one man's meat is another man's poison.
However, it might also have been the era where we first encountered it. By the time I went to college in '83 interactive programming languages using CRT's were the norm. So I judged APL against languages like Basic, Logo and Lisp. Compared to them it seemed unnecessarily arcane.
I don't think the Propeller2 will provide an internal video font, but the Propeller 1 does. I am a bit uncertain how that will play out for an 'all-in-one' solution.
One item on my personal wish list would be for a Unicode dumb terminal that would display Chinese. The Propeller 2 might be able to do that. And if the Forth accepts 8-bit Unicode for dictionary use, you could actually program in native Chinese. But, this also requires a rather challenging keyboard conversion for input as there are about 7000 characters that need to be accessed. (There is an input system called Zang Jie that wil represent any character in 5 or less bytes/keystrokes -- but it obvious requires a rather large lookup table).
ANSI dumb terminal on the Propeller 2 may not be too demanding as ASCII requires less than 255 visual characters at the most. So, it may be optimal for an all-in-one regardless.
Personally, I prefer the Propeller (with X-Bee) over an Android + Bluetooth solution. Can one have a Propeller + Bluetooth linked to a PC + Bluetooth? (I have to admit I am ignoring Bluetooth for personal reasons.)
I do have an Android 4.xx system on a Cubieboard, but with a limited GPIO and a different OS it becomes another level of study and maintence. I am trying to figure out a 'best-use' for the Cubieboard, maybe as a 24/7 internet radio. Most of us already have a Windows or Linux system that can do Bluetooth, but I guess that I am not keeping up with new users that may start out with an Android.
I suppose that another reason I am not using the Android is that I'd have to assign another monitor and keyboard (and I already have three of each in use.) Too many projects means I get nothing done... the Propellers are adequate and cost effective for me.
APL, Lisp, Logo and such... back in the day of fast and furious expansion of computer languages. Thank heavens we have settled down from then. It all reminds of attempting to learn, Esperanto. Esperanto is a language that belongs to no one in particulary, so I doubts that anyone really can learn it well.
That only means you have to include the font table in your program.
Downside is that it eats RAM.
Upside is you can define your own fonts without wasting any more space.
No idea about Chinese and other complex symbols. Looks like you need a higher resolution screen for those than an ASCII screen. Perhaps the PII can handle the resolution required as well.
I guess in UTF-8 the Chinese characters will all be two or three bytes long so programs could end up somewhat bigger. But again the PII has more RAM.
Sounds, quite doable.
You might find the following single-cog 50 column driver useful for sphinx/pfth:
http://forums.parallax.com/showthread.php/129769-50-column-VGA-text-driver-in-one-cog-60-50-40-30-25-20...rows!-%28RELEASED%29
The archive contains five fonts, and the number of times each scan line is displayed can be set in the driver, so this one driver provides the following text modes:
50x75, 50x60, 50x50, 50x40, 50x30, 50x25, 50x20
50x15, 50x12, 50x10, 50x8, 50x6, 50x5
For lowest memory usage, I'd recommend the 50x30 or 50x25 configuration.
The output is 800x600@60Hz (40Mhz dot clock) using the standard 5Mhz crystal.