Kerry Thompson <[EMAIL PROTECTED]> wrote
> I don't understand why this isn't at the top of Macromedia's list of
> upgrades--there is no other single thing they could do to increase
> performance more, at least for Lingo-heavy apps.
>
> At the beginning of a project, the Powers That Be make a decision--do we
> need performance, or quick development time. If performance is the sine qua
> non, they use C++. If they can put up with slower performance, they use
> Director.
>
> A Lingo compiler would put Director in the same class with C++ as far as
> performance, without sacrificing development time.
I can follow you on this, but I would hate to see the loss of the runtime
interpreter and (especially) the ability to evaluate strings. I don't use
'do' very often, but I use value() in almost every project. One of the
biggest problems implementing what you suggest is that Lingo is loosely
typed, whereas compiled languages are necessarily more tight about what
datatypes you use, which slows development down. Most compiled languages
require you to explicitly state the type when creating variables. (C even
requires you to do it twice. Zzzz).
How many Lingo programmers use the same variable to hold strings one minute,
integers the next, members the next? I don't believe that would be possible
with a compiled version. It's a genuine convenience to be able to switch
types like that, or for handlers to receieve parameters of different types.
The compilation cycle itself puts a few seconds between finishing editing
your code and seeing a result. One thing I love about Director is that,
barring syntax errors which prevent 'compilation' to bytecode, the 'play'
button is always ready to go, not to mention the freedom you get when debugging.
What might be more useful would be an equivalent of the old 'CompileIt'
application that used to be available for Hypercard. You'd take a hypertalk
script - a function, say, run it through 'CompileIt' and get an XFCN out the
other end. (Something like an Xtra). The performance of these compiled
modules, while slower than something made carefully in C or (ha) assembler,
was far better than hypertalk alone, and of course, you had to be quite
strict about your types, but it was a good middle way.
The mandelbrot example is a typical situation where you would never find a
commercial Xtra to do that one job, but is just too slow to run in Lingo.
Rather than compiling *all* the Lingo in a project, it would be more useful
to isolate some hotspots (such as the number-crunching repeat loops),
convert them to strictly typed functions, and then compile them. It often
turns out that the hotspots tend to be those parts of a program which are
best suited to compilation. None of the datatypes in the mandelbrot example
are changing. There's no runtime evaluation of strings. It really ought to
be native compiled binaries.
It can be interesting to look at the way this issue has been treated in LISP
implementations. LISP, like Lingo, runs in an interpreter, is loosely typed,
and has a reputation for being slow. LISP is usually 'written in itself',
with only the lowest level routines constructed in assembler. Eventually,
someone realised that some of the essential functions made in LISP could be
compiled to native machine code. Now, any decent LISP implementation also
features a compiler, and the core routines are all compiled. (I believe the
compiler also caches the source of each compiled function, so you can always
go back and edit it). Once you've compiled a function, you can't, for
example, pass it by value, and all the types are 'set in stone', but it
retains the advantages of rapid development, with the option of high
performance where it's needed.
Example: Have a look at the platform game 'Abuse'. It's a LISP program, and
if you're smart, you can even get at the source code of the higher level
routines. All the pixel blitting and collision detection stuff is compiled
to binary, and it's certainly fast enough, but stuff like configuration of
the levels, and AI remains interpreted, because it makes good sense for them
to be so.
I'm convinced this is the way forward for Director.
--
_____________
Brennan
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
