All this functionality makes code slightly more readable. But last week I decided to add support for eachCons and eachSlice, and suddenly I realized that destructuring would be very nice to have not only in the explicit assignment case, but also in cases where you want to pick apart the arguments to an enumerable or sequence method. So I added those, which means that suddenly lots of code becomes much more simple.

Short story, in all Sequence and Enumerable methods, at every place where you could put an argument name, you can now put a destructuring statement instead. Let’s take a look at an example:

Point = Origin with(asTuple: method((x, y, z)))

points = [
  Point with(x: 42, y: 14, z: -44),
  Point with(x: 20, y: 0, z: 444),
  Point with(x: 31, y: 646, z: 3),
  Point with(x: 456, y: 14, z: 12)
  ]

distances1 = points consed map(obj,
  ((obj[0] x) * (obj[1] x) +
    (obj[0] y) * (obj[1] y) +
    (obj[0] z) * (obj[1] z)) sqrt)

distances2 = points consed map(
  ((x1,y1,z1), (x2,y2,z2)),
  (x1*x2 + y1*y2 + z1*z2) sqrt)

distances1 inspect println
distances2 inspect println

This code first creates a Point that can be coerced into a tuple of x, y and z coordinates. We then create a list of Points with different coordinates. We then want to calculate the three distances between the four points. We do this in two ways, using the old method and then using destructuring. The method consed is a sequence version of eachCons. The default cons length is 2, so this will yield three entries with two points in each. We then call map on the sequence. We will get a List of two entries, where each entry is a point. Finally we use Pythagoras to calculate the distance.

The second version is very similar - the only difference is that instead of using the square brackets to index into the lists, we instead give a pattern. This pattern contains two patterns, and the variable names inside of it will be bound to the right parts of each point.

At least in my mind, the destructured syntax is much more readable than the original one. And remember, this works for anything that can be turned into a tuple, which means you can use it on any Enumerable - you can use it on a Pair (such as what a Dict will yield) or any thing you would want to add asTuple to on your own.

We already have some solid speakers lined up. Chad Fowler will keynote, and so will I, and we have a number of other people coming in. A few of my colleagues from ThoughtWorks, such as Sarah Taraporewalla, Sidu Ponnappa and Aman King. Other speakers include Hemant Kumar, Pradeep Elankumaran, Arun Gupta and others. Finally, Nick Sieger will also come to Bangalore for this event!

So as you can see, this is gearing up to be a great event! Hope to see you there.

Ioke is a language that is designed to be as expressive as possible. It is a dynamic language targeted at the Java Virtual Machine. There also exists a version for the CLR. It’s been designed from scratch to be a highly flexible general purpose language. It is a prototype-based programming language that is inspired by Io, Smalltalk, Lisp and Ruby.

Homepage: http://ioke.org
Download: http://ioke.org/download.html
Programming guide: http://ioke.org/wiki/index.php/Guide
Wiki: http://ioke.org/wiki

The two specific releases that encompass Ioke P are ikj 0.4.0 and ikc 0.4.0.

Ioke P is the fourth release of Ioke. It includes many new features compared to Ioke E:

• Number Infinity
• eval
• Reflector
• Hooks
• First class Runtime
• New parser
• Tuples
• Structs
• Destructuring assignment
• Message rewriting
• Functional composition
• Sequences
• Dictionary and Set versions of Enumerable methods
• Enumerable group, Enumerable groupBy
• Set operations for union, intersection, membership, subset and superset testing
• ISpec stubbing and mocking
• IIk history
• DokGen on separate projects

Ioke P also includes a large amount of bug fixes.

Features:

• Expressiveness first
• Strong, dynamic typing
• Prototype based object orientation
• Homoiconic language
• Simple syntax
• Powerful macro facilities
• Condition system
• Aspects
• Java integration
• Developed using TDD
• Documentation system that combines documentation with specs
• Runs on both the JVM and the CLR

The many things added in Ioke P could not have been done without the support of all the Ioke contributors. Thank you!

Regards
Ola Bini    - ola.bini@gmail.com

Another thing you might notice is that your Ruby environment is messed up - all the gems you so carefully installed isn’t around, and overall things just seem weird. One thing that could cause this is when you have a custom built Ruby installation in for example /opt/local or /usr/local instead of /usr. But Emacs just seems to pick up the original versino that shipped with OS X.

The reason for all these weird behaviors is that if Emacs is started from the Dock, or using the application directly, it doesn’t actually pick up the carefully prepared PATH variable you have in your terminal. Instead it will go ahead and use the default system PATH, which is very restrictive.

The way I prefer to solve this is to make sure that OS X plist version of the PATH variable is the same as my terminal one. I do that by resetting this plist on every login. Of course, OS X will not actually reload this without a reboot. If you just want to fix this once - and you’re reasonably sure you won’t change the path again, you can execute this command from the terminal and restart. Everything should be fine after that. The magic incantation looks like this:

defaults write $HOME/.MacOSX/environment PATH “$PATH”

(Note, I’ve had to solve this problem twice, since the first time I encountered it I didn’t blog about it. So now I’m blogging so it might also stick in my long term memory. Maybe it’s enough if it’s in my blog term memory…)

First QCon - after JAOO, QCon is my favorite conference. They always manage to put together an interesting week with great speakers and lots of things to learn. This year, me and Martin Fowler did a full-day tutorial about domain specific languages.

During the Wednesday I spent most of my time hanging out and chatting with people. I did attend Josh Blochs and Bob Lee’s Java Puzzler presentation. This is always an entertaining hour. I also enjoyed Douglas Crockfords keynote about the history and future of JavaScript. Hearing how this all happened is always enlightening.

On the Thursday I had my track about languages. I think it went very well, my speakers did a great job. Eishay Smith talk about Scala, Stu Halloway about Clojure, Martin Fowler about Ruby, Jonathan Felch about Groovy and Amanda Laucher and Josh Graham about F#. I’m very happy with how it went, actually.

During Friday I mostly sat in on Neal Fords DSL track. My colleague Brian Guthrie started out with a strong hour about internal DSLs in various languages. Ioke got a few code examples, which was fun. After that Neal and Nate Schutta talked about MPS. I haven’t seen this much detail about MPS before so it was helpful.

After lunch Don Box and Amanda Laucher did a talk about the technology formerly known as Oslo. I didn’t think this tech was anything cool at all until I saw this presentation. In retrospect this was probably my favorite presentation of the conference. What came together was how you can use M as a fully typed language with some interesting characteristics, and also the extremely powerful debug features. It’s nice indeed.

Glenn Vanderburg put forward some arguments against language workbenches. This made for an interesting hour but I’m not entirely sure I buy his arguments. And after that Magnus Christerson from Intentional showcased what they’ve been working on lately. Very impressive stuff as usual.

I only spent one day at RubyConf, but it was still enough to get a feeling for what was going on, spend some time with several people I haven’t met before and so on. Good times. Charles Nutter did a very good presentation about his Ruby mutants (Duby and Surinx). After that Ryan Davis and Aaron Patterson did a hilarous presentation about weird software.

JRubyConf was a total success. All of the presentations were very interesting, and provided insight into what people liked about JRuby and what they wanted from it. It was fantastic to see so many people come together just for JRuby. It’s great to be part of that. I did a presentation about testing with JRuby, and then I was part of the closing panel. Both went well.

All in all a great week of conferences.

First QCon San Francisco. Except for JAOO, QCon is the best general developer conference I’ve ever been to. Go check out the schedule at http://qconsf.com. This year I’m very excited about doing a full day tutorial about domain specific languages together with Martin Fowler.

I’m also in charge of the languages track, where I have five people who will talk about their experiences with different languages. This time there will not be much introduction to the languages, but instead experience reports, objective descriptions of what worked, what didn’t work and how you can improve your chances of success. The languages covered are Scala, Clojure, Ruby, Groovy and F#. Should be great fun.

Hopefully I will have lots of time to see other presentations too. There are many I would love to see. ThoughtWorks also happens to be a sponsor of QCon, so there will be a booth where it’s a big possibility you can find me or my colleagues.

I will do one day of RubyConf - the Saturday. Funnily enough I haven’t ever been to RubyConf, so I’m looking forward to this too.

Finally, the first ever JRubyConf will happen next Sunday. The program looks really interesting. I’m going to be talking about testing, and also be part of the ending JRuby Core Team panel.

I’m very excited about these conferences. Hope to see you there!

But a big part of it is basically just the fact that Øredev is an outstanding conference.

Some of my impressions, things I learned and did in no specific order:

• Hadoop is really cool and I wish I had time to learn more about it. Alex Loddengaard from Cloudera did a very good job introducing this technology in his tutorial. We got to do way fun stuff!
• People liked my talk about Ioke - and I was very happy with how it went too.
• Stuart Halloway is really good at introducing Clojure - I’m looking forward to his talk at QCon SF even more now.
• Me, Tyler Jennings, Neal Ford, Dan North and Stuart Halloway spent several hours of BoF time to create a new BDD framework for Clojure - this was way fun hacking, interesting from a group management and design perspective and just plain fun. There is a distinct possibility that me and Neal will give a talk at the TW US Away Day about this, if anyone is interested.
• Ze Frank is amazing. Really great evening keynote/entertainment.
• Niclas Nilsson and Hans Brattberg did a very accurate depiction of common problems and failure modes of pair programming. Good stuff.
• Tyler Jennings gave an introduction to Software Craftsmanship. Glad I didn’t miss this presentation. Very nicely done.
• Kevlin Henney did a great presentation about agile modeling. I enjoyed it a lot.
• We did a very fun closing panel that was basically just six geeks disagreeing about lots of stuff. I hope everyone else enjoyed it as much as the panel members.

Conclusion: Øredev was a great conference, I was honored to get the chance to speak there and I’ll definitely try to go back next year.

One of the discussions related to DDD that have turned up several times the last few months at conferences
is how you handle ubiquitous language when your domain is not in English. Since most programming languages are based on English, you end up mixing English and Swedish for example, if you are working with a Swedish domain. Of course, the benefits of working with these concepts in Swedish are very hard to argue against. But the dichotomy between the programming language and the domain language is definitely something that hurts my eyes, so I’m generally not very fond of that approach.

In fact, I haven’t heard anyone come up with a good solution to this problem, and this post is not really a solution either.

One of the things I’ve proposed to make this situation better is to create an external DSL that is fully in the domain language. The implementation of that DSL can then be implemented in English. The main benefit is that there is a clear separation.between the domain language and the programming language. On the other hand, the overhead of creating the DSL and also the complexities involved in translating the domain concepts into programming language concepts can become problematic too.

One interesting idea in Cucumber is the idea that you can easily add new natural languages to write the features in. When it comes to user stories at the level of testing that Cucumber provides, it’s really important to use the right language. So it got me thinking, could you use the same kind of approach in a general programming language too?

As an experiment I took a small example program for Ioke, and translated it into Mandarin, with simplified Chinese characters. Of course I used Google Translate for this, so the translation is probably not very good, but the end result is still interesting. I’m not going to try to get this into my blog, so take a look at the file at github instead: http://github.com/olabini/ioke/blob/master/examples/chinese/account.ik. As you can see there is nothing in there that even reeks of English. If you don’t understand Chinese characters it is probably hard to see what’s happening here. Basically an Account object is created, with a “transfer” method and a “print” method. Further down, two instances of this Account object is created, some transfers are made, and then the objects are printed. But provided my translation is not too crappy, this code should make sense to someone reading Chinese.

Now, this is actually extremely simple to implement in Ioke, since it relies on several of the features Ioke handles very easily. That everything is a message really helps, and having everything be first class means I can alias methods and things like that without any worry. Obviously your language also need to handle non-ascii identifiers correctly, but that should be standard in this day and age.

When thinking about it, something similar to do this can be created in languages like Lisp, Smalltalk, Factor, Io and Haskell - but most other languages would struggle. If you have keywords in your language, it’s really a killer - you would need to branch your parser to make it happen.

Of course, this approach only works when you can simply translate from one word to another. If the writing system is right to left, or top to bottom, it’s much more tricky to create a good translation.

I’m also not sure if this is actually a really good idea or not. It might be. The other thing I’ve been thinking about is how to handle multilingual editing. What if you want to be able to switch back and forth between languages? How can you handle identifiers with more than one name. Would you want to?

Lots of unanswered questions here. But it’s still funny to think about. Communication is the main goal, as usual.

The argument usually goes like this: “Dynamically typed languages are fine for smaller programs and simple web applications, but if you’re building something big, something that will be several millions of lines of code, you really need all the tools you can only get from a statically typed language”. Where the statically typed language mentioned is typically Java. The argument is still common enough without any specific language name mentioned though.

Interestingly, there are several problems and fallacies in this seemingly simple argument. I’m not going to tackle all of them here, but just focus on the beginning. Namely the idea that you are building something big. First of all, how do you know that? Have you done anything like it before? And how do you know it would be big in a different language? How do you know you can’t decouple the application in such a way you won’t have to build anything big? There are so many assumptions that can be questioned here. But at the end of the day, my glib answer that summarizes this usually goes something like this:

“Optimizing for your software project becoming big is the same as optimizing a car to hit a rock wall - you are optimizing for failure”

I firmly believe that becoming big is really failure. Once you have a big enough project you have lost. It might still work, but the cost will be extreme, and maintaining it will be a large burden too.

This is the reason I like agile. It emphasizes small, working pieces all the time. If you work with code this way, you can’t really become big. Instead, your project will be forced to be modularized and divided into smaller, more logical components that are highly cohesive and decoupled from each other.