Looking at Lingo: Part 1

July 9, 1997
by Zac Belado

I haven't actually written a piece of Lingo code in over a month. Mostly, I've been doing Visual Basic and Java work and going back to Lingo (and working in other languages) has caused me to take a hard look at the language we all love to hate.

Things that make you pull your hair out.

For those of you that haven't had much experience with other programming languages its important to note that Lingo is what is referred to as a non-typed language. What that means is that the variables you declare do not have to be of any particular type. So, the variable that you just used to hold a string value can then be immediately used to hold a list, or a symbol, or even, and this is my favorite, a picture.

This is something that will cause your average C or Java compiler to start billowing smoke out the sides of your CPU.

Its darn useful but it also has some rather annoying penalties such as set and memory requirements that are much higher than a strongly typed language.

For the last month I haven't had to type set when I've wanted to declare or change a variable. That's because the languages I've been using have been strongly typed (and very strongly typed if you consider Java). When the compiler comes up to a variable, it already knows what it is and what it can contain because the variable has been declared ahead of time.

Take this Visual Basic code as an example:

Sub convertHex (hexChars as string) as string
dim firstChar as string
dim secondChar as string
firstchar = left (hexChars,1)
secondChar = mid (hexChar,2,1)

In the Visual Basic example you not only have to declare what the local variables are, and what type they are, but also what the data passed to the subroutine will be and what type the return value will be.

Now the equivalent Lingo method would be

on convertHex thisHex
set firstChar = char 1 of thisHex
set secondChar to char 2 of thisHex

The code is certainly simpler to read (in the short term) but it has the annoying requirement that you enter the set keyword before each variable is passed a new value. The reason for this, and this is supposition on my part, is that each time the Lingo compiler runs into a variable, it has to treat it as if it was an initial declaration (treating it as if it had never seen the variable before) and it also has to figure out what type the variable was and what type it is now going to be.

So, if you have a variable called list:

set list to [1,2,3,4,5,6]

and then you convert it to a string

set list to "my list is voided"

the compiler has to remove the one dimensional array that was holding the initial list and replace it in memory with the new string (or set a pointer to the memory area where the string is located). This new string will require much more memory than the array did.

In Visual Basic examples, if you declare an array of integers the compiler knows how much memory each entry will take and if you predefine an upper bounds for the array then it also knows exactly how much memory the entire array will require. Lingo, on the other hand, has to either declare a large amount of memory for each and every variable or hold a substantial amount of memory in reserve in case your code decides to do something interesting like change a string variable into a picture.

Certainly this can be optimized but it does require much more memory and much more finesse internally than code generated in most other systems. This is also often why the memory requirements for Lingo projects are much more substantial than an equivalent project in a language like Visual Basic.

The bright side

The counterpoint is that Lingo lets you do things that make your teeth ache in another language.

Casting a string to an integer in Java is a total pain in the ass. In Lingo it isn't even worth mentioning. Lingo also lets you do really crazy things like evaluate variables based on their names.

For instance:

set thisValue to 10
put value ("thisValue")
-- 10

Or even using symbols to speed up your code and then casting them back into strings to display the names.

set mySymbol to #this
put mySymbol
-- #this
put string (mySymbol)
-- "this"

The only equivalent I can think of is juggling pointers in Object Pascal but it isn't anywhere as easy. Or comprehensible.

But this silver lining has its price as well. Reading Lingo code is, if you haven’t written it or wrote it quite some time ago, is not unlike reading a foreign language. It is especially annoying if you have to track down what types of data a function or method requires.

Take the example provided earlier:

on convertHex thisHex

and ask yourself what thisHex is supposed to be. Is it a letter? An integer? A bitmap? A castlib? The possibilities are endless.

You don’t normally encounter these problems in Visual Basic:

Sub convertHex (hexChars as string) as string

as everything must be declared and is therefore immediately available for your reading and comprehension pleasure.

Growing up with Director

When I first started using Director I hadn’t punched any code for years. So the peculiarities of Lingo didn’t strike me as that odd or even as a hindrance (I mean if you can get used to the special assignment characters in Pascal you can get used to set). But as I begin to explore and use other programming languages some of the underpinnings of Lingo begin to chafe.

Lingo was designed as a language for non-programmers. It is still aimed at those same non-programmers. The problem now is that it is being used by programmers familiar with other languages. It has also generated an entire group of programmers who grew up with Lingo and are now reaching a higher stage of programming experience than may have been envisioned by Lingo's creators.

Going back to Lingo brought this into focus for me. It also begs the question: how can Macromedia continue to appeal to both groups, the OOP programmers and the beginners, with a single program.

Next week: one geek’s answer.

Zac Belado is a programmer, web developer and rehabilitated ex-designer based in Vancouver, British Columbia. He currently works as an Application Developer for a Vancouver software company. His primary focus is web applications built using ColdFusion. He has been involved in multimedia and web-based development, producing work for clients such as Levi Straus, Motorola and Adobe Systems. As well, he has written for the Macromedia Users Journal and been a featured speaker at the Macromedia Users Convention.