Time For Change: Recognizing When Your Current Ride Becomes Too Sloppy | Mendix

Skip navigation

Time For Change: Recognizing When Your Current Ride Becomes Too Sloppy

Time For Change: Recognizing When Your Current Ride Becomes Too Sloppy by Arjan van IJzendoorn

Do you recognize the feeling that something has to change? Starting subconsciously and barely noticeable, but becoming louder and louder up to the point you simply cannot ignore it any longer. Whether “the itch” is about the place you are living in, about your current job or about the way you relate to people close to you; certain aspects of life should change once in a while, however scary and complicated change might seem. While problems like these are most apparent for ‘the big things’ in your personal life (and these are also the most daring ones to change), this also holds for other areas.

To code or not to code

When I went to university in 2001 I learned to program in Java. My first encounter with programming gave me a somewhat mixed feeling. While I like solving puzzles, learning to program was a bumpy road. After the first two courses I was quite sure software development would not be my first choice to pursue a career in.

Nevertheless, I somehow found myself working as a software developer in 2007. Although I had become more proficient in programming during the later years of my study, I still was not certain whether this was the career path I should follow. This changed quite quickly at the highly inspiring environment of a start-up with a bunch of young, intelligent people (among whom a couple of very bright programmers). Learning was easy and fun in this environment and I really started to like to program. Moreover, I realized programming has much more to do with language than I thought and less with highly technical aspects than I assumed (whatever ‘technical’ really is). I have always had a great interest in languages, so ‘coding’ turned out to be a better fit than I thought.

It’s not all peachy

Java was my first programming language and Java was also the language of the Mendix Server Runtime, my foremost programming domain. There was a lot to like about this language, certainly during that time. Java has static typing, object orientation, garbage collection and much more nifty features. However, working intensively with a language for five years inevitably confronts one with its limitations. At first these only seemed minor imperfections, or perhaps there was a neat solution that I had not learnt yet, but after a while more and more frustrations arose and a persistent voice in the back of my head started saying “time for change, time for change, time for change”.

One of my main frustrations was Java’s verbosity and related to that its lack of functional constructs. Reading code takes a lot of time. Studies of software maintainers have shown that approximately 50% of their time is spent in the process of understanding the code that they are to maintain (Fjeldstad & Hamlen, 1983; Standish, 1984). I felt we could be so much more productive if our code would become more concise and we could express ourselves in a more powerful way.

Sort out the mess

To illustrate the above, consider the following example: in Mendix, when a retrieval request for certain objects is received in the server runtime, the sort parameters are filtered for virtual attributes. Virtual attributes consist of computed values which the database cannot sort on. These sort parameters are removed before issuing a database request.

One way to accomplish this task is to iterate the map entries, pick the non-virtual attributes and put them into a new map:

Map<String,SortDirection> filteredMap = Maps.newHashMap();
for(Entry<String,SortDirection> entry : sort.entrySet())
    AttributePath attributePath = parsePath(entityName, entry.getKey());
        filteredMap.put(entry.getKey(), entry.getValue());

Seems pretty standard…and is, when you are used to Java. However, the explicit iteration over the original map and having to use put methods on the filtered map is not very clean and quite verbose.

These redundant explicit actions can be avoided by taking a more functional approach. The following code example uses the guava library from Google (which is very useful by the way) to attempt a functional implementation:

Map<String,SortDirection> filteredMap = Maps.filterKeys(sort, new Predicate<String>()
    public boolean apply(String path)
        AttributePath attributePath = parsePath(entityName, path);
        return !attributePath.getAttribute().isVirtual();

This approach is much better, as no explicit iteration and no put methods are needed anymore. The syntax, however, is awful. The anonymous class declaration is way too verbose and makes the code barely more readable than the previous attempt.

This is one of the many examples where I felt limited in how I could express myself in Java. A lot of these cases could profit from a concise functional syntax. Besides the need for more functional constructions, bloated code due to verbose constructors and get/set methods and the lack of tuples also made me longing for a new language.

Time for change

At some point you will recognize your sloppy old car is just not good enough anymore and an upgrade to a more modern model is in order. In my case Java was this sloppy old car and I felt the time had come to start investigating other options. The results of this investigation will be the topic of my next blog post.

What are your experiences with the programming languages you have used for a long time? Did you feel the urge to change language after a while? What triggered this desire for another language? Interested in hearing your thoughts!


Fjeldstad, R. & Hamlen, W. (1983). “Application program maintenance-report to to our respondents”. Tutorial on Software Maintenance, 13-27. Parikh, G. & Zvegintzov, N. (Eds.). IEEE Computer Soc. Press.

Standish, T. (1984). “An essay on software reuse”. IEEE Transactions on Software Engineering SE-10 (5), 494-497.

Photo by Gill Steenvoorde