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

[Frank Shearar]

On 18 December 2013 09:24, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> 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.

Oh for sure. Last time I nearly had this argument it was in the
context of an RTP server, where latency's a big problem. It's healthy
to worry a bit about GC pauses, but my main point is that it's pretty
much a solved problem. Or, to cast the question the other way: do you
really want to be stuck in a car that's rebooting itself because it
crashed because it had a memory leak? Or that just suddenly its
decision-making processes started swapping out because of a memory
leak?

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

The terminology around typing is basically broken, so when you say
"strong typing" in the above you probably mean "static typing", as in
"the compiler tells me at compile time that I am wrong". But then
people in favour of static typing facepalm themselves by referencing
languages with rubbish type systems like C++. I mean, if you're going
to type statically, do it with a proper type system: an ML family
language, Haskell, and so on. Those at least let you express
_interesting_ axioms.

>> 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

http://home.pipeline.com/~hbaker1/Use1Var.html

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

I'm pretty sure that security and safety are separate concerns, yes :)
A single use system can be extremely safe, with no regard to security,
because hey - single user! No communication mechanisms! Or a nuclear
launch system: very secure, but highly unsafe for its target audience.

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

http://securesqueak.blogspot.co.uk/ <-- last post mentioning
SecureSqueak's two years old!

frank