

Redline Smalltalk on the JVM - Argorak
http://www.indiegogo.com/projects/redline-smalltalk-v1-0

======
nnq
I thought Smalltalk was dead and its good ideas transplanted in other
languages. My question to anyone talking to me about a "resurrected" version
is: _what does it still have that other Smalltalk-inspired languages don't?
what does it have over (J)Ruby for example? what can I do in it better than in
Scala?_

~~~
jhancock
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> 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/>, 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
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
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.

~~~
aardvark179
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.

------
mark_l_watson
I wish the project luck. I have had a lot of good mileage on the JVM platform
using Clojure and JRuby, and a very good Smalltalk implementation on the JVM
might also be useful.

That said, ignoring the commercial Smalltalk implementations, I think that
Pharo is the future of Smalltalk. The Cog virtual machine is reasonably
efficient and the UI is in my opinion much improved over Squeak.

I am not sure how widely used the Seaside web application platform is used
since the original authors went to work on other things at Twitter. At one
point I thought that Seaside would give Smalltalk a lift in the same way that
Rails did for Ruby.

------
DoubleCluster
Looks like an excellent plan. The JVM is awesome and having smalltalk code in
plain text files instead of opaque image files might make it worth to take
another look at smalltalk.

------
teyc
I wonder how class modification is implemented. It claims even "final"
variables can be modified.

~~~
mcculley
Fields marked "final" can be modified through reflection.

