In at the deep end !

Say I want to make a new computer program, or a new app for my smartphone.  I launch a single application called LiveCode, quite like launching a text processor to write a letter.  Then I begin to create things within a new LiveCode document, the app:

I happen to use OSX, but LiveCode runs equally well on Windows or Linux.

At the left you see a palette of objects and tools, at the right is the newly created app's window.  I dragged a text field from the tools palette and a button that still carries the generic name "Button".  I am in the process of drawing a polygon to the right of the text field.  I have not yet written any code to make any of these objects do anything.

I will save my work to a LiveCode file.  That file is not an app.  It is not a directory full of files and subdirectories.  It is just a single file containing everything about my LiveCode program:  the objects I created, the positions and other properties they have, and ultimately the code that will tell them what to do.

Fork in the road?

Once I have saved my work to a file, I can choose between two things:

• use that file to run the app and use the app that way,
• make a stand-alone app from that file and maybe upload it to my smartphone.

For the first option I do not need anything extra, just the installation of LiveCode that I used to create the program.  And that is just a single program, not a huge system composed of hundreds of files and directories.  For the second option I need to tell LiveCode to create a stand-alone app.  I can give copies of it away to friends, but of course I cannot change the stand-alone file anymore.  Any modifications will need the LiveCode file again.

This is much like the difference between the letter in a text processing file that you can still work on and a version of the same letter saved in pdf format.

What IS LiveCode?

Is it a Software Development Kit (SDK) ?  Yes.

Is it a programming language?  Yes.

Is it an interface design tool?  Yes.

Is it a fast prototyping system?  Yes.

What then is LiveCode not?  I don't know.

I find it very difficult to explain to people what LiveCode is.  Javascript is a client-side web scripting language.  Fine.  Php is a server-side web scripting tool.  Fine.  Raspberry PI is a Linux-based microcomputer board.  Fine.  LiveCode is…  A lot of things, more difficult to convey than saying "Swiss Army knife", which would be a tempting but very bad comparison.  I can't say it in one sentence, not even in one page on the web, though I'm going to try here.

You can make real application programs with LiveCode, and they run like any other real app on your desktop, your smartphone, your tablet.  All using the same code.

Perhaps the most characterising aspect is that LiveCode attempts to place itself above the API (Application Program Interface) so that it can be platform independent.

How do I feel about it ?

To me, LiveCode is a tool to tell the computer what I want it to do:  mainly repetitive tasks, difficult things or tedious stuff.  LiveCode allows me to write an "app" fast, get the work done, and then either keep the app for future use, or throw it away.

I want to be productive.  I'm not in the business of developing apps:  I can buy most of what I need off-the-shelf:  most of the time.  And that is precisely the problem:  sometimes I need to do something for which there is no ready-made app, because it is a peculiar task or the market is not large enough for an app to sell.

LiveCode is exactly the tool for making a graphic interface and writing the code I need to handle those problems.  It lets me get a result within minutes.

LiveCode crucially lets me think about the problem:  it is so easy to produce a working app that I can concentrate on the ways I want to solve the problem or demonstrate it to someone else.  I can keep my mind on the task instead of worrying about debugging, coding, development.

LiveCode is the best way I know to adapt the machine to my needs.

Developing? Running? Debugging?

Consider these two buttons of the LiveCode interface:

The left button selects running mode, the right button selects development mode.

But I do not need to switch to make my program!  I can modify the code while the program runs.  That is why it is called "Live"Code.  Of course sometimes I do need to switch and press one of those buttons, but less often than you might think.

Even more important:  I save the program I'm writing to a LiveCode file without the need to make a stand-alone full-fledged app. I can run and use that program, and continue to tweak it or debug it, while working with it.  This is surely a very important aspect for a desktop development system.

There is no difference between running a program directly from its interface and running it as a stand-alone.

Ladies & Gentlemen: The Language!

Programming languages are generally a pain:  syntax is obscure, documentation is incomplete, weird characters are everywhere.

But look at LiveCode:

There are no strange { and } signs, no unnecessary use of parentheses, no semicolons.  There are quotes, but around names of objects and around character strings.

Most programmers, when they first see such a fragment of LiveCode, think I am showing them a comment or a design.  It takes them time to realise that it is actual code, according to a strict syntax, with a completely specified behaviour, that will be compiled and run fast.

More:

If your program runs on a mobile device, it might do things like:

And that would be nearly all you need as code for a working compass app.  By the way, look at A Compass App in LiveCode.

What do I use it for?

A few examples of apps I use very often and wrote in LiveCode:

Bank statements:

I have accounts in several banks.  The electronic statements they send me are almost by definition incompatible with each other.  To make a single list of transactions in a single format I wrote an app to convert the different bank formats to my format.

One of the banks has the nasty habit of changing their format at least once a year.  That is no problem, because LiveCode's running and developing environments are so integrated that I only need to adapt the code to the new format and never bother to freeze it into a stand-alone.

Calculate:

Years ago I found a tiny calculator that took up almost no space on the screen.  But the developer disappeared.  In an afternoon I wrote an app that does the same thing and even has some added features.  It looks like this:

Watch this space, because I will publish the entire code for it soon, and you will find a link to that here.

Application Table:

A friend in a distant country wanted to switch from Apple's Snow Leopard version of OSX to the Lion version but was unsure how it would affect her.  Rather than trying to help her by phone and not getting very far, I quickly wrote an app to list the incompatibilities she wanted to see, made it a stand-alone and sent it to her.  I could have made the app send the results to me too via ftp if desired.  The interface of that app is irrelevant but it looked like this:

Photo names:

Years ago my wife and I got into quite a mess sorting photos we took on a holiday trip.  They come out of the camera with names like IMG_0001.JPG and unless you want to trust your memorable pictures to some proprietary program or server, you want to burn the raw files to a more trustable medium such as CDROM.  I wanted the names of the photo files to give me the date and time the picture was taken, say 20080923_163056.jpeg.  To change the file names by program meant understanding where the timestamp was encoded in the jpeg file, looking at it as a binary file, getting that information out and then renaming the jpeg file.  It took far more time to understand the jpeg format than to write the app to do it all.  I saved that as a stand-alone to handle an entire folder of photos (and included folders by recursion):

Unfortunately soon after that we had a holiday on which my wife took a photo at exactly the same second as I did.  So I added the possibility to mark photos with a two-letter abbreviation of the camera that had taken them (using a photo from that camera as example).  Then one day one of us (I, of course) forgot to set the time zone.  Hence the correction buttons.  All these further refinements were very easy since I obviously kept the LiveCode file, which is only 131kB big.  Making the stand-alone app from it takes about 5 seconds and the resulting app is 3.4MB big.

Baratin:

Eat your own dog food they say.  In 1995 I decided that since I was deeply involved in the evolution of the web, I should use web technologies to make my presentations.  In other words, no "PowerPoint".  I needed two things: a set of html templates, scripts, styles for the pages to be shown on the screen, and an application to produce a list of URLs that defined the sequence in which the pages were to be shown.  The first was easy, the second required serious thinking. 

I called the app Baratin, which is French for small talk, made in order to convince.  The first version was Hypercard based, written well before LiveCode came on the scene.  The version I use now is more sophisticated and allows me to shape my presentations in unique ways.  Details will become available in a separate description devoted entirely to Baratin.  LiveCode allowed me once again to concentrate on the problem, experiment a lot, and avoid distractions from the coding process.

APR:

The last example shows how LiveCode lets you attempt software experiments you would not even consider to start in other environments.  At age two my granddaughter got very active with her Lego Duplo train set.

I confess I helped place the switches, not an easy thing to grasp at her age, but she did all the other laying of rails.  While she was busy placing little dolls in the railroad cars, it occurred to me that there were rail layouts in which certain positions could not be reached from other positions by only setting switches:  you had to pick up the train and move it to another location.  Depending on the layout, not all points were reachable from a given point.  Could I tell from just looking at the topology of the rail layout if this property was true?  I called this the All Points Reachable (APR) problem.  I did not find a simple formula, but I did almost immediately hit on an iterative computation to reach the verdict: APR or not.  Less than an hour later I had a LiveCode app that started from the definitions of the switches for an arbitrarily complex railroad layout (limited only by the number of switches), constructed a matrix, did an iterative operation on it and spewed out the result.  See the description and the program.

Conclusions

• I can concentrate on solving the problem, using my expertise in the problem field, without wasting time and effort on program development, coding and obscure programming language features.
• My apps are real apps.
• The LiveCode language is such that I can still read and understand my code long after I have written it, without the need for detailed comments.
• I do not need to make stand-alone applications:  I can run the programs in the LiveCode environment and evolve them on the fly.
• I can do the interface and the code at the same time.
• I get results in minutes, not days or weeks.
• My apps are independent of the OS.
• I have fun programming.