Today was the starting day for EclipseCon, and for many years Monday has been tutorial day. These tutorials are included in the price of the conference ticket, and two three-hour tutorials fit neatly into the first half of the day, followed by an exhibitor’s receiption and the evening community event.
The tutorials I attended this year were Xtext and Xtend specific. Having said that, I was jealous of others in Benjamin Cab&eaccute;’s talk which was on Raspberry Pi and Arduino programming; however, whilst that’s just a passing interest to me personally the Xtend and Xtext basics were ones that I had been meaning to investigate in more detail for some time but never put the time aside to spend any significant amount of time learning them.
First up was the Xtext tutorial. For those that don’t know, Xtext is a parser generator/DSL/editor which can spit out not only a model of the code but also associated text renderers. There’s a lot of machinery under the hood to making such things work seamlessly, and many more API hooks for performing things like validation and generation than I would have thought possible.
I also now understand some of the syntactic elements in the Xtext grammars,
which aren’t immediately obvious, such as
foo+=bar* means that ‘foo’ will
be a list of zero or more ‘bar’ elements, and
a boolean value ‘option’ which is true iff ‘something’ is present. I’ve
never seen those explained before, and having it come to light suddenly
makes sense of a lot of things in the past.
What I didnt also appreciate was Xtext’s ability to generate content based on both a validator and a generator step. The default project has placeholders for both of these, though they default to no-ops.
There was also a lot of detail in how Xtext raises its suggestions and valid entries for scopes; unfortunately, the exercises took the group slightly longer than planned and so there was a cursory glance over these implementation details. There’s some documentation at the xtext site which makes about as much sense as before the talk …
Still, at least I got to talk to a few of the Xtext guys, and managed to put my view across that whilst whitespace-sensitive grammars are technically possible (and needed for languages such as Python, Makefiles and YAML) there are no open-source examples of using such a whitepsace-senstiive grammar. There’s a difference between ‘technically feasible’ and ‘practical’ which is just a little too big a chasm to cross at this point.
Still: mission accomplished; I know a lot more about Xtext than when I started, even if I now know that there’s more that I don’t know.
The next tutorial was on Xtend, this time on active cnnotations (a new feature in 2.4) and a functional programming quiz. Xtend is based upon the Xtext parsing suite, and translates into Java and then hands off compilation to the Java compiler – meaning none of the headaches usually seen with Scala and none of the blisteringly fast Perl-like performance of Groovy. It also helps that the language is statically typed, yet uses inference (like Scala) so that you don’t have to write repeated boilerplate code.
Active annotations are really very cool indeed; they provide a way of
annotating a class with an interface (like existing Java annotations) but
allows you to hook in a translation rule to say how the generated Java class
should be amended. In this way, it’s possible to define a
annotation that will automatically generate a
serialVersionUID field, or
@ToString generator based on the field contexts.
The exercises then jumped a few levels and dived right into a functional programming exercise. Xtend, it seems, depends on Guava (version 10, if anyone is interested) which I wonder what would happen if a program used a more recent version of Guava as well as Xtend functionality.
The probelm with the gear shift is that many features of Xtend becamse assumed,
such as the integration of the guilement quotes and template
There were also some aspects left unexplained, like extension methods and
how functions like
10.minutes were actually evolved (there’s a
method elsewhere in the example which takes an int, so
10.minutes is an
implicit extension method on
One thing I did learn was that functions which take a lambda as their last
argument don’t have to specify it in the argument list, but can simply place
the lambda after the expression in question. So a call to
also be written as
foo(1) , on the basis that lambdas often span multiple
lines and thus you don’t have to worry about bracket nesting. It looks tempting
to think of it as a partial function, but Xtend doens’t have those; it’s
just syntactic sugar to make it prettier.
I’m still pretty excited with Xtend in general; it’s no Scala killer yet (though Scala is doing a good enough job of killing itself) – but I think the killer feature of Xtend is going to get IntelliJ support. JetBrains have no interest in doing this, so I wonder if a port of Xtend to IntelliJ will have to happen, and essentially port the Eclipse editor into a runtime instance of IntelliJ. Without it, I think Xtend will remain a power tool for Eclipse users and Eclipse plug-in developers, but probably not in the wider JVM replacement language category just yet.
Eclipse community event
One of the nice things about Eclipse is that despite being a large community, events like these really bring everyone together. In this case, the awards ceremony awarded several projects and committers for their work, including a lifetime achievement award for Chris Aniszczyk, who has worked tirelessly promoting Eclipse and projects for all of the time that I’ve been involved with the Eclipse community. I think it’s an achievement well deserved.
There was also a ‘family fortunes’ (aka ‘family feud’ in American) in which I took part, and which our team lost. Oh well, it’s the taking part that counts …
Another great part of EclipseCon is the after-hours events. In this case, the Birds of a Feather sessions get like-minded people in a room to talk about or investigate a particular piece of software/technology. In my case, I went to the Raspberry Pi hackathon, in which I got my hands on an Arduino and a Raspberry Pi and actually did some programming/wiring between the two. Unfortunately I got a duff Pi, which meant that it took ages to do anything, but the Arduino was especially easy to program and hook up with a few hardware buttons and LEDs with a mini breadboard.
I also think I finally understand why a combination of Raspberry Pi and
Arduino makes sense, as opposed to an either-or. The Raspberry Pi is a
standalone computer, and can drive an HDMI screen, make network connections
and do general purpose programming, as well as a few pins for digital I/O.
However, the I/O pins on the Pi are directly connected to the CPU, so if you
do something wrong and fry the Pi then you’re out of luck. On the other hand,
an Arduino is quite hardy, and is able to deal with more rough treatment.
The program is less flexible, in that it needs to be connected to an EEROM
type programmer in order to be programmed. The Arduino makes this trivial,
as you can connect it to a USB port and then flash it with a new program
(they’re called ‘sketches’ for some bizzare reason) but on the plus side
the event loop is capable of polling for changes to any of the pins and
read them in as values, from which you can do simple processing and
manipulation. To do anything serious, you can punt the resulting values by
either serial port (cleverly, you can plug the Arduino Uno into the Pi’s
USB port and both power it and have a
/dev/tty for bidirectional communication
between the two). The Pi can then read these from the standard terminal,
and do more extensive programming and/or network transmission of the data
to a central location.
It’s also possible to hook up a Pi and an Arduino using more low-level technical methods, such as an I2C bus. I didn’t explore these but if a Pi needs to drive several Arduino boards then the I2C bus offers that possibility.
The Arduino kits also come packaged with several ‘shields’, which are really just daughter boards that can plug into the expansion slot. The shields are stackable, so it’s possible to plug one into the top of another, and then another on top. Each one has its own personality; some are used for controlling electronic motors, others can provide networking capabilities, and others still have just pins to which specially crafted backpacks or tinkerset items can be used to provide real plug-and-play electronics.
So, when I get back to the UK it’s time to get ordering some new miniature hardware.