Silk is just too flexible

Oscillating indecisiveness personified as an essay

by Herbert Vojčík

Introduction

Silk ¹ is the young, in-development library for Amber Smalltalk for creating and manipulation of the DOM elements of a host web page (Amber runs in the browser).

There already is a library for that — it would be strange if there wasn’t one already in a system designed to run inside a browser; that library is named Web. Inspired heavily from Seaside, it does its job well, but has its own weak spots:

  • it depends on jQuery,
  • it is hard to go from existing DOM content to object representation,
  • it looks a bit bulky.

So, Silk was created to try a different perspective. First point was to not depend on any external library, but only on handful of selected DOM API, most prominently on insertBefore. Second point was draw inspiration from different places — in particular, from AppJet ² which did create HTML by functional composition and itself drew from MochiKit. And third, trying to make things that were hard in Web less so.

Streams

One of the things that was bothering me in Web was the duo of HTMLCanvas / TagBrush, so having two different types of entities for “the thing you write on” (a place on the page) and “a thing you write” (a DOM element), though most of the time you are writing inside an element anyway. It brought nuisances and confusion here and there, during the everyday use.

That’s why I decided to put the whole framework around the insertBeforeDOM API. This API inserts a DOM node inside another DOM node just before its specified child DOM node (or to the end, if you specify to insert before null). So a Silk object represents the parameters of an insertBefore call — the DOM node to insert into and the place where to do the insert (as a reference node to insert before). In other words, Silk object represents an insertion point or a cursor in a web page.

This metaphor led automatically to the notion of another one — to look at the whole web page as a stream of nodes, each of them being stream of nodes itself all the way down to the text nodes.

As Amber has streams already implemented, those were reused, and each Silk object is itself a basic stream, it can use its API: peek, next, atEnd,resetContents and more; most importantly, <<. This API puts an object on the stream. So, this inserts a text at the insertion point:

aSilkObject << 'Hello, world'.

Drawing from AppJet / MochiKit, you can put different objects in the stream, and they put different things into the DOM element. You can put an association, and attribute gets set; you can put different Silk object, and the DOM node it represents gets inserted:

parent << ('id'->'foo') << 'Beware, child follows: ' << child

But, << stream API has already a useful trait: if you put a Collection in a stream, its elements get put one by one. So the above can as well be:

parent << {'id'->'foo'. 'Beware, child follows: '. child}

Things begin to get nice and scary at the same time.

Tags

DOM elements, commonly called just tags (eg, things like <p></p>, <script></script>, <img />), are most often created for immediate insertion into the parent node, not to float in midair. So, the most convenient API is aimed at creating as well as inserting a DOM element directly at the insertion point. To insert a div element, you do:

aSilkObject DIV

This creates div element, inserts it in aSilkObject, and returns the Silk object representing the insertion point inside the newly created empty div element. In case you want to create a detached div element, you can do it by sending a message directly to Silk class:

Silk DIV

So, the create-and-insert example can be written also as:

| newDiv |
newDiv := Silk DIV.
aSilkObject << newDiv.
^ newDiv

or, if you don’t care if return value is aSilkObject, not the new div:

aSilkObject << Silk DIV

But, you often do not want to insert empty elements, but elements with content. Like in:

aSilkObject P << 'Hello, world!'

This happens so often that there is a convenient form of element-creation message with an argument. This argument is put into newly created element as its content, so the above is equivalent to:

aSilkObject P: 'Hello, world!'

Thanks to the “flatten collections” ability of the stream << API, it is possible to put more pieces of content into newly created element using one argument:

aSilkObject P: {'Hello, world!'. Silk BR. 'こんにちは、世界!'}

DocumentFragment

And to complicate things even more, you can create Silk object representing insertion point in a newly created DocumentFragment instance:

Silk newStream

For those who don’t know, a DocumentFragment is an object that is like an element, but does not have tag name nor any attributes, and is not part of a page. What makes it special is that whenever you insert it into any DOM node, its child nodes are inserted instead (and a document fragment itself gets emptied). This can be useful for many things (IIRC jQuery uses it for bulk moving).


Flexibility

The question is now, how do we do in Silk the equivalent of this jQuery call (question credits @RichardEng) (this kind of code using raw HTML is just too common for my liking):

$('#client-main').append( 
'<form> 
<table> 
<tr><td>Username:</td><td><input name="name"></td></tr> 
<tr><td>Password:</td><td><input name="password" type="password"></td></tr> 
<tr><td><input type="submit" value="Okay"></td></tr> 
</table> 
</form>'
);

For the first part, Silk has asSilk API that uses DOM querySelector API, so the first line is ok, but now, how to create this structure? There’s just too many possibilities. And I myself don’t know, which is more “right” and which is not, which gets adopted, and more importantly, won’t user base be confused by so many ways to do the same thing? ³

As direct use of << is pretty low-level, I am not including scenarios with direct use of it, instead compose them from convenience TAG and TAG: messages with combination of dynamic array and cascading. Few possibilities follow:

"dynamic arrays everywhere"
'#client-main' asSilk
  FORM: {
    Silk TABLE: {
      Silk TR: {
        Silk TD: 'Username:'.
        Silk TD: {Silk INPUT: {'name'->'name'}}}.
      Silk TR: {
        Silk TD: 'Password:'.
        Silk TD: {Silk INPUT: {'name'->'password'. 'type'->'password'}}}.
      Silk TR: {
        Silk TD: {Silk INPUT: {'type'->'submit'. 'value'->'Okay'}}}}}
"dynamic arrays for more, parentheses for one"
'#client-main' asSilk
  FORM: (
    Silk TABLE: {
      Silk TR: {
        Silk TD: 'Username:'.
        Silk TD: (Silk INPUT: ('name'->'name'))}.
      Silk TR: {
        Silk TD: 'Password:'.
        Silk TD: (Silk INPUT: {'name'->'password'. 'type'->'password'})}.
      Silk TR: (
        Silk TD: (Silk INPUT: {'type'->'submit'. 'value'->'Okay'}))})
"chaining and cascades where possible,
dynamic arrays for more, parentheses for one"
'#client-main' asSilk
  FORM
    TABLE
      TR: {
        Silk TD: 'Username:'.
        Silk TD: (Silk INPUT: ('name'->'name'))};
      TR: {
        Silk TD: 'Password:'.
        Silk TD: (Silk INPUT: {'name'->'password'. 'type'->'password'})};
      TR: (
        Silk TD: (Silk INPUT: {'type'->'submit'. 'value'->'Okay'}))
"chaining and cascades where possible,
prefer cascading even more using `Silk newStream`
(though this means you cannot set attributes),
dynamic arrays for more, parentheses for one"
'#client-main' asSilk
  FORM
    TABLE
      TR: (Silk newStream
        TD: 'Username:';
        TD: (Silk INPUT: ('name'->'name'));
        yourself);
      TR: (Silk newStream
        TD: 'Password:';
        TD: (Silk INPUT: {'name'->'password'. 'type'->'password'});
        yourself);
      TR: (
        Silk TD: (Silk INPUT: {'type'->'submit'. 'value'->'Okay'}))
"primarily using in: API with blocks,
dynamic arrays for more leafs, parentheses for one"
'#client-main' asSilk
  FORM
    TABLE in: [ :table |
      table TR in: [ :row |
        row TD: 'Username:'.
        row TD INPUT: 'name'->'name' ].
      table TR in: [ :row |
        row TD: 'Password:'.
        row TD INPUT: {'name'->'password'. 'type'->'password'} ].
      table TR TD INPUT: {'type'->'submit'. 'value'->'Okay'} ]

Footer

If you asked why the messages for element creation are all uppercase — because DNU mechanism is used to intercept them, so you can create any tag that is alphanumeric only.

If you asked why weren’t blocks involved directly as objects that you can put in stream, there is an idea to use them differently (if you want to use them immediately, in: API allows you to do it), specifically, to allow them to specify dynamic content, as in:

aSilk H1: {
  'id'->'time'.
  'The time is '.
  [ :h1 | h1 << Date now asString ].
  '.' }

and adding the refresh API, so that whenever you would do

'h1#time' asSilk refresh

the actual time would appear in a header. The virtue of blocks executable many times allows for this more powerful usage.

Footnotes:

  1. Named after a resource that spiders (and one of the characters, Webber, whose name was the first candidate) produce in the game Don’t Starve.
  2. This is where I personally started (not counting a few amateur uses on some pages) my life with JavaScript. So I naturally see JavaScript as a server-side language (then, node.js came). Also, I always dreamt of creating similar online experience of “have app in minutes” for Amber itself.
  3. This is in fact the main concern of the whole article — though it was needed to introduce Silk to get the picture. Are you thinking this “n ways to do the same thing” can scare away the users, or are my fears just too paranoid?

Where Is Smalltalk Weak?

by Richard Kenneth Eng

As great as Smalltalk is, it is not without its weaknesses. Time to address the key issues…

Hiring and Staffing

Smalltalk does not yet have a large user base compared to, say, Java or JavaScript. Hence, the pool of talent to hire from is more limited. As people start to use Smalltalk in greater numbers, this issue will eventually resolve itself, but until then, businesses will need to be a bit more patient in searching for talent.

Consultants

It’s not difficult to find Smalltalk consultants who can help with business needs; this can often be a suitable workaround to staffing. I personally know of two local (to Ontario) software houses that specialize in Smalltalk consulting. One is Cherniak Software; the other is Simberon. Check your local area. Of course, these companies can serve clients anywhere; in the digital age, geography is usually not an issue.

Performance and Scalability

Smalltalk execution is generally slower than in many languages, such as Java, JavaScript, and C++. It’s comparable to Python, Ruby, Perl, and PHP, however. Like these last four, for most situations (such as industrial and financial applications), performance is not an issue. This is evidenced by the many success stories at Cincom, Instantiations, GemTalk, and software houses such as Cherniak Software. Enterprise users abound. If Smalltalk applications could not scale, then the above-mentioned businesses would fall flat on their faces.

For situations where performance is definitely an issue, Smalltalk options exist. GemStone/S is the best-known among them. Smalltalk MT is a high-performance product for the Windows platform. Smalltalk/X is another option.

That said, I wouldn’t use Smalltalk for crunching big data or controlling nuclear reactors.

Ecosystem

Libraries and Frameworks

There aren’t many third-party Smalltalk class libraries available. This is largely due to the lack of a language standard. However, for specific dialects and platforms, there are opportunities to use other language libraries. For example, Redline Smalltalk runs on the JVM and provides easy access to the huge collection of Java libraries. Moreover, imported Java classes can be treated just like Smalltalk objects! Another example: Amber Smalltalk offers ridiculously easy access to a vast number of JavaScript libraries. Similarly, Essence# opens the .NET ecosystem to its flavour of Smalltalk. And most Smalltalks give you access to C libraries.

Even in the absence of third-party class libraries, Smalltalk remains immensely useful, thanks to the rich classes that come with each dialect.

As for server-side web frameworks, there are really only two options: Seaside and Aida/Web. Seaside is easily the most popular of the two, and for good reasons. Is there really a need for dozens of different frameworks like you find in Java and PHP?

Tooling

Due to the nature of the Smalltalk environment, it is not practical to use the conventional file-based toolchains that many developers know and love. Thankfully, the Smalltalk community has built up an impressive set of tools over the years and the Pharo Project continues to push the envelope in this regard. Moreover, Smalltalk is now well-supported in Github and other source control systems.

A common complaint is that the Smalltalk environment does not have a good text editor. This is true. However, it’s mitigated by the fact that in Smalltalk, methods tend to be rather small (10-30 LOC). When editing such small parcels of code, a mammoth editor like emacs is surely overkill.

Nevertheless, there are exciting new developments coming in the way of IDEs. One of the most notable is Moose Technology. Check it out.

Unusual Syntax

Our industry seems to be hung up on “C-like” languages. By this, I mean things like using braces as block delimiters, or conventional arithmetic precedence instead of prefix/postfix/Smalltalk-style notation. The theory is that having familiar syntactical elements lowers the barrier to entry.

Smalltalk’s syntax is indeed different from that of C-like languages, but the same can be said for Python, Ruby, Delphi, Haskell, and Clojure, all of which have gained substantial followings. Having an unfamiliar syntax is surely no impediment to learning a language. And the fact is, there is so much more to a language than just a handful of superficial syntactical elements.

Throughout most of my career, I was immersed in C-like languages (C, C++, C#, Java, Objective-C). And yet, I have never had a problem picking up FORTRAN, Tandem TAL, Smalltalk, and Python. In fact, learning these languages was fun! What I’m saying is, this is very much a matter of attitude, and not a cognitive challenge.

Enough Rope To Hang Yourself

Smalltalk’s programming environment makes available the entire class hierarchy for your application, including the core classes of Smalltalk. Arguably, this is very dangerous, as you can modify the foundational classes and consequently get into a lot of trouble.

However, access to the core classes is intended to help you understand your software. It is not a green light for you to tweak or alter the foundation. The solution lies in strict project discipline, which requires competent managers. The truth is, if you don’t have competent project management, you have a lot more problems than a programming environment that is too open.

No Corporate Master

In the past, growing a language from grassroots was a hit-and-miss affair. Today, a new programming language really needs a boost from corporate sponsorship in order to compete. Java had Sun, and now Oracle. C# had Microsoft. Swift has recently risen to prominence thanks to Apple. Go gets a boost from Google. Microsoft is now pushing F# and TypeScript, while Google has just introduced AtScript. Mozilla is behind Rust.

Having a corporate backer confers enormous benefits. For starters, it raises the public profile of the language which is vital from the marketing standpoint. Corporate funding can help develop the language much more quickly. Businesses feel more confident about using a language with strong backing. And a thriving ecosystem will always rally behind a major leader.

Smalltalk once had corporate backers such as ParcPlace and IBM, but through their ineptitude and naiveté they squandered their opportunity. We need a new backer today.

Smalltalk’s Proven Productivity

by Richard Kenneth Eng

You often hear about Smalltalk’s productivity advantage over other languages such as Java, JavaScript, and Python. Depending on who you talk to, this advantage ranges from 1.5X to 2-5X. In my own experience, for smaller projects, it’s around 3X. This is all anecdotal, of course, but is there actual scientific evidence to back it up? In fact, there is.

In the seminal 2013 paper published by Namcook Analytics, Capers Jones discusses the use of function points for analyzing software productivity, quality, costs, risks, and economic value. Note that Jones studies productivity over all aspects of a software project, not just the coding or programming phase. So this is fairly representative of the real world.

CEO’s and other C-level executives want to know much more than just the coding part of software applications. They want to know the full cost of applications and their complete schedules from requirements through delivery. They also want to know multi-year maintenance and enhancement costs plus total cost of ownership (TCO).

On page 42, Jones deals with “Function Points versus Lines of Code (LOC) for Software Economic Analysis.” Having established the approximate number of logical source code statements per function point for a wide variety of languages, he then presents a hypothetical software application to compare the development effort among these languages. (Non-code months include things like requirements, design, documentation, management, etc.)

Language Coding months Non-code months Total months
C  128  50  178
FORTRAN  107  50  157
JavaScript  71  50  121
Lisp  64  50  114
C++  53  50  103
Java  53  50  103
Python  53  50  103
C#  51  50  101
Ruby  46  50  96
Haskell  38  50  88
Delphi  29  50  79
Objective-C  27  50  77
Visual Basic  27  50  77
Smalltalk  21  50  71

As you can see, Smalltalk easily trumps JavaScript, Java, Python, C#, and Ruby. Now, this result is not definitive since it makes a number of assumptions, and one has to be somewhat wary of statistics. Nevertheless, the numbers are consistent with anecdotal evidence which constitutes proof within the statistical error. The interesting thing about this study is that it goes beyond simple coding and programming; it takes the entire software project into consideration, which is what business executives care most about.

The Smalltalk Evolution

by Richard Kenneth Eng

A common criticism about Smalltalk in the modern age is that the language is not adapting to the latest language research, which is pursuing things like multi-core concurrency and type system safety. Mozilla’s Rust language is often trotted out as a prime example.

The intent of the Smalltalk campaign is not necessarily to compete with cutting-edge languages. Smalltalk is trying to compete with well-entrenched mainstream languages such as Java, JavaScript, and Python.

Moreover, Smalltalk has been continually evolving for many years, as evidenced by numerous dialects that experiment with new features. The Pharo Project continues this tradition. However, one important point must be made: if Smalltalk changes too much, it will no longer be Smalltalk. The beauty of Smalltalk lies in its simplicity and elegance. Tacking on too many major new features will complicate the language and detract from this quality.

The world doesn’t need more complicated languages; it needs simpler languages. That’s the trend we’ve been seeing in recent years, e.g., in Go and Dart. The idea that piling on new features will solve our development woes is misguided. Simple languages that can be easily mastered, in combination with sound project management, will go a lot further than arcane features. I am not convinced that Rust, or any of its ilk, will ever become mainstream. I still remember the hype that surrounded Ada in the 1980s. It was supposed to provide all kinds of safety guarantees. But Ada never achieved significant popularity.

I am bemused by the spate of new programming languages that have popped up over the past 20 years. Very few of them have incorporated new concepts. For the most part, they are merely shuffling around different sets of language features in pursuit of some mythical software engineering advantage. They are basically chasing after their own tails.

For example, Python and Ruby doesn’t really add anything new that wasn’t already in Smalltalk. Dart has type annotations, a feature of questionable value that in the best case hardly upends conventional development practices. Such incremental changes will change nothing in the large. The proliferation of new languages is really a silly exercise in futility.

While Smalltalk is technically of the past, its image-based, “live” development environment has still not been surpassed by all the latest IDEs such as Eclipse, IntelliJ, and Visual Studio. Smalltalk maintains a huge productivity advantage because its tools are simpler, easier to use, and at their roots incredibly powerful. I have always been put off by the complexity of Eclipse and Visual Studio.

So with these two advantages – language simplicity and powerful environment – Smalltalk can still find a place in modern software engineering. It may not push aside Java, but it can certainly carve out a healthy portion of the market.

The Heretic Web Framework

by Richard Kenneth Eng

Seaside is the preeminent server-side web framework in the Smalltalk world. Think of it as Smalltalk’s counterpart to Ruby’s Rails or Python’s Django or Scala’s Play framework. It is common to talk about Smalltalk and Seaside in the same breath, such is the strength of the association.

The best ambassador for Seaside is the book “Dynamic Web Development with Seaside,” by Stéphane Ducasse, Lukas Renggli, C. David Shaffer, Rick Zaccone with Michael Davies. Borrowing from Section 1.1:

What is Seaside?

Seaside is a free, open source framework (collection of Smalltalk classes). The developer can use and extend these classes to produce highly dynamic web-based applications. By applications, we mean real applications with potentially complex workflows and user interactions, in contrast to just collections of static pages. Seaside makes web development simpler and can help you build applications that are cleaner and easier to maintain because it has:

  • a solid component model and callbacks,
  • support for sequencing interactions,
  • native (Smalltalk) debugging interface, and
  • support for using AJAX and other Web 2.0 technologies.

Seaside applications are based on the composition of independent components. Each component is responsible for its rendering, its state, and its own control flow. Seaside enables you to freely compose such components, creating advanced and dynamic applications comparable to widget libraries such as Swing or Morphic. What is really powerful is that the control flow of an application is written in plain Smalltalk code.

What distinguishes Seaside from other popular web frameworks?

In summary, several aspects of Seaside’s design differ from most mainstream web application frameworks. In Seaside

  • Session state is maintained on the server.
  • XHTML is generated completely in Smalltalk. There are no templates or “server pages” although it isn’t hard to build such things in Seaside.
  • You use callbacks for anchors and buttons, rather than loosely coupled page references and request IDs.
  • You use plain Smalltalk to define the flow of your application. You do not need a dedicated language or XML configuration files.

Combined, these features make working with Seaside much like writing a desktop GUI application. Actually, in some ways it is simpler, since the web browser takes a lot of the application details out of your hands.

Continuations are the key

Seaside is based on reusable, stateful components. The key feature that supports this is called a continuation. A continuation is a snapshot of a program’s current control state. It allows you to “jump” to another execution and when you return, the current state is restored. This provides a conventional “call/return” mechanism for your web application. It can help resolve issues such as the double request and back button problems.

What about REST services?

Sometimes, you need to provide a REST API in order to support a variety of applications. Section 24.1 gets you started.

What is the current state of Seaside?

The latest version, Seaside 3.0, is absolutely rocking! It has numerous improvements, including a new architecture that sets the stage for many future advancements.

Smalltalk: Yesterday, Today, and Tomorrow

by Richard Kenneth Eng

Why did Smalltalk fail to catch on 20 years ago?

James Robertson gave an excellent summary here:

There are a number of reasons that Smalltalk didn’t “catch fire”, most of them historical:

  • when Smalltalk was introduced, it was too far ahead of its time in terms of what kind of hardware it really needed
  • In 1995, when Java was released to great fanfare, one of the primary Smalltalk vendors (ParcPlace) was busy merging with another (Digitalk), and that merger ended up being more of a knife fight
  • By 2000, when Cincom acquired VisualWorks (ObjectStudio was already a Cincom product), Smalltalk had faded from the “hip language” scene
  • Since then, Smalltalk has been a small player on the language space, but it’s back to having a growing market. There are both commercial offerings (Cincom being the largest player there), and open source (Squeak and Pharo which are mostly under the MIT license, and GNU Smalltalk, which is GPL).

Not all Smalltalk implementations require an image; while those of us who are sold on an image environment love it, you can use GNU Smalltalk with your favorite text editor easily enough.

Ultimately, Smalltalk peaked early, and then had damage done to it by the stupidity of the early vendors in the space. At this point in time, that’s all in the past, and I’d say that the future looks pretty bright.

An anonymous poster gave this insightful response:

You had to be there in 1995. At that time, there were a few commercial Smalltalks but the biggest was VisualWorks from ParcPlace Systems. The marketers at ParcPlace were idiots – choosing to optimize for max dollers per seat rather than max seats. Any shop wishing to adopt Smalltalk had to pay a couple thousand dollars per developer for a license. Any developer wishing to learn Smalltalk either had to get hired to do Smalltalk or sink serious cash into buying his own license. So it was just plain hard to get a chance to learn it.

Also about that time, IBM was looking for a successor to COBOL for their business customers. They chose Smalltalk (smart) and developed VisualAge and made it so the same program could run without modification on everything from mainframes to AS400s to PCs. Smalltalk has a friendly minimal syntax and is easy to learn so it seemed a natural replacement for COBOL. The future looked really bright for Smalltalk. The companies that were using it were out-producing everyone else by a lot.

Then Sun showed up with Java. They gave it away free instead of charging for it. IBM took a look at it and figured two things. First they didn’t want to enter a marketing war with Sun that was clearly planning to spend a fortune on the Java brand. Instead they decided to try to beat Sun at their own game – have the best Java on the market. Why not, they already had a great VM that ran on their whole stack – they just adapted it to handle the Java bytecode set. In fact, all of IBM’s Java tools were actually written in Smalltalk for several years. Thus – if one wants to blame anyone for the rise of Java over Smalltalk – it is pretty easy to place the blame directly at the feet of IBM and their unwillingness to compete.

What is Smalltalk’s current state?

Eliot Miranda provides a good overview:

Whether Smalltalk is popular or not is perhaps less interesting than whether it is successful.  It happens to be used still in some extremely important industrial and financial sectors, no matter that Bob Martin talked of this as having occurred in the past.  For example, it is almost certain that the chip in your smart phone was built by fab machines whose control system (GUI and scheduler) is implemented in Smalltalk.  So Smalltalk is still used in the enterprise, and one sad reality is that the Smalltalk community failed to market Smalltalk in part because those enterprise users refuse(d) to allow their use to be mentioned because Smalltalk is seen as providing a strategic advantage.

There is abundant evidence for Smalltalk usage in the enterprise today:

Where is Smalltalk headed?

Well, that depends on you. Smalltalk has the power to revolutionize the software development industry. You only need to recognize a few things:

  • The complaints about Smalltalk’s downsides, such as its image-based virtual machine, its lack of support for existing file-based toolchains, its IDE based on the class browser rather than files containing long stretches of code, precisely reflect the powerful nature of the environment that gives you its unbelievable manifold productivity advantage.
  • As more people understand Smalltalk’s ease of development and productivity, and learn to use this super-tool, the issue of hiring from a small talent pool will simply go away.
  • Smalltalk’s simple syntax, even if it is markedly different from that of C or Java, cannot be a genuine impediment. If it were, then languages such as Python, Ruby, Haskell, Clojure, or Lua would never have caught on.

Even if Smalltalk Renaissance fails to persuade the IT world, at the very least, Smalltalk will continue to thrive in its niche-size market, offering users a strategic productivity advantage unmatched by any other programming language. The Pharo project will ensure this. The Smalltalk vendors such as Cincom, Instantiations, and GemTalk will ensure this. The active Smalltalk community will ensure this. Smalltalk is in no danger of going away.

The danger lies with the status quo of the IT industry.

Smalltalk in Business, Italian-style

by Lorenzo Schiavina

I’ve been using Smalltalk since 1982; from 1990 until it stopped its activity, I have been the Italian distributor of Digitalk and my company (EDOR Metodi Quantitativi) was the Competence Center for IBM VisualAge for Italy since 1995.

I started my activity as a programmer in 1967 and I have used the following
languages:

  • Assembler 360
  • RPG
  • Basic
  • FORTRAN
  • COBOL
  • Smalltalk
  • Java

Since 1975, I’ve been Associate Professor of Operations Research at the Faculty of Mathematics at the Università Cattolica of Brescia. In 1970, I developed (in COBOL) a package called MIDA (Management Integrato Dati Aziendali), which was the official package of HP for the HP-150 series and sold around 23,000 packages in Italy, and was brought into several foreign countries.

In my humble opinion, OOP technology (and particularly Smalltalk) is not only a technological change, but a real paradigm shift like (as I was assured by Prof. Enrico Gamba, a math historian with whom I discussed this aspect) the transition from Roman numerals to Arabic numerals. The results obtained are externally the same, but the process (and the mental approach) have little in common.

Since 2000 (when in Italy we passed from lira to the euro), I brought MIDA from COBOL to Smalltalk (it was not a simple port, but a full reimplementation) and I can guarantee that it was a real success; at present, we have about 300 direct clients and they seem very satisfied. In 2002, the Italian Ministry of Research granted my company a contribution for a project (Azienda ad oggetti) for the creation of a general OOP model for any kind of company. In this model, all business components are made in the form of classes and Smalltalk hierarchies.

Please observe that, some years later, IBM tried to develop a similar project (San Francisco project) with Java, but dismissed it. Based on these experiences, I believe that the arguments in the video “What Killed Smalltalk Could Kill Ruby, Too” are ridiculous and meaningless. The real problem (which I lived through) was very similar to what occurred in Tuscany during the Renaissance: those who knew (Roman) arithmetic got scared and saw that his power would be destroyed and hampered by the new paradigm, came to banish the Arabic numerals. I remember perfectly that traditional programmers did not understand absolutely how to convey their experience in objects and then, of course, did not want to change.

When I held lectures on VisualAge at IBM meetings, people expected me to talk about Java, because traditional programmers understood it, since it was not as “abstract” as Smalltalk; and this was a winning strategic choice for Sun. If I have to make one criticism of Smalltalk, it is that it did nothing to take the market from traditional programmers, continuing to make beautiful things (like the Tower of Hanoi, for example) but ignoring the things that were important at the time, such as business applications.