Thursday, August 27, 2009
 

Xtext Helios Roadmap

... on Sven's Blog. Let him know if you have comments, suggestions or input!
 
Monday, August 24, 2009
 

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
 
Tuesday, August 18, 2009
 

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.
 
Thursday, August 13, 2009
 

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.
 
 

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.
 
Sunday, August 09, 2009
 

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?
 
Sunday, August 02, 2009
 

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 :-)
 

back to voelter.de

ABOUT ME
This is Markus Voelter's Blog. It is not intended as a replacement for my regular web site, but rather as a companion that contains ideas, thoughts and loose ends.

ARCHIVES
December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / April 2008 / May 2008 / June 2008 / July 2008 / August 2008 / September 2008 / October 2008 / November 2008 / December 2008 / January 2009 / February 2009 / March 2009 / April 2009 / May 2009 / June 2009 / July 2009 / August 2009 / September 2009 / October 2009 / November 2009 / December 2009 / January 2010 / February 2010 / April 2010 / May 2010 / June 2010 / July 2010 / August 2010 / September 2010 / October 2010 / November 2010 / December 2010 / January 2011 / March 2011 / April 2011 / May 2011 / June 2011 / July 2011 / October 2011 / November 2011 / December 2011 / January 2012 / February 2012 / October 2012 / January 2013 /

FEED
You can get an atom feed for this blog.