| Edit | Rename | Changes | History | Upload | Download | Back to Top |
Subject: Re: Smalltalk is so much faster
Date: Tue, 09 Jul 2002 23:23:22 -0400
From: Donald Raab
Newsgroups: comp.lang.smalltalk
Sam wrote:
> I've seen various posts from people saying with Smalltalk (and Eiffel as > well) they can develop so much faster than other languages. In fact they > seem surprised such is the increase. > > I'm just curious to know precisely what it is about say Smalltalk against > say Java that makes it so much quicker to developer? Does the compiler do > extra work for you or ... ? >
I'm a Java developer who has to write Java code every day using JBuilder 6 (prefer VisualAge for Java, but IBM abandoned it when they opensourced Eclipse). I used to be a full time VisualAge Smalltalk devloper (6 years). I've gotten used to Java, but will never stop missing Smalltalk . I have gotten pretty productive in Java, but I know I will never be nearly as productive in Java as I was (and probably still am) in Smalltalk. It just isn't possible.
The reasons for this are as follows:
Smalltalk is simple, terse and consistent. Everything is an object, and things get done by sending messages. There are 5 reserved words. The class library is well architected, and easy to navigate (I love Trailblazer in VAST). Everything is available right at your finger tips. You can execute code and inspect the results right away. Smalltalk gives you complete freedom to explore and learn. Once you've done it for a while, you can start to guess that classes will respond to certain messages. Once you break the shackles of your Pascal or C programming heritage, Smalltalk is much easier to read. Easy to read, means easy to learn, enhance and maintain.
Java is kind of like kindergarten. There are lots of rules you have to remember. If you don't follow them, the compiler makes you sit in the corner until you do. There are 59+ reserved words. Everything is not an object. There are primitives, and your classes are not first class objects. And you have to remember that there is no "this" in a static method (in Smalltalk calling self in a class method would return the class itself). You have to remember to tell the compiler things several times so it knows what you're talking about (Date date = new Date()). You have to remember to upcast and downcast, and remember when you can and when you can't. You have to think about exceptions right up front, and build them into your interfaces, and proliferate try/catch blocks all over the place. And you must remember to separate your interface from your implementation (which causes you to double your efforts, and number of files). And you must remember to wrap primitives in objects any time you want to do something interesting. You can't overload operators, and you can't extend classes, so you have to find creative (and often painful) ways to do similar things. You have to think about scope when you add variables (do I make them private? do I make them protected -> to which the answer should always be make them private!) And you have to think about scope every time you write a method (do I make it public, do I make it private, do I make it protected, do I leave it as package). Ad Nauseum.
But this is just the boilerplate answers we've seen a thousand times. These are a couple of the practical things I miss about Smalltalk.
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].
In Java (External iterators are a bit cumbersome, but at least JBuilder code assist can generate code templates for you):
List list = new ArrayList();
list.add("Beer");
list.add("Chips");
list.add("Dip");
Iterator it = list.iterator();
while (it.hasNext())
{
String string = (String)it.next();
System.out.println(string);
}
for(int i = list.size() - 1; i>-1; i--)
{
String string = (String)list.get(i);
System.out.println(string);
} 11 lines versus 4. Hmmm...
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):
Honestly, every time I use reflection, I need to look it up. This is no exception. It's just not that simple to remember. Don't forget to catch the appropriate exceptions as well. And don't forget reflection cannot return primitives, only objects. OOPS! Why do we have primitives again? Oh yes, performance! Duh!
In Smalltalk (operator overloading is easy and fun):
= anObject ^anObject notNil and: [this name = anObject name].
In Java (equals and null are a bit of a pain):
public boolean equals(Object anObject)
{
boolean result = false;
if (anObject != null && anObject instanceof MyClass)
{
if (this.getName() != null)
{
result = this.getName().equals(((MyClass)anOject).getName());
}
else
{
result = this.getName() == anObject.getName();
}
}
return result;
} Too bad null isn't an object. :-(.
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.
In Java, I have to add a static variable to every class I want to be a singleton, and write a static getInstance() method to return the value. You can't override the new method, because there is no new method. There is a new keyword which creates a new instance of a class by calling a contstructor. But you can't have a constructor return anything but a new instance of the object.
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. Effectively what this means is that you can only have dynamic proxies for interfaces. And there is no equivalent of become, although you can use tricks like calling a setter on an object the first time the invocation handler is called to replace the proxy. But this isn't nearly as elegant or powerful, because it relies on the proxy having knowledge about an "owner" objects interface, and there are minor concerns the first time you invoke the proxy, such as if you hold onto the proxy in a temp variable. The proxy can't replace itself in the temp variable, the same way become: would.
I could go on... but I won't. There's no point. Because I don't have my Java development environment in front of me, I wouldn't be able to write code for all of the examples I would use anyway. There are too many things to remember in Java.
The human mind can effectively remember 7 +- 2 things. Java forces you to memorize much more than this. Java doesn't lend itself to information chunking. And it doesn't help that the class library has design flaws in it (java.util.Date anyone !?!? how 'bout java.sql.Date? or java.sql.Timestamp? What's that design heuristic that says that all base classes should be abstract classes? ;-)). If all you have in front of you is your mail editor, it will be much harder for you to remember all of the details for writing complicated Java code. Smalltalk is a bit easier to remember. The fact that I haven't been programming in Smalltalk since Feb. 2000, should be evidence of that. Once you've learned Smalltalk, it's like riding a bike. With Java, I am much more dependent on my JBuilder environment and code assist, and Java Doc to remember things. Because there are a many more things to remember.
Smalltalk is easier, once you've broken the learning curve (it's really not that big, so don't be put off). But after a while, Java becomes bearable, and certainly pays the bills. But it will never be as productive. Not unless Sun has a major rewrite planned. Eclipse is an interesting development. Might be a trojan horse for Java; a tool that causes a language to be rewritten. Every Java developer I know works very hard at building the flexibility of Smalltalk (or Lisp -> Greenspun's 10th rule I think) into their applications. People work really hard writing Java... myself included. People work a lot less hard writing Smalltalk, and usually have a lot more fun.
Oh well... back to Java. Maybe if someone starts marketing Smalltalk, I won't be doing it forever ;-). Maybe one of the vendors will seize the opportunity now that Java is feeling threatened by C# and .NET in the web services arena. "If you're tired of drinking all that coffee, and you don't like your C flat, how 'bout some good 'ol Smalltalk to help soothe the soul." Oh well, never claimed to be in marketing. Get to work on it Smalltalk Vendors!
Cheers, Don
Subject: Re: Smalltalk is so much faster
Date: Fri, 12 Jul 2002 01:46:01 -0400
From: Donald Raab
Newsgroups: comp.lang.smalltalk
Sam wrote: >>|collection| >>collection := OrderedCollection with: 'Beer' with: 'Chips' with: 'Dip'. >>collection do: [:each | Transcript cr; show: each]. >>collection reverseDo: [:each | Transcript cr; show: each]. >> > > Thank you for your /incredibly/ detailed reply. However on the code, I find > that the above is completely unreadable compared to Java. Is that because > I'm not familar with smalltalk? Java might have more keywords but it seems > to me that smalltalk just replaces them all with symbols, which is kind of a > cheat really when people say smalltalk has 5 keywords, and possibly ends up > looking like perl code ? > > > --- > Mail checked by AVG Anti Virus > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.373 / Virus Database: 208 - Release Date: 01/07/2002
You're welcome. Apologies for some of the mistakes I included. I didn't really have time to post the message at the time, but I felt the strange need to volunteer an opinion. But by the looks of it, there were plenty of people more than happy to clean up after me. Kudos to everyone who helped.
Now I'm going to share some more opinions with you (and everyone else who can't wait to start applying grains of salt to this message). But I'd like to preface them a bit.
Java and Smalltalk are both good languages, each with relative strengths (ok who threw the first tomato?). They are different languages, with different philosophies and different pros and cons. It doesn't really matter if one is better than the other. If you are a developer like myself, the decision of which one you use during the day will probably not be determined by yourself, but by managers who make decisions not on technical merits, but on things like market pressures, vendor reliability, resource availability, etc. The important thing for any developer to do is to be a "Pragmatic Programmer" and learn multiple languages. And the most important thing is to learn concepts and techniques. Trends come and go (I hope C# isn't in my future, please!). Dan Ingalls said in his Smalltalk Byte Article "Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones." Some people in this newsgroup and c.l.Lisp would argue this hasn't been the case, myself included. We would be right. Computer history teaches us that quality cannot and will not make quantity go away. VB is alive and kicking. Java is here to stay (unless Microsoft really wants to kill it). Smalltalk and Lisp have been around for a long time, and are here to stay as well. None of them are dying. Languages die, because there is no market for them. Languages evolve, because innovation and competition forces them to. Java is a step forward for the masses of lost C and C++ application programmers. Are the masses always right? Or are the smart deviants always right? As a coworker of mine always says; "billons of people eat at McDonalds; does that mean that they have the best food?" I eat at McDonalds occasionally... but I know there is better food out there (try Burns Steakhouse in Tampa - yummy!) It's up to you to decide. I'm just happy to see someone asking questions, in a hopefully honest attempt to learn. If you stop learning, you'll eventually stop thinking, and then you won't be able to make decisions by yourself. So keep asking questions, and don't take our word for it. Find the answers you're looking for by trying things for yourself.
Now back to our regularly scheduled soap box.
As one of the other posters said, Smalltalk having less reserved words isn't really that important. It has fewer concepts, and fewer constraints.
I can totally understand why you find the code I posted completely unreadable. Hopefully some of the other posts and links have shed some light for you. I had the benefit of learning Smalltalk in a 5 week immersion class called Object Oriented University (Smalltalk track) when I worked for IBM back in 1994. Before that class I had seen some Smalltalk code before, and it looked totally bizarre. After that class, every other language I ever worked with just didn't look as good anymore.
I don't know Perl so I won't comment on that. The 5 words is kind of a cheap comparison, and is not that important. The important thing to understand when learning any OO language is that the real gems are in the class libraries. It takes time for any developer to become proficient in using any OO languages class library. The language that makes it easier to learn, use and extend the class library is more likely to make you more productive.
The next few statements are a matter of my opinion and I will get slammed for them I'm sure, but here goes.
The Java Language and lack of quality IDEs makes it more difficult to learn, use, and extend the class library. The rules of the language are such that what you get in the class library cannot always be easily viewed (with some things it can) and can never be enhanced (which is different from being extended) or changed. Smalltalk has a much more empowering philosophy than Java. In fact, I would say that I think the Java Language is more of a religion encompassing a philosophy.
Smalltalk philosophy: "Here I am. Explore me. Use me. Subclass me. Enhance me. If you really need to, change me. Swipe it. Do it. Save it. Test it. Debug it. Inspect it. Repeat it.".
Java says, "Here I am. Find me. Use me. Don't touch me. Sit down and start typing. Extend this. Implement this. Package this. Protect this. This this = new This. Cast this. Try this. Catch this. Bracket Bracket. Paren Paren. null and void. Save this. Compile this. Run main. Jar this."
But to be fair. I don't mind programming in Java that much. It gets the job done, just a bit slower and with a lot more developers for me to mentor. And since I like mentoring, this isn't such a bad thing IMO. I also get to chuckle every time someone I work with tries to do something really complicated, and either hits the brick wall, or at least crawls through a little bit of quicksand. Then I get to reminisce about the good 'ol days with them when the possibilities were limitless. Greenspun should have an 11th rule that says something like "Any sufficiently complicated Java or VB program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Smalltalk."
Oh well enough babble from me. I hope you find the time to learn Smalltalk, and enjoy it as much of the rest of us (or most of us anyway). If you get to do productive work in it during the day, I envy you (no pun intended for any ENVY enthusiasts out there).
Good Luck, Don
| Edit | Rename | Changes | History | Upload | Download | Back to Top |