Friday, April 12, 2013

Programming For Non-Programmers : No Silver Bullets, No Free Lunches.

Programmers tend to be fond of these aphorisms:

  • There Ain't No Such Thing As A Free Lunch (TANSTAAFL) -- Robert Heinlein
  • There Are No Silver Bullets -- Fred Brooks
But leaving aside our cynicism for a while, we also like to imagine local violations of these general-relativity-principles, and one of those areas of perennial optimism is the Programming Language for Non-Programmers.   That was, if you remember far enough back, the impetus for COBOL,  for the Fourth Generation Language (4GL) idea, for tools like PowerBuilder, and Visual Basic, and even, to a certain extent, for Delphi itself.  It resulted in some horrific syntactical nightmares, like AppleScript.

Where Delphi differs from the typical "tools used by people who write code who are not primarily programmers" is that Delphi offers a programming language with elegance, sophistication, and expressive power, that is not broken or hobbled by its syntax.  Not so with just about everything else in that list.   

However, it's time for people to try again, and the newest attempt I've see at "programming for everybody", is called LiveCode, from RunRev.  Go download it now, I'll wait.

What's great about LiveCode? A few things:

  • The core product is free, and is supported by revenues from their tutorial videos (LiveCode Academy) as well as from their sales and support for their premium product.
  • It's cross platform, on Windows, Linux, mobile, and Mac, in fact, it claims to support all the platforms that Delphi still has on the distant future roadmap.
What's not so great about LiveCode?   Well, if you remember back in the good old Borland TurboPascal days, one of the things they did was give you a language introduction in a book, like this:

Inside was a systematic, carefully laid out, and orderly presentation of core concepts, like this:

After a few pages, you begin to grasp a few concepts which you can use over and over again throughout your working life with Pascal.  That's another way of saying that Pascal syntax is orderly, does not try to be english, but is nevertheless readable, and the language is orthogonal to the task it performs.  Now let's look at how coding works in liveCode.  You drop a button and an edit box on a form.  Score for LiveCode is good so far.  You don't need a PhD or a tutorial video to figure out how to use it.  So far, it's as friendly as Visual Basic, C#, and Delphi, and far friendlier than Java.

Double clicking on the Button does not do what it should do. I invoke Visual Basic, Delphi, and C# as three common environments that know what's what. When you double click a button, you should immediately be given the coding context where you will write what happens when the button is pressed.  Instead you have to locate the properties-inspector analog, and find a button that looks like a CD player Play button, and click that and then click Edit Script:

Now we get the code window:

I'm rather proud of myself. It only took me 20 minutes to figure out that the way to set A = B is:

   put "Test2" into Field "Field1"

Let's unpack the concepts here for pedagogical types:

1.  LiveCode owes a debt most of all to 4GLs, AppleScript and HyperCard, and borrows some good ideas from all three.
2.  Put is one of the ways of writing assignments.
3.  The value that is put into something else is the first thing you write. This is backwards to most of us, who learned BASIC,  which has LET A = 5, which has always made perfect sense to me.  Instead we PUT 5 INTO A in this language.  Already, that's too much typing for me.
4. Next let's note that a field has a name "Field1" and that it is a Field, and that unlike a Delphi edit box named Edit1,  we must refer to it always as Field "Field1", not as just Field1.  

I managed to type a few malformed versions of that above line of code that froze the IDE completely, requiring me to Force Quit (end task), like this one:

put "Test" into Field "Field" to "thing"

The above statement passes the grammar-checker in LiveCode, and then goes into the internal works, and does something that wreaks havoc with the internals.  That, my friends, is the steep cliff that all "friendly" languages have lurking at all times.  Designing a grammar is a difficult task, and designing your own language leads to all manner of quirks.   

The lifecycle of these technologies, it seems to me is, well known, and is documented in various places and by various names, most famously as the Hype Cycle:

Am I saying that LiveCode is unimportant? No, far from it. I'm deeply impressed by the author's goal, and I, like them, dream of being able to teach 8 year olds to make video games, or do whatever else they want to do, in a language free of accidental complexity. But I disagree that emulating english with all its ambiguities is the way to do it.  I think that something more like Python is close to ideal for teaching programming. Nevertheless,  Python lacks a true Delphi-style RAD IDE.

There is a very delphi-like free and open source IDE out there that has enough of the basic Delphi IDE features, and enough power in the backing compiler to be most of what I want, but I still think Pascal is not as friendly as it could be, and so I have some hope still for LiveCode.  Since it's open source, I've been wondering if I could hack a bit on their language choices, and try to do things like this:

  • Let users pick items and combine them using menus and toolbars that will result in code templates being generated, for common tasks like variable declarations and assignment, looping, and conditional checks.
  • Let users write in a simple declarative style without line-noise or overhead:
       Field1 = "test"
  • When users type something that is not understood, provide some kind of interactive help that helps them navigate their way out of the mess or confusion they are in.

Anyways, as an inveterate tinkerer, this gets top marks from me just for existing, and for being open source. (The code is all on github.) Check it out.

Update: I found a pretty nice open courseware (training) program here.  I have to admit, that what I said above about the concepts of the Delphi language being pretty, while that may not apply to the LiveCode language, which is an ugly duckling in the same family as HyperCard/AppleScript, but its parts/components style of visual composition of elements to build software, like the images of "lego blocks" in the training course I linked to, is a compelling way to introduce the construction of software systems to non-programmers.  Score another point for LiveCode.

Update 2: I forgot to mention two of LiveCode's ugliest warts.  The first ugly wart is that live-code stores its applications in a binary ".livecode"  file that you can't use version control with.  That means anybody who works with it is basically working without version control.   The second ugly fact is that it is not completely working with Unicode and UTF8.  There are many open issues with people using languages like Arabic (Right to Left Input, etc), and who cannot get dialogs to contain unicode data.
I think the most important change that LiveCode needs to make is to move to using a .livecode named folder, containing auto-named content files which are JSON format, and can thus be cleanly version controlled.  Even image-based development environments like Smalltalk have their own version control systems that work inside the image (letting you commit and revert, and check in and out right from inside smalltalk) but LiveCode does not. No version control in 2013? That's crappy.


  1. I have use RunRev (before it became LiveCode) and it compiles to native executes on all platforms (Win/Linux/Mac) without one requiring to fumble with SDKs and their setups, etc.

    I will download the OS version and check it out.

    In fact LC is also opening up a new micro market for component writers.

    Finally someone has already built a detailed SDK in FPC to help component writers in creating native components for LC.

  2. Hi Warren,

    I've been using Delphi since version 1, and years before that wrote my first commercial item of software in Turbo Pascal v5.0.

    I still write in Delphi, but only for maintenance of existing projects. All my new projects are written in LiveCode. As much as I love the elegance of Object Pascal and the beauty of the Pascal language that Niklaus Wirth gave us, let me tell you why I switched to LiveCode.

    Back in 2008 my clients started asking for an OS X version of one of my software applications. Actually they had been asking for years, but I kept putting them off, hoping that Delphi would support OS X soon. (At that time Lazarus was not as advanced as it is today.)

    Not being able to wait any longer, I evaluated cross-platform languages and tools and came across LiveCode. (Then named Revolution, an awful hyperbolic name.)

    To cut a long story short, LiveCode did what I needed. Despite the sometimes "for kids" image of LiveCode, my over 100,000 line (definitely not trivial) Delphi application was ported to LiveCode in under 30,000 lines. I now have satisfied customers using it on both PC and Mac, and I could not be more pleased with LiveCode.

    True, the LiveCode language will not win an award for elegance or academic rigour, but that does not stop it from being a great piece of kit. Forget the problems with the language, it is the cross-platform technology that compensates for any weakness in the syntax.

    What other tool lets you use the same code on a web server, in an app for a mobile device (Android and iOS), and on the desktop (Linux, OS X and Windows); without requiring the learning of disparate languages and separate libraries and environments? And before you say Java, does not require a separate runtime environment.

    And most importantly, let you do it today!


    1. Scott,

      Does LC compile executable directly in Mac OS X or do we need to fumble with XCode to compile the app?

      Thanks in advance.

      Yogi Yang

    2. As far as I can see, LC is an interpreter and the IDE and Runtime are just different builds of the same basic application. So you are more or less writing and distributing scripts with the runtime, rather than compiling an executable. However you can package up the runtime inside a native bundle so it looks like a real app. Another quirk is that due to the live nature of the system, your "test data" (everything you input into the program that would not normally persist in delphi unless you wrote code to persist it) persists naturally. So when redistributing apps you need to make sure to clear out your test data.


    3. >What other tool lets you use the same code on a web server, in an app for a mobile
      >device (Android and iOS), and on the desktop (Linux, OS X and Windows); without
      >requiring the learning of disparate languages and separate libraries and >environments?
      >And before you say Java, does not require a separate runtime environment.

      That last condition seems somewhat arbitrary. I was going to answer "python" though, not Java.

      I don't know why people are knocking the language syntax.

      put word 3 to 6 of “The quick brown fox jumped over the lazy dog.” into theVariable

      is absolutely awesome. Delphi would need to create a tstringlist and then copy out items 3 through 6 with a loop or with XE3 use the split helper into a TArray and then use a loop to get items 3 through 6. Python can do it in one line, but it's not as pretty (using two so it fits though):

      sentence = "The quick brown fox jumped over the lazy dog."

      theVariable = [word for count, word in enumerate(sentence.split(' '), 1) if 3 <= count <= 6]

      LiveCode is a descendent of HyperCard, considered by many the most easy to read code that ever existed. Contrary to Warren's feelings, I don't consider this a "horror"; I consider it opening up programming to everyone, and as you point out, it's still much less verbose than Delphi. I believe this is a fantastic product and a wonderful heir to the HyperCard ideal.

    4. I can see what you mean about text processing, at least for some simple cases. That's very nice, but what do you tell a user who can't handle "words" in their native language because they aren't using english latin alphabets separated by english/latin/ansi spaces?

      What I'm saying is that it's FANTASTIC that this opens up programming to more people, and it's wonderful that they've decided to take a swing at accidental complexity. Look at how much noise a Java program has just to do a hello-world app, for instance. And Delphi is closer to Java than Python as far as the amount of boilerplate it needs.

      My view is that Python is nearly ideal for teaching people to program, contains no artificial english-like structures that will get you only so far (your words from sentences example is a perfect example of a capability that will awaken the user's desire to do more with it than it can possibly fulfill). What LiveCode has that I think will rescue it from most of its deficiencies is that it is now open source.

      If I want to build a version control system for it, I can. WOW. That's cool.


    5. This comment has been removed by the author.

    6. Hi Yogi,

      Development for Mac OS X does not use XCode in any way.

      Coming from many years of Delphi, I am most comfortable with the Windows Environment. So when creating desktop applications for the Mac, I do all the coding on Windows, and then turn on an option in the LiveCode IDE that targets OS X for the build. I then open the file on my MacBook Pro and do the build and test there. You do need Mac hardware for the final build (this is to give the executable the necessary file permissions for OS X to recognise it as a program), but you don't need XCode.

      For iOS mobile development you do need XCode, but LiveCode handles all the settings, so there is no XCode fumbling.

    7. Ok that is good.

      I am quite used to RealBasic when it comes to developing apps for multiple OSs. And I have to say RB works like a charm when it comes to coding in one OS and compiling for other OS.

      As I have noted previously I have used windows version of RunRev Revolution before it became LC, but not after that one single project that we had to do and maintain.

      At that time Revolution was compiling a true native Windows executable if I remember properly. But now Warren is saying that it needs a runtime in LC. So does this mean now LC is an interpreter which requires a runtime?

      Thanks for your feedback

  3. Thanks Scott. The fact that you have a useful piece of software in production using LiveCode is a testament to its capabilities. Are you using any SQL database with your application? Im curious of people make line-of-business database-SQL apps with LiveCode. I encountered "Revolution" when that was its name, and found it a lot less promising than the current Open Source version which seems to me to be an incredibly good idea, and I wish RunRev and all LiveCode community members best of luck and will probably try to help them out a bit by contributing some new open source bits.


  4. The application referred in my story was not SQL based, but since then I have produced a LiveCode application that uses MySQL for storage and runs from a Linux server. LiveCode is no Silver Bullet, but it is more powerful than first appears, and works for me. The cross-platform flexibility is key for my purposes.

    At there is a growing compilation of what people are doing with it.

    If you have plans for contributing code that would be great, and it will be interesting to see the direction if LiveCode once Open Source contributions start to flow.


  5. My eyes just saw this and then I stopped reading:

    "The first ugly wart is that live-code stores its applications in a binary ".livecode" file that you can't use version control with. That means anybody who works with it is basically working without version control. The second ugly fact is that it is not completely working with Unicode and UTF8"

    This is not acceptable in any development language/environment, under any circumstances. Period. Unicode support may not be important for many users, but no version control? Let me know when they get thses fixed and maybe I will take another look.

    1. How long was it until there was any official version control support in Delphi? :-)

      >Version control is currently a hot topic of discussion. I've got a version control
      >stack posted to revonline, and it's incorporated into the glx2 plugin if you want to
      >use that as your script editor. As far as version control being built into the IDE, >no, not yet. You can archive the stack itself, of course, but currently git only sees
      >it as a binary object. But stay tuned - things are happening fast.

      This was the way things stood with Delphi for the longest time as well (and honestly it's not much better).

    2. Alcade you are totally missing the point. I give no thought to live code having IDE base version control. It's the very fact that live code has no source code text files at all. That was a dumb choice on their end when Json based or XML based approaches were available. The .livecode file format cannot be diff'd, merged or incrementally version controlled. I suppose you could use visual source safe and a single locked binary file. You see? Hell.

  6. > I think that something more like Python is close to ideal for teaching programming.
    >Nevertheless, Python lacks a true Delphi-style RAD IDE.

    Isn't one of the advantages of python though that (unlike Java, which would be unusable without one) python doesn't *need* an IDE? It "fits into mindspace", as Eric S. Raymond put it. Someone else said that it's the only language you really can write code in on the back of a napkin.

    That said, there are lots of open source and commercial options if one wants a Delphi-style IDE (although that might lead to the temptation to continue to develop Pascal-style even when using Python).

    You have Eric...

    Eclipse with PyDev...


    The commercial Komodo...


    ...or WingWare:

    For more math/science oriented work you have Spyder...

    ...or the incredible Sage:

    You also have iPython which can run in a browser, integrate images and video, embed interactive charting, etc.

    You could ask the question the other way though... with no interpreter, obsessively strict typing, single pass compiler requiring extra verbosity... does Delphi really have a RAD language by 2013 standards vs. 1995 standards? After looking at what's available today, it seems that quite some time ago Delphi seemed to shift focus more towards enterprise development and away from its RAD roots. That LiveCode could be English-like yet still result in a 70% LOC reduction for Mr. McDonald would seem to testify to that. Many Delphi developers today still seem to be obsessed with EXE size, avoiding runtime libraries and splitting hairs with performance, while RAD is supposed to be about quick, flexible development in the face of changing requirements. Sadly, I think there are several languages today that can run circles around Delphi in terms of total development time; LiveCode looks to be the latest one.

  7. Hi alcalde,

    Python is good. But after evaluating it, I wasn't convinced that it was the best solution for closed source applications that ideally won't require any tech support for the install.

    Perhaps the situation has changed, but LiveCode seemed best for producing a single executable/bundle that would "just work" on PC and Mac.


  8. Warren,

    >That's very nice, but what do you tell a user who
    >can't handle "words" in their native language because
    >they aren't using english latin alphabets separated
    >by english/latin/ansi spaces?

    I've occasionally told them that it's time to admit the Romans conquered the world so to just give up their dots and squiggly lines, but that's not very popular. :-)

    Honestly, though, I hope the Unicode situation improves and with the core product going open source that might accelerate closing all of these holes in otherwise what looks like a fantastic package.

    >Look at how much noise a Java program has just to do
    >a hello-world app, for instance. And Delphi is closer
    >to Java than Python as far as the amount of
    >boilerplate it needs.
    >My view is that Python is nearly ideal for teaching
    >people to program, contains no artificial
    >english-like structures that will get you only so far >your words from sentences example is a perfect
    >example of a capability that will awaken the user's >desire to do more with it than it can possibly

    As a Delphi user since 1995 who very recently discovered Python, I'm not going to argue that with you at all. In fact, I've taken to thinking of it as the new Turbo Pascal - cheap (free), easy to learn, a huge amount of learning material available for it (much also free), yet also powerful and capable of producing commercial products. Paired with a $25 or $35 Raspberry Pi (python is the official language of the Pi) it's quite an amazing learning bundle for beginners, even children.

    That said, some of the syntax LiveCode uses for text processing seems so intuitive and powerful it has my mind racing trying to think how it could be implemented as a python library. :-)

    >If I want to build a version control system for it, I
    >can. WOW. That's cool.

    Definitely. I've had the open source epiphany not too long ago too... in fact, all the software I'm using right now is open source. :-)

    You might find this article interesting...
    "Why Hypercard Had To Die"

    Unlike you, he felt the original Hypercard was something amazing... too amazing.

    "HyperCard is an echo of a different world. One where the distinction between the 'use' and 'programming' of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place....
    And all [present alternatives to HyperCard] are failures for the same reason: they insist on being more capable, more complexity-laden than HyperCard. And thus, none of them can readily substitute for it."

    It's an interesting case, especially given the timeframe and how far ahead of its time it appears to have been.