Wouldn't it be cool if you could create a program without having to write any code? And, wouldn't it be cool if your program could run under Linux, Mac, Windows, Android, Windows Phone 7, iPhone and Flash? It would be very cool, and with Illumination Software Creator from Radical Breeze (radicalbreeze.com), you can do exactly that.

Illumination Software Creator (ISC) is a graphical IDE that allows you to drag code blocks and connect them in order to create an application program. Figure 1 shows what the user interface looks like. It's pretty straightforward. To create a program, you simply drag code blocks onto the canvas and configure the block. Then, you connect outputs to inputs. The code blocks are categorized to make them easy to find. Clicking on a code block allows you to set various parameters for the given block. Variables, which appear in the lower-left panel, come in three types: text, number and text file.

Figure 1. Illumination Software Creator's User Interface

Once an application program has been created with ISC, it can be targeted toward any of the architectures mentioned previously.

By default, ISC creates a program targeted toward a Python/GTK environment. This is the most feature-full target and allows programs developed with ISC to run on Linux, Mac and Windows. This target allows windows to have various dimensions and supports file I/O and shell script access where available on the host system.

The Android target creates an Android project, with complete Java source code, suitable for importation into the Eclipse IDE. As I'm not a regular Eclipse user, I had some difficulty getting the Android SDK properly configured. However, I was able to look at the Java code that ISC produced and then get the Android phone emulator working. I'm sure that a regular Eclipse user would be up and running in a matter of minutes, once the software was downloaded.

On the other hand, the iPhone target creates an iPhone project with native Objective C source code. However, because of Apple's licensing policies, this project directory has to be moved to actual Apple Macintosh hardware for compilation and linking against the Apple SDK.

Finally, the Flash/Flex target produces a directory that contains an .swf file as well as an HTML file that embeds the Flash object. The command-line Flash player, swfdec-player, ran my test applications without error, subject to the limitations of the Flash architecture. For example, Flash doesn't support file I/O, so my application's attempt to open a file selection window silently failed. However, the example Flash applications ran flawlessly in my Web browser.

As you can see, re-targeting ISC causes it to produce native code for the given target as opposed to simply linking against a proprietary runtime environment. Also, applications produced with ISC should run identically on whichever target they are deployed. Each code block, though written in different languages, produces identical results on each target. However, application windows you create with ISC default to a size appropriate for each target architecture; this prevents large windows from being clipped on mobile devices smaller screens. You could think of this as object-oriented programming on steroids—not only is the actual implementation of a code block encapsulated, but the target architecture is as well.

So far, I've been talking about code blocks in fairly generic terms. So what kinds of blocks do you have to work with? Of course, the most important block is the Window block. This block creates an application window in which you can put buttons, labels, form fields and text fields. This block essentially creates the “face” of your application. You can create as many windows as you need and open and close them according to your application's needs. You also can create message boxes and confirmation boxes. Additionally, there are blocks that allow you to get and set the value of the various window controls.

The native text manipulation blocks are fairly limited. There are concatenation, search and replace blocks, as well as blocks to convert to uppercase and lowercase. This was a surprising weakness in ISC, but one that can be worked around, as I show later.

Rather than a generalized numerical expression evaluator, ISC provides blocks that implement individual arithmetical operators. Here, you'll find add, subtract, multiply, divide and remainder. You'll also find a block that provides a random number in a given range. I am, however, talking about integer arithmetic, with all of the inherent limitations. That said, practical program applications were written long before the advent of floating-point processors.

There are but two logic blocks in ISC: the if/then/else block and a simple do/while block. As limiting as that may sound, these two blocks should be sufficient to implement just about any algorithm I can imagine. However, these blocks would be much more powerful if ISC had an expression evaluation capability.

ISC is what could be referred to as a “strongly typed” environment. Number variables must be converted explicitly to a text format before they can be used in string operations and vice versa. This makes some sense given that the underlying variable implementation has to work identically in a Python, Java and Objective C environment.

The Run Shell Script code block allows an application to run a local shell script on architectures that have an underlying shell interpreter. In practical terms, this means Linux and Windows. This opens up the possibility of simply forgetting about the cross-platform capabilities in ISC and using ISC merely to put a friendly face in front of an otherwise esoteric shell script. I'm told that many of ISC's users are system administrators who use ISC to create user-friendly system administration tools for use by other staff members.

Since many of ISC's target architectures don't support file I/O at all, ISC's advertised file capabilities are fairly limited. You're able to create file open and file save dialog boxes. However, reading and writing files is on an entire-file-at-a-time basis. Essentially, you read the file, process it and write it back out. Of course, none of this works at all on targets like Flash that don't support accessing local files.

Earlier, I mentioned that many of ISC's limitations could be worked around or mitigated, and that's where the custom code block comes in. Take a look at Figure 2. Here you see the custom code block definition screen. This is how ISC users create new types of code blocks. Starting from the upper left-hand corner and working down, notice that you can name and categorize a new code block. Then, you have to chose a target for the block, and this is where it gets interesting. You actually can implement the same code block for each target architecture you intend to support. So, if you intended to support only the Python environment, you'd need to write out only the code block in Python. However, if you wanted to support other targets, you would implement your block independently for each target. This way, the same block can be used in your application, and the appropriate implementation will be used automatically. Custom blocks even can be saved out to their own files for use in other projects.

Figure 2. Custom Code Block Definition Screen

Continuing on, notice that you can define up to two “outputs” for your block. Custom blocks accept only one input, but you can define the name of that input. This actually makes some sense because the “input” isn't actually accepting any “input”. It's just a connection point. The rest of the center of the custom block definition window is where the meat is, and potentially, where the work is. This is where you write the code that actually implements the function you intend for the block. Keep in mind that you have to write code for each target architecture you intend to support, in that target's native language. As a hint as to what your code needs to look like, you are given example code for the currently selected target.

The right-hand section of the window describes up to three side effects that the block can have. Results of any calculations done in the code body can be sent to variables for use by the rest of the application. Which variables are modified is determined when you drag the resulting block onto the canvas and configure it. There doesn't seem to be any type of extensible API for modifying other variables.

So far, I've tried to point out as many limitations as I could find in ISC, but to be fair, ISC is maturing rapidly. When I set out to review this product, I received version 2.0. I found this version to be stable and usable, but it lacked the custom block feature entirely. The custom block feature appeared in version 2.2, which apparently was released a few weeks later. I've been told that version 3.0 beta 4, which will be available by the time you read this, will have many new features. There will be a rudimentary graphics capability suitable for writing games. There will be a clock timer block that “fires” periodically. But the feature I'm personally most interested in is the SOAP-based Web services client block. This will allow an ISC application to have real-time access to data and advanced functions over the Internet. These features will greatly expand the range of applications that can be created with ISC.

The fact that ISC is developing so rapidly is astounding. Consider that every code block, feature and bug fix has to be implemented identically in at least three different programming languages. Each target architecture imposes its own limitations and way of doing things. For ISC to be a useful tool at all, it also must expose as much functionality as it can that is common to every target platform. This is a truly ambitious project, and the fact that the project is only two years old is simply amazing.

Radical Breeze also is planning to host a repository of user-created blocks. By the time you read this article, you'll be able to go to this repository and download custom blocks other users have created. Based on what I read in the user forums, I would expect networking blocks and SQLite blocks to emerge pretty early. There won't be any guarantees that a given block will function on all the supported targets. But because you'll be downloading the source code for the block, missing functions and targets could be added fairly easily.

I'm told that school computer departments are one of ISC's largest users. Schools are using ISC to teach programming classes. Although I happen to be a fan of structured programming, which ISC doesn't support very well, I can see where ISC would provide a means of getting young students interested in computer programming. After all, the results of any project students write with ISC would run on their cell phones. This could be a tremendous draw, though I shudder to think about what types of applications the average high-school-aged kid might produce.

Another common usage that ISC sees is as sort of a “jump start” program to allow an organization to prototype an application quickly in a desktop environment and then port it to mobile environments without too much additional investment. Even if the company eventually moved away from ISC and onto another IDE, having had ISC automatically generate much of an application's code could shave months off a delivery date.

With just a little prior thought, a nonfunctioning Flash-based demonstration program also could be created and posted on a Web site as a sales tool. Potential customers could interact with the demonstration applet on the Web and feel confident that the program will function the same way on their mobile devices or workstations.

“There's an app for that” has been a tremendously successful marketing tool for Apple. However, I frequently find myself saying “I need an app for that”, and I don't think I'm alone. With ISC, even beginning programmers can produce useful applications and have them run on their mobile devices. Simple games and list managers are some of the first things that come to mind. But mortgage calculators and cost estimation software also would be trivial to produce with ISC. With version 3.0 beta 4 of ISC and its Web services capabilities, real-time point-of-sale and inventory-tracking applications become easy to implement on a wide variety of platforms. Having a program that behaves the same way on both a workstation and any number of mobile devices would cut down on training expenses and much of the development of a custom application could be done in-house.

When I committed to review this product, I had formed the impression that ISC would solve all of my inter-architecture development problems. Well, it doesn't, but it sure solves a lot of them. Rather than having to invest in becoming an expert on several different architectures, I can allow ISC to write much, if not all, of my code. And with a price tag of a mere $49.59, I can't see how you possibly could go wrong. ISC does what they say it will do, and it is very cool.