[Cuis] To GC or to Recycle?

Casey Ransberger casey.obrien.r at gmail.com
Thu Dec 19 08:08:30 CST 2013


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. 

It's already possible to incorporate manual or "unmanaged" code with the Cog infrastructure. You can do it with the interpreter, and you can do it with the stack VM too. 

You can do that with C code, Slang, or assembler via Igor Stasenko's NativeBoost. You can do it with FFI. You can even kick it off with OSProcess at the OS level. 

What's the problem you're actually trying to solve? Is it possible that you see things missing that really aren't missing at all? Are you certain that you've researched the things you're interested in enough such that you don't end up reinventing the wheel?

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. 

I don't mean to be cruel here, not at all, in fact I mean to be as kind, welcoming, and supportive as I can be, but you have to actually read and try to understand the things people point you at before continuing to make arguments in debt of the information contained therein, unless you want people to write you off. 

I don't want to write you off. Please at least read the Back to the Future article, Tim Rowledge's tour of the object system, and David Ungar's paper about garbage collection. Then come back, understanding the material, and we can talk about other things worth reading, given the goals you're expressing. 

Otherwise we're just going to waste the list's time with me repeating that I've *already* told you where to start looking for the answers to your questions. 

You don't want to be hit with the Andreas Stick, which involves reading a longish essay about what constitutes a smart question and why. 

Trust me :D

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




More information about the Cuis mailing list