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

[Casey Ransberger]

Inline. Bert CC'd because I think he'd know what was going on with Secure
Squeak for some reason, I think he's brought it up before.


On Wed, Dec 18, 2013 at 12:31 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 18 December 2013 06:27, Casey Ransberger <casey.obrien.r at gmail.com>
> wrote:
> > 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.
>
> GC's a bit of a red herring.


This is what I was trying to say above. With Ungar's alg, pauses are down
to fractions of a second, which is the problem the OP was concerned about,
pauses in GC leading to catastrophe on the road. I think it's mostly a
non-issue, because even with an occasional tiny pause, the machine still
has better reflexes than a human ever can, which meets one of the goals of
a car on autopilot.


> First, it's not that big a problem for
> almost all applications anyway, and second, people like Azul have
> shown that you can built a real time GC (for Java, which means for
> Scala and Clojure).
>

Again, I'm sure there's been lots of great work here, but with machines as
fast as they are now, I doubt one would need anything much more clever than
the generation scavenger.


> Type safety has nothing to do with GC (C#, Haskell, ML: statically
> typed (far better than C++), and GC'd).
>

Too true! I may have left out a paragraph break where I needed one. It can
be argued that type safety can rule out a class of bugs under some
circumstances, I think. In a system that literally puts lives at stake, I
think strong typing is worth consideration. That's all I'm really saying.
Note that implementing it in Smalltalk shouldn't be too terribly hard!
Which is fun to think about, because the converse is not so much awesome.
Implementing dynamic dispatch (well) in a statically typed language is
almost certainly going to be a right PITA.


> But if you're _that_ set against GC, use a linearly typed language and
> (once your program compiles) you will have NO GARBAGE AT ALL to
> collect. See Henry Baker's papers for details.


Is this it? I will definitely give it a look :D


> > 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.
>
> This!


Indeed!


> > 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!
>
> SecureSqueak's something entirely different to _safety_.


So sure, are you? When car is driven by program, communicate with other
cars, it must! Foxtrot Charlie of code injection this could become. Many
lives in danger. Beware the Dark Side!


> Also, it
> looks very strongly like it's a dead-because-of-lack-of-time project.


That's too bad. Aren't they using it in Etoys? I could have sworn they
were. CC Bert so he can tell me how wrong I am.


>
> frank


P.S.

While I realize that in a world of expert and diligent testing, coupled
with great design, autonomous cars could hypothetically reduce the number
of accidents that occur a great deal, if most of them were automated: I'm
Bones McCoy and those things are the transporter. It looks like a very
large, self-similar distributed decapitating attack surface to me. I
probably won't be caught dead in one of those things. I don't want my atoms
scrambled.


> _______________________________________________
> 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/20131218/8173abdb/attachment-0004.html>