Smalltalk – Better productivity ? A popular myth ?

What I have heard over the years again and again: Smalltalk has a better productivity. But I doubt that this is over all correct.

Yes, I have seen various reports telling me, that languages like Lisp and/or Smalltalk have a higher productivity per written word – but does this mean, that you are really more productive in your daily work ?

All these reports are in my opinion theoretical observations perhaps telling me, that Smalltalk has a better base to be a more productive system than other systems/languages.

Where have *I* seen this higher productivity? Perhaps in situations, when there is no available free source code for some stuff or there has been no standard defined in a domain field and therefore you are in an experimental environment.

But these situations are not very often. Have a problem in C# or Java ? Go out and you have a very good chance to get an initial solution !! When the world outside is defined mainly by MS standards, .NET standard or Java standard the productivity of using Smalltalk is going done – because normally you have to write your own wrapper for MS products (etc) and these wrappers are sometimes a project by itself, simply because these MS standards are complex by themselves.

Other topics ? The debugger in Smalltalk is still very good and the turn-around time is in large projects very well – but the other IDE’s are improving very fast. Build systems are limited and project resource managements are also limited in Smalltalk IDE’s.

After working over the last years in both worlds: C# and Smalltalk I would not bet on this higher productivity. Smalltalk is perhaps good in lots of domain fields – but is it first class ???

This entry was posted in Smalltalk, Uncategorized. Bookmark the permalink.

6 Responses to Smalltalk – Better productivity ? A popular myth ?

  1. Jan says:

    If integrating with other systems is a big part of your daily work than I agree. Smalltalk is rather weak in this area. This has been the case for a long time. I think this is caused by technical limitations and because the community is not that large. The fact that there are different Smalltalk dialects with incompatible interfaces also doesn’t help.

    Smalltalk is still great and productive for implementing complex business logic. I have seen several examples of successful business applications. The costs of maintaining and extending these systems is low compared to Java applications.

    How can we improve the integration facilities of Smalltalk so it becomes competitive in this area as well? Is it possible to create an external interface that is compatible with Ruby? This would be great because we could reuse all the great integration libraries of Ruby. For example Nokogiri for xml and html processing.

  2. This is a very interesting question, and a key one.
    I would certainly like to see more studies and experiments measuring the relative productivity of languages (or, really, frameworks written in those languages. Because honestly, in any given web development project, I don’t really care about the language, I care about the framework). Even if they’re personal experiments, like this Ruby on Rails vs Java post.

    I would personally like to see:
    Smalltalk/Seaside vs Ruby/Rails
    Seaside vs various PHP frameworks (Cake, Zend, NOLOH)
    Seaside vs Python frameworks (Django, web2py)
    and Seaside vs whichever the best-of-breed Java framework is popular today.

    Specifically, measuring the relative productivity of those frameworks, for a given web project/set of specs. Total time spent coding and debugging, total lines of code, richness of features.

    (And, in fact, I’m going to do those experiments personally, too, but I certainly would love to see other people study this).

  3. Bruno says:

    Hi,

    I do not think that interconnection with other system is a big issue. You can connect to databases, web services, xml, COM (Dolphin is pretty good with COM, check out Dolphin Smalltalk videos), and so on.

    There are different Smalltalk dialects because the were created with different goals.

    IMHO Smalltalk is the best development environment to create complex software. I’m using Smalltalk since 1999 (also worked with Java, C, C# and others).

    Regards,
    Bruno

  4. Friedrich says:

    It depends on the quality of software you can find. Yes there is much more available in C# or Java. But is it always good in quality? I don’t know. I see one of the biggest shortcomings in Common Lisp with the quality of software. Yes there is useful software out there but some software just can be used by very few. And so theoretically you do well with it, but in reallity it simply sucks.

    Anyway I’ve decided myself to use Smalltalk for my Web development project. I found people using it and that’s what has made the decision. I probably could have found something for it in the C#, Java area. However in some aspekt the area is very special (it’s the waste management industry) and there the libraries are not abundant.

    I simply think in my case that Smalltalk is up to the task and I will spend at least 10-20 years with that software, so I do want to have it of the highest possible quality, and I think in this regard Smalltalk has a very long history. I also am using it because of Gemstone, a database from which one can know it was developed and used for nearly two decades. And so no OR mapper, which really is a terrible problem in any OO language.

    I also want a way to fix things on the run. Common Lisp can do it, Smalltalk can do it, Erlang can do it. If I’m right C# and Java can’t.

    Another big problem (as I see it with Java or C#) is the bloated software programming cycle with tons of configuration files and tons of some kind of XML handling. I hate XML. It is IMHO way overused and “overspecified”. I also like the intereractive development cycle I can do with Smalltalk (no waits on compilation) not the handling of dependencies etc. This all an the way we have to develop our software (in cooperation with my customers) will probably be better done with Smalltalk than anything else.

    You also have to keep in mind how you are used to develop software. If you really to much research and paper work in advance your surely will prefer something like Java etc., tools which are used by herds of programmers. But if it comes to small companies you just can get that much done and doing it the same ways others do it may not pay off. See e.g the comments on http://www.joelonsoftware.com/

    I have always encountered the point, that I often just get it right in “principle”, and yes I even was able to write small programs which simply did work. But more often I start in one way, and during development things just “fall” into place. And there I need a simple way of starting afresh or just even throw software away and try it again. This is quite comfortable in Ruby, Common Lisp, it’s bit more tedious in C where you have to handle the diverse tools also.

    But one thing was not mentioned. I simply like the way software is developed in Smalltalk it’s my “way” of doing it. I have my share of C, I’ve my share of Eiffel (which I also liked very much), Ruby, Common Lisp, VBA (which simply astonishes me over an over again, where you think things are for granted and they are not supported, a thing I still can’t believe is that there is not way of giving back something from Forms but via Globals) . You can just keep your Forms around but if the form is closed you can not just have some return objects from within this form it must be some global. There is nothing you can call revision control in it also, and testing is terrible difficult because you often find yourself somwhere deep in forms or Reports) it still is used extremly much…. So there must be something in it….

  5. People will always default to the language they learned at school or on the job. Free promotions of new tools by big vendors will also sway the language decision. In all cases, the entire lifecycle of software is not measured in terms of cost, delivery rates, support rates and defect rates.

    Here are some points, in my opinion, that make Smalltalk a better, more productive and cheaper environment:

    a) Single Image – there aren’t multitudes of files and directories to manage during development or maintenance (C, C++, C#, Objective C, Java).

    b) Live Environment – everything is a live object and can be modified while the “system” is running, allowing for a tremendous prototyping, development, XP, development experience.

    c) Real OOPL – other languages are pseudo object-oriented; the variable types are not objects and the design process degrades to a procedural mindset using objects; abstraction, refactoring and reuse of design and code is often never done. When you truly think in objects, your design is much cleaner, maintainable and cheaper.

    d) Clean Distribution – when completed, the Smalltalk Image can be shrunk and packaged for clean distribution and installation.

    e) One Language Binds Them All – you can use Smalltalk for web development, GUI development, database development, network development, etc. Python uses Tck/Tk for its GUI and IDE for example. Ruby doesn’t have a GUI. The C languages don’t have a GUI or use proprietary libraries. Often, you need to know multiple languages to develop your complete system.

    f) Mature Language – it’s only been recently that other languages have included Collections, MVC, reflection and other mechanisms. Often their implementation is arduous (C++). Smalltalk has these and other facilities for over 30 years. Tried and true mechanisms in production for 30 years.

    g) Best Practices – it was Smalltalk that fathered the concepts of TDD, XP, SUnit, Patterns, refactoring (and refactoring Browser) and other mechanisms. This improves the quality of code and the maintainability of code.

    There are other reasons that also contribute to the productivity and usefulness of Smalltalk, but these points are significant in my opinion. When taken in aggregate, they make a compelling case of using Smalltalk.

    I should also mention the elephant in the room: the focus upon cheap labour (locally or off-shore) tends to create a market for brute-force programming. This in turn creates a demand for procedural programmers who write in every language, thereby blunting/eliminating the well-known Best Practices. “It’s good enough, get it into production (or on the shelf)”. “How many bodies can we get for Language-X”. The mindset of brute-force programming creates a barrier to using Smalltalk. This combined with the hype for other languages and vendor-tools creates a demand for non-Smalltalk solutions and programmers.

    While this point applies to the entire industry, it truly does limit the adoption of Smalltalk.

  6. Peter says:

    I’ve used Smalltalk for years. Now using C#. With Smalltalk, it’s like writing with a word processor. C# is like reverting back to the days of typewriters. I’d love to see a Smalltalk implementation on .NET.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s