A better abstraction

When I graduated engineering in 1987, Fortran was still part of Engineer in Training (EIT) exam. Due to the EIT, each class in engineering had at least one computer assignment. The professor expected the program to be written in Fortran, and the engineering department provided access to a PRIME system. However by 1986 I was using business departments' 286 computers and Lotus to deliver the assignments. [A huge time saver that provided better results.] Soon after my discovery, the business department placed access controls to their computers. There were too many engineering students using business resources.

Lotus was just one of the many higher-level abstraction tools engineers eventually used in place of Fortran. By the early 1990's Fortran had been dropped from the EIT. A few years later the programming proportion was dropped entirely.

Domain-Specific Language (DSL)

In the mid-90s I wrote a Domain-Specific Language (DSL) to marry a proprietary claims processing system to mainframes. Each client had a variety of: interfaces to the mainframe, navigations within the system, and business needs. A set of configuration tables or files would be unruly if not impossible to solve the problem, and rather than having a developer write and maintain code for each client, a DSL was provided that allowed the customer to easily control the connections.

DSLs are commonplace and used extensively by every developer. Examples include HTML and JavaScript. Presently I'm learning Nullsoft Scriptable Install System (NSIS) to create install programs for a commercial product.

DSL concerns

• Proper level: A huge problem is the improper use of an abstraction for a given problem space. The limits of Lotus were obvious when I arrived in graduate school. Lotus was not well suited for many of the computational problems I was trying to solve in the field of Finite Element Analysis (FEA). I've seen the improper language abstraction appear over and over again. I just finished a project that was originally started in FoxPro. The group using FoxPro did 90% of the application in the first 6-months, however over the next 2-years they could not achieve project closure. Even if closure had been achieved, the application would have been horrific to maintain. One of the big questions today is the use, and misuse, of the HTML abstraction.
• IDE: Many high-level abstractions lack the facilities provided with a modern IDE, especially debugging and testing. Even though spreadsheets have been around for decades, and heavily integrated throughout society, there is no debugger for a spreadsheet.
• Integration and maintenances: Talking to developers at my local Honda plant, apparently Honda has made a commitment to Java from the mainframe to the controllers in the plants. Even if Java is not best suited for everything, using 1 language can definitely lower cost of purchasing, integration and training.

Ideal world

Ideally, the problem would be defined and solved using the proper language abstraction, that the user have access to feature rich tools to edit the abstraction, and that the abstraction integrate into the present state of the art 3GL, Java.

The future

I had a chance to see the future thanks to a presentation conducted by Hui Wu and Dr. Jeff Gray, from the CIS Department at the University of Alabama at Birmingham. The presentation demonstrated a method of extending the Eclipse debug perspective and JUnit, to support testing and debugging of domain-specific languages. The technology will allow developers to create debuggers and test suites for specialized language. Eclipse is already an IDE for any language, and providing test and debug features will dramatically improve the usage of Eclipse for DSL.

In my opinion, the huge improvements in productivity will NOT be achieved through scripting languages like Ruby or Groovy, nor language features like Annotations, Generics or Aspects, but developing DSL for the client specific needs. I envision a future where developers create proper abstraction for the end-user. Developers provide the end user with a rich set of tools such as a fully functional IDE. The DSL will be able to easily integrate into the Java environment, which will allow developers to deliver embedded DSL into products.

Rather than dozens of specialized configuration screens, I would have loved to add a DSL to the project I just completed. As Eclipse and debugging frameworks mature, I will be adding DSL to future products.

Maybe someday we will see a debugger for spreadsheets, or Jython.

More about the Domain-Specific Language Debugger Framework (DDF) can be found at: http://www.cis.uab.edu/wuh/. You can also see their presentation at the upcoming OOPSLA, and the next EclipseCon 2006.