Hacker News new | comments | show | ask | jobs | submit login
Redline Smalltalk on the JVM (indiegogo.com)
38 points by Argorak 1605 days ago | hide | past | web | 18 comments | favorite

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?

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.

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.

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.

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.

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

Dunno what 'dead' means. There are several commercial vendors and several open source versions. The ecosystem is at least stable and probably growing.

Agreed. Cincom Smalltalk (ParcPlace's VisualWorks) is certainly not dead. Its a powerful system and keeps getting updates. Gemstone Smalltalk: there is nothing that competes with this unique approach to DB and code execution in a somewhat seamless server cluster.

My guess is that after a 10-15 year lull, Smalltalk is growing a bit. I'm very happy to see Pharo chugging along. I think that by 2014, Pharo 3.0 will be a hit. Pharo 2.0 is already very compelling for many use cases.

Smalltalk didn't really die. It was the Smalltalk vendors that died. There were three++ viable Smalltalk vendors when Java came along. Java did not have a tech advantage. Not even close. Java was crammed through the industry by big players that didn't own Smalltalk implementations and Sun was in a position to give Java away for free. At that time the Smalltalk vendors had old-school business models whose investors did not allow them to turn the corner at the dawn of the Internet age of the mid-90s. Had either Digitalk or ParcPlace given a free license to embed Smalltalk into Netscape's browser instead of Netscape/Sun pulling the Java applet and Javascript move, we would all be writing browser apps in a clean consistent language, instead of Javascript. This is not speculation. I was in the room when such an opportunity was discussed. It was soon dismissed as "our board won't allow it as it would destroy our current business model".

Smalltalk is like Objective C without the C part.

But seriously, things going for smalltalk: (a) a huge library of very extensive code, (b) a nice programming experience (though getting rid of images and adding files back would destroy that), and (c) it has a unique design that some prefer.

I think everyone should be exposed Smalltalk. It was my real intro to OO programming. It really is the pure OO language, where you can see objects unencumbered from all the non-object crud in more pragmatic OO languages.

> Smalltalk is like Objective C without the C part.

Yeah… no. Smalltalk is much more than the Objective part of Objective-C, beyond even the development environment.

Sure, hence the "but seriously..."

Also, I'm sure Objective C is the language still in mainstream use that most resembles Smalltalk (at least the non-C OO parts).

> Also, I'm sure Objective C is the language still in mainstream use that most resembles Smalltalk

That's just... no. It has superficial syntactic similarity with Smalltalk's message-send syntax, nothing else of its syntax and (more importantly) pretty much none of its semantics.

Having programmed for 20+ years in both Smalltalk and Objective-C ( + implemented both + contributed to Squeak,..), I have to disagree with you there.

For me, the Objective part of Objective-C is very close to Smalltalk, same dynamic messaging model, same perform(Selector):, same doesNotUnderstand/forwardInvocation handling, same ability to capture and replay messages, similar dynamic typing in the "object" part.

Recent developments are a bit of a mixed bag, Objective-C blocks are a welcome addition, though the syntax is cumbersome, ObjC finally got SmallIntegers.

In terms of "feel", the two can be very similar, though some of the libraries admittedly have a very different flavor and a lot of the recent activity in ObjC land has been pushing more in the direction of Java, which is a loss.

In the sense of objects being a means of connecting parts, ObjC actually seems closer to what I understand as the Smalltalk mission ("recurse on the idea of computer") than current Smalltalks, because it is so much more adept at talking to the rest of the world.

Differences, yes: the image, no "become:", memory management (very mixed bag on the ObjC side, but ...).

Agreed. If anything, I would say Ruby is the language still in mainstream use that most resembles Smalltalk.

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.

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.

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

Fields marked "final" can be modified through reflection.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact