Malcolm Davis's Blog

The next generation of languages

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.

Comments

• You can already debug jython using pydev for eclipse. Anyway, you will probably be interested in the JetBrains (creators of IntelliJ IDEA) project Meta-Programming System. You can read about it at http://www.jetbrains.com/mps/

  Posted by: keithkml on August 29, 2005 at 04:20 PM

• I think that we need to create better basic concepts to build the DSLs on, current languages, runtime environments and IDEs aren't providing the "right" abstractions. Shameless plug: I am trying to get the jexplique project off the ground, so please take a look at https://jexplique.dev.java.net/

  Posted by: tobega on August 31, 2005 at 02:35 AM

• Jython:
  Look at the Python support for Eclipse:
  http://pydev.sourceforge.net/
  As far as I see, this has Jython debugger support.

  DSLs:
  About your comment that DSLs will have a larger impact than "scripting" languages like Ruby or Groovy: this ignores the fact that those languages lend themselves particularly well to building DSLs. Actually, they have the benefit that you can build them without writing a special parser, but instead use the flexible syntax of the language to do it.
  One example would be the Ruby build tool Rake; Martin Fowler has a good article talking about Rake and DSLs:
  http://www.martinfowler.com/articles/rake.html
  

  Posted by: murphee on August 31, 2005 at 08:57 AM

• DSLs will enable end users when end users become programmers. Unfortunately, of the many users I have encountered over the years, very few have the gumption or motivation to make that step.

  Simplest and most prevalent example being Excel. You can argue that VBA isn't a particularly good DSL, and thats very true (it's quite generic), but the fact is, few even bother to use the Macro Record function (which is basically the easiest DSL made). While super power users and developers can make Excel jump through hoops, a VAST VAST majority do not.

  So, yea, DSLs are all flitty right now, but it's a technology that as much as it enables a user, it requires the user to enable it. And, simply put, they don't.
  

  Posted by: whartung on August 31, 2005 at 10:28 AM

• A program is essentially a domain specific ontology, and compier is much like a theorem prover. It appears as though the author is relabeling a difference without a distinction.

  Each proper descripton of a domain has some minimal information complexity, regardless of how it is rendered.

  No set of programs will be smaller, regardless how DSL they are. They merely become smaller by assuming a larger context (prefix).

  Posted by: ericlindahl on August 31, 2005 at 12:22 PM

This work is licensed under a Creative Commons License.