While building my blogging software, my test data has been all the entries I ever wrote. Amongst them all, I found five or six never-published drafts.
So while we’re waiting for the DNS for cardboard.nu to shake out, I am running a series that I think of as “Unseen Alan.” I’ve given these entries a grammatical tidy up, and re-written the most egregious ramblings, but the basic thoughts are unchanged.
Here’s one I wrote on 25 September, 2003. Note the embarrassing comment about Perl and Lisp. How in the world did I ever hold that view?
In a recent post, Charles points out that it takes a lot of (keyboard) typing to iterate over a list in Java, compared to the same piece of functionality Ruby, Perl, Python, Lisp, Smalltalk, OGNL and Haskell.
It would only be a fair comparison if these languages were suitable for large systems development.
At the time Java was created, Ruby, Perl, Python, Lisp, Smalltalk, OGNL and Haskell were either non-existent or suffered serious deficits as large-systems programming languages.1 Back then, the in-vogue large-systems programming language was C++.
Update: It turns out that Smalltalk is the best ever language of all time, including future time. It is a better language than French, Classical Latin or Swahili. My apologies to anyone whose sense of reality this post may have previously offended. (True story: All the good guys ‘do’ Smalltalk. Gandalf used VisualWorks, the Hobbits were blessed with Enfin, and Aragorn wielded Digitalk. On the other hand, Saruman coded Java, the Oliphants were fueled by COBOL, and the language Orcs grunted to each other was C – except the Uruk Hai, who spoke ANSI C++.)
Java compares well to C++. As Phillip Pearson points out in the comments on Charles’ post, Java is an improvement over C++ for this task. Java is also well ahead of previous choices for large-systems programming: Assembler, COBOL, Fortran and C.
These days, however, some of the comparison languages are becoming suitable for large-systems development. Python particulary interests me, but Perl is developing in a promising manner and there is a slim, but frightening, chance that Lisp Smalltalk may yet gather a critical mass.
1 I snort in the direction of the OGNL-Java comparison. OGNL is neat, but it cannot replace Java.
Comments
response here:
http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3260563227
You are wrong regarding Smalltalk. Smalltalk has long had excellent support for building large, integrated systems. One large Smalltalk reinsurance system I worked on has by now over 18000 classed and was development by around 30 developers, simultaneously working on the same source code. In total, over 100 developers have been involved so far.
The system is delivered as one single, integrated executable. Development of this system started in 1996 and it shipped around 1999. At this point of time, I cannot recall that "Java" had other meanings than "coffee".
Andy,
"Perl is developing in a promising manner" - could you expand on this ?
You make some interesting (and possibly controversial!) points in this piece.
What has happened to LISP since Java's birth to give it a new chance ?
I think you have material for new posts!!
Keith
Runar,
C is another language that doesn't have great support for building large systems, and yet gigantic systems are built with it. Smalltalk's lack of namespaces, the difficulty of integrating third party libraries and its "program = image" ethos are all serious deficits in so far as building large systems.
a
PS: I worked with such a system at Marsh and Mclennan here in Australia. Would it have been the same one?
VisualWorks has had Namespaces since 1999. Prior to that time, people simply added prefixes to their classes. An impediment? yes. Hard to overcome? No.
Another oddity in the original article is mentioning "Assembler, COBOL, Fortran and C" as "previous choices for large-systems programming" but ignoring Ada.
"One of the major goals of Ada 95 is to provide the necessary language facilities for the development of large-scale information systems"
http://www.adaic.org/standards/95rat/RAThtml/rat95-p3-f.html
Hi Isaac,
That was probably because Ada never really caught on here in Australia. I understand that it was used for some defence work but, by and large, it was ignored by the bulk of the IT world.
If we're going to mention Ada, we should also mention Eiffel and Modula-2/3.
Alan.
Alan, the point is that Smalltalk (also back in 1996) has great support for building large systems. The system I referred to (SICS/nt) is not a hack with 18000 classes lumped together. It is only one of many equal-sized projects. You should be aware that large, structured, and well-organized projects were built in Smalltalk, long before Sun invented Java.
One key component to Smalltalk's success in building large systems (back when development on SICS/nt started 1996) was Envy; a powerful source control system. It allowed breaking the system down in components, not simply collections of class source code files. All developers have equal access to all code, and versioning is at method (function) level.
TopLink -- an object to relational database mapping framework -- was another must in the project I describe. It allowed mapping a few thousand classes to a few hundred tables. Only recent Java got a product like this (TopLink for Java). I assume C has no framework like this, as there would be no objects to map.
Garbage collection, tools for refactoring, an IDE (you con customize yourself, as it is written in the language itself), and simple language syntax are other things that help a lot when doing large projects in Smalltalk.
James Robertson already commented on "Smalltalk's lack of namespaces". We never had serious problems with this, even with 18000 classes.
The "difficulty of integrating third party libraries" consisted of using a relational databases and Windows DLLs. This was also easy. There might be closed Smalltalk systems, but the major ones for build business applications, are not.
When you mention that Smalltalk's " 'program = image' ethos are all serious deficits in so far as building large systems", you should be aware that the image can be seen simply as an IDE. It is tightly integrated with the source control system, and I simply don't see what problems it creates for building large systems. Is it the size? Note that you can partition the image and load parts of it as needed.
Runar,
I was writing Smalltalk in 1991. I too have seen big Smalltalk systems, though only one the size of SICS/nt.
I like Smalltalk. It was a lot of fun to program in. It was extremely productive for two-tier departmental apps with complex business rules.
However, just because you were able to use it on one or a few "large" projects doesn't make the language generally "suitable" for large systems; neither does it disprove that the language has serious deficits.
I fail to see how a Smalltalk can move out of its primary, two-tier space. Gemstone had some promise, but I haven't heard anything of it since last century.
Another thing: as a Java and Python programmer, I find your attitude toward 3rd party libaries puzzling. The systems I work with integrate tens or hundreds of libraries, each providing little snippets of functionality. These systems would never have seen the light of day if I had to build everything beyond the Windows DLLs, O/R mapper and GUI development environment.
You and I work in different worlds.
Right now, we're arguing about the word "suitable" in my original blog entry. I wrote that entry last September and didn't post it then, probably because it was unnecessarily trollish and didn't actually add anything new to the debate. I'm not prepared to defend my post with any more than I have already written.
How about this compromise? I'll strike the reference to LISP looking promising and replace it with Smalltalk.
Alan.
Smalltalk has been used to build large systems with great success many, many times over a long period of time predating Java. It is just a simple fact, for a recent example check out:
http://secure.cwheroes.org/briefingroom_2004/pdf_frame/index.asp?id=4909
(sorry about the underscore problem)
There are plenty more examples, here is a pointer to some:
http://www-306.ibm.com/software/awdtools/smalltalk/casestudies/
And I have no idea what you mean with the "two tier-space" thing. Technology for partitioning Smalltalk systems over multiple hosts like CORBA, GemStone etc etc have been available long before Java even *existed*. GemStone was created in 1985 IIRC. I read tons of large system case stories back in 1994 and I have worked myself on at least one pretty large system using VisualWorks/ENVY and GemStone and that setup is still IMHO way superior to the current crop of Java tools. And yes, I am saying that because I also work in Java.
IMHO this is just another case of "talking about things I don't really know much about" - and it seems to be a rampant trend in blogs these days.
How about just writing you don't really know much about Smalltalk? And then write down your thoughts as "guesses" or something. I would never write such things about languages or tools I haven't worked with.
James, Runar, Göran,
Your lecturing and insults have convinced me that Smalltalk is the best language there ever was. Or will be.
Please, I did not intend to insult you. I cannot see how these posts are insulting. You said Smalltalk is not suitable for large systems, and we only pointed out that this is not true.
Sorry Runar,
Your comments were not insulting, and I should not have put them in the same category as James's and Göran's comments.
Hi Alan!
I apologize for getting on "too hard". I just get worked up over these things, my bad. It just frustrates me to no end to read statements about Smalltalk that IMHO simply are not true.
regards, Göran
...oh, and btw - I am not writing this to convince *you* anything about Smalltalk, feel free to think whatever you like.
I am writing this because you are telling others that Smalltalk is not suited for large systems. And since I work hard to promote the use of Smalltalk - I react, simple as that.
If you had written about "real" Smalltalk problems that you have actually experienced, then I would not have responded.
Of course Smalltalk has problems just like any tool or language, but being unsuitable for large systems is IMHO not one of them.
Hehe, just saw your adjustments. Frightening indeed eh? :)
Peace.
regards, Göran
I'm not sure how or why you are implying that my comments here have been insulting - unless insulting translates "pointed out uncomfortable facts that the author would rather ignore". You admit that your experience with Smalltalk is very old, and yet you feel completely free to make all kinds of assertions about its past and present suitability for projects. When confronted with counter-examples, you call them one-offs.
Let me put it this way - since you think Java is so much better for large projects than Smalltalk, would it be intellectually honest for me (or anyone) to always talk about Java in the context of JDK 1.02 when making assertions about it? Because that's what you've done here - translated your ancient experience into a new "fact". Your snarky "update" doesn't help matters a lot either.
As to third party libraries, it's not that difficult to do multi-language development, particularly on a server.
I'm not sure how or why you are implying that my comments here have been insulting - unless insulting translates "pointed out uncomfortable facts that the author would rather ignore". You admit that your experience with Smalltalk is very old, and yet you feel completely free to make all kinds of assertions about its past and present suitability for projects. When confronted with counter-examples, you call them one-offs.
Let me put it this way - since you think Java is so much better for large projects than Smalltalk, would it be intellectually honest for me (or anyone) to always talk about Java in the context of JDK 1.02 when making assertions about it? Because that's what you've done here - translated your ancient experience into a new "fact". Your snarky "update" doesn't help matters a lot either.
As to third party libraries, it's not that difficult to do multi-language development, particularly on a server.