Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)
Locked
Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)
 
|
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: And since I brought it up, this is Ada: 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:
The other is a project called Physical Etoys, which builds upon the popular children's authoring environment:
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 <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)
|
|
On 18 December 2013 06:27, Casey Ransberger <[hidden email]> 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. 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). Type safety has nothing to do with GC (C#, Haskell, ML: statically typed (far better than C++), and GC'd). 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. > 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! > 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_. Also, it looks very strongly like it's a dead-because-of-lack-of-time project. frank _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)
|
|
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 <[hidden email]> wrote:
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 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 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 Is this it? I will definitely give it a look :D
Indeed!
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 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.
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 [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)
|
|
On 18 December 2013 09:24, Casey Ransberger <[hidden email]> 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 <[hidden email]> > wrote: >> >> On 18 December 2013 06:27, Casey Ransberger <[hidden email]> >> 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 _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Is Smalltalk right for my autonomous car? (was Re: Audio and Video Object Analysis)
|
|
In reply to this post by Casey Ransberger-2
(note I'm not subscribed to Cuis so this might end up in a filter somewhere)
- Bert - [*] with apologies to Swiss Cheese, which is supposed to be holey. VMs are not. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |