[Cuis] Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)

Casey Ransberger casey.obrien.r at gmail.com
Wed Dec 18 00:27:44 CST 2013


Maybe, maybe not. I'm less worried about the GC -- Ungar's generation
scavenging algorithm is pretty good even in real time -- but in the rare
cases where bugs can kill (and do feel free to stone me to death for saying
so) I think the nuisance of type safety may outweigh the convenience and
expressiveness of dynamic typing; anyway it often will matter to decision
makers. The other thing that might be an issue is concurrency, but I think
there are pretty straightforward ways of dealing this this.

In terms of performance and popular strategies for efficient
implementation, Smalltalk isn't terribly different from Java, which is used
in embedded systems all the time; note that the JVM has several tunable
garbage collection strategies to accommodate different spheres of
application (from applets, to web servers, to phones, to servo control, and
so on.)

It's a shame that Sun fired photon torpedoes into Strongtalk, as it had
optional strong typing and a fast VM (which was eventually co-opted by Java
and renamed Hotspot.) Something like that might be preferable for
life-or-death applications. One can take advantage of convenience and blow
off types while nailing down the prototype with test pilots (who are, after
all, in the business of being test pilots!) and then move on to a more
bullet-proofed implementation as the prototype matures into a product.

It's all relative. I'd *much* rather my car drive itself using Smalltalk
than C++! At least the arrays are bounds checked and we don't get memory
leaks, protection faults, or (perhaps most chillingly!) buffer-overruns.

SecureSqueak is a thing. It's beyond my experience at present, but might be
worth looking into if you are concerned about the safety of your end users!

The DoD has long mandated the use of Ada for these kinds of things. I must
admit though: I'm really not sure. Life-or-death applications tend to get
pretty rigorous testing, or should, and so-called "type safety" may be
overrated (one often ends up casting between types so much one may as well
be a duck to begin with, etc.) And Ada complains. A *lot.* I wouldn't call
it well suited to rapid prototyping, but it has just about every safety
feature (bunk or not, you decide!) known to programmers.

If you're curious about the generation scavenging algorithm, you can read
the original paper here:

https://www.cs.purdue.edu/homes/hosking/690M/p157-ungar.pdf

And since I brought it up, this is Ada:

http://en.wikipedia.org/wiki/Ada_(programming_language)

No cars yet that I know of, but there have been some previous explorers in
the Smalltalk robotics space so I'll throw a couple of links out there.

The first is NXT Talk which is a custom VM that runs on the Lego robotics
smart brick, and uses Squeak as a development environment:

http://www.hpi.uni-potsdam.de/hirschfeld/projects/nxtalk/

The other is a project called Physical Etoys, which builds upon the popular
children's authoring environment:

http://tecnodacta.com.ar/gira/projects/physical-etoys/

I do recall hearing about some robotics stuff to do with MIT Scratch, but
unfortunately I can't recall enough keywords to find the project.

--Casey


On Tue, Dec 17, 2013 at 9:37 PM, Kirk Fraser <overcomer.man at gmail.com>wrote:

> Thank you for the articles.  I spent a lot of time today looking at Python
> and I do like Smalltalk best.  But tell me, would you trust Cuis or any
> Smalltalk to run your driverless car - during garbage collection?
>
>
>
> ------------------------------
> View this message in context: Re: Audio and Video Object Analysis<http://forum.world.st/Audio-and-Video-Object-Analysis-tp4730295p4730877.html>
> Sent from the Cuis Smalltalk mailing list archive<http://forum.world.st/Cuis-Smalltalk-f4632260.html>at Nabble.com.
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20131217/602dce9e/attachment-0003.html>


More information about the Cuis mailing list