Xtext Helios Roadmap

... on Sven's Blog. Let him know if you have comments, suggestions or input!  permalink    0 comments

 

Java programmers: you must read these two books

Recently, there has been a lot of hype around the idea of using different languages for programming the JVM. Many languages are available, as you probably know. However, I think two of these languages are specifically worth taking a look at because they approach the problem quite differently. These languages are Scala and Clojure.

So, what is the problem? The problem is, in my opinion, that the Java language (not the JVM) has stagnated. When Java was created, one of the primary goals was a significant simplification compared to C++. And I would argue, that this goal was reached. Java has deserved it's success. However, the landscape has changed over the last couple of years and Java did not evolve. Example areas include concurrency, functional programming, metaprogramming (internal) DSLs and type systems. As a consequence, alternatives languages flourished.

It is interesting to see how Clojure and Scala address this challenge very (although not completely) differently. I'd say the only thing they have in common is their emphasis on functional programming.

So let us look at some of the differences:

Typing: Scala is strongly typed, even more strongly than Java, but it comes with a sophisticated type inferencer to make sure the type system does not get in your way. Clojure on the other hand uses dynamic typing (duck typing, specifically), like so many of the "newer" languages. Consequently, Scala has a very sophisticated compiler, whereas Clojure emphasizes much more the runtime system.

Concurrency: Scala uses the actor model. Actors are lightweight threads that communicate by message passing. Clojure mainly relies on immutable data structures and pure functions, but it also comes with a software transactional memory facility for managing shared state without requiring developers to manually manage locks.

Syntax: Scala's syntax is in the tradition of Java. Although it reduces noise significantly (thanks to type inference and many other useful conventions) it is still driven by keywords and different special symbols. Clojure on the other hand, in the tradition of Lisp, basically treats everything as a list. I have not yet made up my mind as to which syntactic style I prefer. My stomach tells me I prefer Scala style. However, I do recognize that the simplicity orthogonality of Lisp like syntax provides for some very powerful facilities (macros)

Extensibility and Metaprogramming: Both languages emphasize extensibility in the sense that you should be able to use libraries to provide powerful functionality, which ideally looks like as if it would be built into the language. As usual in Lisps, closure provides a macro system that supports the definition of almost arbitrary special forms (as long as they still look like a list, syntactically - that's the catch, of course). In Scala, by being able to avoid the dot operator, parentheses and semicolons and through clever use of functions, you can achieve some of the same goals (there is also a compiler plug-in framework).

So, why am I talking about this, and why thus the title of this post talk about books?

I would suggest that every self-respecting Java programmer has to inform themselves about these two languages. Even if you will never use them, you should take a look to understand how the same problem can be solved in different ways, and how languages on the JVM can evolve (both provide extremely good interoperability with Java the language, by the way). It's a matter of looking beyond your own nose.

To do so, I suggest you read the following two books. Both are reasonably short, very well written, and emphasize the important issues:

Programming Scala by Venkat Subramaniam and Programming Clojure by Stuart Halloway  permalink    3 comments

 

News about OSLO

Some news about OSLO. I am not sure I like the merging of the Data Programmability team and the "Oslo" team ("Quadrant", Repository, "M"). I was always confused by some of the talks I heard where the SQL-ishness of everything was put into the foreground.  permalink    1 comments

 

Hardware for Podcast Editing

As you may know, I do quite a lot of audio editing these days for the various podcasts I am involved in. The time I spend editing the audio is worth optimizing....

So I was looking into buying affordable external controllers (aka control surfaces) for Adobe Audition. There are two ways how Audition can be controlled from an external device: the MIDI interface as well as "something that simulates a keyboard".

I have been looking into the following devices: Frontier Design Tranzport, the Numark Total Control, the Miditech MTB Command as well as the Contour Shuttle Pro V2.

The first three are MIDI devices and cost ca. 200 EUR. The last one is a "keyboard simulator" and costs EUR 99. I decided to try the cheapest one.

It arrived today. It has 13 buttons and two wheels, I use one for transport and one for zooming. I've assigned the most commonly used editing operations to the 13 buttons.

After editing a bit today I have to say it works really well! I now use the mouse with the right hand and the Shuttle with the left hand, hardly touching the keyboard. The editing experience is a quite a bit more efficient, and much more pleasant.

It's a little bit like HOTAS from military aviation: it takes a little bit of time to learn to "play it", but once you have practice, you're much faster and you can operate the device blindly.

Recommended.  permalink    0 comments

 

DSL Variant Management for TMF Xtext Released

Over the last couple of weeks Andreas Rytina and I have been working on porting the DSL Variant Management Tools to Eclipse 3.5 and TMF Xtext. We have finally finished these efforts and the plug-ins are available as a download.

The DSL Variant Management tools allow you to access pure::variants feature models from within your own textual DSLs. Static checking of feature names is the supported. There is also an integration with pure::variants relations view, which means that if you select a feature in the feature model the relations you will tell you, which off your DSL files refer to that feature.

In addition, you can also specify feature dependent regions in manually written code (in fact, any text file) and you can query selection status of features from within model transformations and templates.

We have also updated the documentation. The code used in the documentation is available for download, too.

On a related note: we are currently preparing an eclipse project to implement simple feature model tools based on EMF and other Eclipse Modeling technologies. Over time, we will and able the DSL variant management tools to also work with this open source feature modeling environment, and not just with the commercial pure::variants.  permalink    0 comments

 

Results of my Layouting experiments

Over the last couple of months, together with a couple of other people, I have been working on model visualization tooling, based on GraphViz and ZEST. However, the layout algorithms that come with these tools aren't as good as I'd like them to be; specifically, the algorithms in ZEST don't avoid node overlaps and aren't robust with regard to adding a few new nodes (i.e. the layout can change completely if you add new nodes).

A while ago I had the idea of using numerical simulations for layouting. Each node is assigned a negative charge (i.e. nodes repel each other) and the connections act as springs (i.e. they create a pull force between them). Doing an interative numerical simulation of the forces between them should result in a nice layout. That was the idea.

Since I couldn't convince somebody else to try this out, I had to do it myself :-) Here are the preliminary results.



I built this thing "from scratch" using Scala and Java2D. I think the results are convincing. The next steps would be to either integrate a layout along these lines into ZEST or to enhance my prototype to become a complete Eclipse-based model visualization solution.

I'd prefer the first alternative. Anybody interesting in integrating this approach into ZEST?  permalink    6 comments

 

Back to the Roots

Yesterday evening, and also most of today, I spent coding in Scala. I was prototyping a layout algorithm. I implemented the prototype in Scala, nicely test-driven (ScalaTest), and using IntelliJ as the IDE. I've used Scala before, but ScalaTest and IntelliJ was new for me.

The coding was/is a lot of fun! As you probably know, these days I spend most of my time doing meta stuff: languages, meta models, code generators. Or, if I code, it's either C (in customer projects) or it's Java based on huge frameworks (usually Eclipse or JEE stuff). Programming against these frameworks is not so much about creatively programming, it's more about understanding and mastering existing frameworks, which can be very frustrating.

Over the last two days, the only framework I had to work with was Java2D. Everything else is very much self-contained, really nice OO design. Scala is really refreshing, and I have to say, I start understanding people who say that IntelliJ is the better IDE for Java development... Eclipse is of course very useful because of it's plugin architecture and the huge amount of existing plugins, but for pure coding... IntelliJ really is nice.

So, in summary: this was a lot of fun. I should do more coding like this :-)  permalink    0 comments