Where do you use Smalltalk?

We are using Smalltalk (a rather old implemetation) for a logistics and foreign trade application with a bit over 500,000 lines of code (comments and empty lines excluded ;-) ) The pros: Smalltalk usually provides easy solutions to everyday problems like a great collection framework Debugging is very simple and quickly done Smalltalk is really object oriented. If you have embraced Smalltalk, Java and C# look like half-hearted implementations of object orientation The cons: You spend much time correcting errors that other (typed) languages detect at compile time. This means you have to test more and spend more time with trivial syntax problems than in other languages Most stable Smalltalk implementations are single-threaded.

This poses a problem if you want to build servers or have to do a lot of data processing that could be parallelized The lack of interfaces makes it hard to enforce the use of, well, interfaces. When you want objects from different spots in your object hierarchy to react to the same method calls, you have no way to enforce that they implement the needed set of interfaces Only few developers on the market work with Smalltalk. So it takes more effort to get good developers, and to train them.

And you don't find answers to common questions easily on the internet Having worked with Smalltalk for 10 years now, I would not recommend it for larger business applications. You could try it if you have very disciplined developers that invest a lot of time for unit testing.

We are using Smalltalk (a rather old implemetation) for a logistics and foreign trade application with a bit over 500,000 lines of code (comments and empty lines excluded ;-) ). The pros: Smalltalk usually provides easy solutions to everyday problems like a great collection framework. Debugging is very simple and quickly done.

Smalltalk is really object oriented. If you have embraced Smalltalk, Java and C# look like half-hearted implementations of object orientation. The cons: You spend much time correcting errors that other (typed) languages detect at compile time.

This means you have to test more and spend more time with trivial syntax problems than in other languages Most stable Smalltalk implementations are single-threaded. This poses a problem if you want to build servers or have to do a lot of data processing that could be parallelized. The lack of interfaces makes it hard to enforce the use of, well, interfaces.

When you want objects from different spots in your object hierarchy to react to the same method calls, you have no way to enforce that they implement the needed set of interfaces. Only few developers on the market work with Smalltalk. So it takes more effort to get good developers, and to train them.

And you don't find answers to common questions easily on the internet. Having worked with Smalltalk for 10 years now, I would not recommend it for larger business applications. You could try it if you have very disciplined developers that invest a lot of time for unit testing.

Nice answer. Exactly how I felt when I quit smalltalk in '98. – krosenvold Feb 5 '09 at 9:15 About the lack of Interfaces, did you try Smalltalk Traits?

– Sébastien RoccaSerra Feb 5 '09 at 9:16 @Sébastien Rocca-Serra No, Traits are new to me, but I will look at them. Perhaps we can teach our old Smalltalk some new tricks. We will have to maintain it at least for the next 10 years, so that could prove an interesting alternative.

Thanks for the tip. – Sebastian Dietz Feb 5 '09 at 9:37 1 In my experience, I have never found the lack of static typing to cause additional problems. I don't think one needs prolific developers to use Smalltalk; you should probably have "good" developers but don't you already have that?

;) Other than that, I agree with your points. – Julian Feb 5 '09 at 10:28.

I use Smalltalk to create the Seaside framework and applications developed with it. The largest was a campus-wide electronic CV database (quite a modeling challenge). On the plus side, I have never found a language (environment, really, as others have pointed out) in which I am remotely as productive as in Smalltalk.

There's no compile-test cycle. Debugging is a awesome (actually the Squeak debugger has some room for serious improvement but it still beats debuggers for other languages). Methods gravitate towards small and composable, refactoring is easy, exploring code is a joy with "senders" and "implementors".

Personally, I can't think of ever having had a problem with type errors (other than during development). I just haven't found that to be a problem. On the negative side, I always feel like there's a shortage of polished (ideally open-source) libraries.

There are lots of 80%-implemented or slightly outdated libraries but, if you just need to whip off something that uses SNMP, or TFTP, or directed graph analysis, you can end up having to implement it yourself. And that's probably why there are so many unpolished libraries in the first place. That may just be a factor of the size of the community.

I also do sometimes wish there was better support for "interfaces" of some sort. Traits would be great but are not portable enough. Being limited to inheritance for specifying protocol can be pretty frustrating.

Smalltalk is being used by large enterprises for applications with good success, especially when the problem domain is complex and requires constant updating: JPMorgan's Kapital OOCL's IRIS-2 and others who decline publicity. It isn't likely that these systems could have been implemented (even today) using other technologies: complex object model complex (sometimes distributed) computations involving complex object model high speed access to complex object model regular updates to the business model logic Smalltalk's strengths play into it's weaknesses. It's not the language (dynamic vs static typing will always be a discussion point) as much as the development/deployment environment.

Smalltalk is primarily an image-based environment where all of your code and all of your objects live in harmony, including the tools. With the code/data/tools all living inside of an image, the 'normal' development/deployment styles don't apply. To live, work and deploy in this environment takes a shift in thinking and this shift isn't always obvious.

Once you've made the shift, you are immersed in your objects - they are always present and can be easily inspected and your code which is easily debugged. You can work for long periods of time without having to make a context shift (from one tool set to another), so complex problems can be solved and complex object graphs can be understood. The cons end up being things like: smaller pool of experienced developers 'special' deployment considerations lack of a standard libraries (each vendor has slightly different base libraries) which contributes to the lack of 'polished libraries' as mentioned by Julian.

I use Smalltalk as my main tool to develop products I market myself (I'm a MicroISV) and must say that no other environment permit such level of productivity and independence. Smalltalk is a lot more than a language, is an environment that has a language of the same name :) I develop web and desktop apps and also I developed services that run on servers Windows and Linux with no problem and not need of other things installed. All that I need is Smalltalk :) Sound a bit fanatic?

Yes, I'm.

We use Smalltalk to implement two different versions of BASIC. The first is called Liberty BASIC. We've been selling this since 1992 and it is developed in Smalltalk/V.It currently runs only on Windows but we are porting it to VisualWorks Smalltalk.

Have have a demo-able version that runs on Windows, Mac and Linux. The second is called Run BASIC which is a web programming language and appserver designed to appeal to the BASIC programmer. This is built on VisualWorks and uses Seaside to implement the web user interface.

It runs on Windows, Mac and Linux. Seaside allows us to develop Run BASIC in a way very similar to a desktop app, and it allows us to provide a version of BASIC for the web that doesn't force the programmer to deal with web-isms. Pros: Over the years many people have asked me why I develop programming languages in Smalltalk.

Given my limited time resources I'd say that if I had to develop in C/C++ the software wouldn't exist. Smalltalk is an extremely productive language.It lets your write very English-like code, it has powerful metaprogramming features that come in very handy when crafting compilers, runtime systems, debuggers, etc. And it is extremely interactive. If a runtime error stops your program the debugger opens in a live stack.

You can see what caused the error, but it doesn't stop there. You can often fix the code right on the spot and continue running without needing to restart your app. Very few systems can do this.

Cons: I would have to say that the seamless cross platform support can be an issue because you lose tight OS integration especially in the area of graphics and GUI features. Also as some others have mentioned, deployment is harder than it should be. In the 90's I used Smalltalk to build a complete soup to nuts factory management system for a circuitboard shop that managed everything from quotations, order engineering, job tracking, defect management, reworks, shipping, reorders, etc.It had a built-in email system, reporting language, and customizable views for each user.

This whole system ran on a single 486 with 16MB RAM and drove 32 serial ports with 3 printers and 29 terminals with very comfortable interactive performance. Smalltalk allowed me to develop and debug this system as people used it. I did not need to restart the system to install new features and bug fixes.

If a user process crashed, the debugger would open on my monitor and I could debug it live. The user's terminal would restart automatically. For the same circuitboard factory I implemented a CNC machine simulator and editor in Smalltalk.

A special text editor understood CNC drilling and routine programs, and the simulator allowed engineers to do a visual check and saved lots of time and money on the factory floor. I could go on. Smalltalk is awesome.

We used Squeak to build a children's authoring environment with drag-and-drop tile-based scripting. Apart from being very platfom-agnostic, what Smalltalk allowed us easily is to have these tile scripts execute as efficiently as regular Smalltalk methods. Also, for tasks where the tile scripting is not sufficient it is easy to escape into Smalltalk code, so there is virtually no ceiling to what you can do with that tool.It has been deployed to more than 500,000 children worldwide.

My company uses Smalltalk (Squeak and Pharo) for both websites and custom applications. The websites include web-based CMS systems and in-house applications for Logistic companies, for example managing their Goods-In flow to their warehouse. The custom applications include software to drive the hardware of a remote-locker-based distributed delivery logistics model, providing application intelligence and communication to a central system, and thus live track and trace.

The main con to Smalltalk is really the lack of familiarity with it and therefore the relative lack of programmers out there. On the other hand, Smalltalk programmers tend to be a self-selecting subset: most of them are very good! It's true that the lack of native multi-threading may become an issue as CPUs gain more and more cores.

On the other hand, I'm sure that'll be something being looked at by VM developers pretty soon. Meanwhile green threads do the job. The pros are manifold: A tightly integrated environment complete with refactoring, the most highly expressive language I've ever come across, true Object Oriented programming, true reflection, minimal keywords, helpful community, etc.Those who state the lack of type-checking is a problem are (in my opinion) badly mistaken.

Ruby shares this "problem", but really to develop any non-trivial system without enough automated test coverage to highlight incorrect message sends (whether typos or even the wrong messages) is simply irresponsible. As others have mentioned above, any IDE worth its salt will also tell you that you're trying to use an unavailable keyword.So: I love Smalltalk. Every time I program in it, it feels "right".

Whenever I go back to any other environment, I feel constricted and channeled into the way the language designers intended me to work. That's the mark of a great programming language and environment: it gets out of the way and lets you solve the business problems you need to.

We use and maintain a product for the configuration management of telecommunication networks. It is based on VisualWorks and Gemstone/S (the next release will be based on GLASS). Even if the produce restricted the access to the development environment it's easy to extend and the seamless integration of language and OODBMS is great.

The dynamic typing is no problem. But many developers are not grown-up with Smalltalk and try to bring their curly-braced languages style in. That's sometimes a bit weird.

Additionally the current VMs aren't optimized for the upcoming distributed multicore/multiprocess environments. This has to be solved for future systems.

I'm a software engineering researcher. We use Smalltalk both as the language to develop our reengineering and software visualization tools, and as a subject to analyze and experiment on with language design. As a programming environment, the reflexive and agile nature of Smalltalk allows us to prototype rapidly, then to implement adaptive tools.As an experimentation platform, the history, variety of implementations, and also the ability to reflectively modify the language semantics are great advantages.

Even the virtual machine design is relatively simple (but not naive) to understand and modify.

I'm using it to build web applications for business users, using the Aida/Web Smalltalk web framework. Those applications are for Gas Billing System, Logistics, to the Business Process Management. Smalltalk allows me to be agile, productive, my systems are maintainable regardless of all changes of business climate in recent years.

Two drawbacks of Smalltalk are that there are not a lot of preprepared components around (comparing to the other development environments) and that interfacing with others is somehow hard and therefore rarely used.

I have been working on Natural Gas Logistics system in Smalltalk since 1995. While I love the expressive nature of the language there are real problems with Smalltalk in a system such as ours. 1) Our system has been refactored heavily over the years and the lack of interfaces or similar compile time checking causes many errors.2) Our Smalltalk is "image" based and the mix of the IDE and the runtime can cause some very subtle errors due to the differences in "development" testing and true runtime testing.3) Our vendor has very poor support for deployment (caused in large part with item 2 above).4) In response to jarober above -- Almost every error reported by our customers in the field are simple type errors that would have been caught by a compiler.

On the the other hand the debugger is an awesome tool.

Sorry, but strictly speaking refactoring doesn't lead to any behavioural changes or breackages: that's the definition of refactoring. Your system has been changed. – Si Kirk Feb 7 '09 at 13:15.

Currently I am using Smalltalk to Control my robotic telescope, as well as Image Processing via ImageMagick. I have tried all of the other "mainstream" languages such as JAVA, VB, VB. NET, Python Perl, C, C++, and the list goes on.

I finally found a home with Visualworks Smalltalk. All of the interfaces are there - COM, . NET DLL calls etc.No need to go and hunt for a module to do this or that.

I can develop on my MAC Book Pro, then run the code on Windows usually (not always) without modification. It's nice creating something in Smalltalk, putting it down for a month, and then coming back to it -- picking up right were I left off. This is not so easy with JAVA, or C no matter how well they are written.

The popular answer above - that Smalltalk use (or dynamic languages in general) leads to lots of type errors is just silly. I've been developing in Smalltalk for over a decade, and used C for many years before that. What leads to type errors is a weak typing system and static checks.In Smalltalk, keyword messages make it much less likely that you'll get a type error.

An example: server startOnPort: portNumber hostName: hostName would be something like: server. StartOnPortAndHost (portNumber, hostName); in a language like C++, Java, or C#. Which one is more likely to lead to argument transposition?

There's a whole class of numeric errors that simply never happen, because you can't overflow or underflow. For instance: 1000 factorial just yields a very large number; I didn't have to worry about whether I needed a BigNumber class or not (the numbers auto-promote as needed).

My argument was more that a Smalltalk IDE cannot not warn me that "1000 factoril" is not valid, because I mistyped it and forgot an "a". In a typed language, the IDE knows the type of nearly any method and variable and can validate the code before compile time. – Sebastian Dietz Feb 6 '09 at 7:22 Not really.In those languages the typing is deliberately broken by casts.

Lots of casts in practice. – Stephan Eggermont Feb 6 '09 at 10:22 except... it can, and does. If the message doesn't exist, it prompts you.

– jarober Feb 6 '09 at 13:17 But not until run-time. So these errors are caught later. – Wouter Lievens Feb 6 '09 at 15:50 You're supposed to coverage test everything... :) – bart Feb 6 '09 at 17:19.

I use Smalltalk (Squeak, Pharo and Dolphin) for the odd tasks at my work. Say I need to manipulate some data, I find it easier to do in Smalltalk over Java even though I have 9 years Java experience. Say I need to knock up a utility web page I'll use Seaside and webservices and have it up and debugged much quicker than using Java (Groovy/Grails are catching up there though but then again its another language to learn...again).

I've also used Seaside to create some WAP pages for an estate agent as a proof of concept. Sometimes I refer to Smalltalk implementations to see how they solved a design problem (so I'd run through say StrongTalk, Squeak, stx, Smalltalk MT, Dolphin, VisualWorks). Often the implementations are the same sometimes different.

Sometimes I try and copy a protocol and put it in my Java code as much as possible, although I always try and keep within the Java idioms that the other developers in my team would be comfortable with :) The main benefit I find is the debugging support, the 'low ceremony' of dynamic typing and the expressiveness of Smalltalk syntax and Seaside. On the downside it takes a while to get used to the image and maintaining it effectively; using a source code repository helps though.

The huge credit & rates "exotics" system at JPMorgan (called Kapital) is written in Smalltalk. It has been around a long time but the flexibility of being able to just pause a live trading system and fix bugs/write code on the fly means it is probably almost irreplaceable.

Sebastian Dietz says 'My argument was more that a Smalltalk IDE cannot not warn me that "1000 factoril" is not valid'. This is only partly true: Squeak can tell you that nothing sends the message called "factoril", and asks that you confirm this unknown selector (giving a list of possible correct spellings).

Sebastian Dietz > "The lack of interfaces makes it hard to enforce the use of, well, interfaces. When you want objects from different spots in your object hierarchy to react to the same method calls, you have no way to enforce that they implement the needed set of interfaces. " Most Smalltalk implementations are so comprehensively customizable that pressure to change Smalltalk itself can sometimes be ameliorated without vendor involvement, for example, interfaces - "Using SmallInterfaces, the developer has now the ability to define interfaces and to indicate which classes conform to them."

Adding Dynamic Interfaces to Smalltalk Sebastian Dietz > "You could try it if you have very disciplined developers that invest a lot of time for unit testing. " We should remember that unit testing has for good reason become popular in Java and other languages that provide some static type checking, and some projects simply mandate and enforce "complete unit testing" (pdf).

I'm using Seaside/Squeak for OpenPiczza and My Own GTD/PIM application. This is not big scale service application but it provides a few good merits compared with other Web Framework; first, it's easy to packaging and the size of package is rather small. Second, it is very portable, at least it has Windows, Linux and Mac OS X support without code modification.

Now, bad story; I do think network performance of Squeak(not general problem of Smalltalk), should be faster than current implementation(namely 5 times). And I hope Open Source smalltalk implementations like Squeak/GNU smalltalk have portable GUI framework support.

I use smalltalk for many of my personal projects including desktop, server and script development. At work, I've only been able to use smalltalk for data processing and logistics, scripts and presentations. On windows I use Dolphin smalltalk for tight integration with windows and I use Squeak on Linux, BSD and Solaris.

Pros: The paradigm; messages and objects all the way, smalltalk provides a very good balance of power and simplicity. Smalltalk environments have an excellent feedback loop my mind requires to build good quality software without getting in the way. Cons: Depending on the product implementation or platform, there can be a lack of libraries or frameworks written in smalltalk.(Much less then say, ruby, python or java, although FFI helps).

I don’t see green threads as being much of a con, however coordination of processes needs to be home grown if your smalltalk does not support native threads.

I've seen it used in a large industry specific accounting/billing package. The huge downside to it was trying to find developers that knew (or were willing to learn) smalltalk.

I tried to break into Smalltalk development some years ago, and had huge (fatal, in fact) problems finding a position. Strange how things work out, no? :) – Arkadiy Feb 5 '09 at 17:54 Nowdays you can make the position - I'm just starting to use Smalltalk for developing web applications (not sites, applications).

Check out Aida/Web (aidaweb.si) and Seaside (www.seaside.st) web frameworks. – Damir Horvat Feb 5 '09 at 21:34 I wonder if that would still be a problem today. Dynamic languages are enjoying increased credibility, and a lot of Ruby programmers seem to be very interested in Smalltalk.

– Carl Gundel Feb 6 '09 at 16:39 I'd always prefer to code in Smalltalk than many other languages. And Smalltalkers usually love their language. I do not buy this argument about shortage of Smalltalkers... – Friedrich Oct 7 '09 at 5:28.

I use it to teach O.O. Programming, so far to a few friends and my girlfriend, with a lot of success. I only miss a better (more mature) deployment system, a la wxsqueak so they can make seamless native apps. That's what they miss the most.

I have also used it for prototyping, but so far not at work. Hopefully soon!

IME, once you get the gist of Smalltalk and how to use it to support and enable your creativity, there's no going back. Basically you start working on your problem with the assistance of the computer, rather than having to work on your problem AND deal with how a language thinks you should structure your thoughts. I got a few letters and a check from Knuth because I used Smalltalk.

I am very happy with it.

I use smalltalk for prototyping and for creating models and specifications. Prototyping of web applications is very easy with Seaside. I'm one to two orders of magnitude more productive writing web apps with Seaside than with our regular .

Net frameworks. I use the same meta-model to generate both a web-app and specification documents for the regular environment.

I'm guessing you'd get more smalltalk developers (who as you know are usually quick to learn) if you didn't require specific tools from applicants.

You use Smalltalk for an application that has proven to be too complex to be implemented in any other way. Virtually every ST contract I ever got was from a company that had tried several (at least three) different approaches that failed miserably. These were always "mission critical" applications at the core of the business.

I can confirm that! (there are quite a bunch of ST-apps around, but it seems somehow "politically incorrest" to admit, they are written is ST ;-) – blabla999 Aug 16 '10 at 20:18.

You can learn some more about real Smalltalk applications from conference experience reports - read through Niall Ross's conference summaries.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.