Smalltalk Minus Minus

A synonym for JavaLanguage, a language with some of the strengths of Smalltalk, and which corrects some of the most egregious failures of C++.

Java. The elegant simplicity of C++. The blazing speed of Smalltalk.

Java is like Smalltalk,

Without blocks.
Without #perform.
Without closures.
Without real metastructures.
Without first-class dynamic extensibility.
Without effective windowing support.
Without builtin state-of-the-art configuration and version management.
Without dynamic typing.
Without restartable exceptions.
Without any mechanism to extend or enhance operators.
Without any dynamic high quality run-time debugging support.
Without a convenient syntax for literal arrays.
Without a way to retroactively add methods to classes.

Some of those are considered to be advantages: Java is certainly much less "reinvention of the world".

However, Smalltalk doesn't have hierarchical namespaces. Some of us view this as a Smalltalk feature *smile* -- TomStambaugh

I agree wholeheartedly. I've been doing some pretty namespace-intensive stuff in VisualWorks 5i for the last month or so, and, frankly, I don't see the big win. Namespaces (in Smalltalk) add lots of complexity for not much payoff. --AnthonyLander

I would disagree about hierarchical naming through packages being a "bug" in Java as defined by Gosling by 1995 (the fair comparison with various Smalltalks should perhaps be around that timestamp, given that Smalltalk had a twenty year start). How else should class name clashes be avoided when composing stuff from multiple sources, including when downloading applets and loading servlet classes at runtime? Which reminds me, what about standards for loading new classes into virtual machines from separate suppliers? How's Smalltalk doing at that these days? It worked well in 1995 for Java. Plus, what's the comparative verdict on interfaces, threads and the monitor-based concurrency model Gosling may have copied from ModulaThree or Tony Hoare (CarHoare)? -- RichardDrake

The only problem is that he chose the wrong Hoare paper! :) Java really should have used CommunicatingSequentialProcesses, a more recent Hoare paper that solved many of the problems associated with monitors. Happily, there are various Java implementations of CommunicatingSequentialProcesses. -- RobertDiFalco

I wouldn't deny that. But the comparison with Smalltalk computes to what?

Good point. -- RobertDiFalco

On to interfaces, I think they are one of the most elegant solutions to the diamond multiple inheritance problem I have seen yet -- much better than SmallTalk in this regard. I'm very happy with Java interfaces and how inheritance works. I know some would like true multiple inheritance, but I think this would open pandora's box. Multiple interface inheritance slays the diamond problem perfectly. While effective, I think the C++ solution (virtual inheritance) is just plain ugly. -- RobertDiFalco

Are you aware of the EiffelLanguage approach? The compiler must work harder but it seems painless for programmers.

It looks like MI of implementation is one of the things which Microsoft's new system doesn't support directly, so if they have their way we are stuck without it. Eg it's one of the few differences between EiffelSharp? and EiffelLanguage. -- DaveHarris

Dave, yeah. EiffelLanguage has an interesting approach. Of course, they also have CoVariance which is so great in so many ways. I would even be happy for return-type CoVariance in JavaLanguage or CeePlusPlus. This is one area where the no compile-time types of SmallTalk really shine -- the whole covariance/contravariance issue is side-stepped. I also prefer EiffelLanguage's approach to genericity over CeePlusPlus templates. I think GenericJava is a good middle ground for JavaLanguage. -- RobertDiFalco

Robert, CeePlusPlus already has covariant return types (unless you're using Visual C++ 6 or worse) and has had for years. It's not vital in C++ (there are ways to get the same effect without it by combining non-virtual methods and virtual methods) but it would be useful in Java (where it can't be simulated sensibly). -- JamesDennett

Are you aware of delegation in SelfLanguage as an alternative to inheritance?

Yes. The relationship between delegation and inheritance has been explored at great length, both in the literature and here. Are you aware of the heritage and pedigree of SelfLanguage, specifically as it relates to SOAR, the SPARC architecture, and similar history?

There is a discussion going on at http://forum.java.sun.com/read/16789542/q_tzLgu-LxJkAAagM [BrokenLink] which relates to dynamic dispatch. Is this something that would happen in Smalltalk ?

ChanningWalton

I thought ObjectiveCee was SmalltalkMinusMinus :-) --KeithRay

It was ... ObjectiveCee was SmalltalkMinusMinus, Version 1.0. Java is SmalltalkMinusMinus, Version 1.2 -- or 2.0, depending on who's talking about it. -- TomStambaugh

So that makes Java SmalltalkMinusMinusMinusMinus?, having removed true dynamic dispatch which ObjectiveC keeps. -- MarcelWeiher

Or more succinctly, it makes Java ObjectiveCeeMinusMinus?. -- Fogus

Without builtin state-of-the-art configuration and version management.

And that really is a feature of the SmalltalkLanguage? Or are you writing about Envy, a commercial add-on?

Does it matter? The point is that Smalltalk had it, and Java doesn't. Ibm tried hard with VisualAge, and just couldn't keep up with the many Java VM changes. Because Smalltalk is pure objects, all the way down, EnvyDeveloper was far more straightforward. Java is a VERY different kettle of fish. --TomStambaugh

CategoryJava CategoryNotaProgrammingLanguage