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:
-
Native Merlin - these implementations will run directly on the
hardware. They will normally need some kind of network to operate.
-
Embedded Merlin - like the previous style, but will work stand-alone
and may have significant parts of the system omitted to save space.
-
Nested Merlin - will run on top of another operating system
(Windows 95, Linux, OS/2, etc) as an application (more like a shared library,
actually). This will be less efficient than the first alternative as there
will be much less memory and CPU power available for Merlin. Unlike "normal"
applications, however, Nested Merlin will make very little use of the OS's
resources and will do most of the work itself. For example, it will not
use the native systems font system to create text, but will do it itself
and just use the OS to "blast raw pixels" to the screen. Even
so, Merlin applications will look as much like native applications as possible.
You will be able to launch Self applications directly and have Merlin load
(unless it is already running for another application) transparently.
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:
-
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)
-
write a driver for the interface you will be using (unless this has
been done already)
-
generate a special "monitor" program that you use to boot
the remote machine and get it talking to the host running Merlin
-
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)
-
you can upload enough of Merlin to be able to compile natively on the
remote machine
-
you can develop keyboard, mouse and video drivers and start working
directly on the remote machine
-
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 |
| faq |
| tutorial | | tiny |
back to:
please send comments to jecel@lsi.usp.br
(Jecel Mattos de Assumpcao Jr),.