/* */ /* */

Monday, October 1, 2012

The Projucer

A lot of uninvited stuff shows up in my electronic mailbox. There's spam, sure, plus my share of links, stories, and pictures from friends and family members who are more easily entertained than I am.  I also get questions and comments and links to C++- and software-related things people think---or hope---I might be interested in. I skip a lot of the "entertainment" I get from friends and family (none of whom read this blog, so I'm not worried about offending them), but in the realm of C++, I look at everything I get, because it's part of my job as a C++ consultant. Most of the stuff I see I dismiss without action, because I don't think it's interesting or I don't see how it's useful or I simply don't have time to really analyze and pursue it.  There are, after all, only so many hours in a day.

Julian Storer
(unless he's using
a picture of
somebody else)
Every once in a while, something piques my interest, and not always for the reason the sender imagines.  Such was the case about three weeks ago, when I got a message from Julian Storer. He wrote (with minor editing and link addition on my part):
For the last decade I've been running a big C++ cross-platform toolkit called JUCE. Won't attempt to describe it in this email - there's plenty of info about it on my website if you want to learn more.

I've just been making some announcements about a new tool that I'm aiming to release soon, and being proud of what I've managed to cook-up, I thought it'd be worth pestering some of my C++ guru heros to have a look at it. It's something that nobody's managed to do in C++ before, so I think you'll probably find it interesting!

The TL;DR is: I've built an IDE that uses Clang and the LLVM JIT engine to provide real-time interactive execution of C++ GUI code, and to allow GUI editing by automatic refactoring of user-code... Hard to sum it up in a sentence, but if you saw the Bret Victor demo that everyone was talking about a few months ago, you'll get the gist - he
was showing off interactive javascript, and I've managed to do the same trick in C++.

Hope you can spare 10 mins to check it out!
I did check it out, and not just because he called me a C++ guru hero. Though I had not watched all of  Bret Victor's demo, I had watched part of it, so I had some idea what was involved, and the idea that something similar could be done for C++ intrigued me.  Also, when people tell me they have done something in C++ that nobody has done before, that tends to catch my attention. Most important, at the time I was trying to figure out what to do with Julian's email, I had much more pressing things to work on that I didn't want to attack yet, so I needed a way to tell myself I was working without actually, you know, working.  So I toddled over to the screencast Julian had put together and invested the six minutes and thirty-six seconds it runs.

It's a nifty demo, but the application area is GUI development, and that's not really an area I know a lot about.  So when he ran the GUI from the compiled application, changed the application source code, then showed how the GUI updated itself, I was impressed with what must be happening behind the scenes, but I didn't have to hold onto my hat, nor was I concerned that my socks would be knocked off.  And when he modified the running GUI and some literals changed in the source code, I thought it was, well, nice. But then I saw something that made me replay that part of the video several times.  Not only did the literals in the source code change when he moved a GUI widget around, he was also able to have new statements added to the source code by interactively editing the running GUI.  He was editing the program source code through the GUI.

Maybe this is old news.  Maybe Visual Studio and Eclipse and various other IDEs for GUI development allow you to create and edit source code via both text (traditional source code) and generated GUI (arguably an alternative form of source code).  As I said, I'm not a GUI development guy, so I have no idea what the state of the art in this area is.  What I do know is that Julian's demo is consistent with the idea that there is no such thing as canonical source code.  C++ text is source code, of course, but there's no reason that the GUI generated from that source code can't be viewed as source code, too.  Since they're both source code, it makes sense that the underlying program can be edited through either.  One could argue that each representation of the program (C++ text and displayed GUI) is simply a view of that program, and the program itself is something more fundamental--something more abstract that transcends the concrete syntax and semantics of whatever view is used to see and manipulate it.

I'd like to believe that this is a reasonable argument, because, in essence, this was the topic of my PhD research many years ago.  My dissertation, Representing Software Systems in Multiple-View Development Environments, explored how one could represent programs such that they could be viewed and edited through any of a variety of concrete syntaxes ("programming languages").  Let me save you the trouble of reading my dissertation by summarizing my conclusion: It's hard.

I'm guessing that Julian was not expecting that his demo would remind me of the research I was pursuing over 20 years ago, but it did.  And that's why I'm blogging about it. Besides, as far as I know, he has done something in C++ that nobody has done before, and groundbreakers like that deserve encouragement. If you're wise in the ways of GUI development with C++, I encourage you to watch Julian's screencast and offer him feedback to help him continue his work.  I'm sure he'd be pleased to hear from you.

Scott

7 comments:

Matt said...

Although not related to GUI, some automatic refactoring features of the SublimeClang plugin seem somewhat related / of interest:
Clang compiles C++ as you edit in Sublime Text 2. Now, if we could only get the best of two worlds :-)

White Wolf said...

The demo of that Sublime+Clang is not really convincing - yeah, it does compile it but it does not use that info for anything but displaying error messages. The real deal would be intelligent editing, where typing that '2' there would realize it is renaming of that class and do that on a codebase. I don't say it is easy to do... :)

White Wolf said...

To be on-topic also: my dream would be a language that could be used to describe solutions to problems and then apply those to specific languages/platforms. Starter step would be a standard C++ front-end in which one could write "clean code" that could then be "compiled" into the usual obfuscated C++ that one sees in power tools such as Boost. (workarounds etc.)

Jules said...

Thanks for the write-up, Scott!

Re: whether any other IDEs are doing anything similar: AFAIK all the existing GUI tools involve some kind of metadata document that describes the layout. Some will generate source-code from this metadata, or embed the metadata in the source-code as special comments, but I'm not aware of anything else that attempts to do the round-trip from raw code->layout->code.

Really interesting to see the parallels with your dissertation, and to think about the problem in terms of different kinds of views of an underlying program.. In fact, my longer-term goals are to make the projucer more versatile than just being a neat GUI editor, and to allow users to extend it by writing their own custom editors for manipulating code in any way they want.

The way that it works is that everything that happens inside the floating GUI editor window is performed by code that has been dynamically compiled and is running in the JIT. The IDE compiles the user's code, mixes in some GUI editor classes, opens a window, and just leaves the editor code to do its thing in there. The IDE also provides an API for the editor to use when it wants to refactor some source-code or request details about the program structure from Clang. Although initially my focus is to get it running as a GUI editor, there's actually no reason why the editor code itself couldn't be customised at runtime to do provide any kind of view.

For example: a large proportion of the JUCE users are in the audio industry, so I'd expect there to be some interest in using this trick to build an editor that can dynamically manipulate audio synthesis algorithms while playing them.

Matt said...

@WW: Oh yeah, I'd definitely love that kind of support, too! :-)

BTW, one more project that springs to mind in this context is Runtime-Compiled C++ -- although I'm not sure what's the progress / current status there.

Scott Meyers said...

@Jules: I think this will be just one of many very interesting projects that will end up being built on Clang and LLVM. I think that platform looks to be a boon for C++ developers.

Doug Binks said...

@Matt - thanks for mentioning Runtime Compiled C++ here as an example project for runtime editing of running C++ code. We started the project mainly aiming it at game developers where rapid iteration is key to success, but GUIs are another area where I've found it excels.

I'm currently porting the code to Mac OS X, and from there to Linux so if you're not developing for Windows there should be a version to try out in the coming months.

For those interested in LLVM and Clang for runtime compilation, you might want to take a look at Cling.