Subject:
|
Re: Why Java for Robots (was NXT and bluetooth enabled phones)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 18 Jan 2006 19:20:23 GMT
|
Original-From:
|
Bruce Boyes <bboyes@systronix^spamcake^.com>
|
Viewed:
|
1596 times
|
| |
|
|
At 07:58 AM 1/17/2006, PeterBalch wrote:
> > In lugnet.robotics, PeterBalch <PeterBalch@compuserve.com> wrote:
> > for robots, Java requires a ludicrously huge virtual
> > machine.
What do you consider "ludicrously huge"?
Java for robots in fact does not require a virtual machine at all, it can run
on a Java implementation in silicon. We've been using this for about 4 years,
and so have classes at the Univ of Utah and other universities. Plus this
approach is now in several commercial products in the US, UK, Malaysia,
Europe, etc; it's a commercial reality.
> > I was looking into Java as a small-robot programming language and examined
a few implementations. I came to the conclusion that it simply wasn't
suitable. Sure you can shoehorn a cut-down version into a small processor
but you've had to remove so much that what's left hardly counts as Java.
See comments above. I come to a different conclusion, here's some of my
opinion on the matter:
http://www.practicalembeddedjava.com/WhyJava.html
J2ME/CLDC is the smallest real (meaning Sun certified implementation of a
standard Java edition and configuration) Java we use. It's not perfect but
overall I really like it. It's possible to write complex things much more
quickly and reliably than C, and we can share code and tools across the
embedded end, PC, and IT systems very smoothly. Java is currently the best
tool in such a case.
> > IMHO Java is just another run-of-the-mill language. It's C++ with the nasty
parts taken out. (Which to me means that it's object-oriented Pascal with
curly brackets.)
> > I want to be convinced otherwise because maybe I'm missing out on something
wonderful. I'm no Java expert so maybe I'm talking complete drivel.
Java is a decade or two newer than C++ and a few decades newer than C. It's
not perfect or magical, but it does incorporate more "state of the art"
thinking and technology than languages which are much older. We use Java, C,
and assy code in our commercial development. Each has its place. They are all
just tools, really.
> <scratches head> OO is not the only way to do this. It is not clear
> to me that the overheads of Java (relative to say a brickOS / C
> combination) are worth it on the RCX, especially as you have to
> manage memory manually in both cases anyway.
> Spot on!
> What makes Java special are the class libraries and the garbage collection.
> It absolutely requires an enormous heap and a garbage collector - neither
of which make it suitable for a small robot.
This has not been a true statement for the last five years or more. You may as
well say "laser printers will never be affordable for the small office" -
which used to be true too.
> And most of the standard Java class libraries are concerned with graphics,
windowing and string handling so aren't relavent.
We use lots of standard packages for serial I/O, data manipulation,
hardware-based I/O (SPI, I2C, 1-Wire, ethernet) on small Java systems. We
don't use any graphic packages yet on small Java.
> And what use are Objects anyway? (Heresy!?)
> I use them all the time in Delphi and they're great because 99% of the
objects I use are associated with something that appears in the user
interface. I drag a button into the window and an object appears in my
program that I can talk to. How useful is that in a robot? Sure, I could
have an object that corresponds to a pushbutton or Sonar but does that make
programming easier? Easier than just a library of subroutines? I haven't
found it so.
You seem to confuse "GUI" design with "Object Oriented Design". Graphical User
Interfaces are but a small subset of OO design.
Objects, properly applied, *can* be a huge benefit. But like any other tool
you can write crummy code in an OO language too. Many books have been written
on this. Here's one reference at CMU:
http://www.sei.cmu.edu/str/descriptions/ooanalysis_body.html
What's between the programmer's ears is still more important than any tool.
> > Objects are wonderful in their place. I just don't think their place is in
small robots. If I'm writing a Windows business application (yuk) where,
say, clients arrive, have transactions and depart then Objects would be the
way to do it. But robots aren't like that.
This is not at all the experience of my students or colleagues.
> > Especially not if Objects require the huge overhead of a heap and garbage
collection.
An assumption with little basis in reality, today. In J2ME/CLDC on our
aJile-based systems you can turn off GC if you want, and statically allocate
all data. No GC. Or you can statically allocate some, on a thread basis, and
have a realtime high priority thread which preempts the GC. Let the lower
priority threads which need a lot of dynamic data allocation use GC.
> > Lets compare Java-plus-objects with old-time Fortran-plus-subroutines.
> > Java treats all objects as dynamic. Java treats the stack as dynamic. That
is a mistake in a small processor with limited memory.
This is simply not true in all small Java implementations. We use static
objects all the time. The Java stack is used for local variables; this is no
different from C, is it?
What is "limited memory"? Our smallest system (JStamp+) has 512 KByte RAM and
2048 KByte flash. We stopped making the version with 512 KByte flash because
now the 2048 KByte parts are the same price.
This is enough memory to run AI in an autonomous checker playing bot, which
two student teams were able to write in 1/2 semester. (Try that in C or assy
code.)
> > Old-time Fortran treated all data allocation as static. A good Fortran
compiler will analyse the subroutine calls and work out which local
variables cannot be used concurrently. That's exactly what's wanted for a
small processor with limited memory.
Limited memory 20 years ago meant something different. Come on, it's 2006.
There are still people who lament the passing of DOS and the Commodore 64.
Many long for "the good old days" which, when they were occurring, were "these
trying times".
> > It seems to me that it would be perfectly possible to write something that
looked superficially like Java-plus-objects but where everything was
statically allocated. (Am I right? I know lots about writing compilers but
very little about Java. Because Java is a better designed language than
C++, it should compile to smaller code. Pascal is even better in that
respect.)
You can statically allocate everything in Java now... in fact, in dealing with
I/O devices, it often makes the most sense to have just one, static, instance
of a class, such as a SPI interface. If there's only one set of actual SPI
hardware, you only need one instance of a class to encapsulate it. In that
case we use a static initializer to instantiate that static class.
> > In 1980 I had a DOS Fortan compiler that would generate code to run on a
ZX81 (a Z80 machine with 1k RAM for data and program). Java and C++ live in
the world of Windows Software Bloat. Hobby roboteers live back in the
1980s.
Ah ha!! There you hit it! "Hobby roboteers live back in the 1980s".
There's no need to be stuck in the 80's any more. It's 2006. Come on out and
enjoy the benefits of the last 20 years! You may like it!
When C came into the embedded space, the assembly code naysayers (and those
who didn't want to learn something new) were violently opposed to it, on
general principles.
Best regards
Bruce Boyes
PS for some reason when I just hit "reply" and try to send that from Eudora
(my mail program) the list bounces it back with the error:
<lego-robotics@crynwr.com>:
ezmlm-reject: fatal: Sorry, I don't accept messages of MIME Content-Type
'text/html' (#5.2.3)
But I'm not sure how I accidentally create MIME content just by hitting reply
and adding text. Anyone have an insight?
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
