Are we live, or deadorex?

For what it's worth, Guido van Rossum has stated that he intentionally rejected the "image" approach taken by Smalltalk and Lisp, which I think is what makes the Smalltalk live development approach possible. He apparently wanted something many people would be familiar and comfortable with.

PythonCard might offer a way to do image-based development, or at least an approach that would be friendly to it (a la HyperCard). There's nothing that I know of that outright prevents it in Python; it just requires mucking around with some stuff that most Python programs don't.

Comment by James Robertson

George, it's a tradeoff, sure. However, in Ruby, you can modify objects at runtime, correct?

In Ruby and, IIRC, in Python you can modify objects at runtime, but it isn't quite same thing as in Smalltalk. For example, in Ruby you can modify a class definition at runtime by redefining it or modify a specific instance's definition.

class Object
    def foo
        "foo"
    end
end

or

x = Object.new
def x.foo
    "foo"
end

However, being able to change the source at runtime has a few restrictions. You need need "load" a file rather than "require" a file. If you "require" a file it will only be loaded once. If you "load" a file, it can be reloaded again. This becomes very problematic if you want to do a more interactive Smalltalk style development. It is possible, but nobody has written an environment that allows this. I would imagine it would look something like VisualAge for Java where you had this discontinuity between the image approach and a file based system.

Smalltalk's IDE ... Eclipse on the other hand ...
Eclipse is a Smalltalk IDE!

James wrote

"They have customized Eclipse for Resilient... Programming support for debugging, profiling, introspection in the plugin... They built the Eclipse support using the Eclipse plugin support."

Comment by James Robertson

There's a difference between an IDE and an Environment

James "There's a difference between an IDE and an Environment"
Blaine "Smalltalk's IDE... a great IDE like Smalltalks"

You say Blaine is writing about "a Smalltalk environment" when he writes about "Smalltalk's IDE" - so what is the "difference between an IDE and an Environment"?

Comment by James Robertson

In a plain IDE, they are all dead

So you agree that Eclipse is a Smalltalk environment?
James wrote:

• "IDE
  • Connectes to running system
  • Supports true incremental execution
  • Full servicability and visibility - can change device drivers as it runs"

Comment by James Robertson

Yes, you can update Resilient in the field (i.e., at the device). That's not the same as the development tool, last time I checked. With Smalltalk, you can modify things at development time or at runtime - the line between the two is blurry. In the Java and C# worlds, those lines are firm.

That's not the same as the development tool, last time I checked

the IDE is able to inspect and make changes to the object model on the running platform... The reflective interface on the embedded platform allows the IDE to inspect, pause and terminate running threads, inspect and modify objects in the object heap, and update code on the running platform... Since developers can evaluate chunks of code on the target device, and upload changes while the system is running, it is possible to immediately see the effects of changes in source code.
p10 "Design, Implementation, and Evaluation of the Resilient Smalltalk Embedded Platform"

Comment by John Rubier

"Hot code replacement failed - Add method not implemented"

"Hot code replacement failed - Scheme change not implemented"

"Obsolete methods on the stack. The virtual machine was unable to remove all stack frames running old code from the call stack. The virtual machine is not supplying the debugger with valid data for those frames. Stepping into these obsolete frames may be hazardous to the target virtual machine."

Eclipse (and others) are not even close to a Smalltalk environment. Yes, the IDE's are nice WRT intellisense, refactoring and layout. However, you don't have the IDE's available at a production runtime. And even in development runtime, as you can see from the above messages, you don't have a "Smalltalk" environment.

John, you haven't said what those messages are from - the example I gave was the Smalltalk development environment, Eclipse for Resilent.

Isaac, an Eclipse IDE can modify and interact with a running Java application, but that application is not part of the IDE.

A Smalltalk image (call it an IDE if you like) is different because it does not interact with a Smalltalk application. Instead it IS the application. The objects and methods that comprise the development tools and the objects and methods that comprise an application live in the same space. In fact the development tools and any applications being hosted in that environment are running in the same space and using classes and methods implemented by the same bytes in the computer. This means that by definition the system is always a runtime application, and since the developer can change anything this means he can change anything at runtime. The developer can do anything at runtime that he might do at development time because there is no distinction.

Even though the Resilient language is a version of Smalltalk that is accessed using an Eclipse plugin, this does not make Eclipse a Smalltalk IDE in the standard sense. It cannot do all of the things that other Smalltalks do since the Eclipse part is in Java, runs in its own memory space, and does not have the metareflective capabilites of Smalltalk. It may have just as well been written in C.

The fact that development enviroment and the developers application is in the same address space (object space) is the biggest weakness of Smalltalk environments. The fact that the development enviroment and the user applications share the same frameworks at runtime is a huge problem. Once I start my application in a VW image, it is not safe to save that image. If I entered debuggers, there are often processes created or left over. Database state may be captured in some SharedVariable. It could be a whole lot better, but the Smalltalk community is still stuck in the past. I know Cincom has deployment improvements on the list -- I can't wait to see them

Carl, it seems as though you wish to sanctify a particular approach to Smalltalk deployment - afaik there's nothing that suggests you can only call what you're doing Smalltalk if you include a complete development environment with the deployed application. (Of course, some Smalltalks don't have an effective way to strip the development environment out of the image - so we make a virtue out of a necessity.)

A Smalltalk image (call it an IDE if you like)
I don't like :-) If the development environment has been stripped from the image then it would no longer be an IDE but it would still be a Smalltalk image.

It may have just as well been written in C
I think it's true that the IDE could just as well have been written in C - and it would still have been a Smalltalk IDE. It would still use a Smalltalk image - and for the intended application area Smalltalk GUI classes would be pure overhead.

does not have the metareflective capabilites of Smalltalk
To the extent to which that is true, does it have anything to do with the choice of IDE or was it a performance trade-off to be competitive with Java interpreters?

Isaac, I wasn't trying to sanctify anything. If you have a good and practical reason to host the development tools outside of a Smalltalk image, then go ahead, but it isn't really in the spirit of the language to work that way. Smalltalk isn't just the syntax and class library.

I wasn't trying to...
Then I apologise for my misunderstanding. Could you explain why it "isn't really in the spirit of the language"?

Isaac, without trying to say too much about this myself, I'll refer you to what Dan Ingalls (from the original Smalltalk team) wrote in his paper Design Principles Behind Smalltalk:

"Just to get warmed up, I'll start with a principle that is more social than technical and that is largely responsible for the particular bias of the Smalltalk project:

Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.

The point here is that the human potential manifests itself in individuals. To realize this potential, we must provide a medium that can be mastered by a single individual. Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment. If one part of the system works differently from all the rest, that part will require additional effort to control. Such an added burden may detract from the final result and will inhibit future endeavors in that area."

Any part of the system he says. There should be nothing running on the computer that is not held in the same framework and malleable by the user of the system. This is why for example these same people wrote for Squeak a Smalltalk to C translator so they could expose even the VM to the Smalltalk programmer. Whether or not you agree with these ideas, I hope you at least now understand what I was trying to put forth. :-)

To read the whole paper Google for: smalltalk reactive principle ingalls
To read the paper about Squeak Google for: squeak written itself future

If a system is to serve the creative spirit...
Ah! The spirit of a language emerging from a world-class research center 25 years ago.

(Ever wonder why people look at Smalltalk as something from the past?)

Isaac, I give up. You're hopeless.