Tuesday, October 25, 2005

History lesson

At the end of 1997 I started my job in ICS (a small company, I was their 10th member) as a programmer. My main task was developing simple database applications for small bar-code readers (handy terminals in other words). These times, such a terminal was a computer with a numerical keyboard, a simple BW display, processor and most importantly with a laser or a CCD reader for reading bar codes. Pretty much it looked like a mobile phone. The usual project life I was participating on consisted of these steps:
  1. Verbal agreement
  2. Specification
  3. Price estimation
  4. Implementation
  5. Documentation
  6. Operator training
  7. Maintenance
Documentation was usually a more detailed version of specification and the implementation was copied from sources of previous projects. At the time I was working on the third (very similar) project, I wrote a general library of common functions for storing, manipulating and searching data in a file, for drawing menus and input forms, even an implementation of AVL tree for fast search. Although these times I didn't suspect anyting about LOP, this library was an instance of DSL for writing these simple database applications.
Soon I realized that this policy must have been changed and offered my boss - director of this company - to develop a project for creating these applications. Thanks to his enthusiasm to new projects, the project really started and got financed.
First I supposed the tool would be a very simple source code generator using already mentioned libraries. Later, the company's management decided on possibility of selling this product (without re-selling the compiler) so it must not have only generated source code, it must have also run the code. This is the final idea that got also implemented:
  1. Graphical IDE that helps the bar code expert to create an application
  2. The application will be then downloaded into the bar code scanner
  3. In the scanner runs an interpreter of this application.
Although we didn't have a single notion of terms like DSL or a domain expert we soon realized that more easy the tool would be, less general problems would it solve and less steep the learning curve of this tool would be. Project structureWe were also aware of the opposite - a more complex tool would never be used by non-programmers. Balance these two opposite requirements was the most difficult task. Finally, we (me and three other university mates) made it happen. In the tool is possible to define several entities (data tables, menus, input forms, variables and procedures) while it checks if all references are correct; it supports easy refactoring and also allows debugging. From its very beginning it supported 4 different platforms (DOS, Windows, and 2 bar code readers) all programmed in C/C++.
From this description is clear, I hope, that the tool (named Karel after our parrot that shared a dormitory room with us these times; later it was renamed to a less poetic name ProGen) is nothing less than an instance of DSL provided with an editor exactly as it is described in this great Sergey's article.
Interestingly, I started participating in LOP/DSL area even before I realized this area will once exist. I noticed recently that the same idea - unintentional creation and use of DSL - is expressed in the new blog entry of Intentsoft. If one was interested, here are screenshots of the tool:
Data definition
Menu definition
Form definition
Variables list
Variable definition
Procedure definition
Search command definition
Program debugging
Data watching during debugging
Correct reference check