[Cuis] To GC or to Recycle?

[Casey Ransberger]

I think the real lesson here is: you really need a prototype that fails in
some respect in order to discern what technologies are inappropriate to a
fully realized product. If we take this as a given, it would seem that the
solution which provides the prototype most quickly is the prototyping tool
to use, would it not?

In many, many cases, Smalltalk will leave you with a prototype in less time
than anything else on the market, assuming you've learned to use its tools
to their effect. In most cases, it will even be performant enough to
deliver a final product based on the prototype. If it doesn't? Oh well? The
automotive industry usually needs to go to task a decade in advance of a
new idea because *so much* testing must be done in order to ensure good
safety for consumers. If you're Google, you can get away with Python
because you can throw an army of engineers at the problem. If you're Kirk
Fraser? I bet the advantages provided by the interactive programming
environment will be an asset that few other languages can provide. Given
that you've already expressed a preference for working with the language,
why not get started with building that dream car?

If you haven't got a prototype yet, build one, as quickly as you can. Drive
a remote-controlled car with it. I don't mean to be patronizing at all when
I say that NXT Talk coupled with Lego's robotics prototyping kit is
absolutely appropriate to proving ideas in this space! Prove the concept.
If you can prove the concept, *then* you'll be in a position to choose the
correct implementation vehicle for the final product, and you'll have
funding to get it done, because you'll have *proof,* which is SO much more
powerful than speculation.

Casey



On Thu, Dec 19, 2013 at 6:13 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 19 December 2013 14:08, Casey Ransberger <casey.obrien.r at gmail.com>
> wrote:
> > Sorry, I don't understand. Not sure what the advantages of Java and
> Python really are. I mean, Java is painfully limiting but well documented.
> It has what's probably the most strongly invested-in VM in history. Python,
> on the other hand, has a totally decent VM and is also very well documented.
> >
> > We aren't. I think that's our big weak point.
> >
> > But I don't think that the supposed real-time advantages of these
> systems exist. If they do, a cursory examination of how they're done should
> provide insight into how to do the same thing (with less code!) using the
> Squeak infrastructure.
>
> Azul implemented a soft real-time GC for their JVM. It _can_ be done,
> it's just expensive. The more important question is: why bother?
> You're not implementing a rocket engine control module, you're
> automating a car. In other words, we're talking about human reaction
> times, and a 100 ms total complete shutdown of all processing is still
> _twice as fast_ as a human's _mental_ reaction, never mind the
> latencies involved in depressing brake pedals.
>
> It's not even worth thinking about GC until you have a working
> prototype that you can measure. (Because, if it turned out that
> Smalltalk's GC wasn't fast enough (or Eliot's Spur, because that might
> well be ready before the first prototype), your code base would be
> high level and clean enough to automatically translate to something
> else.)
>
> > Because it really sounds to me like -- if you spent a bit more time
> reading -- you'd find that most of the obstacles you perceive between you
> and your goal are either a) already solved, b) non-existent, or c) the same
> problems everyone has, regardless of language, VM, or anything else.
>
> This.
>
> > Casey
> >
> >> On Dec 19, 2013, at 4:26 AM, Kirk Fraser <overcomer.man at gmail.com>
> wrote:
> >>
> >> For completeness another big reason for traffic accidents is
> socializing.  One can get so distracted by other people in the car or on
> cell phones that they pay too much attention to their social interaction
> and not enough to the road resulting in an accident.  That is an
> illustration of what we are talking about with Garbage Collection.  We have
> the dynamic of GC to clean up after playing to develop something in
> Smalltalk.  What if instead we ask the VM builder, Elliot, to add a switch
> to go from dynamic GC mode to static or compiled mode where all objects do
> not get GC'd but recycled?  So for example, if an application drags lots of
> data from disk into memory, the new data objects reuse the same object
> pointer headers as before?  In other words, in compiler mode there would be
> no new objects.
> >>
> >> This switch would allow Smalltalkers to play all they want creating new
> objects like now but when they want to deploy a time sensitive end user
> application like a self-driving car, they flip the switch and the VM treats
> the code as another language would treat .exe's.  This could in effect
> supply all the advantages Python, Java, and other .exe producing languages
> have without a lot of work except one primitive call. Plus the Smalltalk
> playground could become available again with another flip of the switch.
> >>
> >> Kirk W. Fraser
>
> _______________________________________________
> 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/20131219/5a2c49b9/attachment-0004.html>