| |
Ralph,
This is something that has been bothering me about pbForth ever since
you developed it... please do not take this as an attack against you or
your efforts. I do, in fact, truly believe that you have contributed
significantly to RCX programming - in the same league as David Baum and
Markus Noga.
However...
While I can understand the need for something along the lines of a
byte-code interpreter being necessary on the RCX - I do not see any
benefit to using the RCX like a mainframe system, where you hook up to
it via a dumb terminal, and let the RCX do all the work. Considering
the RCX's tiny size (not physically, but memory-wise), I see it as much
more practical to consider the RCX as the "dumb"(er) end of the
connection. You edit the source code as desired on the PC, compile it
on a PC, and let the PC detect the errors that can be seen in the source
code, then upload *ONLY* the object code to the RCX, where a bytecode
interpreter (which is assumed to always be resident) can execute the
program.
This is, basically, how NQC operates... but my biggest beef with it is
its reliance on the standard Mindstorms firmware, whose limitations (the
standard firmware, not NQC in particular) make it frustrating, at the
very least, by people accustomed to real-world software development.
> > Mark
|
|
Message has 1 Reply:
 | | 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
|
|
|
|
