| |
Ralph Hempel wrote:
> 1. Waaaaay back when a well-equipped mini-computer had 32K of RAM, a couple
> of terminals, and a hard disk with 10Mb capacity, programmers would enter
> their programs via punched cards, or the terminals. They would submit
> their source for compilation, and go for coffee. When they came back, the
> compiler would point out a few syntax errors, and the cycle would begin again.
>
> I'm not anxious to return to those days, but the point is that the RCX is
> the equivalent of a decent minicomputer 20 years ago.
Neither am I... but the fact is that it's not 20 years ago. My attitude
is why use computers as if we are? (btw, I was programming back then...
and I must confess that there are a few things I miss about programming
in that era [most notably, that programming back then was a whole lot
simpler than it is now], but I cannot say I have any desire to return
there).
> 2. The original Forth was developed on such a minicomputer. For that matter,
> so was UNIX. It allowed the programmers of the day much finer grained control
> over CPU resources. In those days, you didn't worry too much about porting
> from one platform to another, you might worry about making different terminals
> work with your system. This was the genesis of the "termcap" file so familiar
> in *NIX systems today. The Wyse vs DEC terminal debates were like the Windows
> vs Mac vs *NIX debates today.
>
> Once again, not the best of programming times, but Forth and *NIX offered a
> quantum leap in the ability of programmers to control their machines.
Yes... but trying to going back to that development environment today
is, at the very least, a few steps backwards (IMO).
> 3. pbForth was developed so that almost any source of serial communications, from
> an HP calculator, to a PalmPilot, to a PC, Mac, or *NIX machine could interact
> with the RCX in a simple way.
>
> Once the firmware is loaded, all you need is a dumb serial link. Now I agree that
> the RCX is not the best place to compile bytecodes, but on the other hand, users
> of pbForth do not need to mess with compilers and other cross-platform issues.
Okay, thanks for explaining your rationale. However...
The simple fact is that real-world software development is done these
days by doing almost all of the work on moderately to very sophisticated
desktop computers, with (usually) pretty powerful operating systems.
Once the software has been developed and debugged to a satisfactory
extent, it is then moved onto a smaller platform that is more
commensurate with what the layperson of the day owns. I see no reason
why RCX development should be any different. While the methods you
describe worked just fine in the 70's, and I will agree that they may
work just as well today, the point I am making is that I do not think we
should settle for "just as good as 20 years ago" when computers are so
much more sophisticated today than they were then.
As for the porting issues, it is relatively simple to develop a compiler
that does not deviate from ANSI C (as simple as writing a compiler can
actually be, at least). And doing so would make such a system
completely portable across all platforms that provided such a
development system (that is, most systems today). All that is then
required for the end user of the compiler is to know how to compile it
with whatever native C compiler he or she happens to have (not an
unreasonable requirement, actually... because if they are computer
literate enough to be able to make use of a different programming
language, they probably know how to run things like make and cc).
Further, precompiled binaries can always be maintained for the most
common platforms that do not always have a C compiler present (DOS,
Windows, Mac, for example). No binaries would be necessary for the
different Unices, IMO, because most Unix systems pretty much always have
a C compiler present. And again, if they are sophisticated enough to be
using such a system, they would probably know how to compile a package
with it. Hey... you could even throw in an compiling and installation
guide, just in case.
The issue of uploading the files to the RCX is not as portable as
compiling, of course... but if you isolate the communication program
from the compiler, porting it would not be too complex, and as a
fundamentally simpler program, you may be able to quickly find
volunteers who would assist in porting efforts. As it sits, NQC comes
with such a program program already.
The idea of being able to do development on something like an HP
calculator is kind of interesting, but cannot really be seen as much
more than a novelty, given what the average home computer can do today.
Software for the HP itself is often fully developed and tested on
desktop computers before being uploaded to the HP calculator.
> You edit the file and submit it (hopefully without errors) to the RCX for
> compilation. This might make you think carefully about checking the source
> for errors before you ask the RCX to compile it.
As I said before, I think this is a step backwards from where we are
today.
> 4. The RCX should never be considered the "dumber" end of the system. It has
> all of the comuting brains needed for even fairly complex algorithms - we just need
> to get better at designing algorithms that work around the other limitations.
But it is "dumber"... by definition. There's only so much complexity
that you can squeeze out of a given piece of hardware, given a finite
amount of RAM. This fact is incontrovertable. No matter how
sophisticated algorithms get, you cannot transcend the physical
limitations of the hardware without changing the hardware. The average
home computer today has more than a thousand times more memory than the
RCX (and that amount is growing). Since you cannot add expansion cards
to the RCX, it simply follows the mathematical axiom that an unbounded
system will be larger than *ANY* finite system. Of course, if all
you're using to talk to the RCX is a terminal or terminal program, then
yes... the RCX *IS* the smarter end of the system.
> I know it seems as if I'm pushing pbForth as a magic bullet sometimes. I have been
> getting emails from all over the world asking me for more materials, suggestions for
> improvements, and even contributions of code. It's not for everyone, though.
Actually, I really *LIKE* Forth as a language. It has an elegance about
it that is unmatched by most languages today. I just can't say I
approve of the idea of using the RCX as one would have used a mainframe
or minicomputer in the 70's.
> I welcome discussions like this because it gets me to take a step back and think
> about where pbForth is going. Thanks for prompting me. I'll probably add this
> as well as some more history to my website soon.
Thanks for taking my criticisms constructively.
> > Mark
|
|
Message has 1 Reply:
 | | Re: Thought on pbForth
|
| I am new to this group so please forgive this reply to an old thread. I've been doing embedded realtime software for over 20 years. A small amount of that has been using FORTH. The question is what does FORTH add to robotics software development? To (...) (24 years ago, 19-Apr-00, to lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | RE: Thought on pbForth
|
| (...) Wow! Great company indeed! (...) This would be a good idea, and one day, pbForth will get there. I used to ship a Tcl based shell with pbForth, but it wasn't working well on all platforms. Here's why pbForth is the way it is, and forgive the (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.pbforth)
|
7 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
