Pinderkent

I heard today that the development of Dolphin Smalltalk has been discontinued. Although it isn't a product I used or was familiar with, I have been involved with a number of Smalltalk-based development efforts in the past. While it was somewhat popular in the late 1980s and early 1990s, the commercial usage of Smalltalk has declined significantly since then.

Slava Pestov suggests how poor implementations are leading to the downfall of Smalltalk. I would tend to agree, to some extent. Most Smalltalk implementations really don't compare to a development platform like Java, or even what Microsoft has put together with C# and .NET.

However, I would tend to think that the main reason why Smalltalk has started to really fall out of favor is that it doesn't bring the level of productivity that it used to, relative to other technologies. Back in the early 1990s, a lot of enterprise-grade software was written using C or C++. For developing complex business applications, Smalltalk often did offer a very significant productivity boost to developers, even if the runtime performance of the applications suffered somewhat. Being at a higher-level, it allowed business rules and concepts to be more easily and effectively represented in the software itself.

But that started to change by the mid-1990s. Java arose, and offered many of the benefits that Smalltalk had been offering. That's not to say that Java, as a language, is comparable to Smalltalk. In many ways it's quite inferior, even over a decade after its initial release. But it was more familiar to those developers who'd come from the world of C and C++, while also offering OO functionality and garbage collection similar enough to that of Smalltalk.

I've worked with several excellent Smalltalk developers in the past. A talented, experienced professional can do wonders with Smalltalk. Unfortunately for them, Java and its vast array of classes, class libraries and frameworks have brought a similar level of productivity to only average developers. So if these average developers can churn out an adequate software product at a lower cost than the Smalltalk expert, as has often become the case, then the business will flow towards the Java developers.

Unless the Smalltalk developers bring something to the party that drastically increases their productivity (or their software's productivity) over that put out by Java developers, they won't have a real chance at survival.

Michi Kono recently wrote about how the most talented Web developers are usually also the most talented application developers. I propose that we take it a step further: a great Web developer is usually a superb application developer. Or in a different light, a great Web developer is a waste of a really great application developer.

Fairly early on in the article, Michi makes this statement: Nothing is inherently easier about developing an application in PHP than in C++. That is quite true, but I don't think it goes far enough. What we usually find is that developing a Web application in PHP is more difficult than developing a comparable desktop application in a language like C++, Java or C#. When using a language like Python for GUI desktop applications, the inefficiency of PHP (and Web development in general) becomes quite apparent.

Large-scale Web development is usually not a pleasant experience. One of the main problems is just coping effectively with the wide variety of technologies that are involved in Web applications. Not only is knowledge of HTML required, but so is knowledge of JavaScript and CSS. And that's just for the front-end. You still likely need to know PHP, Java, Ruby, or some other language when developing the back-end of the site. As most applications require some sort of database access, you usually have to add SQL into the mix.

Granted, the essentials of those languages and technologies are not overly difficult, and are well-understood by most developers. But it's still not a very effective way of developing software. Some may argue that we see multiple domain-specific languages in use, and that may be the case. But the end result is that we often have developers who are over-streched when it comes to implementing advanced features. There is only so much knowledge that a typical developer can effectively acquire and manage, especially when deadlines are looming.

Five years ago, many of us were developing enterprise applications using C++ and the MFC, or Java and AWT or Swing. Since we were really only using C++ or Java in many cases, we were able to become quite familiar with all aspects of those languages. We didn't have to learn two or three separate languages for developing the UIs of our applications, as they were built upon the common constructs of C++ or Java (usually with the help of a GUI designer utility).

Languages like Java and C++ allow for large, complex applications to be developed with relative ease. They have a rich heritage. They were initially developed, and subsequently evolved, by those who had to deal with massive software systems. The Web technologies, on the other hand, grew from the low-end up. And it shows. They lack the coherency of languages like Java, C++, Smalltalk and Python.

CSS, HTML and JavaScript also lack what I'd like to label as "maturity". This isn't maturity as in their age, but as in the raw experience and knowledge that went into designing them. It just isn't there, or at least doesn't come from the world of large-scale application development.

One area in which Web application development is particularly pathetic is when it comes to debugging. There are a wide variety of excellent debugging and program tracing tools available for languages like C++ and Java. It's only recently that we've been seeing Web development tools like Venkman become somewhat suitable.

So in my past experience, I've generally seen excellent application developers suffer from a significant decrease in productivity when dealing with Web development. Many times this has been when it comes to debugging large Web applications. The disjointed nature of the various Web development technologies proves to be a significant hindrance, especially when compared to the more cohesive technologies like C++, Java, Smalltalk and Python. Were those developers instead developing using technologies like those, they'd be far more productive, and the resulting applications would be far more portable, efficient, reliable and enjoyable to use.

When the computing world moved from manually toggling input switches to machine code encoded on paper tape, there was a vast improvement in programmer productivity. Likewise, when machine code instructions were first represented with more comprehensible text-based mnemonics, we again had a major boost in programmer productivity. It was easier to write programs, and it was easier to maintain them.

Soon enough, the computing world moved on to languages like FORTRAN, COBOL, and PL/I. As had happened earlier, we had a major increase in developer productivity. What was tedious in assembly became far easier in such higher-level languages as those. Likewise, once a program was written, it was much easier for other programmers to come along later and comprehend and modify the program.

We experienced a similar productivity jump with the advent of C in the 1970s and early 1980s. Standard libraries and better portability made it far easier to move programs between two or more systems, often with drastically different architectures. Soon enough we had programmers writing far more complex software in only a fraction of the time and with only a fraction of the cost of earlier methods.

Then in the 1980s, object-oriented languages started to become mainstream. The likes of C++ and Smalltalk became widely used in industry. By the mid-1990s, we had Java. The move to such languages again brought significant productivity increases, especially in the area of graphical user interface implementation. But they also did allow for the construction of larger and far more complex systems than could be easily done in C alone.

Soon enough we entered the 2000s. Languages like Perl, Python and Ruby have started to become popular because they allow developers to perform common tasks quickly and efficiently.

Do you see the trend? Yes, it is one of ever-increasing productivity. That's not to be unexpected. After all, it's what has happened in nearly every other field and industry. It's just how the economy works; increase your productivity or perish.

We're now getting to the point where JavaScript and Web-based applications are being touted as the way we should proceed. Many are calling them the next "revolution" in software development. But I disagree. We just don't see the productivity increases materializing.

A typical AJAX-based Web application is often difficult to effectively create, even for experienced developers working with the latest libraries, frameworks and tools. A lot of developer time is wasted trying to sort out cross-browser incompatibilities. We're not talking about small differences, either. Often these differences require two or more implementations of the same JavaScript code, targeting specific browsers. That's just not effective, nor is it productive.

Debugging AJAX applications is also a terrible experience, even when using a tool like Firebug. Combined with the browser incompatibilities described earlier, it can become very difficult and time consuming to get an AJAX-based application working acceptably, let alone well.

And for the sake of your sanity, I hope you never have to maintain somebody else's AJAX application. I've seen very talented developers struggle for days on end with relatively simple problems in JavaScript-based Web applications. Part of this is because these applications are often developed very poorly in the first place. A second major struggle is the lack of mature, effective tools for mapping existing programs. All of these factors combine to cause problems.

So as you can see, JavaScript-based Web applications are clearly a step backwards. They fly in the face of what we've traditionally seen when moving to a new language paradigm. In the past we've seen clear improvements in terms of developer productivity, and in the complexity and scale of the applications that can be effectively developed. But we just don't see such things when using JavaScript in the browser.

Thankfully, some people have seen the light. They're realizing that languages like Erlang, Common Lisp and Haskell are clearly the way to go. They do deliver the developer productivity boost we've seen several times over and over again in the past. They're better equipped to handle the issues we will soon face with the rise of multicore systems in even the cheapest of desktops. In short, they exhibit an evolution of software development, rather than the devolution we see so often with JavaScript and AJAX-based Web applications.