Smalltalk's pro and con Smalltalk's pro and con Here I give an example why Smalltalk can be a very good choice for realizing a Software-Project. But I will also outline some problems.
First I will describe common misbehavior of software which has its cause ( to my opinion ) in the underlying implementation language:
The list can be continued. In my argumentation these problems are caused by the underlying implementation language. Of cause always someone can argument against saying - it is only due to some application design - it is merely poor implemented and so on.-
I discovered that the use of a pure Object-Oriented language avoids such behavior of the resulting application - provided that the application is implemented in a proper way.
I will analyze now some of Microsoft's "software" in misbehavior:
Open the Internet-Explorer and right click on properties - You will get a modal dialog - the underlying Explorer is disabled until you close the Property Dialog. Someone can argument it is by design. Try the same with Windows-Explorer - Property Dialog is not modal ! Welcome "Microsoftware" if we are generous let it be "Minisoftware". If you ask the implementer to improve it he would choose a thread - to avoid polling they will use a semaphore - Big deal - if they would have chosen Smalltalk - the problem would probably never have been occurred. Because Smalltalk is a System in a System which has its own implementation for a Process everything will run smooth.
Next try to travel with Internet-Explorer to a FTP-URL. Now the System hangs. That's because the DNS is implemented without Win-Socks "Asynchronous" capability. Of course the problem can be solved. In pure Smalltalk you would never observe such problems - of course where Smalltalk relies on operating system features you will run into the same trouble.
Next try to interrupt an accidentally started operation - for instance you click on a CD-Drive, Network drive or even want to cancel some operation in which Microsoft show's the wait cursor - a Cancel button is shown - but pressing it has no effect. Try to interrupt a Smalltalk operation - if your processor got not already stuck in the operating system you will probably immediately get a debugger window - in a runtime scenario it should be something different.
Memory fault ? You will get it after working some time with Windows-Explorer and its siblings. I argue that observed accidentally refresh of the Windows-Desktop is a hidden Explorer crash. Windows-Applications tend to crash if you ran out of Hard disk space ( a tip - just have always a Smalltalk open to be able to start Explorer.exe ) - All other Application - even the most important under MS-Windows ( Process-Viewer ) will probably hang. In Smalltalk there are rare situations in which you must deal with memory-faults. One very tricky is the use of a ByteArray for OS-communication which you store only in a temporary variable and which the garbage collector removes ...
Too much memory consumption ? No problem - in our days of Mega or Gigabytes. But it is - some applications like to report that they can't continue - especially after lengthy operations - even leaving you destroyed data. Try to compress a 1 Gigabyte MS-Access database. You will observe all 5 misbehaviors at once - ending up with restarting a Windows 2000 Advanced Server. Process Viewer will not help because MS-Access hangs in the System process ...
Coming to this point my words may sound like someone how hate Microsoft - no - I want to use only their "software" as an counterexample of well-working software - because I think that they for sure never used Smalltalk for its implementation. There are countless more examples of misbehave - Try to install Oracle8i and observe the memory consumption of the Oracle-Installer ( written in Java ). With such a memory footprint a Smalltalker would be able to implement a Object-Oriented Database itself ! Microsoft seeks the problem always in user's misbehave - if you execute a Query in SQL-Server 2000 and the query delivers a few results - after some time you will be notified with a Message-Box that for memory reasons your query was closed - You are advised to require and you have to confirm by pressing OK - which is not ok.
Because in Smalltalk all these 5 listed misbehaviors are addressed either by the design of the Language itself or by the Virtual-Machine Implementation my argumentation is by use of Smalltalk as an implementation Language one can avoid these problems.
To my opinion types are unnecessary to write programs - Programs should be written to communicate them to others ( Smalltalk ) as a side effect they can be executed on a computer. If you need types to explain your algorithms to someone else - something is wrong. You also don't need types in our natural language. Types are inferred from the context of the explanation. Types would be helpful for deployment.
I didn't want that by reading my arguments one of the mentioned Big-Players discover Smalltalk and we end up with a strong typed Smalltalk with a "switch" statement, multiple inheritance and Thread-support - threads are necessary if you have more than one processor.
I hope I convinced you if you are not already a Smalltalker - to have a look at Smalltalk. But why programmers give up Smalltalk and start over with Java ?
There are a number of never general solved problems with Smalltalk:
First of all Smalltalk is s System in a System. If you want to deploy your application - then you will realize - it is difficult to extract exactly that what is needed for deploying your Application you will end up with a time consuming error prone process. There is no general solution to that problem. An Argument can be that a type system will help - of course a type system only for sake of deployment would be great - but I don't like to have the need for specifying types during implementation - because of deployment - Then a Smalltalker will end up with the Java-way at every development step to deploy !
Smalltalkers are much more productive because of their powerful environment. But the disadvantage is that very often a lot of unnecessary and inefficient code is produced. Only because of that Smalltalk applications are often slow.
There is no sufficient standardization. Mostly Standardization is understood as a least common divisor. May be Smalltalkers are afraid of it - because a Standard means that you have to give up your solution and be conform to a Standard - But why not to include all the different solutions.
There are MVC, MVP, Morphs, ViewManager, ApplicationController, ApplicationCoordnator, and all the other ways in every Smalltalk - I often discovered misuse.
And last but not least Smalltalk's doesn't put much focus on operating system integration. Maybe because it is a System in a System - but to deliver applications one must have an optimal OS-Integration. The only Smalltalk's with a really good Windows Integration are Dolphin and MT. I would prefer Dolphin - MT is more for C++ Programmers.
Last but not least - Smalltalk is in general cannot be not compiled to Binary-Code or C-Code ( there is ST/X ).This means you deliver your Source code. Most Smalltalk's can easily be decompiled ( You will only loose temp names ). It isn't always a good idea to deliver your Source-Code.
To my opinion the pro's of Smalltalk are much stronger than the con's. Con's can be solved but to solve them Smalltalk-Vendors must be supported by buying their environments..
Companies which claim to deliver modern Software are still using obsolete Smalltalk dialects like Visual-Smalltalk. To my opinion even IBM VA is obsolete for Windows client development. It's GUI is build on top of an Unix Motif layer. Cincom the manufacturer wants their Visual-Smalltalk Clients to convert to either VisualWorks or Object-Studio. But in most cases this isn't an option:
VisualWorks doesn't have Native Widgets yet The Pollock-Framework should change that in the future - I don't believe in its availability in the next years. We have ourselves chosen to implement a Smalltalk with Native Widgets ( LSW Vision-Smalltalk ). It is proprietary but we shall start to publish more over the time.
Object-Studio - which is an successor of the Enfine-Smalltalk which were in Business in the 90ies has an obsolete Virtual-Machine architecture. Its GUI fastness is build on top of Microsoft's MFC Class-Library. Cincom wants to replace the Object-Studio Virtual-Machine with their VisualWorks Virtual-Machine. The VisualWorks VM is not suited to work with MFC or to handle Native Widgets. It's outcome remains to be seen.
We did in the past mainly consulting for Visual-Smalltalk. Visual-Smalltalk is in maintenance mode. Until 2000 we did a lot of bug-fixes and Windows-OS synchronizations. After the IT-Crash a lot of our consultancy contracts were cancelled. Now the motto of some of the Software-Managers is to get their Problems solved by asking in Newsgroups and mailing lists. We luckily survived this IT-Crash and are selling now products developed in our Smalltalk. The time were we enthusiastically helped Software-Companies for peanuts money to get their Smalltalk-Applications to work is over. Now we are very successful selling our Software-Applications worldwide.
Please contribute to Smalltalk-Programming.com. Please excuse my German English and correct me.
Thanks for stopping here !