Props to Donald Raab for writing this article, which really entices me to take a real serious look at smalltalk. Now if only I could find a tutorial with as much clarity.
Of course, the last thing I need right now is to pick up another pet project. I'm dealing with gigantic ASP classic/ASP.net hybrid system at work with about 10 different major moving parts, my image database which is crawling along, having to get back into client side html/javascript development for aformentioned work project, and now school for this semester is going to involve writing a bunch of systems progamming in C (interprocess communications mostly).
All this and I'm still not more than 200 pages into The Dark Tower, a book I've been waiting with baited breath for probably 12 years now. There was a time where I would have finished it overnight.
Rob, usually I enjoy reading what you do, but this is tripe. You have obviously ODed on Nordstrom's half-yearly sale for men.
> Everything is available right at your finger tips. You can execute code and inspect the results right away.
Just like in java with the right IDE.
> There are primitives
Agreed, java deals with primitives in a dumb way compared to other languages/compilers.
> and your classes are not first class objects.
I've never had a problem with this. Example?
> And you have to remember that there is no "this" in a static method.
I've never had a problem with this. In smalltalk, what can you do with the class that you can't do with static methods or new This()?
> You have to remember to tell the compiler things several times so it knows what you're talking about (Date date = new Date()).
Uhm, OK. This is just challenging the basic instaniation paridigm of java. It's fine if you don't like it.
> You have to remember to upcast
Huh? PreparedStatement.execute("sql"); works fine. Example?
> and downcast
Fair enough, although there are plenty of libs that take care of most of this pain for you.
> and remember when you can and when you can't.
When can you not upcast or downcast? I believe this will compile: Object foo = (Number)((Object)"string");. If he's saying that Object foo = (Number)((Object)"one") should result in a Number of 1, then that's fair enough, I know other languages do some debatable magic in this realm. (and maybe he should talk to the google calculator developers: http://www.google.com/search?&q=one%20plus%20one)
> You have to think about exceptions right up front, and build them into your interfaces,
This is a good thing, but debatable.
> and proliferate try/catch blocks all over the place.
This can be a PITA (especially if you're using a third-party API), but you can also make your exceptions Runtime if you don't care if the given operation works or not.
> And you must remember to separate your interface from your implementation (which causes you to double your efforts, and number of files).
No. You can, if you want; but java and javac deals with concrete impls just fine.
> And you must remember to wrap primitives in objects any time you want to do something interesting.
OK, given.
> You can't overload operators
OK, this is debatable.
> and you can't extend classes
Huh?
> You have to think about scope when you add variables (...)
Debatable, maybe 'private' should be default.
> And you have to think about scope every time you write a method (...). Ad Nauseum.
Debatable, maybe 'private' should be default.
> In Smalltalk (Collections, blocks and internal enumerations are key):
> |collection|
> collection := OrderedCollection with: 'Beer' with: 'Chips' with: 'Dip'.
> collection do: [:each | Transcript cr; show: each].
> collection reverseDo: [:each | Transcript cr; show: each].
This is pretty much fixed with 1.5, although java still leaves something to be desired wrt to callbacks and delagates.
> In Smalltalk (reflection is a piece of cake):
>
> object perform: #someMessage.
> In Java (reflection requires me to either look at JavaDoc or my previous code):
Reflection is, intentionally, a tool to be used at *design time*, not runtime. The value of this is debatable, but it does show in the implementation.
> In Smalltalk, I can implement a Singleton class by overriding new and using a class instance variable, and have sublasses just be singletons by subclassing.
This is kind of cool, and easily done in java. However, it's debatable if this is a good idea or not since Singleton is a pattern, not a framework. Given that, it would be nice to have a Singleton keyword, even if it did just foobar the bytecode to give you what you want.
> In Smalltalk, I can implement a proxy by subclassing nil and implementing doesNotUnderstand: and can use become: to replace proxies with the actual values.
> In Java, I can call Proxy.newInstance() but have to specify which interfaces to implement.
I've never run into any problem like this. Square peg in round hole? Or maybe he's had trouble with class loaders?
Not that I'm at all married to Smalltalk; in fact, I can barely get anything done in it at all. Most of the pro-smalltalk fair runs something like this:
"Everyone not using smalltalk is a total idiot, and could get productivity gains of 1000% and have more reliable, robust software by using smalltalk."
So this is the first things I've seen that makes me say, "hey, some of those things sound neat." I'll address what I know of a few of your points.
Java IDE's don't come close to smalltalk's interactivity. In smalltalk, the vm (for better or worse) is the IDE. It supports full-blown on the fly replacement, inspection, and drilling down of everything. Even with the right VM and the right IDE, Java doesn't really come close as I understand it.
In general, a lot of the things brought up point to smalltalk's dynamicism. It's not common in Java to see a lot of reflection or onthe fly code code generation because it's a major, major pain. IMO, even passing around function pointers in C is easier than reflection in Java (or at least less cluttered). In smalltalk it's all trivial so the designs tend to leverage it heavily. It's a different way of thinking about problems, and I'm not sure I totally grasp it at all, but it's allegedly where most of the benefits come.
So it's not so much that a lot of those things are "problems" with java per se, just that because it's either incredibly verbose or not possible it limits what patterns and techniques you can use to build a solution.
WRT casting, you can't cast something to an incompatible type. Your example won't compile, because you can't cast to a more specific object. ((Object)"string") returns an object, which can't be cast into a Number. In smalltalk if I grok it right, there are no incompatible types. There are no casts, just messages. You can handle messages however you like. The programmer is in total control over what happens when a message is passed to an object that doesn't know how to handle it. You can write a default handler, dispatch it based on class, and all kinds of other crazy stuff.
Did you mean that not overloading operators in Java is debatable, or that its value is debatable? Obviously, you can't override operators in java so I assume you mean the latter. Operator overloading, done right, is a great clarifyer of code (see: Python's __index__).
Scope wise, I -think- methods in smalltalk are always public and fields are always private. In java, each of those can have 4 values, so even if there is a default, you still have to think about what it's going to get.
In smalltalk, you can extend the definition of classes themselves. Arbitrary example (I think); in Java, if you wanted to track the number and type of each object created, how would you do it for -every- object, including those in the class library? Total nightmare right? I don't even think it's doable within the language; you probably have to write something external to get at the JPDA info. In smalltalk, I think you can just extend the global class definition to do the counting and examining for you. That's pretty powerful.
Anyway, all of this is what I've gathered from reading a bunch of pro-smalltalk propaganda. I'll probably continue to poke around with smalltalk and report back here. It's definitely a totally different world.
> Your example won't compile
It does compile, it just doesn't run. :)
I take the point, though, that casting is pretty inflexible in java. However, I'm pretty sure it's trivial to implement a method-based 'casting' framework that is as dynamic as C++ or smalltack.
Ah yes, my mistake.
I certainly wouldn't call it trivial. In fact, strictly in java, it's impossible to ever make this line:
Object foo = (Number)((Object)"string");
work at runtime. Incompatible interfaces, so they are never assignable. You could change the VM, but then you're not implementing Java anymore, you've got some other language.
You could write a bunch of code, with special interfaces to be implemented that define "universally assignable" objects, and all objects that you wrote could implement that, with a bunch of code to dynamically handle attempting casts, but then if the cast fails dispatching to default method handlers, etc. But that would never apply to existing class library code so you'd have to wrap everything you wanted to use in that framework. Basically, you'd very quickly have a big library of code to provide a language feature. What you're doing is modifying the language, constrained by not being able to change it's syntax or rules.
Which is really where smalltalk leverages its power. You can redefine the language itself to fit the problem at hand. Even looping constructs and what not are fair game for reimplementation because they are part of the library rather than the language.
I think mostly what I've learned is that if you are used to one or the other, then really grokking the other is going to be a PITA, because each makes the other's method of solving problems a royal pain.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: