The best programming language

This blog post is also available on the Fortnox developer blog.

A couple of weeks ago a friend of mine posted a very open (and admittedly pretty bad) question on #VXODEV, the local Slack developer community here in Växjö. The question can roughly be translated into something like ”Which [programming] language is the best?”. Naturally he and the members in the channel knew that there is no such thing as the ”best” programming language. Instead, the question was asked to get a discussion going on why people prefer one language over another. From my perspective as a novice Clojure enthusiast I had to stop and think for a moment. Why do I keep picking up Clojure for my late night hacks over other languages?

It’s not like Clojure helps me to solve problems that cannot be solved with other programming languages. Sure, it is true that a particular technology may be more performant or better suited for a particular task than others, but in most cases it doesn’t really matter.

Take for instance the Advent of Code (AoC) challenges that I’ve been having fun with lately. In these challenges you are free to choose whatever technology you want to use when solving the puzzles. Wouldn’t it then make more sense to just pick up the programming language you feel most comfortable and productive with? My main language as of now is with no doubt Java. I have been working as a Java developer for many years now, and I am pretty sure that I would solve challenges in AoC a lot faster with that language than with Clojure. Despite this I’ve not considered using Java in any of the challenges as of yet.

Perhaps the programming paradigm supported by the language has something to do with it? Clojure is a functional programming language, and the declarative style of programming that comes with that paradigm is something I’ve grown quite fond of.  The thing is that nowadays Java also has support for functional programming; since version 8 of the Java language developers can apply functional programming in their code. And while Clojure is predominantly a functional programming language, other languages that fall into a similar paradigm category, e.g. Haskell, pretty much lie in my toolbox collecting dust. Which in a way is kind of sad as Haskell is cool.

At the time of writing this blog post I looked through the history of the Slack channel to check what my answer to the ”which {programming] language is the best” question. It read something like the following: ”I haven’t come up with an answer yet, but what I do know is that I’m having a great time writing Clojure code”. And I think that ”a great time” is a pretty sound argument here. I mean, if you spend time in the evenings writing code it should be fun, right?

But what is fun for you may not be fun for me. For instance, a TV show may have some qualities that you enjoy but I don’t appreciate as much. Some of those can be quite obvious and be put into words, e.g. ”I don’t like sci-fi”. Other qualities are more or less based on feelings that are not as straightforward to identify and express. They just feel right and makes things interesting enough to make you watch the entire season of the show. It’s like, ”hey, this hammer feels nice in my hand so I choose it over the other ones in my toolbox”, but there is no single and obvious explanation why.

With the above ramblings in mind, I guess the ”best” programming language (for you) is a language that through some desired qualities makes you enjoy the creative process of programming.

But then again, there is no such thing as the best programming language (at least in the general sense). 😉

I’ll end this little text with a related blog post about how programming languages may relate to different personalities. Enjoy!

Until next time!

Advent of code

Den här bloggen börjar bli lite väl rörig nu rent språkligt. De senaste inläggen var främst ämnade för jobbets blogg och jag passade då helt enkelt på att kleta in texten på den här bloggen också. Det kan nog bli rörigt igen nån gång framöver, men om inlägget är tänkt att bara hamna här så kommer jag i fortsättningen att skriva på svenska. Även om det inte är jättemycket knepigare för mig att skriva på engelska är svenskan mer bekväm för mig, och ska jag ändå skriva här för mitt eget nöjes skull väljer jag att ha det bekvämt. Det är ungefär samma sak när jag väljer böcker att läsa. Finns de på svenska tar jag gärna den svenska varianten just eftersom det blir mer bekvämt. Man ska ju ha det bra.

I vilket fall ville jag med detta blogginlägg lobba för Advent of Code, en slags julalmanacka för programmerare där man får en ny uppgift att lösa varje dag fram till julafton. Eller nja, det läggs ut uppgifter varje dag fram till och med den 25 december eftersom amerikanarna är som de är, men det gör ju inte så mycket med en bonusuppgift. Varje dag får man en ny del i en pågående historia i vilken man ska hjälpa jultomten i olika sammanhang genom att hacka loss. Har bara testat på de två första so far (här är kod på github)  men hittills har det varit lagom svårt och helfestligt. Kul också att få jobba vidare med Clojure, börjar faktiskt bli varm i kläderna med med de grundläggande byggstenarna i språket.

Ni som läste mitt föregående inlägg märker att inläggens teman (och nej, jag menar inte julen) hänger ihop. Det här med små, fokuserade uppgifter som ska lösas inom en viss tid är något som funkar skitbra för mig. Det är lätt att dagarna bara rinner iväg bland alla småbarn och då är det svårt med stora projekt. Det är lite som med TV-spel. Jag älskar stora svulstiga rollspel som kräver hundratals speltimmar, men grejen är att det är svårt att få något gjort i sådana spel när livet går i 110 km/h. Man blir liksom aldrig färdig.

Till exempel försökte jag för ett tag sedan ge mig på The Witcher 3. Jag hade hur kul som helst den kvällen och hade då tid att spendera flera timmar på spelet. En vecka senare när jag hade tid igen hade jag glömt bort hur man styrde. Och vad var det för prylar jag hade i mitt inventory? Likadant med Bloodborne – att spela 1-2 kvällar i veckan fungerar inte för att hålla koll på vad man har gjort och vad det var man ska göra härnäst.

Då funkar lite strömatcher i PES eller FIFA bättre. Eller varför inte en challenge i Advent of Code?

What do to?

One thing that tend to be a bit problematic for me whenever I want to try out a new programming language or technique is coming up with something meningful to do. ”Hello, world!” is obviously a good place to start, but where do you go from there? Perhaps you have some functionalty that you kind of always implement as a kind of reference, and that’s great! That approach hasn’t quite worked out for me as of yet.

For me, the ideas that get me going are commonly too complex and ill-defined to be suitable being new to a programming language. The result is most often a pile of code far from the grand and not very clear vision I had from the beginning. And that’s not very fun.

Now, a couple of months ago, a former colleague of mine told me about some programming challenges posted weekly by Jamis Buck. Prior to that, I had spent a couple of evenings trying out Clojure, but as ususal my idea was too grand with respect to my limited skills in the language. I decided to leave the pile of code to rot and instead start hacking away at the current weekly challenge, which was about finding the shortest path through various mazes.

It took a couple of evenings for me to complete the challenge, but in the end there it was (and here it is on GitHub). The problem to solve was crisp clear, and the solution, implemented in a language new to me, fullfilled the given requirements. The code was far from perfect, but it worked and the solution was complete. And that felt pretty good when compared with the usual pile of code that doesn’t really do anything.

I guess you can find programming challenges all over the web if you look for them, but for me the format that Jamis Buck have come up with is pretty sweet. After some thought I think the reason why this format works for me can be summed up by the below three key points:

a) The problem to solve is well-defined and limited
b) There is a deadline
c) No pressure, just fun

I think I’ve made my argument about well-defined problems and being new to the programming language at hand pretty clear above. Along with being well-defined, the scope in his challenges are limited and require not too many hours to complete. The normal mode for solving a challenge usually takes an evening or two of work, depending on how comfortable you are with your language and the algorithms to apply.

Another key thing is the deadline. To have a date when you need to finish means that you can’t polish your code forever. You have to let it go and, before the time is up, publish it somewhere (e.g. on GitHub) in order to submit your solution. And I think that is something valuable as well, to practice in being comfortable with exposing your code publicly.

Moreover, you get to see the same problem you’ve been working on solved in various languages and with different approaches. The way you ”hand in” your solution is by posting a comment in a web blog post, so you can have a look at all the other attempts there as well. It’s pretty cool to see the challenge implemented in Javascript, Clojure, Haskell, Elm and whatnot.

And finally, it’s okay if you don’t get there. You don’t actually have to post your solution at all, so there is no pressure at all.

Just fun.

Paradigm crisis

Detta inlägg finns även att läsa på HRM Softwares teknikblogg!

Ever since I took the Haskell 101 course I have gradually entered a state best described as a paradigm crisis. Prior to that course I happily hacked away in an object-oriented fashion, and I felt pretty confident in how to tackle problems when I faced them. I knew the most commonly used design patterns and how to look up the ones not that frequently used when needed.

Then came functional programming.

Admittedly I was not immediately convinced when I took my first steps in the Haskell 101 course, and I think the reason for that was that I did not quite see where these new functional tools would fit into my very object-oriented toolbox. Somewhere in that toolbox, along with factories and decorators, I had to find room for map, fold, filter and other functional concepts so I could easily find them.

It turned out that I actually needed a whole new compartment in my toolbox, as object-oriented programming and functional programming indeed are two very different paradigms.

It is true that we in the hybrid world of Java 8 can mix these two paradigms as we see fit, but when we are writing functional Java we leave the object oriented paradigm for a moment and become declarative and immutable, which is really cool. For me as (mainly) a Java programmer, the functional style of doing things are increasingly becoming my first-hand choice. I mean, what’s the point of for-looping a list of elements when all I want to do is to grab some elements that matches a given predicate? The ”old way” of doing this is way to error prone to be worth it. Moreover, when we leave out the ”how” part when working with collections, the language can apply optimizations to the ”how”-part. The declarative style of programming allows you to work on a higher level of abstraction and let the language worry about the specifics of ”how”.

Now, the leading paragraph of my blog post mentioned the word ”crisis”, which intentionally was a strong word to get your attention. 😉 Although the new compartment in my toolbox have complicated my professional life a bit – especially at the time of writing when I am still a newcomer to the functional paradigm – I have noticed that I am starting to think about how to attack problems a bit differently than before. When in the object-oriented world, you would use all kinds of design patterns and language constructs to control mutability of objects in order to get a fair chance to understand and reason about what’s really going on. In the functional world, you would instead work declaratively on immutable data structures, which means that we write code on a higher level of abstraction without the need to worry about mutable data.

And suddenly, the new functional toolbox compartment seems really compelling.

I have to admit that I may be a bit over enthusiastic right now, I usually behave like that when I try out new things that I like. But when listening to Martin Odersky in yet another course I’m enrolled in on functional programming I find it a bit sad that object-orientation turned out like it did in languages like Java. I mean, why is everything mutable by default? That doesn’t make sense. And why did the programming courses I took at the university teach this mutable object-oriented way of programming? As far as I understand, imperative programming where everything is mutable has been a well-known problem for decades.

Time to sum up this blog post with a stupid quote coined by myself over a cup of coffe: functional programming is like sudoku! 🙂

Event storming

Detta inlägg finns även att läsa på HRM Softwares teknikblogg!

Lately I’ve spent some time catching up on what’s happening in the Domain-Driven Design (DDD) community through watching sessions recorded at the Domain-Driven Design Europe 2016 conference. The session I watched yesterday was about something called event storming – a concept that was new to me but so simple and seemingly powerful that it got me quite worked up. The purpose of this blog post is not to go into details of how event storming works, but rather to convey my initial thoughts of why the idea is worth thinking about.

When running an event storming workshop you only need a few basic things:

  • post-it notes with different colors
  • a lot of space to place the post-it notes on (e.g. a large whiteboard or a paper roll)
  • the right people

The right people are key in event storming and should involve a moderator, developers, domain experts and other people involved that can contribute when storming away at the problem at hand.

Domain events

With all these smart people gathered in a room, you start with identifying a few core domain events. A domain event is formulated as something important that can happened in the domain under analysis, e.g. ”ticket purchased” or ”seat reserved”. As you can see, domain events are always expressed in past tense. Each domain event is written down on a post-it note with a specific color – the resources I’ve found online so far suggests orange stickers by convention – and placed on the whiteboard from left to right in order of occurrence in the business process we are analysing. This means that we get a visual representation of the business process flow to see when the various domain events occur.


During the identification of domain events we also need to ask ourselves how they are triggered. For instance, the domain event ”ticket purchased” might be a consequence of a user placing an order via a web application. The act of placing an order is, in event storming terms, a command. A command is something that generate domain events and is expressed through blue post-it stickies. Commands are formulated in present tense, e.g. ”purchase ticket”, and placed on the whiteboard just before the domain event(s) that are generated as a result of the command. For example, a ”purchase ticket” command should probably be placed just before the ”ticket purchased” domain event to signal that they belong together.

The flow of the workshop

With the two core concepts of commands and domain events, the participants of the workshop keep exploring the problem area to gradually refine and expand it. As the notion of event storminig stems from DDD, we take extra care to capture the ”ubiquitous language”, i.e. we want to make sure we are naming things so that it makes sense for the business problem we are trying to solve. Participants in the workshop are encouraged to question things, no matter how trivial they may sound. Is ”ticket” really the correct word? Is it to general?

It is during the ongoing discussion, with post-its being replaced and moved around, we hope to nail the complexity of the domain problem. Suddenly, a domain expert states that there should be a way to reserve tickets. And by the way, you should be able to get a refund if you cancel your ticket purchase within a given amount of time. The complexity of the problem gradually reveals itself, captured in a process time flow and grouped by commands and domain events on a whiteboard covered with colored post-it stickies.

What do we get out of this?

It should be noted once again that I’ve not actually tried this workshop format, but in my mind it really makes sense. The idea is super simple and the potential outcome of it is interesting in several ways. First and foremost, we can express the components of a problem we are trying to solve (and how they relate to each other) with terminology that comes directly from the domain experts. Another neat thing is that commands and domain events map really well to implementation. They are a natural fit for CQRS and event sourcing, but when you think about it, commands and domain events can be mapped pretty well to any kind implementation technique. Something triggers an action (command) that produces some kind of result (domain event).

Final notes

Event storming include more stickies for e.g. highlighting actors, UIs and domain models. Moreover, as we are in the DDD world, we can map related commands and events to a particular aggregate and express that directly on the whiteboard by simply grouping them together. The same goes for bounded contexts; to group aggregates into a bounded context you just draw a line around the involves post-it stickers with a whiteboard marker.

For those of you versed in DDD, we can start drawing a context map from here, but that’s the topic of a blog post for a later time.

This blog post was authored by Martin Moberg.