True become false
The miracle of Smalltalk’s become: (2009)
21–30 of 30 posts
Re: The miracle of Smalltalk’s become: (2009)
#22Earlier quoted context omitted.
I usually use it as an example when people say Python is too dynamic to have a JIT, when Smalltalk was one of the percusors of JIT for dynamic languages with features like become: (SELF then took it even further).
It's really unnerving when people repeat that "too dynamic" remark when there is widely known counterexamples. Fortunately it seems now people stopped denying the problem with the faster cpython project. IIRC, I think the roadmap for 3.12 or 3.13 already has some form of lightweight JIT.
Yes, apparently it took Microsoft's persuasion to make it happen, hiring Guido exactly for that purpose.
Re: The miracle of Smalltalk’s become: (2009)
#23> In the absence of an object table, become: traverses the heap in a manner similar to a garbage collector. The more memory you have, the more expensive become: becomes.
Well, yes, that should be "the larger the reachable object graph you have, the more expensive become: becomes". It's not necessary to do the substitution in areas of the heap that are garbage.
I would rather do it without any sort of object table, because then you can do things like make some string object become the fixnum 42 everywhere. :)
If you're doing something with object persistence, you can't be doing individual become operations object-by-object. There has to be a batch API for doing a mass become where you pass a dictionary of what is to become what, and the objects are traversed once to do all the rewrites.
Re: The miracle of Smalltalk’s become: (2009)
#24In fact in most cases dynamic subclassing is enough for such things. In JavaScript that's achieved by changing __proto__ reference on an object. So "obj instanceof A" becomes "obj instanceof B". As of persistence case I've solved it on JavaScript internal implementation level. In Sciter there is built-in JSON-ish data persistence module - close to Mongo-DB on feature set (modulo sharding). Storage loads objects as ha…
Not really, because the goal is that obj is replaced by a different instance, not to change its type.
Become can swap two objects that are exactly of the same type, where the prototype change would be a null operation, achieving nothing.
Re: The miracle of Smalltalk’s become: (2009)
#25In fact in most cases dynamic subclassing is enough for such things. In JavaScript that's achieved by changing __proto__ reference on an object. So "obj instanceof A" becomes "obj instanceof B". As of persistence case I've solved it on JavaScript internal implementation level. In Sciter there is built-in JSON-ish data persistence module - close to Mongo-DB on feature set (modulo sharding). Storage loads objects as ha…
Not really, because the goal is that obj is replaced by a different instance, not to change its type. Become can swap two objects that are exactly of the same type, where the prototype change would be a null operation, achieving nothing.
"obj is replaced by a different instance"
Could you provide real life scenario when you will need that?
I mean to change all references to the object in the heap at runtime ...
Re: The miracle of Smalltalk’s become: (2009)
#26Earlier quoted context omitted.
If I'm not mistaken, this is also an amusing retort to the idea that only statically typed languages can have common refactoring tools.
Specially since the first IDEs with such features were for Smalltalk and Lisp. Mesa (XDE) and then Mesa/Cedar, have several references Xerox papers, on how those enviroments served as inspiration for their IDE like features, like REPL, typo corrections, debugging, code reloading,...
Exactly. Too many folks take "static typing" as the only form of static analysis that can be done. Sometimes the only analysis that can be done on a codebase.
Re: The miracle of Smalltalk’s become: (2009)
#27Earlier quoted context omitted.
Not really, because the goal is that obj is replaced by a different instance, not to change its type. Become can swap two objects that are exactly of the same type, where the prototype change would be a null operation, achieving nothing.
"obj is replaced by a different instance" Could you provide real life scenario when you will need that? I mean to change all references to the object in the heap at runtime ...
Live code editing on Smalltalk debugger, after changes on the class browser, redoing statement that caused the break into debugger, and have all live instances on the image updated.
Re: The miracle of Smalltalk’s become: (2009)
#28The magic here comes from Smalltalk's object memory system, which makes this object easy. (Well.. okay.. not completely easy, but simple.) Also... I know in Digitalk, you couldn't do a become: on SmallInteger because of the way their object memory worked, but don't remember if this was a limitation of SmallTalk-80 or Squeak. Which is to say... when you have time, if you haven't done it already, do a search on "smallt…
Squeak implements it with horrible performance, IIRC
I hear you. The last time I used squeak as a prototyping tool was around 2002 and yeah, the performance was pretty craptastic. I bumped into David Ungar at a conference a few years back. He mentioned there has been a fair amount of work back-ported to Squeak from some of the later Self work and maybe even from Lively Kernel for all I know.
But lest someone read this thread and use it as evidence that Squeak is completely crappy, I would encourage them to do a bit of testing with a recent version. Also... I don't think people are going to use Smalltalk for it's raw performance, but in it's ability to model problems with pleasant "pure" OOP-ness.
Re: The miracle of Smalltalk’s become: (2009)
#29Earlier quoted context omitted.
Squeak implements it with horrible performance, IIRC
I hear you. The last time I used squeak as a prototyping tool was around 2002 and yeah, the performance was pretty craptastic. I bumped into David Ungar at a conference a few years back. He mentioned there has been a fair amount of work back-ported to Squeak from some of the later Self work and maybe even from Lively Kernel for all I know. But lest someone read this thread and use it as evidence that Squeak is comple…
There have been very extensive changes since 2002, yep, such as a much improved interpreter, a JIT, a replacement of the original object memory format which incidentally supports faster become and most recently a new bytecode set.
Re: The miracle of Smalltalk’s become: (2009)
#30The magic here comes from Smalltalk's object memory system, which makes this object easy. (Well.. okay.. not completely easy, but simple.) Also... I know in Digitalk, you couldn't do a become: on SmallInteger because of the way their object memory worked, but don't remember if this was a limitation of SmallTalk-80 or Squeak. Which is to say... when you have time, if you haven't done it already, do a search on "smallt…
The SmallInteger limitation is probably because as an optimisation they stored them as immediate values rather than generic objects, and Squeak shares this limitation (the newer Spur format extends this to one or more additional types depending on image bitness).
Related to references and the above, Eliot Miranda's blog may be informative as it provides both details and sometimes code for many of the changes that have happened in the Squeak (and now OpenSmalltalk) VM, e.g. http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-a...