3 ms·

Smalltalk is two things: language and environment. Many langs have borrowed from Smalltalk the language. None provide the environment. The leverage this envi

Smalltalk is two things: language and environment. Many langs have borrowed from Smalltalk the language. None provide the environment. The leverage this environment provides is something that has to be experienced to appreciate. The environment provides exploration, reasoning about the code as a whole and refactoring at a level that no text editor or traditional IDE can match. IBM VisualAge for Java was actually mostly VisualAge Smalltalk under the covers and provided a Java dev experience that for me has never been matched. When IBM dropped it for Eclipse, my productivity took a nosedive. I don't care much about Smalltalk running on the JVM without the environment. I wish Redline success and hopefully they will create an environ as well. http://www.pharo-project.org http://www.pharo-project.org is a fantastic cleaned up derivative of squeak. Pharo 2.0 will come out of beta within a month. The 2.0 beta is good and Pharo v1.4 is also solid. The Cog VM http://www.mirandabanda.org/cog/ http://www.mirandabanda.org/cog/, which is the newer VM that works with Squeak and Pharo is impressive. It doesn't have the tuning options and scale of JVM at the moment. I see no reason the Cog VM can't fairly quickly evolve to scaling on par with JVM for many use cases. If the sugary syntax of ruby is a key motivator to use it over Smalltalk, that's cool. For me, I find the simplicity of the Smalltalk syntax combined with environment worth far more than the complexity of what Ruby has to do to provide all that sugar with little ability to reason about the code as a whole. Scala provides language features that Smalltalk nor Ruby provide and those attributes may be more important for some.

stcredzero 14y ago
The "Smalltalk Environment" is almost completely written in Smalltalk, you know. So long as you can replicate the behavior of the Change Log. Saving and restoring images, and morphing instances when you change classes, it should be portable. Also, there's the broken class side inheritance on the JVM to deal with.
- seanmcdirmid 14y ago
  There is no way they would reuse JVM classes in a faithful Smalltalk port; it would probably be more like JRuby where the object system is implemented a layer above the JVM and some interop is provided to the Java class system.
  - stcredzero 14y ago
    > There is no way they would reuse JVM classes in a faithful Smalltalk port Dunning-Kruger moment for you. Inheritance is in the VM for Smalltalk. So to avoid broken Java class side inheritance, they'll either have to modify the VM, which they can't do and maintain compatibility, or they have to have some support code.
  - aardvark179 14y ago
    It's worth looking at Mark Roos's talks about RTalk which is a port of Smalltalk to the JVM to support some existing commercial software. It compiles JVM byte code from existing Smalltalk bytecode, and keeps the images if I remember correctly. In the language I work on we do use JVM classes, but our own methods tables are used to model the inheritance hierarchy, and methods are all static JVM methods under the hood so we can support all the meta programming that you'd expect in a Smalltalk inspired language.

stcredzero 14y ago

The "Smalltalk Environment" is almost completely written in Smalltalk, you know. So long as you can replicate the behavior of the Change Log. Saving and restoring images, and morphing instances when you change classes, it should be portable. Also, there's the broken class side inheritance on the JVM to deal with.

seanmcdirmid 14y ago
There is no way they would reuse JVM classes in a faithful Smalltalk port; it would probably be more like JRuby where the object system is implemented a layer above the JVM and some interop is provided to the Java class system.
- stcredzero 14y ago
  > There is no way they would reuse JVM classes in a faithful Smalltalk port Dunning-Kruger moment for you. Inheritance is in the VM for Smalltalk. So to avoid broken Java class side inheritance, they'll either have to modify the VM, which they can't do and maintain compatibility, or they have to have some support code.
- aardvark179 14y ago
  It's worth looking at Mark Roos's talks about RTalk which is a port of Smalltalk to the JVM to support some existing commercial software. It compiles JVM byte code from existing Smalltalk bytecode, and keeps the images if I remember correctly. In the language I work on we do use JVM classes, but our own methods tables are used to model the inheritance hierarchy, and methods are all static JVM methods under the hood so we can support all the meta programming that you'd expect in a Smalltalk inspired language.