Thoughts of Oz

DSL - good servant, bad master

2007-05-14T22:43:00.000+02:00

I'm always happy to read, hear or watch anyone writing, talking or presenting about Language Oriented Programming and/or Domain Specific Languages as it is my favourite topic and I have a soft spot for it.
I dipped into Neal Ford's presentation he had at JavaOne conference entirely alike (I was not that lucky to hear the talk, however).
Neal goes through the classical examples of DSLs and explains the main benefits of LOP. Although it mostly describes nothing new, I did like reading it since it proofs more people is starting to be interested in it.
I liked the word context he mentioned when talking about the main feature of DSL. It is certainly true that every specific language has a domain that can also be called its context and that this context is always implicitly given for each single DSL.
But that is not the main thing I want to draw one's attention to.

One thing struck me. The simplicity with which he added new language constructs into this language. I was not struck positively, however.
I remember having similarly mixed feelings with overloaded operators in C++. Although it was contributing when used smartly for creating a completely new library (everyone is familiar with iostream library and << operator), it was disservicable when a programmer overloaded his/her operators recklessly (and headache to read such code). One could be sure with nothing.
I believe - it is good to create new languages as it is good to create tools to help design these new languages. But I do not believe that most people will be able to easily create new languages in the correct way where correct way means not to mess things up.
Not many SW developers are skilled enough to design good API and creating a new language is not an easier task either. Design of languages is a job for language designers -> simple way of adding new constructs to a language is not a feature intended for broad public. Moreover I believe that every non-trivial language should contain guidelines and design patterns to use this language. Again, to bring such patterns up is not a task for an ordinary programmer.

P.S. It is also worthy to see this video, an older Neal's presentation about DSL/LOP - some slides seem familiar.

Internal vs. External Domain Specific Languages

2006-12-27T19:28:00.000+01:00

Martin Fowler mentioned at the end of his speech he had recently on JAOO conference, it is difficult to gauge the impact of Language Workbenches and inherently External Domain Specific Languages. Although neither Intentional Software nor JetBrains have revealed themselves yet what they are up to, I do not believe people will start creating external DSLs recklessly sooner or later. It is much too difficult to create a new language, its parser and teach this language other people, simpler the language can be.

What I believe more is that people start to realize their APIs and libraries in currently used general-purpose languages should resemble DSLs more so other people can use these as a new language with all properties a new language has. Thus the resulting application will be much better layered and different aspects of the project separated while keeping one (or few) programming language(s) with one syntax only within whole project.

The main difference will not be in programming, it will be in thinking about programming.

History lesson

2005-10-25T23:09:00.000+02:00

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:

Verbal agreement
Specification
Price estimation
Implementation
Documentation
Operator training
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:

Graphical IDE that helps the bar code expert to create an application
The application will be then downloaded into the bar code scanner
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. We 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:

On the subject of SMS typing

2005-09-15T23:49:00.000+02:00

Have you ever thought how different or how easy the life would be if we didn't use our bad habits from the past? Just imagine the disaster if scientists proposed new much safer rules of car driving and enlightened politicians tried to put it in use even though it was much easier than the way cars are driven now. The long-term advantages are indisputable, however, the immediate results will discourage any brave politicians. No wonder that Britons never changed their left-hand driving... As the old saying states - can't teach an old dog new tricks.
Similar thing happens, although with no such severe consequences, when typing an SMS (for those who never typed an SMS - sending text messages from mobile phones is fairly popular in Europe, especially in countries like Czech where calls are so expensive). Why are the letters shown in alphabetical order on the keypad? Wouldn't be the typing easier when all vowels and consonants were shuffled as they are on a computer keyboard? Certainly would. Let's do it! Is there any courageous mobile phone producer?
Isn't a similar thing happening now in computer programming? Aren't we learning new tricks? If only we could drop all old tricks and start learning the new ones easily.

Mother Nature

2005-08-18T22:14:00.000+02:00

Many great human activities and inventions were inspired by nature in the history and computer science is no exception. In this contribution, Charles expresses an idea that is inspired by the Nature. He compares the program generation (a method that should bridge the wide gap between problem description and its solution and also a method that Intentional Software aims at) to DNA - a description (of a problem) that Nature uses to generate whole human being (the solution). This comparison is a good one, I believe. The only thing that remains is to find the right enzymes producing healthy individuals and no rejects.

Speaking of inspiration by Nature, there are other ideas concerning computer science. Although the Recapitulation theory is being abandoned lately, the connection between Ontogeny and Phylogeny undeniably remains.

If we compared the evolution of programming to Phylogeny and an evolution of one program to Ontogeny, we would get a simmilar connection. If the Ontogeny copies some steps of Phylogeny (as the Recapitulation theory claims), does it mean that in different stages of one program development, its authors should use different styles of programming? Should we start with very basic elements, then design fundamental procedures, create modules and finally use objects and find cross-cutting concerns? Or does it mean that in every well-written more complex program a different programming styles will inevitably appear?

Aspect limits second time

2005-08-03T18:33:00.000+02:00

Although this blog was opened six months ago, I've discovered its existence only recently. Interestingly, Charles' contribution little formalizes an idea I mentioned six months ago. When I wrote about AOP use-cases and its limits I didn't suspect that it's exactly what Charles means by an insufficient degree of freedom. AOP allows advice to be woven before, around or after a method call only. It does not offer the possibility of waving it into critical section entry or leaving or even into different branch instructions (if, switch, for, while, etc.).

If one intends to implement the same use-case - monitoring of locks acquiring and releasing via AOP - she has different possibilities whether she monitors Java built-in synchronized keyword or whether she waves into methods of the Java 5.0 API (the class java.util.concurrent.locks.Lock). In the former case, she fails; in the latter one, she can do it.

Why language designers' mother tongue is not English

2005-04-01T11:00:00.000+02:00

Experts, journalists and laymen interested in Language Oriented Programming wonder why there is that few LOP researchers natively speaking in English. Look at faces of these great men - Сергей Дмитриев (Russian), prof. Ulrich Eisenecker (German), Krzysztof Czarnecki (Polish), Todd Veldhuizen (I don't really know, Swedish by the name), me (Czech) and many others. None of them uses English as his first language. Why is it so?

The answer is as simple as the English grammar. You don't have to be really gifted to figure out what is behind. Here is the explanation.

Obviously, everybody thinks in the language he/she speaks in, so no wonder that a scientist thinks in his/her native language. By comparing the English grammar with any other European language it can be easily seen that English cannot compete in complexity. Therein lies the rub! Evidently, more complex grammar scientists must learn during their childhood, more advantages they can profit from during their research. Just look at the simple English grammar and compare it with complex, irregular one of Sergey's native language or even with the fourth toughest language in Europe or look at Charles and its Hungarian with all its forms, case suffixes, moods, etc.

Basically, if someone wants to put himself up by his bootstrap in the field of LOP, he must learn Hungarian, Czech or Russian first. Pity is that there are no Chinese researchers so far. God help us!

Programming by copying

2005-02-28T21:53:00.000+01:00

Recently, I've seen a demo on programming by copying. It takes just few minutes to see it and it's really worth to do that. Although it might be seen as a funny plaything first, a much deeper idea is hidden behind that. Not many programmers would admit that programming by copying is a good idea. Nor do I. On the other hand, say frankly, how many times did you program by copying? I did many times. What's wrong on that? It shows a bad concept of your program. What's good on that? It's fast and accurate; the copy becomes an original piece of code immediately and you can adjust the copied code instantly without worrying about side-effects at another parts of your program. Shortly, copying is good when jotting down a prototype of your idea and you don't really bother about misconceptions – you know your program will need refactoring in the productize version, but all theory, dear friend, is gray, but the golden tree of life springs ever green (as a great German writer once said). We don't always have time to refactor it, do we? In such a case programs made by copying get to products. So, what's the hidden idea? Here it is – program is not only a piece of text and programming is not just typing of it. It shows that text editors are still a weak substitute of real program editors. If an editor tracked all changes made on the program and remembered which parts of the program were made by copies of another parts, the editor could refactor the program without programmer's help. Moreover, the editor would refactor program without making mistakes, it wouldn't forget any possible side-effects. The demo shows one way to do that in not real textual editor and in not really common way. Similar idea can be implemented into more sophisticated and common editor. Much in programming has been changed since time of Turing but not the way we program. It's like making cars with hammer and sickle only! I'm not saying – using primitive tools for making cutting edge technologies is impossible, I'm saying – let's do something with it!

Aspect limits

2005-02-17T22:18:00.000+01:00

Aspect Oriented Programming (as most of people interested in LOP already know) enriches the world of languages with cross-cutting concerns. Although the idea is not new, it is still being heavily researched.
Typical use cases of AOP are logging, debugging and error handling, these examples can be found in every reference to AOP. But, isn't it too little? What are the other use cases of AOP? What are the real production use cases? Even though error handling is used in products, hardly can it be considered as the main feature of a product. Transaction handling, synchronization in multi-threaded environments, lazy initialization, security; all these fields are certainly other areas where AOP can be used appropriately, but what else?
The lack of AOP use cases may result from little usability of AOP features. Look at the logging - AOP can log any call or return of a method but it can't log other branch instructions (if/else, switch/case) - scarcely it can be used for full logging of a program flow.
Similar limitation exists for AOP usability in synchronization - AOP cannot handle monitor lock/unlock (entering into/leaving from a critical section) - this keeps automatic deadlock prevention tools from being implemented.
Although the main two AOP projects have joined recently to work on new releases together, many things still remain to improve.

Why we have used notations and why they are not necessary anymore

2005-02-08T23:41:00.000+01:00

In this great article, I've read recently, is a very interesting belief: "We believe that next-generation programming systems will most likely store source code as XML, rather than as flat text. Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors."
This is certainly true. As soon as I read the sentence above, it was clear why we have used notations in programming. Do you also ask, why there were invented such rules as Hungarian notation, indentation, firstLetterOfEveryMethodNameInCapitals, CONSTANT_NAMES_UPPER_CASED, etc? Here is the answer - we didn't have the right tools those days. We were lack of expressiveness and all the notations were merely poor escapes from that mud. Now, when any programmer may express his/her ideas in the proper way, these notations are not as important as they were before. I'm not saying, stop using them, but in case you do, it's much easier to refactor all the pile you wrote now than it has ever been before.

Create your jargon first

2005-02-08T23:01:00.000+01:00

As has been posted by many smart men, Domain Specific Languages will drive the world of programming in the near future. As another great artist said: "Bad artists copy, great artists steal", the best of us try to be great. Actually, what we do is stealing ideas from native languages – the ones not to be as artificial as programming languages are.
What's going on in the native languages? They change, they adapt to the environment they are used in. People working in one environment tend to create their own jargon – to express ideas of that domain more easily, more accurately and more concisely.
Domain specific languages relates to general languages as well as different kinds of jargon relates to different native languages.
As an example of a domain we may know a lot about, look at creating the IT jargon. In English it is done in a fairly different way than doing the same in Czech. In English, old words get new meanings so words like computer, web, network, file, etc. having their original interpretation have suddenly a new meaning. In Czech, however, most of the IT jargon is created by borrowing words from English. Thus, just few jargon words stay originally Czech. Although creating a jargon may be done differently in various languages, the purpose is always the same – to be concise in that particular domain.
Jargon of native languages is the proof that DSL is the future of programming. To express your ideas properly - create your jargon first.

Welcome

2005-02-08T21:46:00.000+01:00

This web will, hopefully, comment anything in subjects I'm keen on, especially in the domain of Language Oriented Programming and related areas. As I'm not a native English speaker, but a native of Bohemia and my mother tongue is Czech, please, respect my English.