History



CONTENT

Why does CodeWorker have been developed?

The adventure of CodeWorker started in 1996, with the wish of avoiding typing some repeatitive and tedious programming tasks. It is better to focus the skills of a developer on modeling and implementing code once, rather than writing kilometers of code lines.

How to reach these points, to grant these wishes? Not by proposing a new method that doesn't offer something concrete, but just reassures the staff and puts back the problem further. So, you'll never heard me to tell you: "It concerns the development's team, we don't care about the final implementation tasks, except that you must conform to the method 'XXX' and all will be OK! Now, give me money!". But I can do it, if you insist.
So, not a method to propose, but a software that does the work properly. The first step is to allow acquiring data (UML, source code, personal description...), stored in any kind of text files (Rational ROSE, JAVA, HTML, DTD, personal format...). The second step is to organize the interesting parsed information into structured types, which hold the role of a parse tree. The third step is to generate code (any kind of text) or to transform existing files, according to the parsed data.

Why use an adapted language for doing the job?

At the beginning, the intention wasn't to implement a new language, but to extend a generalist language with specific components for parsing text and generating code. The library was written in C++, and offered some convenient functions for reading tokens and for extracting protected areas from a file, for example.
However, text to generate was written in the syntax of C++, using stream operators (once the pattern to generate code has been written, it is too hard to move or change some parts), and data structures were declared in C++, heavy to manipulate (quite verbose to iterate a list in C++, not flexibility enough to change structures if some attributes or associations have to be added or moved or changed, ...).

This approach was acceptable on projects where the data to extract weren't too complex, and were the source code generation was quite simple. But it is unusable on big source code generation projects and hard on complex data structures.
If you share the same experience, you know that it is just sufficient to convince you that a fascinating world may be tackling with source code generation, but that the syntax of a generalist language doesn't allow to do more than touching upon this world.

So, a new language had to be implemented, mainly (at this time) to make easier the source code generation in a way that is very common today: by inlaying the scripting language to interpret into the text to write. This is exploited for instance by:

  • the JSP (Java Server Pages), where the Java code is embedded between the tags '<%' and '%>',
  • the HTML pages, where PHP is embedded between the tags '<?' and '?>',
  • the HTML pages again, where the Java Script (for example) is embedded between the tags '<SCRIPT' and '/SCRIPT>',

Why not to exploit an existing scripting language?

This new language was an interpreted scripting language, where parsing, data representation and source code generation could be developed and manipulated in an homogeneous way (all in the same language), and where the syntax could be adapted to facilitate as well source code generation than parsing or data handling. And now, we dispose of:
  • the tag '@' that allows swapping between text generation and interpretation of scripts, but it accepts the tags '<%' and '%>' too,
  • all interesting functions to read tokens an to ignore blanks or comments,
  • writing a parsing script like a BNF (more convenient than reading tokens) that allows changing the syntax independently of the parsing representation,
  • structured data as trees, which are populated in a very natural way
  • a syntax looking like the one of a classical procedural language, such as C++ or PASCAL (declaration of functions, iteration of lists, try/catch management, ...), so not arduous at all,
  • an integrated debugger,
  • a profiling tool that measures the coverage of scripts and the time consuming,
  • ...
Thanks to this approach, it has appeared that:
  • pattern scripts (means dedicated to source code generation) were reflecting the skills of developers and that these skills were really reusable,
  • the more concepts the developer will put into the modeling, the more reactive he will become and the more architectural solutions or application designs he will be able to validate,
  • a good formal language for modeling allows never typing twice the same code, but implementing a lot of code automatically , if it is coupled to smart scripts for source code generation (remember: the skills of developers, it capitalizes the IT knowledge),
CodeWorker is maintained by Cedric Lemaire. Please send a mail to Submit a bug or feature