Juan Vuletich is an Argentinian Smalltalk programmer who has been collaborating with Squeak for many years. In 2010, ESUG is going to sponsor one his projects, Morphic 3. Here, we have a rich talk about Smalltalk :-)
CS: Juan, you have been involved for many years with Squeak and Morphic, what can you tell us about Morphic 3 and this announced support from ESUG?
JV: Well, I discovered Squeak in 1997. I had been using OS/2 as my main OS, because it had been for several years the only one to allow for multithreading programming. Then Squeak came. An open source Smalltalk at last! And straight from Alan Kay and Dan Ingalls, and from Smalltalk-80! I immediately decided to port it to OS/2. That was my first Squeak related project.
Later, Morphic was ported to Squeak from Self. Morphic was an incredible discovery. I realized a new era was starting, and the books I'd bought to learn about MVC were obsolete. However, several things happened that made it hard to understand it. The biggest hurdle for me was the introduction of Etoys. Etoys was added to Squeak without a clear separation of what was part of the base Morphic framework, and what was part of the Etoys application. Besides, Etoys supports a programming style based on instances (a la Self) and the code was not easy to understand. This only got worse as time passed. People kept adding stuff, and nobody did any cleaning. You can see, for example here:
http://wiki.squeak.org/squeak/920 that Dan Ingalls always felt that serious cleaning was needed. Also John Maloney (one of the creators of Morphic, and the guy who ported it to Squeak) speaks about the history of Morphic and the issues he thinks that should be fixed in the SqueakNews interview. Get it at
http://forum.world.st/squeak-dev-Squeak-News-td83662.html.
For some time, I hoped Squeak Central would finally focus on cleaning Morphic and Squeak. I started thinking about doing it myself around 2003. Then Tweak was announced, but it was not what I wanted. So, around 2005, I started to clean Squeak and Morphic myself. I'd been interested in scalable user interfaces for over a decade, so that was the main feature I wanted. I worked on this in my free time and showed it in Smalltalks 2007 and Smalltalks 2009. People liked it, and Esug offered some support.
CS: You have announced that in Morphic 3 you have developed some algorithm using the sampling theorem, which is the basis of the digital audio and photography. How did you start studying this and when did you realize that could be applied to 2D rendering?
JV: I studied CS at the University of Buenos Aires. I took several courses on Image and Signal Processing, starting in 1999. The PhotoSqueak project was part of this. At the same time, I did my thesis on a technique I developed to do "smoother audio". This gave me the mind set and tools to attack the problems in 2D graphics with a new perspective. As Alan Kay says, "point of view is worth 80 I.Q. points"!
CS: In your website (www.jvuletich.org) we can read that Morphic 3 is looking for a highest-quality 2d rendering, even more that Cairo or other libraries and it's 100% done in Smalltalk, what can you tell us about the architecture, the speed and the compatibility of this new version of Morphic? JV: At the current state, there are 2 parts to this. One is the Morphic 3 classes that would replace the Morph hierarchy. The other one is the rendering engine that would replace Canvas, BitBlt and Balloon. Morphic 3 is not meant to be compatible with Morphic 2. Back compatibility is the single major force against progress in software. On the other hand, the rendering engine is pretty general, and it would not be too hard to integrate it with Morphic 2, giving better quality to most morphs.
With respect to speed, the code is right now in Smalltalk, so it is not very fast. When turned into a VM plugin, performance will be similar to the other rendering alternatives.
CS: What are the major problems do we have with Morphic today?
JV: In Cuis, there are no real big problems, but just that the features are a bit outdated: It doesn't do high quality anti-aliasing, and the UI is not scalable (well, no widely available UI is scalable yet!). Those are the issues I want to fix in Morphic 3. Besides I also believe that a normalized programming style on widget composition and model dependency is needed. I have already developed one, and I use it for my projects. It would be good to rewrite the programming tools using it.
In Squeak / Pharo, the biggest problem (that I have already solved in Cuis) is massive unneeded complexity. You can see it in the Squeak and Pharo mail lists, on the problems people have with Morphic, the kind of questions they ask, and the answers they give. Nobody can understand Morphic. It is slow and bloated, and nobody knows why. And all they do is to keep adding layers on top of the previous ones, making it bigger.
CS: You have developed a new spin off from Squeak called Cuis, what are the objectives of Cuis?
- Close to the ideas in Smalltalk-80 and "Design Principles Behind Smalltalk".
- Include only kernel functionality.
- Included stuff should be in very good shape.
- Include a greatly simplified version of Morphic as the main UI.
- Easy to fix and extend.
- Cuis is yours to extend it to suit your needs.
- Stable. Smalltalk kernel should not change much.
- Compatible to a reasonable degree with packages intended for other Squeak distributions.
- Lead by Juan Vuletich (jmv) after these principles.
I believe that Squeak and Pharo don't follow
Dan Ingalls's ideas expressed in the Design Principles paper. The idea of avoiding unneeded complexity has been central to Smalltalk since the beginning, but it seems to have forgotten in the last decade. To me there is no real advance if the system is still a mess. And working in a Smalltalk where all the time you are faced with old, silly and buggy code that nobody dares to try to understand is a constant pain for me. That's why I do Cuis.
I don't think that being a step ahead is an objective for Smalltalk. The objectives for Smalltalk have always been "do the best we can with the knowledge we have today" and "be a good tool to experiment, create new knowledge and express knowledge in a runnable form". I believe that software to drive computer displays will move away from the individual pixels exactly in the same way that printers have done it many years ago. No desktop publishing application lets you deal with the individual dots drawn on paper by a laser or ink-jet printer. As all software follows this trend, Smalltalk will also do it. I'm doing in Smalltalk because, to me, it is the best tool for any programming.
CS: What benefits could the scalable user interface give us?
JV: Independence of pixel resolution. Applications that look almost the same on a 72 dpi screen or a 300 dpi screen. (Printers have done this for over 20 years!) The ability to make a gui look bigger or smaller to fit our individual taste, while maintaining very high visual quality.
CS: You said that it couldn't be hard to integrate Morphic 2 with Morphic 3, you could use them at the same time or you will have to change a configuration?
JV: I said that the Morphic 3 rendering engine could be adapted for Morphic 2 rather easily. That would give better visual quality to Morphic 2, but it won't make it a ZUI. May be Morphic 3 morphs could also be used in a Morphic 2 world. Not sure about that.
CS: If new primitives must be added to the VM then the portability will be affected?
JV: This has no relation to Cuis or Morphic 3, right? I'm not adding new primitives to the VM! In general, the answer to your question is that it depends on the primitives. If they are properly written, that should not affect portability.
CS: You said that Squeak and Pharo don't follow Dan Ingalls's ideas expressed in the Design Principles paper, in that line, what do you think about SqueakNOS for example? Do you think that we should go back to the roots?
JV: I think that SqueakNOS doesn't follow "Design Principles". Especially when Dan says "Operating System: something that should not exist"! WRT "go back to the roots", I think it is a bit silly to declare Dan one of our biggest heroes and maintain a system that is bloated and convoluted for no good reason.
CS: You said that MVC is obsolete and Morphic represents a new era but what do you think of HTML and that the whole IT world is looking for web-based applications?
JV: MVC was obsoleted by Morphic over 20 years ago, when Morphic was written in Self. WRT my opinion about HTML and web-apps, listen to any talk by Alan Kay (for example
http://softwareengineering.vazexqi.com/2009/10/22/how-complex-is-personal-computing---by-the-fine-folks-from-vpri), or check the Lively Kernel by Dan Ingalls.
CS: So, if we sum Cuis and Morphic 3, we can say that you're looking for a clean Smalltalk that could be simpler to understand for everyone?
JV: Yes, indeed.
If I said ... Would you answer
Sports?
Soccer. Motorcycle racing.
Food?
Food, as a cultural artifact, from all over the world is interesting.
Computer brand?
Anyone, as long as it can run Squeak (better if small and silent).
Operative system?
Anyone, as long as it can run Squeak (and it doesn't crash too often).
Mobile Phone?
None is best.
City?
Paris
Book?
Ficciones (Fictions) by Jorge Luis Borges.
Film?
American Beauty
A Music Album?
"Kill Gil" by
Charly García and
"Genesis for 2 grand pianos".
TV Series ?
Two and a half men.
Magazine?
Scientific American.
Car?
Mercedes Unimog (not exactly a car!)
Open Source?
Yes, please.
Namco, the owner of the Pacman game, has sent a letter complaining that a kid has recreated the game using Scratch. Scratch it's a programming language based on Squeak for kids. Namco is complaining to the kid, that everyone can play Pacman for free. It's evident that if a kid could reproduce their patents or the playability using Scratch then they're commercially useless. We need to review our copyrights laws, this is absurd. 
