IBM Japan has been researching a new development paradigm based on cards, sheets and fields. Called ADIEU, the work-in-progress has recently been pre-released on IBM's AlphaWorks website with preliminary documentation.
ADIEU aims to help non-programmers develop websites without writing code. It is a Java server application and runs on either IBM Websphere or Apache Tomcat. (Not everything previewed on Alphaworks ends up in a product but it is a useful, and free, source of inspiration.)
To evaluate ADIEU 0.8, I ran IT against Apache Tomcat using an Apache Derby database. Installation is straightforward for those familiar with Tomcat, which is good news as the installation documentation is pretty irrelevant — it contains detailed notes on IBM Websphere configuration, together with Japanese screenshots in the English installation guide.
Once the installation is complete, all admin and development is undertaken using a browser, but at the moment the only supported browser is IE6. However, a reasonable drag-and-drop environment is provided within the browser, featuring both trace and step-debugging mode.
Step-debugging is not quite what is expected, however, as there is no real source code, apart from one-line expressions within cards. Instead, step-debugging and tracing is done at a card level. The use of cards instead of code should work fine when it comes to dealing with smaller problems, but I suspect complexity issues will arise once too many cards are in play.
Several of the cards mimic simple programming statements, such as "if", "case", "repeat" and "while". Other cards are more complex, standing for "web page", "web service" and "XML file" etcetera. Effectively, the cards have public properties that act as output for one card and input for another. This allows the user to perform dependency-chaining and works in a similar way to how a spreadsheet does. This is part of the cards' default-event model and ensures all views of the data stay up-to-date.
The applications can be broken down into a number of sheets, and the default mechanism for re-using code, in the form of subroutines, is to expose the top level of the re-usable asset as a web service.
The vast majority of business applications involve moving data from A to B, with intermediate validation and transformation. As such, the structure of some of the cards with input/control/output seems to be well-designed from the point of view of ease of use by developers not trained as programmers. For example, developing a "hello world" is a simple as dragging a web-page card onto a worksheet, entering "hello world" in the output panel and then running the "world".
However, on the downside, the persistence interface is pretty clunky. It mirrors the relational database, with "transaction" cards, "insert" cards, "drop table" cards and so on. The complete absence of any sort of data dictionary to hold default captions, relationships and standard validations also rather detracts from the company's claim that ADIEU can be used by end-users.
In its current form, the project falls between two stools: it is too complex for end-users but is too restrictive for professional developers. But, as this is still only version 0.8, there is time to fix it. My wish list for improvements would include a stronger and more graphical data dictionary across the persistence layer and the ability to zoom a worksheet to aid in handling increased complexity.
But, on the upside, the software is free and available for download.