What Will Be...

Progress in the Merlin Project has been less than spetacular so far. To correct this, the next steps will include the first release of tinySelf and the construction of an effective demonstration of the technology being developed. This demonstration will be used to interest additional investors. With better funding, more people can be hired to carry out the strategies described here. 

Merlin First

A large percentage of people who will be programming in the year 2004 don't currently know how to program - they will learn in the next few years. The simplicity of Self makes it an excellent first language and the tutorial will be created to teach the needed skills (instead of simply explaining language features). 

For children, Logo is normally considered the best choice. In a world of multimedia, however, its turtle drawn line art has lost most of its attraction. To meet Logo's original goals in the late 90s, 
we need a system that allows kids to build applications that are relevant to them, like their own video games and simulations. Pretty presentations and Web Pages are nice and should be easy to create, but they cannot replace the learning that programming brings. Self is great for all these things, and can be easily extended to allow old turtle graphics programs to run too (with a trivial translation of the syntax - which can even be done automatically as in the Smalltalk emulator). 

Merlin Everywhere

There will be three styles of Merlin implementations to meet a wide variety of needs:  The key to this strategy is making it easy to develop these ports for a wide range of different hardware (and OS) platforms. You will need a machine that already runs Merlin and one to which you intend to port it, connected via a serial or ethernet link. You then: 
  1. write a backend for the compiler for the CPU in the target machine (or use an existing one if there has been a port to another machine with the same CPU) 
  2. write a driver for the interface you will be using (unless this has been done already) 
  3. generate a special "monitor" program that you use to boot the remote machine and get it talking to the host running Merlin 
  4. you now have full control of the target machine, so you upload to it and run tests for your new backend (any problems with it would probably have resulted in a bad "monitor" program, but it pays to be paranoid) 
  5. you can upload enough of Merlin to be able to compile natively on the remote machine 
  6. you can develop keyboard, mouse and video drivers and start working directly on the remote machine 
  7. with a few more drivers you can cut the umbilical cord and start booting Merlin directly on the target machine. 
To be able to port Merlin using only the target machine (with only the host machine you could never do it, of course) you would have to use a native OS of that machine and the compiler for some language (C, most likely) as the development environment for Merlin. I feel that this is so much harder than what I described above that it is worth the extra trouble of having two machines. 

The current version of tinySelf runs on top of Self, so this exact same strategy will be used to "port" it to the PC (with X86 compiler). Also planned are versions for the ARM, the PowerPC and the 680X0 CPUs. 

Bridge to the Past

To be of any use in the commercial world, Merlin must be able to work with all kinds of legacy systems and offer a smooth migration path from them. The Nested Merlin implenetation described above is a part of the solution. The main focus here, however, is compatibility with industry standards. Merlin will "talk" to the outside world using the OMG CORBA  standards. In addition, all internal interfaces in the system are being defined to be as close as possible to the corresponding OMG service standards (both adopted and emerging) so Merlin objects will be able to be used as components in business applications.

Another standard the is being developed is the ANSI definition of the Smalltalk-80 language. This will allow the non graphical part of Smalltalk applications to run unchanged on all implementations. One of these implementations will be Merlin. Though many consider Self to be a very different language from Smalltalk, they are actually just different dialects as Mario's Smalltalk emulator for Self 4.0 clearly shows. Smalltalk has proven to be the best path to introducing object to business applications development groups (which normally have backgrounds in Cobol and similar languages, not C). There is no reason why Merlin shouldn't try to be the best option here.

Future Products

Future Merlin products will be able to use the most advanced technology possible ( even processors that haven't been designed yet ). Old and new Merlin computers will be able to share objects through the network with no additional investment by the users. 

Beyond the workstations, portable computers, notebooks and pen based machines we will have computers that are worn like watches but able to generate huge virtual images for the user. The user will, practically speaking, be inside the computer. An interesting idea is that the computer should "see" everything that the user sees by placing a tiny camera in the user's glasses-like virtual screen. This will allow the computer to input images, to overlay virtual objects on the real world and keep them in place as the users move their heads. It will also be possible to use gestures to communicate with the machines without the need for cumbersome data gloves, for the computer will simply see the user's hands.  
see also: 
| new3 | | intro | | faq | | history | | runtime | | tutorial | | tiny | | plan | 
back to: 
| merlin | | LSI | | USP | 
please send comments to jecel@lsi.usp.br (Jecel Mattos de Assumpcao Jr),.