Skip to main content

ABL in a Pacific World

Printer-friendly version

Can we generate ABL from Rollbase to make ABL more “sexy”?

Corticon and OE BPM are “sexy” because they are based on visual models which are readily understood by non-programmers and those models can be rapidly modified in response to changed requirements. Data Direct Cloud is “sexy” because it provides a very simple, visual interface that allows connecting to a very large universe of potential data sources without special development. Rollbase is “sexy” because it provides an easily learned, highly productive way to build attractive web interfaces with significant functionality. While ABL is more productive than popular 3GLs, it is worth asking if there is a way to make it more “sexy” as well, especially if this would also provide the productivity gains and the rapid responsiveness we associate with Corticon and OE BPM.

There has been some mention in discussions of Pacific about producing ABL code from templates, presumably in similar fashion to what is done with Rollbase for the code it produces. I would like to suggest this is not a good avenue for development.

Back in the 1980s I was a Varnet VAR and Varnet had a template-based program generator as part of their toolset. This was not a particularly sophisticated tool, but I quickly decided that it was not worth trying to extend it. My key issue was responsiveness to change. If one changed one’s mind about how a function should be implemented or about what functionality should be provided in a particular program type one could only implement this changed requirement in the existing code by manual modification of each program, with the consequent labor and potential for error.

In response to this problem, in 1992 I developed a system called Specification-Driven Development (SDD) which used templates and specification files to generate finished programs. This system was fundamentally different from the Varnet system since one could alter a template, rerun the generator, and very, very rapidly incorporate the change in the entire relevant code base. Similarly, changes could be quickly made to the specifications in response to changed requirements and new code generated. This allowed very rapid initial development6 and even faster modification in response to changed requirements. In the years following it was not uncommon to spend significantly longer determining the specifications for a particular new piece of functionality than it took to implement.

However, the templates in SDD were very specific to the architectural model which I had at the time, i.e., ChUI and procedural. Modifying them for event-driven GUI code or AppServer separation or OERA layering would have not only meant a whole new set of templates, as well as having to recreate all the specification files as well because each specification file was closely tied to the architecture of a particular template7. Thus, I think a template-based approach for generating ABL, while more productive than hand-coding, provides a limited ability to adapt to future architectural and general functional requirements. Without regenerability, it is even more limited in its potential.

ABLinaPacificWorld.pdf68.95 KB