Multimedia (was re: HeatedDiscussion)

David Cramer dacramer at
Thu Mar 16 07:13:37 UTC 2000

I've been enjoying this discussion a great deal over the last couple 
of days. Since many of the opinions presented about Squeak vs 
special-purpose multimedia authoring programs seem to be based on 
perceptions of HyperCard as the definitive expression of its genre, 
the arguments are in danger of falling into the old "straw man" 

I have been involved with various scripting approaches to some very 
specific multimedia applications over the last few years. The main 
emphasis of these applications has been to emulate Windows-based 
office programs as part of multimedia training packages.

I started scripting in HyperCard. My last project in about 1988 
included a nicely functioning little text outlining system complete 
with autonumbering, expanding/collapsing topics, and drag-and-drop. I 
quit HyperCard at that point both because I recognized its 
limitations, and saw Apple's support fall off, especially in areas of 
basic functionality like color support.

Since then I've played around with other macro and scripting 
products, always stopping short of "true programming" due to the 
limited amount of time I have always been given to produce a product, 
and due to the fact I have always ended up working pretty much on my 
own. I'm currently completing a Smalltalk course by correspondence 
from Acadia on my own time as part of a longterm plan to move beyond 
scripting at some point in the future; but there's absolutely no 
possibility that the kind of products I have to build could be 
accomplished by me in the time period I have been given, because I 
would have to attain a much higher level of sophistication in 
programming in Smalltalk before I could build them.

This might be a point someone more experienced in Smalltalk 
programming would debate, but I've always been pretty good at 
assessing my own capabilities at any point in time, and that's my 
assessment for what it's worth.

As I analyze my authoring options right now, it all comes down to the 
compromises inherent in the way a scripting/programming language 
provides prebuilt structure vs. flexibility and extensibility. Toss 
in a measure of limitations vs. features and you've got some sort of 
idea how it compares to other authoring systems.

HyperCard provides/provided a simple structure, some flexibility, and 
not much extensibility.

Squeak provides a rich structure, with practically infinite 
flexibility and extensibility.

So why can't I use Squeak to build what I need? Because the 
structure, as rich as it is, is on level beyond my skills, and 
doesn't include any of the prebuilt interface widgets that are so 
essential to what I have to produce, so I'd have to roll my own, 
which would require those skills I don't yet have.

The straw man part comes in when people use HyperCard as the program 
to compare with Squeak. This is a poor choice, IMHO. My choice would 
be MetaCard. In some ways you might say that MetaCard is to other 
authoring apps as Squeak is to other programming languages.

MetaCard started in 1990 as a HyperCard for Unix, and is built on an 
intriguing set of assumptions and paradigms. It consists of an 
engine/kernel/runtime that totals about 1 megabyte and comes in 
versions for Mac, Windows, Unices, and Linux. Along with the engine, 
the developer works with a bunch of supplied stack files, which are 
all unlockable MetaCard apps and are completely cross-platform. The 
engine is not open-source, but the IDE is. All of the dialog boxes, 
menus, windows, icons, buttons, and cursors are available for 
modification, rescripting, redesign, whatever. And the developer can 
add anything he/she can script to the IDE to extend it (plus the 
usual platform-specific extensions characteristic of HyperCard et al).

MetaTalk, the scripting language, is a superset of HyperTalk, but 
we're talking super-superset here. One of the best examples that 
quickly gets across some of the power of MetaCard is an FTP download 
app created as a MetaCard stack.

You can download it for free:


The MetaCard demo can be downloaded for free from this page, you 
choose your platform:


What you get in the demo is actually the full version, it just isn't 
fully enabled. You are limited in the number of statements (about 10) 
in a single script. This allows you to do a whole lot of testing of 
anything you want in the scripts you create, but on a small scale. 
Paying about a thousand bucks gets you the registration number which 
you enter into one of the stacks, which then fully enables the 
developer stacks (the engine itself is always fully functional, by 
the way, it's just that until you register, your *scripting* access 
to that functionality is limited).

The scripting limit pertains to the developer stack scripts in that 
you can inspect them all you want, you just can't modify them.

Another cool thing about MetaCard, which is nicely demonstrated by 
the FTP demo stack, is that all text and graphic content and stacks 
themselves can be referenced via the internet just as easily as from 
your hard drive. So if you get the MetaCard demo and unpack it, and 
do whatever you have to do on your particular platform to link the 
.mc extension to the MetaCard engine, then you can do things like run 
Netscape, go to <>, click on the 
<> link, and the remote application will run.

Besides that, MetaCard apps tend to be really fast and really small.

I have to go sleep now, but I really do think MetaCard is a great 
complement to Squeak in a lot of ways, and MetaCard support is 

At 3:30 PM +1100 3/16/00, Russell Allen wrote:
>I would respectfully disagree with the description of Squeak as a "program
>development system".  In my opinion, this is as limiting to Squeak as
>saying that Squeak is a "multimedia authoring system".
>Squeak is fast on its way to being a "content development system" as well
>as a "program development system".
>As it does so, it subsumes the functionality of more specialised programs.
>Within Squeak is a compiler, an IDE, a web server, a flash player, a midi
>player and sampler, a web browser and email reader etc.

I guess my feeling is that Squeak shouldn't worry about subsuming 
specialized programs if they exist and already provide the right 
prebuilt components to allow people to quickly and efficiently create 
what they want within the boundaries of those prebuilt components. 
Squeak's role is to allow people to go beyond those boundaries where 
prebuilt components don't exist.

At 3:30 PM +1100 3/16/00, Russell Allen wrote:
>For precisely the reasons you have stated above - Sibelius is limited in
>what it can do because it is a specialised, closed-source program.

When the limits of a specialized program don't get in the way of your 
efficiently creating what you want, they are specifications, not 

At 3:30 PM +1100 3/16/00, Russell Allen wrote:
>Yes, this is a good start.  But I am a greedy person - I want the
>flexibility of Squeak and the ease and power of Sibelius too.  And lots of
>other stuff!

I expect that if I can become more of a programmer, comfortable with 
rolling my own structures and interfaces at a level of sophistication 
beyond MetaCard, and Squeak continues to mature, I could transition 
from MetaCard to Squeak for actual production work.

And to be honest, I accept that it may largely be my own limitations 
that hold me back now. I really appreciate the entire Squeak 
community more than I can adequately express.


David Cramer, Process Innovation Evangelist          87-1313 Border Street
PBSC Computer Training Centres (an IBM company)      Winnipeg MB R3H 0X4
Corporate Office Research & Development              Canada

More information about the Squeak-dev mailing list