Smalltalk and the future

I recently said that I'm working on creating the "Smalltalk of Modeling". To me, this means creating an elegant system that is practical but also embodies radical and powerful new ideas. It should also be implemented in itself and also capable of creating real applications.

But there are few things about Smalltalk that I hate. The first is the idea of an "image". I cannot stand it when my program is tangled with the IDE. It makes it difficult to collaborate, do version control, or deploy final products. I'm also not a big fan of read-eval-print loops (REPL). I like to write code in files, compile them into programs, and deploy them to customers. My IDE should help me write and debug my programs, but stay out of my way otherwise. Perhaps I did too much C programming when I was young. Some people love images, but I don't get it.

The second one is model-view-controller (MVC). I love MV, but I can do without the C. I have always suspected that it is an artifact of the Smalltalk runtime model, which was written right on the metal and did its own bit rendering and mouse tracking. I have to admit I'm not as experienced at GUIs as I am at other kinds of programming, but I've done a few. More modern toolkits don't have separate controllers. The controllers are built into the views (widgets). That is fine with me. Every time I see a library that emphasizes its adherence to MVC (with a capital C) I cringe. For example, does it really help web apps to modularize where to go next from a page?

Other than that, I love Smalltalk. On the other hand, I'm convinced that OO has run out of steam, and should be best used as the foundation for the next dominant paradigm. What is the next paradigm? Models. Yes, that's it! Not UML. Not MDA. Not EMF/QVT. Not Rails. These are good hints about what is to come, but they are still not complete. Hence my current project, to create a Smalltalk of Modeling.

4 comments:

  1. Having an image has a number of advantages:
    - it is a cheap and reliable persistent mechanism. Gemstone even consider it has a reliable database
    - make the deployment easy. Just one file to copy
    - no need to deal with files, this is cool for versioning. In my opinion, text files are a poor medium for storing source code. Too easy to get conflict where there shouldn't be (e.g., shuffling methods and a concurrent method edition).

    However, image is indeed central. And it shouldn't be. Gilad says it should be a cache, no more.

    ReplyDelete
  2. Hello,

    I started to leave a comment, but it grew long enough that I decided to post to my blog instead.

    ReplyDelete
  3. Hi Neel. I posted a comment on your blog about this, since it seemed more related to what you said than my original post.

    ReplyDelete
  4. Hi William,

    The 'C' in MVC is for most applications limited to the keyboard and mouse input. But give it a moment's thought and generalise the programming model to other 'sensors' and generalising the View to other 'actuators' than the screen or sound. Like in robotics domotica. In these case I'm happy that some trailblazers suggested the V and C abstractions and the whole MVC pattern.

    Smalltalk started without a preconceived notion of a user interface (keyboard, mouse, pen) with all the widgets we are nowadays take for granted.

    ReplyDelete