I shouldn’t care about this because I don’t use JavaFX. But it bugs me so I’ll rant a bit.

A while ago (probably around version 1.2) the language caught my eye. I especially liked its literal declarative syntax for creating tree structures and data binding. I thought I heard that Oracle was discontinuing JavaFX but version 2.0 is in beta. I now realize that it is only JavaFX Script that is canned — JavaFX is alive and well. (JavaFX Script lives on in visage.) The features of JavaFX are available as APIs that can be used from Java or other languages on the JVM. This is a good architecture.

Writing procedural code to construct a scene graph looks as ugly and cumbersome as JavaFX Script was elegant. To “fix” this problem FXML was invented. FXML is a XML dialect for declaring a scene graph.

From what I have read there are two main motivations for using XML:

• Familiarity — from the getting started with FXML page: “One of the advantages of FXML is that it is based on XML and is therefore familiar to most developers”
• No need to compile (presumably changes to FXML are made on the fly without having to restart the app). This is fair but doesn’t imply that XML is a good answer.

The familiarity argument is false. It confuses syntax with semantics. Yes many developers are familiar with the syntax of XML but just because someone knows XML Schema doesn’t mean they will have any understanding of XSLT. One must still learn the semantics of FXML and that’s the hard part.

Here is what I think is bad about FXML:

• XML is just not a convenient language for source code. It is verbose and cumbersome. It has lots of little things that get in the way such as entity references. New programming languages including declarative ones should not be XML.
• Use of character case in element names to distinguish between instances and properties is ugly.
• Properties can be represented by either XML attributes or XML elements. This is practical but confusing and stems from using the wrong tool for the job (XML).
• Type coercion.

And a few things I liked:

• Use of XML processing instructions.
• Built-in support for string translation. But it doesn’t go far enough. It should eliminate the need for maintaining resource property files and support format substitutions.
• Concept of static properties.

What FXML shows is the importance of having a literal representation for data. It looks like FXML could be used to build arbitrary heterogeneous object trees which is generally useful. What I think is really needed is an object literal syntax for Java similar in concept to what JavaScript has. The syntax used by JavaFX Script would make a great starting point.

I recently watched a video about a cool new technology called <angular/>. It looks like a great way to create web applications. It caught my attention because I saw in it some parallels with some of my recent writings and what I am currently working on.

The video was very good but in the beginning Misko Hevery struggled a bit to describe it and at the end admitted the biggest problem was explaining to people what <angular/> is. To me it is clearly a language, and an extensible one at that. It is (or at least contains) as he describes an HTML compiler. Doesn’t a compiler imply some language to compile. The source is clearly more than just HTML so it must be more than just an HTML compiler. I wonder if there is some reason he avoids calling it a language. The fact that it can be extended to handle new behaviors, widgets, etc. just makes it a better language. Is there some fear that calling it a language would put people off? It doesn’t bother me since I previously said that higher level languages will provide the biggest productivity gains.

The parallels I was talking about are:

• Its a declarative language
• The language is designed to be extended
• It has two way data binding

Two way data binding is a very important aspect in simplifying the creation of web apps. The first time I ever saw data binding was back in the the late ’80s. I was visiting a friend that was working on a maser, which is cool (literally) in its own right, but what caught my eye, as he showed me around his lab, was some software running on an old Mac. That software was LabView. The fact that a line drawn between a sensor and a gauge meant that any time the senor value changed the gauge was updated really impressed me. More recently I noticed that data binding is built in to the JavaFX language. I haven’t written any programs in LabView or JavaFX so I’m not sure if the bindings can be bidirectional but I’m pretty sure at least in JavaFX that bidirectional changes can be accomplished.

It is the two way data bindings that most notably distinguish <angular/> from template languages. I used to be a big fan of template languages, and StringTemplate was my favorite. Lately I have found them to be less useful. One reason is that in my recent work I have found that procedural logic far outweighs the amount of template text. The bigger reason is that most template languages don’t automatically protect you from script injection (XSS). There are many JavaScript template languages available now and I don’t have a need for any of them. But <angular/> is different — it is not a template language and it looks like it protects against script injection by default.

<angular/> is new but it looks very promising.

I have been so busy at work lately that since wrapping up the climbing robot I haven’t had time for any substantial personal projects. What I’ve been working on is a declarative DSL for implementing a web application based on ideas I previously wrote about. Like I said its a work project so I can’t go into any details. I will say that I’m working with ANTLR v3 and jQuery, which are technologies I really like. My point in mentioning it is that if you read that post and wondered, like I did, if those ideas would work I believe the project is far enough along that I can say that they do.

Since my last post where I presented a number of ideas on a declarative domain specific language for implementing web applications, I learned about the language oriented programming paradigm.

I recommend reading “Language Oriented Programming” by M. P. Ward. It also claims programmer productivity as a benefit of what it calls the “middle-out” development style.

In a couple of recent posts I have argued that a higher level language is needed to
provide a significant boost to programmer productivity in the area of web applications. This is a topic I have been thinking about for many years. I’ve worked out some aspects of what I think the language should be. A little over a year ago I even started implementing a parser for the language in ANTLR. I worked on it for a few weeks before moving on to other higher priority projects. Higher priority simply means something more interesting caught my eye. It’s finally dawning on me that I’m not going to get a big enough block of free time to work on this any time soon. I guess I prioritize the smaller projects that have a better chance of getting finished.

Instead of mothballing the project completely I’m going to share some ideas from it. This his may be of interest to others and who knows, I may get back to it from time to time.
Continue reading…

Tools, languages or frameworks — which will have the biggest impact on developer productivity? I previously said that I thought languages could do better than frameworks in this regard. Now I’ll talk about at least one class of tools.

A good deal of focus around developer productivity is on visual editing tools. I think these efforts are misguided and unlikely to produce major benefits to developers. Clearly tools are useful. Humans are natural tool makers and users. Written language is arguably the most important tool invented by humans. Programming languages are tools.

So what do I mean by visual editing tools? My definition may be a little fuzzy but here it is: I’m talking about tools for creating software that don’t have an underlying text based language or completely hide it. They usually involve working with pictures, diagrams, or forms. Some examples:

• Business Process Workflow editors
• Property editors
• Visual UI layout editors

These are some of the general problems I have found with visual editors. Not all of them have all these problems and I’m not signaling out a specific tool.

• Scale — Sometimes the visual editors don’t take scale into consideration. They work well for small programs but break down when used on larger programs. The breakdown may be due to implementation details or a more fundamental limit in ability to comprehend the visualization at large scales.
• lock in — This is when a tool requires you to use a particular platform, IDE, tool set, library or framework. The same lock in is possible with languages but it tends not to be; at least not for the more popular languages. Perhaps that is what makes them popular. As a developer I’m very skittish when it comes to lock in. It is much easier to share (and reach agreement on) a language specification than it is a GUI specification.
• Poor source control integration — Being able to track changes to software source over time is very important. Some tools make arbitrary text changes that confound source control systems. The worst example I have seen is a visual work flow editor that changed all ids in its XML format source file every time you saved it. Binary formats are a definite no-no.
• Lack of flexibility — When writing software in a text based language you are free to write in whatever order your thoughts come to you. Tools that force you to translate your thoughts into specification in a fixed way will end up frustrating users.
• Inefficient — I tend to find that visual editors get in the way after a while (if not right away). They tend to require a lot of mousing around. Once I know what I’m doing typing is much faster.

Good editing tools assist you while working with a text based language. The most basic editing such as random access to the text, insert, delete, cut, copy, paste etc. is sufficient to get the job done and has the benefit of working equally well for all text languages. Advanced features such as syntax coloring, unobtrusive flagging of errors and warnings, context sensitive completion, access to language and API help, type based searching and navigation, refactoring, template insertion/completion, bracket pair matching, indenting etc. are very useful and don’t replace or get in the way of the text.

Diagrams can help visualize aspects of programs but programs are too complex and multidimensional to be fully represented in any picture or diagram so it is a mistake to think that the visualization is the program and can be edited directly. Being able to draw (or even edit) diagrams is a nice add on for a language but the language must come first and stand on its own.

Some tools claim to have an editable underlying text format when in fact it is just the tool’s internal model serialized as XML. This doesn’t count. Not because its XML but because it tends to favor ease of serialization and the needs of the tool over the ease with which humans can read and write it. XSLT is a good example of a language that uses XML syntax. It was clearly designed to be edited directly by humans. The fact that it can’t be fully described with XML schema is probably a good indication of this. I like XSLT but I also agree with Terence Parr when he says “I implore everyone to please stop using XML as a human interface!” (see his excellent book “The Definitive ANTLR Reference”) .

The best development productivity tools help the user write in a given language not replace language.