Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

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

on April 12, 2012

Share:

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

Rusted Out CarWhen 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());
    if(!attributePath.getAttribute().isVirtual())
        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>()
{
    @Override
    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

Tags:

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog

About Arjen Hoekstra

Software Developer at Mendix.

  • Bart Tolen

    I do agree with the verbosity and lack of certain constructs and have looked at Haskell and Scala some years ago. The functional and especially generic way of programming helps a lot.

    Maybe a good compromise would be Scala which can run in a JVM (or .Net runtime for that matter). You could gradually transform Mendix in an application written in Scala 🙂

  • In Smalltalk, that would be:

    filteredMap := Dictionary withAll:
    (entrySet reject: [:entry | (self parsePath: entityName key: entry key) attribute isVirtual])

    I guess if you have a classic car that still runs well and gets improved all the time, you don’t feel much need to change :-). Some people think classic cars are cool, others think they aren’t trendy, but I just like getting from A to B faster and being happy while doing it.

    For a server-side app people can’t see what it’s built in, so your main question would be migration cost and learning a new language. I can’t see much point in migrating – generally not enough gain for the pain – but if you need a major new version, approaching a rewrite, Smalltalk would be one option.

  • skin27

    Projects like Google Guava and project Lombok makes it a lot easier. Scala is well established alternative on the JVM platform. Clojure has a nice functional approach.

    Some new interesting projects on the JVM like Kotlin, Fantom, Xtend and Ceylon have also a much less verbose syntax. Besides that you can now run Python (Jython) and Ruby (JRuby) also on JVM. A non-JVM language with a clear syntax is IBM’s EGL.

  • You should really have a look at Xtend (http://xtend-lang.org/, from the guys that brought us Xtext): compiles down to Java, but with a much cleaner syntax, real closures and such.

    As an example, your 2nd code sample would reduce to:

    val filteredMap = Maps::filterKeys(sort,[ String path | !parsePath(entityName, path).attribute.virtual ] )

  • Arjen Hoekstra

    Thanks for your reactions! 
    I investigated most of the languages you mentioned, in my next blog post I will report my findings.

  • I would bet my money on Scala and anything with DSL capabilities. Cleaner code doesn’t seem like a pragmatic gain from an execution perspective, but it does make sense having code that is easier to read, understand and maintain. With Scala you retain the Java eco system to a degree, still have Object Orientation, have the bonus of functional programming and the appearance of a dynamic language with the benefits of a static language.