3 ms·

A lot of what he's talking about is done automatically when you're using a classic Smalltalk/Squeak environment. (E.g., names are in one place. Refactoring can

by cpr 17y ago

A lot of what he's talking about is done automatically when you're using a classic Smalltalk/Squeak environment. (E.g., names are in one place. Refactoring can happen automatically, because the IDE can find all uses of a method and fix them.)

raganwald 17y ago
How does that differ from using Eclipse with Java? (Interesting sidebar: Eclipse is a descends directly from Smalltalk)
- aaronblohowiak 17y ago
  Eclipse attempts to bolt-on features external to the runtime to make it appear integrated. The smalltalk implementations offer exactly the kinds of changes you are asking for in your post. see my comment above.
aaronblohowiak 17y ago
Most smalltalks ship with method and class-level versioning with browsers. Full discussion of this is here: http://objectmix.com/smalltalk/16421-version-control-systems-smalltalk.html http://objectmix.com/smalltalk/16421-version-control-systems... Eclipse is an effort to bring the advancements of smalltalk to java programmers, as the smalltalk community got absorbed by the java borg (see also: hotspot vm history.)
epe 17y ago
There's no idea that a single class might have two versions and that some bits of the program depend on the old version and some on the new. Why not? Why isn't live, running code versioned and transactioned so that we can release a patch of a few classes into a running server without taking it down? It should be possible for the old code to handle all of the existing requests and then get garbage collected when it has no further dependencies. Isn't this also something that Smalltalk can do?
- aaronblohowiak 17y ago
  Yes. You can even have the new version get the function that called it and change the implementation of the caller so your code re-factors itself. Not that I'd recommend this, but you could do it =)
- avibryant 17y ago
  It's also something Ruby can do, when running on MagLev.
  - raganwald 17y ago
    It is not a coïncidence that MagLev came from the Smalltalk community. See all the other comments here :-)

by cpr 17y ago

raganwald 17y ago

How does that differ from using Eclipse with Java? (Interesting sidebar: Eclipse is a descends directly from Smalltalk)

aaronblohowiak 17y ago
Eclipse attempts to bolt-on features external to the runtime to make it appear integrated. The smalltalk implementations offer exactly the kinds of changes you are asking for in your post. see my comment above.

aaronblohowiak 17y ago

Most smalltalks ship with method and class-level versioning with browsers. Full discussion of this is here: http://objectmix.com/smalltalk/16421-version-control-systems-smalltalk.html http://objectmix.com/smalltalk/16421-version-control-systems... Eclipse is an effort to bring the advancements of smalltalk to java programmers, as the smalltalk community got absorbed by the java borg (see also: hotspot vm history.)

epe 17y ago

There's no idea that a single class might have two versions and that some bits of the program depend on the old version and some on the new. Why not? Why isn't live, running code versioned and transactioned so that we can release a patch of a few classes into a running server without taking it down? It should be possible for the old code to handle all of the existing requests and then get garbage collected when it has no further dependencies. Isn't this also something that Smalltalk can do?

aaronblohowiak 17y ago
Yes. You can even have the new version get the function that called it and change the implementation of the caller so your code re-factors itself. Not that I'd recommend this, but you could do it =)
avibryant 17y ago
It's also something Ruby can do, when running on MagLev.
- raganwald 17y ago
  It is not a coïncidence that MagLev came from the Smalltalk community. See all the other comments here :-)