LiveCode: an inside perspective from the outside

On StartNewBlogPost
Answer “Hello, World!”
End StartNewBlogPost


I just finished my second year of University here in Edinburgh reading Informatics and was recently appointed to a part time software development position at LiveCode.
In the past week (which coincidentally was my first week of work in this shop), I have been tasked with doing various bugfixes, not just because this is the main item in my job description, but also because it will introduce me to both major components that make up our product: the engine, which is written in C++, and the IDE, which is written in the LiveCode language.

I would like to first share with you, the reader, my favourite bug of the week. Coincidentally, it is also the bug that will perfectly illustrate the paragraphs that are to follow it.

We had a bug where when the “undoChanged” handler of an image was set to retrieve certain attributes of that image, the entire IDE would crash. Crash bugs are usually somewhat easier to fix than “doesn’t do expected things” bugs, as the C++ IDE of your choice will nicely give you a stack trace of the crash and ideally let you explore the state of the system at the time before/of the crash. However, this one was a hard one to crack, as the connection between the stack trace and the actual cause of the crash was quite weak and the solution involved making certain design choices regarding the architecture of the code.

In a few words, let me illustrate what the problem was: the (internal) object that was in possession of control flow at one moment in time called a function that caused in further calls the deletion of that (internal) object before the method it was called from terminated, causing control flow to act on a corrupted object and a crash subsequently.

The fix for it implied adding safeguards preventing this from happening again and fixing what was an inherent bug in the design of the method that deleted the object. Anyone familiar with object oriented programming will know that getters and setters are as essential to OOP as oxygen and water are to human life due to the data abstraction concept. One of the basic rules of getters is that they should never change the internal state of the system (the peek() operation on the stack ADS is a perfect example of this). However, the buggy method violated this rule by deleting the object pointed to by a member of that class and replacing it with a different instance. As such, part of the fix was restoring the integrity of subset of the getters of that class. (Credit to Ali Lloyd and Mark Waddingham for being patient with me and helping me throughout).

I give this example as it illustrates a bug that could never occur in a LiveCode Script. By abstracting memory management away from the programmer, the programmer is able to focus on the features of his code and not on the exact implementation of those features. This is quite similar to nature one might say (though doctors lost on this page will probably contradict me on the physiological details): you don’t get to say in which neuron information is stored, or when a neuron deletes its information, it just happens.

Whilst I have only managed to scratch the surface of LiveCode, my experience with other programming languages (Java, C++ to name a couple) is much more vast. I think that puts me in a position to understand just how it compares to more traditional programming languages, and even paradigms if you wish.

You might think that because I’m now working for LiveCode, I’m biased. However, I’ve only been here a week and with my fresh eyes I would say to you: download the community version of LiveCode, play half an hour with it and I guarantee you will then agree with me.

Now I could give you an example of how all arrays are dynamic and generic in LiveCode, or how you can index them with anything you like (except other arrays) but that would miss what I think is the best feature of LiveCode. Where I think it genuinely shines are GUI’s. In my 2 years of doing C++ and Java I have always avoided doing GUI’s because, well frankly it’s a pain. I can write a basic templated dictionary in C++ in around 300 lines of code without too much of a hassle but I don’t think writing a basic GUI would take less than 1000 lines.

In a sentence, LiveCode takes that pain and turns it into a pleasure.

The LiveCode snippet at the beginning of the post creates a pop-up window that contains the text “Hello, World!”. To achieve the same in Java, one would need this


import static javax.swing.JOptionPane.showMessageDialog;

public class Main{
public static void main(String[] args){
showMessageDialog(null, "Hello, world!");
}
}

I think most people would agree that this doesn’t look anywhere near as nice as the LiveCode option, nor is it as intuitive. This is my issue with most consecrated programming languages: they are like a secret club, and if you are not fully initiated it all looks like Chinese to you. Java and Python are languages that try to address those issues by introducing a certain level of verbosity (closeness to natural language), but LiveCode takes that to the next level.

Had you asked me one month ago what language I would use to create an iOS App, I would have said C# via Xamarin or begrudgingly Swift (god bless the souls who still use Objective-C to develop new apps) . Ask me the same question now, and it won’t take a heartbeat for me to say LiveCode.

Am I saying: drop every other programming language and go learn LiveCode? Not quite: there still are tasks where using C/C++, Java or other, more traditional programming languages still makes the most sense, but LiveCode is fighting its way through the Fight Club of programming languages to becoming the King of apps, and I reckon it’ll get there faster than people think. If you don’t agree, look at what’s happening with Android and Kotlin. The world is moving towards more “natural” programming languages if I can call them that, and LiveCode is for sure a part of that revolution.

If you think about NLP’s raison d’etre you will soon come to the conclusion that advancements in NLP will inadvertently trickle down into programming languages. LiveCode provides a glimpse into that future, by showing us just how close programming languages can be pushed towards natural language at this moment.

Moreover, LiveCode does something that the industry has mainly forbidden people to do for too much time: it lets them explore their creativity and follow their ideas; or to put it in a sentence:

LiveCode is the tool that will allow most people to transform their dream into reality.

I would like to end this blog post on slightly funny note: I have drawn up some metaphors for how LiveCode compares to other languages in my personal opinion.

C++ is like a jet fighter: it’s incredibly fast and you can turn and twist it how you wish. However, the slightest mistake will kill you and possibly cause collateral casualties oh and did I mention you have no parachute. This is why only a very small subset of pilots can fly them.

LiveCode is like the Dreamliner: it’s modern, gets the job done, it looks fabulous and it does most of the work for you.

C++ is like a BMW M5: it’s blazing fast, it has tradition, it’s becoming ultra-modern, however it is rear wheel drive and just when you think you’ve got the hang of driving it your tail slips and it kills you.

LiveCode is like a Mercedes S-Class: it is elegant, refined and you can do with it almost anything you wish without having the fear of proverbial death lying next to you.