Today I saw a very cool movie created from World of Warcraft scenes.  Check it out.

After ragging on MarsEdit about it's image support, I thought I better try out Ecto image support.

First thing I noticed it that I can drag an image from my filesystem (or even a web page) and drop the image into the editor.  I can also resize the image by clicking and dragging a resize handle.  Very cool.  I can also double click on the image and get a number of options.  For example I can specify that I want this image to be a thumbnail.  That is a nice feature.

I will now try to publish and see what happens.

The fact that Ecto posted my entries with a seemly random publication date, I have decided to continue my search for a good blog authoring tool. Today I am playing with MarEdit. MarsEdit seems to strive to be similar to an email client. The first thing that I notice is that MarsEdit does not have a Rich Text editor. You manipulate the HTML directly. While I like the freedom of modifying the HTML text, I would prefer to have a Rich Text editor.

Now MarEdit does have a combo box that list a number of HTML tags. By using the HTML tags tool, it does make it easy to add HTML tags. My main concern at this time is how to insert images. The HTML tags combo box does have a insert image item. So maybe it will help. Lets try it out.

So far so pretty good. I was able to select a picture and the pictures alignment. When I pressed the Ok button, MarEdit took care of sending the image to the server.

The image is a picture of my four children. The picture was taken the same day that my youngest son was born. August 25, 2006.

MarsEdit has a Preview option (so did Ecto). The Preview window has a live preview option. The live preview option allow you to see the entry in WSYWIG. The question I have is why not put that in the editor? Also after adding the image, I noticed that every keystroke I type in the editor cases the preview window to refresh. Which causes the image to redraw over and over. It was very annoying, so I had to close the window :-( . I have not turned off the live preview, and I notice that the image still flicker when I scroll the preview window. Very annoying.

Well now it the lime to publish.

Publishing Results Well the good thing is that the entry was published and immediately appeared. That is good. However, again the new line characters where not replaced with HTML line break tags. Before editing I thought that I set the option to convert line break to tags. I will try it again.

When I inserted the image, I specified that I did not want the image to have an alignment. I just realized that MarEdit defaulted the image to be left aligned. That is not good. I had to update the HTML by hand.

Well that did not work either. I just gave up and added the paragraph characters myself. All and All I like Ecto better.

One of my hang ups with blogging is a writing the blog.  You have to enter the blog into a text field a web page.  The problem is that you do not get nice editing tools.  Well at least I have not seen any editing tools.  So, I decided to see if there are any good blog editing tools.

I am testing out Ecto.  What is cool about using Ecto (maybe other blog tools as well) is that the entry editing feels like you are writing any other document.

Well this is my first entry using a blog editor.  Pretty cool.

Ok, I learned two things.  First, there is a delay from when you publish and when the entry appears in the blog.  The reason is that a publication time is set for the entry (why I do not know).  Second, you have to use the option edit setting "Convert line breaks in Rich Text mode" to automatically convert newlines to <p> and <br> tags.

Alright I have now updated my client about the time zone information.  Lets see if this works. 

Well that did not work.  Matter a fact, it seem random on when it will decided to actually post the entry. :-(

I have heard that people think that Domain Specific Languages (DSL) is a very abstract concept. Because of the abstraction, a lot of people are nervous about domian specific languages. I can see how people get that impression. In order to have a DSL, someone uses abstract concepts to design the language. The goal of a DSL is actually quite the opposite. The goal of domain languages is to move away from the solution domain details and embrace the problem domain. What I mean is that instead of talking in abstract concepts like Classes and Components, we start using the domain concepts (Car, Truck, Node, Project, etc) when developing software. Describing aspects of a system in concrete terms makes it easier to understand the system.

By no means is this concept new. If you look at the history of software engineering you will see steady progress of moving away from the abstract concepts to a more logical concept. First, we started with machine code. I would argue that the machine language is a very abstract language to a human, while the most concrete language to a computer. We then move to assembly language. Assembly language made developing a little more concrete to us humans by representing op codes (numbers) as names, but assembly was not understandable to a computer. Therefore, the assembly language program had to be assembled to machine language so that the computer could understand. The assembled program became the artifact. Next came structured language and functional languages. At first people said that these languages could never produce code as well as programs written by hand in assembly. Over time, this statement was proven to be incorrect, and the object code became the artifact. Next came concepts like object oriented programming and aspect programming. Over and over the process repeats. We move to a logical reprsentation of the machine code. Each iteration makes that programming language more abstract to the computer but easier to understand for us humans. Domain specific languages simply repeat the cycle. Trying to make it easier to understand the concepts needed to develop software.

The previous statements are all fine and good, but is there any practical use? Yes, there are a number of examples of domain languages out in the world. If you look at NetBeans you will see a number of examples. The one that everyone will be most familar with is the form editor. It is a language that is designed specifically for designing user interfaces. As such, it is very intuitive to use and very powerful. The reason it is very intuitive is because it uses the concepts of a user interface to describe the user interface. It does not use general programming concepts of classes and components to describe a user interface. The form editor uses buttons, panels, labels, and a host of user interface controls to describe a user interface. To build the same user interface in code is very possible, but it is a lot of work. It takes a lot of work to get the control in the correct locations, not to mention how to handle resizing windows. However, when you use the form editor, this becomes a farily trivial task. Especially a form editor like Matisse. Note that in the form editor a lot of code still needs to be written. It is still up to the developer to write the user interface logic. The fact that the form editor leave a lot of code to be written by hand is a very improtant thing to note. A domain specific language does not mean that there will no longer be a need for a good source code editor. The goal of a domain specific language is to start generating more code not to do away with writing code.

Another example is the orchrastration editor. The orchrastration editor is a graphical editor that is designed to write BPEL documents. The orchrastration editor is an example of a domain specific language that represents not structural information but instead behavioral information. Even thougth the orchrastration editor represents behavioral information, it is still easy to use. It is easy to use because it uses the concepts of the BPEL domain to describe the behavior that is to be executed.

In my previous examples of domain specific languages, I have used graphical languages. Domain specifc languages are not limited to graphical languages. Indeed, there are may example of textual domain specfic languages. BPEL is a good example of a domain specific language that is a text based language instead of being a graphical language.

I can already hear the arguments that BPEL documents can easily be represented in a general purpose language like UML. That is a very true statement. The UML Activity diagram would be a very good fit to represent BPEL documents. As a matter of fact, I have made that argument myself many times. Also, a page flow diagram can easily be represented as by a state diagram. The point is that the higher the level of the language, the more intuitive the language. Now, I am not saying that there is no need for general pupose modeling languages. I believe that general pupose modeling languages like UML can be used to represent domain specific langauges, but that is a topic for latter discussion.

So, where does that leave us? Are domian specific languages by its nature abstract? Well, the designer of a domain specific language has to think about how to design the language. Usally the designing of a language will take you into abstraction. I would argue that the level of abstraction required to design a language is no more than it would take to build the concepts into a modern object oriented application. For example, to write an accounting applicaiton you would still have to develop the concepts of the accounting domain into your system. You would instead use the accounting terminology as an abstract concept, and the object oriented concepts as the concrete concepts. With domain specific languages, the domain concepts become the concrete concepts. Therefore, putting the focus on the problem domain insteading of focusing on the domian of the programming language.