Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 May 1999 02:33:30 GMT
|
Original-From:
|
stephen p spackman <STEPHEN@ACM.ORGspamcake>
|
Viewed:
|
1568 times
|
| |
|
|
Stephen's view:
-> We want something higher level than FORTH or C so that it will be
usable by *everyone*. We also want something higher level than NQC so it
will be *usable* by everyone.
In short, for semantic level we'd like something that puts Lisp and
Smalltalk to shame.
-> We want something simpler than FORTH or C so that it will be *usable*
by everyone. We want something simpler than NQC so it will be usable by
*everyone*. Simple enough to implement in a few days would be good, too.
So for complexity we want something simpler than (say) LOGO or TCL.
-> We want something tolerably fast and tolerably dense, since we're
constrained on both axes.
Which means that, yes, we want fast interpretive techniques such as a
tight bytecode interpreter or a FORTH kernel, with an offline compiler.
-> We want distributed programming, with code running both on multiple
RCXs and on multiple host machines, under the same programming model (if
you've got a DACTA box, it should look like a fat, non-mobile RCX...).
Which implies, to me, that we want a second interpreter for the same
bytecode written in Java or C or C++ or Perl.
-> It *should* be garbage collected. No beginning programmer - and no
programmer of reusable components - needs be burdened by explicit memory
management. Any runtime overhead will be overshadowed by an interpretive
implementation anyway. (Why does GC have such a bad rep? It's a sine qua
non of high level programming - for non-real-time programming it's
actually *faster* than explicit management, though I suspect we'll need
some kind of incremental algorithm.)
-> It should *not* (to address a previous point) have floating point,
which is useful only for physics simulations with insane dynamic ranges;
32 bit ints are probably overkill for anything that an RCX is ever going
to do, and promote better programming practise IMO. (Are we really
dealing with physical values with a four billion to one range?) It's a
feature that's only put into languages to support the hardware; here
there's no hardware to support, so leave it out.
-> It *is* going to have real-time features, including something akin to
multiple threads and some kind of synchronisation. Personally I advocate
a non-pre-emptive reactive-programming arrangement (it has very low
synchronisation overhead and a trivial programming model; it shouldn't
have to be any worse on modularity). But that may only be because I have
a model for this that I want to try out.
Ok, now to the features which I want but which undermine the case for
this design I've been working on here :-).
-> It *should* have static type checking.
The problem with this one is that the type theory guys are (still)
lagging; we don't yet have a good type theory with Type : Type, which
means that strong typing is still in conflict with high level
programming. For small systems (as opposed to real engineering) I'd
rather fly without the seatbelts, but YMMV. (This is not to say that
*no* static typechecking should be done, but that the language level may
suffer if it is made focal as it is in Java, which you observe badly
needs first class classes and doesn't really have them.)
-> It should have exceptions or something.
I have a nice semantic model for exceptions, but it absolutely relies on
strong typing, and I've already told you my problem with that. Without
it, it's really quite difficult to give a clear model of what they do
and there are some major modularity issues to do with signal name
scoping.
[BTW, unless we are a lot cleverer than Sun, I don't think we can do JVM
on the RCX because of the *data* representation: objects seem to require
a length, a dope vector, a hash code field, and a mutex lock at a
minimum; I think we measured an empty string at 32 bytes (suggesting
that they use four-pointer cells?) - even with cleverness, that won't
drop below 8 bytes.]
stephen
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message is in Reply To:
 | | Re: Something else is needed, I think...
|
| (...) So this is a nice start at least. Regarding things you like, I'm going to ignore 1) and 6) because they are not features of byte code, they are features of Java; you either use the JVM and you get them, or you do not use the JVM and you do not (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
67 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
