Java Vs Smalltalk
Java Vs SmalltalkA hundred clear streams make the mighty muddy river flow. -- WardCunningham
I have been more of a serious SmalltalkLanguage developer in a VC++ company for graphics doing mostly prototype dev and testing programs. Now switching over lately to the core VC++ production code. For one there is nothing to compare with Smalltalk for 1-3 yrs experience developer. It is THE language which can teach almost all facets of Computing Sciences from Networking, COM, dev team work through Store and the whole gamut of CS. You name it, all those so very complicated technology, issues have been resolved to a simple method calls to a class. Being string oriented, no worries about Memory handling, no datatype worries, single IDE encapsulating the entire dev code is a boon to the initiation to even most complex issue. Today I can easily relate to the most complex issue simply because of Smalltalk gentle way of leading you into it and to any extent you desire as I did in case of porting of MySQL interface from the JDMySQL package for VW3.0 to VW7.0 right down to the bits and bytes on the TCP pipeline. The complex nature of Micro$oft's Visual Studio and MFC ensures that even the simplest task of say a Ansi CPPUnit ramework build takes 5-10x more effort. Java can be fun platform to start coding with but to feel the raw power of your computing system in hand there is nothing to beat the combination of Smalltalk RAD and C dll's where you want something really hacked like a device driver and all this probably at 0.5x time effort. For trials on ease of use simply try out SmalltalkMT to access any or all of Windows API or any dll's custom built.You can learn or experiment with any external library [ libs and dll's ] usage in much shorter a time span than in any other lingo. I am more than convinced it needs just the right marketing acumen/muscle to make Smalltalk the future of computing.
-- skrishnamachari
I'm a serious Java proponent, I program only in Java now, and haven't programmed in anything else for over two years (except for one, short back-slide early this year). My job title has the word "Java" in it, for goodness' sakes.
However, the bitter truth is that it's not as productive, or as useful for rapid, bug-free programming, as Smalltalk. I used Smalltalk day in and day out for over six years. That followed almost two years of day-to-day use of C++. Out of the three, Smalltalk is still the hands down winner for productivity. I can develop probably 1.5X as fast in Smalltalk as I can in Java, which is probably 4X the speed with which I can develop in C++.
The Smalltalk libraries had at their inception things that are just now starting to make their way into the JDK 1.2 (e.g. real collections). There is nothing I can think of in Java that I have today (except possibly servlets) that Smalltalk did not have, usually better, two or more years ago.
So, why didn't Smalltalk win? Because in the marketplace the best solutions don't always get picked. It's the Dvorak vs. QWERTY effect, or the Beta vs. VHS effect. Java had Sun's massive marketing muscle behind it. It was the first language demoed in a browser, so it forever had the internet "shine" attached to it. The JavaBandwagon is a real phenomenon. Some jump on without knowing where's its going because it's flashy and hip, some leave their old, worn-out horses for a better, faster ride, and some sadly leave behind their first loves because it's quickly becoming the only show in town.
See LanguagePissingMatch. -- RandyStafford (January 7, 2000)
-- KyleBrown
The best solution ALWAYS wins. That's the more general definition of better - it wins. Just have to look at the whole process that defines the winner, based on a criteria of what is winning anyway.
The most popular product is hardly ever the best, because most of the people who choose products lack taste. To choose the better of two programming languages, you have to know both sufficiently well. Most of those who chose Java didn't even consider Smalltalk as an alternative. In the long run, the better product does win but that can take many years. -- DonaldFisk
("In the long run, we'll all be dead" -- John Maynard Keynes; Dead like VHS)
Well, there is the minor issue of a distributed component model a la EJB. Right at the end of its zenith Smalltalk started to become accessible via CORBA, which might have sufficed, but the market for Smalltalk ORB vendors was even smaller than the market for Smalltalk. -- RandyStafford (January 7, 2000)
Started implies that it didn't happen. Cincom and IBM both provide ORBs with their Smalltalks. Plus, you can connect them to Web servers, connect them with DCOM, and connect them with databases. From the stories I have heard of EJB, Smalltalk systems that are comparable are faster and faster to implement. Of course, EJB is improving. But that is Java in a nutshell, not as good yet but improving. -- RalphJohnson
See LanguagePissingMatch. -- RandyStafford (January 7, 2000)
''DolphinSmalltalk and SmalltalkMT both support the Windows API extremely well. You can make COM objects with them. They both have free or lowcost implementations."
I was involved in a project using Digitalk Smalltalk\V developing shrinkwrapped CD-ROM based edutainment/reference products for AXIA Multimedia back in '93-'94. It ran acceptable on a 486/166 with 8M and a 2x CDROM :-) -- DaveAstels (March 26, 2003)
There is nothing I can think of in Java that I have today (except possibly servlets) that Smalltalk did not have, usually better, two or more years ago.
Does Smalltalk have Multithreading support, Unicode support, Internet URL support, Network Programming, Cross-platform support, Applet support (can you run Smalltalk in a Web Browser?)?
Also, Squeak can run in a Web browser through a plug-in.
Well, I believe that Dolphin runs applets in a Web browser, (and will produce code for the Lego robotics kit too). There's a Smalltalk for the Palm. Chrysler converted C3 to run multiple threads of GemStone Smalltalk instead of single-threading - in a week. VisualWorks runs on PCs, all forms of Unix, Linux, and the Mac. I don't need Unicode, but I think VisualWorks has that, too. It's a bummer that no one uses Smalltalk or ever will. I feel really dumb having made such a good living at it for the past 10 years.
Smalltalk-80 has had multithreading support since the early beginnings. In fact, prior to ObjectWorksForSmalltalkFour?, each StandardSystemController? ran in its own Process. I suspect this was an artifact of the fact that the Smalltalk VM served as something of an operating system on the early Xerox machines. Anyway, I've found Smalltalk's multithreading support to be more intuitive than Java's. For example in Smalltalk all Processes (threads) at the same priority level take turns in round-robin fashion but, annoyingly, in Java there are no guarantees as to which of a set of threads at the same priority level will run next. I've also had occasion in the past to port Smalltalk's Semaphore class to Java, because Java's built-in synchronization semantics didn't meet my needs. And as I mentioned in DefinitiveSmalltalkBooks, one of the cool things about earlier releases of Smalltalk-80 was its support for discrete-event simulation, which is an inherently multi-threaded solution. I know of at least one commercially-available implementation of a multi-threaded discrete-event simulation tool in Smalltalk (the Dynamic Verification Facility in Ascent Logic's RDD-100 product - http://www.alc.com). I will admit that for a while the Smalltalk vendors had difficulty with native multi-threading (in other words, when one Process in a Smalltalk VM would block on an external call, it would block all other Processes in the VM), but I know that at least GemStone (and perhaps other Smalltalk vendors) solved this problem. -- RandyStafford (January 7, 2000)
VW images (what it spits out) will in fact move to and run on any machine. Better than java will, in fact. Across vendors, the Smalltalk language is not as standard as Java, but then Java isn't as standard as Sun wishes it was. As with Java, the real functionality of Smalltalk is in the class libraries, and those are not entirely standard. As for running in a browser, the trick there, of course, is just to get your interpreter downloaded. It's not a function of the language but the implementation.
Still, I'm all for using whatever tool works, and in another world or another month, I'd use Java. Nonetheless, as I observe what works and what doesn't, if programmer productivity is the question, Smalltalk is the answer out of all the languages I know. If political correctness is the question, then Java or C++ might be. -- RonJeffries
That said, while it's true that there are some Smalltalkers here, and like most Smalltalkers we're quite sure it's the best thing we've ever used, there are proponents of other languages here, and (save us) even some methodologists. Don't paint them all with the same brush you'd use on me. ;->
-- RonJeffries
Sorry. I'm all for people using the best tool for the job and the one that makes them the most productive. I am glad you have found that in Smalltalk and have made a great living at it. I really dislike the attitude of the Sun folks and the Java fanatics that everything should be written in 100% Pure Java (whatever that is) and that everything else is legacy code. I went to a most insightful talk at Software Development 97 by Dr. Stroustrup, where he implored us to learn as many languages as we can and apply the best one to the job at hand. No one language can do it all. He stated something to the effect that the Java fanatic's attempts to do that smacked to him of something like fascism (I'm not sure if that's the exact word he used but it was something like that.) From people's reactions to Smalltalk here, it must be a great tool and like I said, more power to you. -- sg
I second that thought. The java fanatics can sometimes be a bit much. I literally almost fell out of my chair laughing in a meeting over this a couple of years ago. We were having all the *nix hardware vendors round to see what they could offer - considering a platform change. So Sun sends round a couple of very clueless girls from marketing - apparently, their tech. person couldn't make it at the last minute. About 15 minutes into our description of what the product did, one of these salesdroids perked up with have you ported your application to Java yet?. After picking myself up, I took 10 minutes to describe how exactly how badly ~ 500k lines of tuned numerical (signal processing) code would perform under Java. I did suggest that if they were willing to reduce the top end ultrasparc's cost by a factor of 10, we could consider it :) From her pained expression, I believe she actually thought that Java was the best, whatever the application.
When was this, exactly? Even number crunching can be done equivalent (within an order of magnitude) to C code if written correctly, and HotSpot will optimize heavily used code for you as well. It may have been true at one time, but I doubt it is true currently. -- Will Sargent (6/28/01)
Well, it's still true in March 2003. On Win32/Intel, anyway. Compare the time needed to call exp(), pow() and/or log() for Java and for MSVC on that platform. Java is substantially slower on the JREs that I have tried (Sun's). I believe this is due to Java's strict floating point accuracy specifications making it difficult to optimise to the Intel processor. If anyone finds a JRE, running on Win32/Intel, that can match C/C++ performance for these functions, please do let us know.
Lets not bring out the 'java fanatics' thing. Browse around at the ThisVsThat? and ThisIsDead? and WeHateThis? programming pages and you'll see that Java people are on the receiving end of most of these language battles. It is totally wrong to call them fascists, when it would appear that most of the other programmers are. Maybe the smalltalk and python programmers are just angry 'cause they don't get paid as much as the J2EE programmers, but they shouldn't be asses about it.
Actually, since the Smalltalk people seem so happy with their language, I looked at a tutorial and started to download it. I immediately stopped the download when I saw some Smalltalk. Here is some example code:
Smalltalk:
lineCount "Answer the number of lines represented by the receiver, where every cr adds one line." | cr count | cr Character cr. count 1 min: self size. self do: [:c | c == cr ifTrue: [count count + 1]]. ^ countThis is the ugliest smalltalk code I have seen for long. For this purpose there is a method. (I do not want to mess up String, that's why the parameter.) lineCount: aString
^aString occurrencesOf: Character crEnumerations do not need a counter, the writer of this code has NO idea of smalltalk. Shame on him, double shame because he is a tutorial writer.
Java (for an Object which extends java.lang.String)
/**
* Calculate the number of carriage returns ('\r')
* in this <code>String</code>.
*
* @return the number of lines in this <code>String</code>
*/
public int lineCount() {
// it isn't at all clear what 'count 1 min: self size'
// means, so I'll take a guess
int count = (length() == 0) ? 0 : 1;
for (int i = 0; i < length(); i++) {
if (charAt(count) == '\r') count++;
}
return count;
}
Error:
Can't extend 'java.lang.String'; it's declared 'final'.
Alternate:
import junit.framework.TestCase; public class StringTest extends TestCase { public int lineCount(final String str) { final int length = str.length(); int count = (length == 0) ? 0 : 1; for (int chrIdx = 0; chrIdx < length; ++chrIdx) { final char chr = str.charAt(chrIdx); if (chr == '\r') ++count; } return count; } public void test() { assertEquals(0, lineCount("")); assertEquals(1, lineCount("x")); assertEquals(1, lineCount("Hi mom!")); assertEquals(1, lineCount("Hi\n" + "mom!")); assertEquals(2, lineCount("Hi\r" + "mom!")); assertEquals(2, lineCount("Hi\r\n" + "mom!")); assertEquals(2, lineCount("\r" + "right")); assertEquals(2, lineCount("left\r")); assertEquals(2, lineCount("\r")); assertEquals(3, lineCount("\r\r")); } }Please what is wrong with you people??? No you can't extend the String class - it is by intent, it is by design [foolish intent; bad design]. Create an utility class - and don't use the final keyword unless you mean it (and understand it):
public class StringUtilities? { public static int lineCount(String text) { int count = 0; for (char c : text.toCharArray()) if (c == '\n') count ++; return count; } }And if you need the code corresponding to "count 1 min: self size." it is "int count = Math.min(text.length(), 1)".
There you have it. What is conceptually clearer? Sending the message "min" to a number 1 with another number as a parameter or calling the static method "min" with the number 1 and another number as parameters?
Somehow I think this a rhetorical question. I, for one, find Smalltalk idiom far clearer than having to guess what random file might have the method buried in its collection of random methods. -- TomStambaugh
It is open to debate. But I will pick Java anytime over Smalltalk. Not everything is an object.
Saying not everything is an object would make me believe you're using a MultiParadigmProgrammingLanguage, in which you have the choice to express a problem as a mix of OO, functional, procedural, or whatever your language supports. Stating this for Java seems like a contradiction. Java doesn't give you the option, it forces you it's design, with a rather confusing mix.' If not everything is an object, i'd say Java < C++ (because options). C++ < Scala | Scheme | Oz ... (because even more options). But if you're forced on an ObjectOrientedParadigm? (not entirely true, but anything else will still be done through objects), then Java < Smalltalk all the way down because coherence (Smalltalk < Self | Io for that same matter). fs.
Many good points have been made here, but there is one thing I have seen numerous times and still am rather bewildered:
How in the world can any language that supports OO programming force good OO code???
The basis of this assertion is that no matter how good the language, you still need good programmers to write good code (and good OO code as well). I don't believe that even the best designed language that supports OO is a silver bullet that can stop bad OO style such as:
BruceEckel has commented that Java was designed to reduce the complexity for the programmer (see http://www.technetcast.com/hz-show-980501.html ). This is a very good thing, but it won't stop blecherous design.
-- AlanHecht
Reduce the complexity? Ha!! Compared to Smalltalk, the lack of uniformity (primitive versus reference types) in Java increases complexity, and the exception-handling syntax increases complexity (witness all the wiki pages on Java exception-handling idioms, starting from ExceptionPatterns). Not to mention the lack of BlockClosures?, for which AnonymousInnerClasses and their requisite interfaces are a poor substitute. I concur with the above assertion that you still need good programmers to write good OO code, but at least in Smalltalk everything is an object (including classes, which enables inheritance of "constructors" and the use of self (this) and super in class methods (which static methods are not, really), and all computation is accomplished via message-sending, rendering it a completely uniform environment regardless of whether the design is good or bad. -- RandyStafford (January 7, 2000)
Fully concur. As I mentioned in Sam's area above, bad programmers will write bad programs in any language. I feel very confident that no language is going to correct that. If you can't think clearly what you want, no language is going to get you a clean program. -- RonJeffries
Totally concur also. -- SG
RandyStafford, just because Smalltalk is consistent doesn't mean it isn't complex. I think separation of certain ideas makes them easier to use and understand. Randy, you spend a lot of time focusing on object vs primitive. Java is not the only language with this separation. Do you want to begin dissing Perl (you'll lose that one - it may be cryptic at times, but it outdoes smalltalk), Ecma/Java/JScript, C++ (theoretically you could do some object-oriented number stuff in C++, but I've never seen it), PHP, and most of the other languages? I suppose maybe you do, but if you can't see that each of those languages is best suited for certain programs, then you're just another example of the Smalltalk bigot. I don't know what there is to dislike about Java exceptions. They are clear and useful. Anonymous inner classes work as a replacement for BlockClosures?, although that is not what they are intended for. Indeed a BlockClosure? is an anonymous class of sorts, just declared with a quick and obscure syntax.
Anonymous classes can in some cases be hacked to work like block cloures, but it's hardly the same. That obscure syntax you speak of makes using blocks so simple that it becomes idiomatic, something innerclasses are horrible at due to their lenght. So obscure should be convienent.
In Java, you can call methods from superclasses as well, so you were just uninformed on that point. Rather than 'self (this)', would be equivalent to 'super()' in Java, which is in fact automatically called if you don't do it manually.
No, you didn't read what he wrote. Smalltalk can use self/this in class methods, what you would call static methods because in SmallTalk the class itself is also an object. Though static methods hardly compare to class methods.
In good java coding all communication should be done through methods, just like communication is through messages in Smalltalk. When you are not communicating, you don't need a method.
And you don't understand the importance of the difference between message and method. Messages are objects and can be passed to higher order functions enabling many advanced idioms. Methods can't, without methods as first class objects at the language level. Java cannot do this, at least not the official Java.
The use of 'public static final' is better than using a method because you recognize what type of information you are dealing with. In good code instance and static variables are only used within the class itself. However unlike Smalltalk Java gives you the option to use variables directly (which is not too unacceptable for inter-package communication). Basically, the moral is that you do not know Java (at least not well enough to claim you do). Don't try to trick others when you are uninformed yourself.
No, the moral is you don't know OO, you know Java which supports weak OO. He was not uninformed, you are, and you're being very rude by accusing him of tricking others.
OTOH, I have heard it said that there were virtually no badly written programs in MIX :-) -- FalkBruegmann
No bad programs in MIX? I certainly saw quite a few back in the late seventies when I was programming lab assistant at Georgia Tech. Of course, back then the profs were frequently looking for the most horribly over-optimized solution (proof that you understood the machine architecture) rather than one with any structure to it. :-)
And MIX would be? -- sg
MIX was the mythical computer used by DonaldKnuth in his landmark books. I guess the language was actually MIXAL, the assembly language for that machine. -- ChuckMcCorvey
Well, I haven't seen any bad programs in INTERCAL either... :-) -- WillSargent
I am always amused by the "my language is better than yours" threads. While Bertrand Meyer's Eiffel is perhaps one of the most complete OOPL's (and the only one worth using, if you listen to Bertrand), it has seen little or no market penetration. I have used Smalltalk, C++, and Java on large commercial projects and all of them produce excellent results when used properly. They can also be abused horribly, and perhaps the worst abuse is to force the use of Language X idioms in Language Y. Besides, as the old saying goes, "you can program Fortran in any language". -- ChuckMcCorvey
See LanguagePissingMatch. -- RandyStafford (January 7, 2000)
Perhaps a good measure of a language is how fast you can restructure a poorly structured program. In this case, it seems that languages like Smalltalk and Self have an advantage. -- MichaelFeathers (said enviously as he sat at his C++ IDE)
I hate to start this again, but I still don't completely understand this concept of restructuring. No one is going to get the design right the first time. I know that. And one may have to restructure code inherited from someone else for maintenance reasons. But the way you put it above, it is like restructuring or refactoring is a constant thing and Smalltalk gives you advantages. That may be but I can't get convinced yet that constant restructuring is a good thing. Some is great but too much of it may indicate a bad design in the first place. What am I missing? Maybe I'm not understanding something but it seems to me that the restructuring would end at same point. -- sg
See ConstantRefactoringIsaGoodThing. -- RonJeffries
See DoesXpWorkForJava. -- RandyStafford (January 7, 2000)
Kyle, surely you remember the Smalltalk bandwagon! All those groups starting Smalltalk projects without any experience in OOP at all. They knew about Smalltalk because their manager had read an article that promised the moon. There has been a C++ bandwagon (just like C, only you automatically get reusable code!), a C bandwagon, and probably a COBOL bandwagon. Bandwagons are a fact of life. People are drowning, and grasp at straws to stay alive. The new solutions are not nearly as good as people hope they will be, but they often are better than the old solutions.
Bandwagons are good because they help people change. We often are stuck in an obsolete way of doing things and we need a jolt to move. But there are so many choices! Which way should I go? If a big, shiney bandwagon comes by, surrounded by a cheering crowd, I am much more likely to get up and follow it. It might not be perfect, but at least I'll be in good company, and it forces me to change when I'm stuck.
The problem with us Smalltalkers is that we are just jealous of the Java bandwagon. The Smalltalk bandwagon broke down, and at its best it was not nearly as shiny nor as noisy as the Java one. Java is proof that marketing is essential. Great marketing and decent technology gives you a better bandwagon than great technology and decent marketing.
-- RalphJohnson
I don't think you can characterize ParcPlace marketing as even decent.
See WhoIsDougPollack.
I would go even further, and consider ParcPlace to be a canonical example of how not to market.
I have a theory as to why Smalltalk failed to gain significant market share. I think it's because it looks weird. Java went for a syntax that was like C. This gave people a feeling of comfort even though Java is a very different language from C in reality.
Between all possible reasons often cited as a possible cause to Smalltalk "market failure", I find this one (syntax weirdness) the hardest to believe. It's true that some languages with "weird" syntax, like Forth or J or Lisp are put aside by most programmers/industry. But how many are put aside too that have "normal" curly brace syntax (asuming curly is normal for most)?
Or, to put it another way, I don't think it stops people from switching from BASIC to C to Python. (OTOH, Ruby seems to get more new adepts than Smalltalk. Go figure). And the syntax is so simple you can fit SmalltalkSyntaxInaPostcard! fs.
I now call Java "SmalltalkMinusMinus".
It is absolutely true that I am many times more productive when coding in Java than in C++. So what - in my experience, the productivity of any developer using C++ approaches zero (in the limit) and so virtually any tool is superior, including SAP, Excel, VisualBasic, C, Pascal, ObjectiveC, and a host of others. I therefore view the observation that Java is a better tool than C++, in most situations, tantamount to observing that the sun is likely to rise in the east tomorrow; true, but containing very little information.
I use Smalltalk because I can do with ease and robustness things I shudder to even contemplate in Java. Yes, of course much of the functionality is in the environment, instead of the language. That is the entire point! If it is in the language, then (like Java and C++) it becomes impossible to fix.
I have hard-copy of the Smalltalk-80 environment as it existed in 1985 or so. It contains better support for file I/O, sockets, TCP-IP packets, and process scheduling than anything I've seen since. I grant you that we have learned enough about UI since then that the GUI classes have an archaic, crinkly feel to them when read with 2000 eyes.
Let me offer this example: I just finished releasing a distributed application, written in VisualWorks 2.52 - from about 1995 - that is in daily use by hundreds of scientists. It is still in VW252 because 90% of our platforms are Mac's, and VisualWorks is the only Smalltalk that effectively supports the Mac. Our system supports Smalltalk clients running on Mac's, PC's, and multiple flavors of Unix.
Can someone please cite a similar application built from a competing platform? Which platform can support all three environments today? Which platform supported all three platforms five years ago? Which platform could, today, run code that easily coexists with code that is 3, 5, or in some cases 10 or 20 years old?
I agree we must choose the right tool for each job. I have found jobs for which Perl is the best tool (for me), others for which Excel is the best, and some for which C is a win. Since the inception of C++, I have not yet found a problem for which it was a superior tool, for me, than Smalltalk. The same is true for Java.
While I agree with the sentiments about tool choice, my experience has been that usually this right-tool-for-the-right-job mantra is generally just a rationalization for I-like-what-I-like-and-leave-me-alone. By all of the methodology metrics I can think of, Smalltalk and Lisp have blown away the C++ family (including Java) for decades. I've also witnessed our technical community steadfastly ignore these results. So can we please give up the fiction that this anything more than personal opinion? Except, of course, my own comments about the superiority of Smalltalk - these being merely descriptive statements of objective fact *smile*.
I also agree with RalphJohnson's observation that technical superiority has only coincidental relationship to market success. My SONY SL-5800 Betamax player, from 1979, still outperforms any VHS player available at any price if you care about slow-motion, still frame, variable-speed playback, tape wear, and image quality. So what? Sony lost the marketing war, and the Smalltalk community made the same mistakes 10 years later. The Macintosh, in 1984, was a more usable platform for a single user than a Win95 environment from 10 years later. The NexT platform was head and shoulders above its competition in technical quality, by virtually any measure. So what?
I believe that we are still in the birth-pangs of genuine computer science. Our children will find our arguments about C++, Java, and Smalltalk amusingly quaint. yes! - see SecondGenerationProgrammer
And I still think Java is SmalltalkMinusMinus.
-- TomStambaugh
When I wanted to learn Smalltalk, a copy of VisualWorks cost $3500.
When I wanted to learn Java, I ftp'd the JDK from Sun.
-- JohnBrewer
The importance of this for Java's success cannot be overestimated. I could write cool applets right away, and put them on my Web page. The JDK was the RealThing?, not some evaluation version with tons of strings attached.
VisualWorks Non-Commercial is free
SqueakSmalltalk is really free, with code and all, even for "commercial" use. This might be the best thing happening to Smalltalk in years. -- StephanHouben
But then the Squeak interface looks like something coded in the 70's. Squeak is written in Smalltalk itself, I believe. Maybe this is a symbol that Smalltalk is a programming language that should have died out with the 70's. Just a thought.
Ugh. Now who's flaming? The Truth about Squeak follows: -- RobertChurch
Squeak is actually written in Squeak. The UI is archaic-looking, but the intent of the designers was for the entire codebase, including the GUI, to be simple, easy to understand, and written in Squeak. At present, Squeak can't make native-looking GUI applications. If you want VisualWorks or Dolphin, you know where to find them.
But I can't write multiple-window, native Mac/Windows-looking apps using Squeak. Calling native code was too arduous to consider doing in Squeak. It isn't too bad in Java, and QuickTime is already available Java (didn't see any way of using QuickTime from Squeak.) -- KeithRay
(QuickTime for Squeak: http://home.attbi.com/~zurgle/quicktim.htm )
I agree that there are now a lot of high-quality, low-cost Smalltalks. Unfortunately, at this late date, it's largely a matter of closing the barn door after the horse is long gone. -- JohnBrewer
When I first heard about Smalltalk I downloaded Squeak. I though it looked absolutely awful. Really odd, clunky, tacky, totally outdated graphics, no concession to modern look-and-feel, with appalling documentation. It could hardly have done more to put me off. Eventually I had a look at Dolphin, which was much more like the standard I was expecting, though the tutorial just ran out after several chapters. Compare with Sun's great Java Tutorial... -- DavidAllsopp
I heard that IBM was going to rebrand VA/Smalltalk as VA/Java Pro. -- BruceAnderson
In the comparisons between the two notice that it's always Smalltalk product X could do that, product Y could do that. Any version of Java has the standard set of features where every version of Smalltalk is different. Add to that the initial costs and the licensing costs and how could smalltalk ever become ubiquitous? It's not a matter of better. I could argue Lisp is better than Smalltalk. But if i can't afford to own/use/sell the version of Smalltalk that has the feature set I want, assuming I'm not worried about portability between versions, then how could I use Smalltalk? I've always found this very unfortunate because I really wanted to use Smalltalk but did not find the pro arguments convincing enough to counteract the risks. Being X times more productive really is just one small part of any metric. -- AnonymousDonor
Being X times more productive really is just one small part of any metric.
And THAT summarizes the development "tool" market quite crisply, especially when X is often cited as 40-100. -- TomStambaugh
There is one issue I'm missing in this discussion, which is not related to the language itself, but to the *environment*. When talking about the development speed or the speed of learning a new language, at least one of the most important factors is the language support. means:
Sound's like dib hasn't used IBM-Smalltalk or VisualWorks. Even Squeak compares favorably with any Java IDE that I'm aware of, along all four dimensions cited by dib. Perhaps dib might offer his or her choice of Java tools.
I've used VW 5.i4 (now 7.2), and I was very disappointed about the IDE. For example:
IF you expect it to behave the same way. When I first started VisualWorks Smalltalk, I did lose time looking for "where is the entire class written", "how do I create a new class/method", thinking that the last is same with "where do I write public class..." and "where is public class so that I can write public method " . But you create a class by adding an item to the package, and you create a method by writing it in the method area, no matter what is where already, the IDE deals with it. You always have separate views for each item, and manage them. That is exactly what people think eclipse should get to someday. It's the way eclipse 3 has taken with the options to show/hide portions of your code. What people coming from eclipse to Smalltalk IDEs find strange to deal with, it's exactly what win95 users just couldn't get when facing a Mac for the first time - "you just drag it?!" -- AnonymousDonor
[If you know of good, free Smalltalk tutorials on the level of Sun's Java tutorials, please post a link. I played with Squeak and Dolphin but gave up because of lack of documentation.]
http://smalltalk.cincom.com/tutorial/index.ssp?content=tutorials
[How much does that Smalltalk cost? Does anyone know of good tutorials for a free Smalltalk?]
You can get a license to use that Smalltalk for non-commercial purposes for free: http://smalltalk.cincom.com/prodinformation/index.ssp?content=nc. And that's the original Smalltalk, i.e., VisualWorks, i.e., Smalltalk-80.
[But how much does it cost to use commercially?] The last time I checked, the development image is free. When you deploy the finished app, you pay for each deployed image. Check with cincom for more details.
Squeak, a full open source implementation of Smalltalk, can be downloaded from http://www.squeak.org/download/index.html. This is even more "original" than VisualWorks (if that's a good thing), in the sense that you can run the original Byte Magazine-era look-and-feel if you like. Squeak was created by the original creators of Smalltalk-80, including AlanKay. Squeak is free. Be sure to visit Squeak Swiki (http://minnow.cc.gatech.edu/squeak/1), a wiki (written in SqueakSmalltalk, of course) where you can learn lots more about Squeak, the community, and Smalltalk.
[As I said above, Squeak is one of the Smalltalks I tried. I couldn't comprehend the documentation (or the GUI). Is there a good tutorial for it?]
If you visit the Squeak Swiki referenced above, you'll find a section titled "Getting Started With Squeak" which has several links to get you started. The second, http://minnow.cc.gatech.edu/squeak/377, takes you to a rather good summary of various resources for LearningSqueak and LearningSmalltalk. I don't know how up-to-date it is. Further down, the "Documentation" link (http://minnow.cc.gatech.edu/squeak/2983) points to reasonably detailed documentation about Squeak. Someone, above, asked for documentation at the level of Sun's Java tutorials -- I believe these links exceed that threshold.
I went through the tutorials listed at http://minnow.cc.gatech.edu/squeak/377. Few of them seem to be written by native English speakers. I can't find anything about creating new classes. None of them are nearly as thorough as Sun's Java tutorials. The most promising tutorial I've found (at http://www.cosc.canterbury.ac.nz/~wolfgang/cosc205/smalltalk1.html) is very confusing. Sentences like:
"choosing 'add item' from the leftmost browser pane's yellow button menu"when all of the menu buttons are green. Or:
"Let us assume that we have successfully proceeded to define all class and instance methods for both monsters, and that the state of the model is now reflected by the figure below, which also shows the code for our CookieMonster's isFull method in the browser's bottom pane."without ever showing me how to define class and instance methods. I can't figure out if I've become lazy and stupid since I learned Java, or if there's something about Smalltalk that makes people write incomplete tutorials.
If you're starting from scratch, start with SmalltalkTheLanguageAndItsImplementation. If you can find a copy of SmalltalkTheInteractiveProgrammingEnvironment, it will provide the specific description of the oldest Squeak interface -- including the references to mouse buttons.
The colors, by the way, are red->left, yellow->middle, blue->right for a right-handed person. These were chosen so that they can easily be remapped for left-handers that like the mouse on the other side. Choosing colors lets the documentation and code stay unchanged.
Meanwhile, if you exercise the same patience, tolerance, and tenacity required to figure out, for example, how to use Eclipse to get anything done with Java, then you'll do fine with Squeak. IBM is making noises about releasing IbmSmalltalk as an open-source product - this would be a GoodThing.
All theses littlenesses together makes it hard to deal with the IDE (thus dealing with smalltalk), especially when coming from a java IDE like netbeans, eclipse, websphere, jbuilder... -- dib
By the way, if you can afford websphere you can afford IbmSmalltalk (at one time WebSphere WAS smalltalk, but maybe not now). My experience with eclipse, websphere, and jbuilder has been that ANY change to the sorts of things you describe is at best tedious and difficult. Visualworks is designed to be customized. If you can customize eclipse, you can surely customize VisualWorks. The exercise is how many Smalltalkers learn the language, tools, and environment.
I agree that some of the tools (e.g. Websphere) are really complex tools, where you can probably do 10x more things you want to. But at least you can be sure to be able to easily change the syntax highlighting, have a CTRL-C/V/X support ... . I don't want to customize the IDE, to have for example alphabetically sorted search results! This is one of the absolutely basics of an IDE. Don't get me wrong. I don't want say "java is the better language", but the language *support* for smalltalk(IDEs, documentation, etc.) is worse in my opinion and that's a key factor. -- dib
In Squeak, to adjust CTRL-C/V/X support, open the KeymapManager?. This can be done by typing "KeymapManager? open" into any text window, then selecting the text, then using the right-button popup menu to invoke "do it" (on the selected text). Most things that you search for are already alphabetic if they are strings (method senders, implementors, instance var refs, etc). If not, use the browser to find the implementor of the search message (invoked from the menu) and look inside that method. To learn about syntax highlighting in Squeak (there are several options, including "Shout"), try using "squeak syntax highlighting" in Google and examining the hits. It's beginning to sound like you are more interesting in complaining about the environment than in understanding it.
We've got a pretty good game of "Why don't you... Yes, but..." going here, a la GamesPeoplePlay
For me, coming first from C, ASM and Pascal, then Cobol, then Smalltalk, then Java, the choice is simple. Smalltalk with either VisualAge, VisualWorks, or Squeak (possibly Dolphin but I haven't used that one) effectively beat out Java with Eclipse or WebSphere.
The language itself has less code, a simpler syntax, richer object(class) library, is extendable, encourages frequent refactoring, blocks (this alone is enough), etc... The IDE encourages programmers to read the code(real answers) not the documentation(presumed answers) which also enhances one's understanding of the language and OO principles and most importantly the application they are working with. Programmers read code a method at a time allowing a focus on quality that will never be accomplished in a Java application. Smalltalk code runs faster and usually is easier to package(image based) and configure than java jars, wars, ears(file based). I suggest giving it a real chance if you are open to it. Quite likely, besides the need for an income, you'll seldomly return to Java to get work done.
Java has some advantages that have come from the hoards of developers working with it and Sun was wise to offer it freely but it is nothing compared to Smalltalk in terms of productivity, education (OO), and pure programming grace. Of course, this is all just my opinion.
Doug Stewart July 7, 2004
Ok. I decided a few years ago to join the JavaBandwagon. To learn Java I:
I got a job maintaining an app they were intending to port to java. To learn the enterprise stuff, I:
How would I learn Smalltalk? How would I get myself up to the point of being able to write commercial applications in it?
Well, I guess you would read a short tutorial to get yourself started with the environment you are using, read a short tutorial to get known to the syntax. For anything further you use the Package/Class browser to look at the code, the comments etc.
At least, that's the way I do it using VisualWorks. If you want to get known to the style of Smalltalk, you read other people's code.
I have to agree that Java is more accessible. Smalltalk may be better then Java, but where is the freely available version that can be used for commercial applications. Squeak just does not match up to the JDK in this regard.
Download and use either Squeak or VisualWorks.
Well, we can always hope SmallScript / SSharp / whatever name David Simmons gives it next year actually gets any major. Inline C++ and full blown .NET / Windows API integration could make for -very- smooth integration with half anything else, which is always good in practical situations. A programming language that doesn't play nice with other languages is inherently limited, which is why I chose to use .NET instead of Java for a recent assignment of mine - ItJustWorks beats JNI into a bloody pulp any time of day.
Seen October 19, 2005 on IRC
<rh>man ... this takes me forever to finish ... smalltalk is more productive?
bah, not when you lack motivation
<isomer>just try it in java
<isomer>it's like having a personal trainer standing over your shoulder hitting
you with a bat every time you try to do something nicely
<rh>well there's not much different between not writing smalltalk code and not
writing java code, is there
<isomer>sure there is
<isomer>it feels better to not write java code
<rh>so actually smalltalk is worse in that respect
<isomer>i suppose so
I know I missed the boat on this conversation; I was probably bogged down in some unlrealistic deadline :). I find it funny that any Java programmer could criticize Smalltalk when the best things about Java are taken from Smalltalk. Virtual Machine and portability - who invented that? Smalltalk. Garbage collection? Smalltalk.
The MVC paradigm on which both awt and swing are based on I wonder who invented that ... Smalltalk. The original java Collection library - hmm, where did they get that? Smalltalk Collections. It is sad that the history of computing isn't taught or taken seriously by developers who are always in a hurry to meet some deadline. I have caught myself often skipping the history section in technical books but as I matured as a developer I started to realize that the history of computing and Ideology is more important then the exact technical details of any library or language. For an OO programming to criticize Smalltalk is almost sacrilegious since Smalltalk is at the very source of OO ideology. Java is C++ moving towards Smalltalk; anyone who has programmed in all three languages should be able to see that. Is Java more OO then C++? Definitely, but Java is still less OO then Smalltalk - which in my opinion is the source of the whole OO paradigm. If you look at all the great ideas that came from Smalltalk and its community, it is hard to criticize it seeing as we are still all using those ideas today and haven't yet come up with better ones yet. I make a living as a Java Developer and I am against biting the hand that feeds me but for any software I develop myself I use Smalltalk squeak because it's a better language.
I noticed someone made the comment that squeak is not as good as the JDK in terms of commercial development; actually, I would disagree - while squeak does not enjoy the same level of support (i.e., books written about it, community size, corporate funding etc.), it is still a better development enviroment than the JDK with IDE (browsers, inspectors, graphical debuggers, etc.) built-in support for software versioning and unit testing built into the VM, all this accomplished with less funding, and fewer people/smaller community. Imagine what squeak could be with a community the size of Java's. I admit I use to be impressed with Java till I did a little bit of historical computing research and realized that there is nothing revolutionary about Java other than its successful marketing.
One thing I see no reference to here yet is run-time performance. For some purposes, a key requirement is that the application run efficiently in its deployment environment. As far as I've been able to tell, there are four widely available languages in which you can write stuff and have it run really, really fast. Assembly. C. C++, if not too horribly mangled. And recently joining the club, Java, purely because of Hotspot. Hotspot JIT compiling is one crucial aspect. The modern generational GC implementation, which can even take advantage of multiprocessor machines' multiple CPUs (and of hyperthreading), is the other. Typical OO apps in Java have lower allocation costs per object than in C++; allocating anything but huge objects is not much slower than a pointer add or two and deallocation costs amortize to zero as the proportion of short-lived objects increases, becoming effectively zero if an application doesn't create any long-lived objects after some initial startup ones and doesn't create short-lived objects with nontrivial finalizers nor Reference objects.
For a Smalltalk implementation to compete with Java effectively, it will have to do all of the following: implement JIT compiling in at least the x86 VM binaries; implement a comparably-advanced GC to Hotspots as well; implement a decent facility for calling into and being called from native code; and implement soft/weak reference objects of some kind to support certain kinds of memory/space performance optimized code.
For example, to efficiently implement a substring from index 334 to 809 of a string, you want an object with a string interface that's actually backed by the parent string and only needs to hold a reference and the numbers 334 and 809 -- constant time creation and around 12 bytes of data plus the runtime's per-object overhead as opposed to linear time creation and almost 500 bytes(!) (for that particular example) of data. On the other hand, if the parent string is 540,000 bytes long and no longer referenced except via substrings, you want the parent string to be collected. This suggests having string and substring both hold references to a backing char array, and substring holding a weak reference to the parent string. When the parent string goes away the substrings detect it and replace the char array backing them with copied data from those arrays, and the char array, all half a meg of it, is now garbage collectible. Our example substring changes the backing char array to a new one that contains a copy of the subarray of the previous one from index 334 to index 809, and its start and end indices to 0 and 809-334, respectively. Now the substring is around 500 bytes of data -- but it's saved us half a meg. Of course, loss of the parent string also cost us the time to copy the substrings, but it's worth it to save half a meg of ram.
So, weak references are valuable. Soft references are also valuable, as they can be used to cache loaded stuff (e.g. Web page data) with the implementation knowing that this stuff is safe to null out to reclaim memory if space is getting tight. Versus the programmer having to write all kinds of cache-management code including some sort of low-memory exception handler to wipe the cache and retry the botched alloc, as they would have to do in C++ but not in Java.
Another thing that would be crucial is access to the implementation's native numeric data types. High performance code has to use ints and doubles wherever possible in place of some bignum implementation, and only use the latter when the higher precision or larger max magnitude is needed. Ideal would be to have a Float class whose instances have fixed precisions and can be combined arithmetically with like-precision instances, and where the precision is low enough, thunk to a native float, double, or long double as appropriate. (Java doesn't even give access to the native long double, which costs you 24 bits and a bunch of exponent range on x86 hardware and more on most other architectures -- lots have a 128-bit native FP type with over 96 bits of mantissa! Plain old "double" has what 56 bits of mantissa? And 8 of exponent.)
Show me a Smalltalk that can do the things noted above, including high-performance generational GC and a JIT capability in the VM binaries for the most common architectures that can optimize inner loops to near-native speeds (comparable to C++) and I'll show you a possible Java-dethroner. Until then...
Of course, many of the Smalltalk implementations mentioned here are unfree (indeed, less liberally licensed than Sun's Java implementation, which is moving towards open source as we speak anyway) and the rest have sufficiently poor documentation that, for all I know, some of them actually do have some of the capabilities suggested above.
The ability to make (or fake) a Windows-style GUI is also likely to be important for serious adoption in client side development. This doesn't mean duplicating the L&F exactly -- Windows or Mac users can generally get used to the other or to Java Swing's default L&F without much difficulty. The gap between any of those three and e.g. Squeak's default L&F is enormous by comparison. The ability to randomly nuke or modify any GUI object with a few mouse clicks or keystrokes is also a problem outside the development stage, since otherwise users will inevitably mangle the application's UI and make ten thousand mailing list threads or support calls asking how to fix it and how to stop it being all too easily done accidentally. Users that accidentally nuke the toolbar with the file menu and can no longer save their document, then when they ask how to get it back are told they have to exit and restart the app, will probably end up wanting to nuke the developers of the app, followed by a random Middle Eastern country, followed by Redmond (where the people responsible for the failure for continuous save to become widely adopted in desktop computing are, or at least where suitable proxies are), followed by several other proxies for their rage, followed by that irksome wobbly newel post and the loud music played so often at odd hours by their neighbors. :)
AFAIK all Smalltalk implementations make arbitrary writing of their windows and arbitrary event handling therein possible, given enough coding work to implement basically a whole extra window manager. AFAIK none of the free ones (meaning at minimum compatible with open source development) make opening multiple native windows possible.
On the plus side, some of them seem to have a smaller minimum runtime footprint than Java.
Here's more on performance. I just cobbled together a Squeak "morph" to display the contents of an array of arrays of small integers as a color-coded grid of rectangles. If the arrays have size 100 (effectively, a 100x100 2-D array) it draws 10,000 rectangle primitives. A joke, right? Actually, the joke's on you: a framerate of about 2 fps. On a 2GHz CPU with a modern GPU. The same machine can run Quake 4, Doom 3, Half-Life 2 ... etc. quite playably, and only lags a little at one spot or two in Quake 4, the most demanding of those games. Of course, those are native code explicitly using the GPU. But even a basic Java equivalent of the above can blast 10,000 polygons via Java2D at a decent framerate on the same h/w.
I don't know whether the inefficiency is in lack of JIT compiling (apparently they're working on that) or the graphics subsystem. Either way, it's not clear that there's any way to eke more performance out of Squeak and "Morphic".
I might add that my attempts to make this Morph even not crash the runtime (with of course the development tools *inside*) took some time.
Basic algorithm programming in Smalltalk is a dream. Doing anything nontrivial with graphics is a nightmare, and that might actually be purely down to lack of documentation. There might be a low-level graphics primitive I could use to blast large numbers of polygons efficiently onto the display, but if there is, there's *no way to find it*. Even examining existing GUI code and inspecting live GUI objects is no help, since the language doesn't require declaring parameter types anywhere and as a result you don't know which of the 300,000 pre-existing classes to look at. With some working, fast Java graphics code you can just find code like "void paintComponent (Graphics g)" casting the parameter to Graphics2D and invoking obvious graphics primitive methods on this, and know to look up the Javadocs for Graphics2D to do your complex 2D graphics. Squeak equivalent: examine Morph>>drawOn: and note that its parameter is named "aCanvas". Hope the key class is named Canvas (no namespacing for classes means it might be manually name-mangled to prevent collisions of course). Find "Canvas" and note it has subclasses like "FormCanvas?", "BalloonCanvas?" ... and of course not know whether you can safely use the methods of the latter. There are methods to draw "images" that might be the efficient lower-level primitives needed, but they just expect parameters like "aForm". Form exists but isn't enlightening. There is a Graphics-Primitives category (the poor, name-collision-not-preventing namespacing) with a Bitmap class but this seems to be for images loaded from disk, rather than created on the fly; it has some mutators, but they work with the primitive representation of a bitmap as a byte array. There's nothing *that I can find* that's equivalent to an abstract image object with pixelAt: and pixelAt:put: methods, like you'd hope. There's nothing that looks like a lower-level, more efficient polygon/rectangle render either. The conclusion seems to be that in Squeak, unless you extend it heavily yourself, raster graphics either have to use solely premade image files from disk or be really hairy, and vector graphics won't scale to more than maybe a thousand primitives at a time. On a fairly powerful desktop computer.
Upshot? Performance is lacking. Documentation is lacking. JIT compilers are not yet ready for prime-time. UI toolkit is dangerously unstable (easy to crash whole UI and lose stuff with a bug in your "morph"; there are logfile-based recovery tools, but these are hairy). Vector graphics primitive performance is lacking. Programmatic creation and modification of raster graphics, rather than using premade images made in Photoshop, is hairy.
Thought I may clarify just a tiny bit of confusion here (I'm in no way an expert with Smalltalk, Squeak nor Squeak's Morphic implementation). This is all from my understanding, and might be a bit off.
Forms are just what you'd call buffers in other context. It's just a historical thing. This is where you could be doing much of your optimised drawing, before telling the canvas to copy it somewhere.''
The canvas is an abstraction of the screen. It's not a big deal if you need some other class than you got, you can ask it to "transform" to the right one -> "aCanvas asBaloonCanvas" gets you a BaloonCanvas?. You can draw directly in it, or paste things like forms.''
The thing you probably want to use, is not a Bitmap, but an ImageForm?, which is also a Form.
Forms and Canvases are in between high and low level. Lower is, for example, BitBlt?, with primitives to manipulate raw bytes, copy them, operate at the bit level, and lots of other things.
Morphs are a lot higher level abstraction. You wouldn't really use them to represent pixels (in normal situations). Morph are intended as a way to represent a single atomic object to interact with users. They can respond to key presses, mouse actions, timers, and such, and thus are kind of overkill to draw a dumb rectangle to make a drawing. If every square in your 100x100 chart is a button, then it should be a morph (but you have to understand that's 10.000 buttons, not rectangles, and those are complex objects integrated to the UI). If they're just rectangles, you're hole chart area is a morph, which draws rectangles (it should work much faster).
This took me a lot of time to understand, and documentation in this area seem lacking. Exploration of Squeak classes is tough too: there are a lot of them, and they overlap on different UI paradigms (morphic vs mvc vs etoys). I could wrap my head around this things better thank to Cuis, a stripped down and simplified Squeak clone.
Well, I just downloaded Squeak and fired it up (Sep 2008). After about 3 minutes of trying to create a new program a gave up when I was unable to close one of the toolbox windows blocking the screen.
I'm not going to bother learning something that doesn't even show a standard windows interface in the IDE. Is it even possible to create one with Squeak? Regardless of a language's technical merits, users of our business applications really want to be able to find a close button in the right spot.
It sounds like whinging, and I suppose it is. It is more dissapointment that after trying out both Lisp and Smalltalk over the last week I have been really dissapointed with basic stuff. - Matt Johns
so far as of 2014-02-11, the Squeak 4.4 http://www.squeak.org/ claims to be 2-10x faster with the Cog jit virtual machine. I don't know how it compares to others (for my own interests, interested in dart, v8, and luajit), but the appearant speed on my workstation seems quite nice /responsive. -ipstone
CategoryProgrammingLanguageComparisons CategoryJava CategorySmalltalk
EditText of this page
(last edited March 18, 2014)
or FindPage with title or text search