Posted on

Monkey see, monkey love

Disclaimer: The following content expresses my own opinion and does not aim to represent circumstantiated facts.
Google, IDEA, IntelliJ, Java, Kotlin, and other names, brands, products mentioned in this post are trademarks of their respective owners.

Everybody loves Kotlin, right?

It’s the best language on the JVM! It’s as fast as Java, less verbose, it provides better null handling (because heaven forbid that we stop using them), etc, etc… A true miracle of modern software engineering!

And it’s also young, cool and if you are not using it well… you are obviously a moron!

“Why?” you ask? Well, because everyone says so, of course!

And why does everybody say so?

To give my answer to this question, let’s go back a couple of years…

True Story!

I happen to work in a great environment, yet many of my coworkers – while being good fellows – are of the most conservative and rigid sort.

They have Java (and Typescript which I think I can safely call “browser java”…), Java is their shepherd and they shall not want.

When I tried to interest them in anything else, the reaction has always been: “back off, Riccardo, with all your Clojure and LISP nonsense!”.

But then they added:

“Kotlin seems interesting, though…”.

“Why?” I ask.

No conclusive answer.

They know nothing about it. They never read a book or an article about it, they never coded with it, there is not a single project they know about where Kotlin is the key factor. They just happen to “find it interesting”.

And let’s be clear, most of them never heard of Lua, Clojure, Elixir, Erlang, Haskell, or other languages before knowing me. Maybe (just maybe) they heard about Scala.

But still, they do recognize Kotlin as a potential Java replacement. They know it’s most likely a good thing.

This leads us back to the first question:

Why it seems that anybody considers Kotlin the best next thing after sex?

Conspiracy time!

Here is my little conspiracy theory: keep in mind that everything that follows is pure speculation, I’m not pinning anything on anybody.

Kotlin is an IntelliJ creation, the same company that makes the (excellent) Idea IDE: that they are pushing their language on every turn is no surprise.

But then, there is also Google.

Google is all over Kotlin, with its tech evangelists oozing loads of virtual ink on it, Bukkake-style.

Did you know that Kotlin is the best language for Android development?

I’m sure Google would have let you know by now.

Care to try a new young, cool, slim language? Kotlin is the language for you: even we, at Google, use it!

How many Google developers are actually using Kotlin by the way? 50%? 107? 2? We will never know…

It would look as if Google is drinking the Kool-Aid from IntelliJ, except that Google is smart and we – the developers – are the morons who are drinking it!

I don’t know if this is really how it shook out, but If I had to put my money somewhere, I would bet that Google received Android Studio from IntelliJ almost for free.

Why?

Because Google used us suckers as a currency to pay them.

How?

By pushing for every technology Idea puts into Google’s mouth.

Kotlin could be the best language for Android development because it’s the language provided to Google by Idea and because – I would think – Idea has also provided all the manpower for the porting Kotlin on the platform, just as I’d say they provided the manpower to put a bow on IDEA and gift it to Google as Android Studio.

Google is pervasive and ubiquitous: should Idea want to shove Kotlin down our throat, would it be so strange for it to want to have Google on its side?

Remember when I said that “it seems that anybody considers Kotlin the best thing after sex?”. Well, I think that the “anybody” I was talking about is mostly Google.

The apple of our eyes

Take the most rigid, focused, and conservative Java developer on the planet, and, no matter how indifferent he may be about other languages, you can bet IDEA or Google has slapped Kotlin on his face at least once a day.

And, I think, this is all it takes to inspire trust in otherwise rational human beings.

“If IntelliJ created IDEA which is so damn good, then Kotlin must be good as well, right?!”

“If Google that’s so big and powerful uses Kotlin, it must be that Google is big and powerful because it uses Kotlin!”

It’s as I wrote in the title: “monkey see, monkey love”.

I think I can almost hear you.

“How do you dare to compare us to monkeys, Sir! We, the developers, are not common human beings! We talk with computers! We have degrees in Physics, Mathematics, Engineering!”

This is the hubris that gets us: we think we are so special, so rational, so smart, but in the end, as humans, we have just the same cognitive biases as everybody else.

Conclusions

“But Riccardo” you may say “even if that may be true, in this way Google doesn’t have to develop a half-assed IDE, Idea gets the advertising it deserves and we – the developers – get great tools to work with. Aren’t we all winning? What’s the problem?“.

The problem is that the same company that created our IDE may be aggressively pushing for its (mediocre) language to replace the one we came to it for in the first place, and could be doing it without being upfront about it.

Another problem is that it may be trying to establish a monopoly and incorporate us into an ecosystem where they control all the variables.

Isn’t it funny?! We got to them because they provide the best IDE for Java around, and they could end up using it to defeat the competition and making us leave Java in the first place!

Doesn’t that bother you?

Well, maybe you are right. I’m overreacting. Don’t worry about it.

Have a glass of Kool-Aid, instead: it’s on me!

Posted on

Good fences make for good neighbors

If you work in an environment as professional as mine, automatic testing is probably a given.

Odds are, also, that the expression “Design by Contract” (or DBC) isn’t. Maybe that you even never heard about it.

So, what is it?

DBC, in short

If you want to know more about “Design by Contract” and “Assertive Programming” in general,  “The Pragmatic Programmer” (Thomas, Hunt) has a section about each to get you started.

Design by contract is a form of assertive programming where you ensure that functions/methods only operate on sound input and produces the output expected.

You can also identify “class or state invariants”: conditions that should hold before and after each function/method execution, and enforce them.

How do you implement it?

Some languages, like Clojure, have built-in support for DBC (I have briefly mentioned this technique in a previous entry on my blog), for example:

(defn function [arg1 arg2]
    {:pre [(is-foo? arg1) (is-bar? arg2)}]
     :post [(looks-right? %) (sparks-joy? %)]
    ;; your code here
)

will throw an exception if the checks on arg1 or arg2 fail, or if the function result will not "look right" or does not "spark joy".

In other languages, you can still make do. The first time I used DBC was with Objective C on an iPad application. Since the language doesn’t support it, I used a mix of assertions and preprocessor macros.

If I had a function and I wanted to make sure it would add a single value to a non-empty array, I would have done something like:

// PSEUDOCODE!
void appendValue(NSMutableArray *arg) {
#ifdef DBC
    NSUInteger origSize = [arg count];
    assert(origSize > 0); 
#endif

// Do your thing

#ifdef DBC
    assert(origSize + 1 == [arg count]);
#endif
}

It’s clunky – I know – but it works, and proved invaluable thorough development.

Plain Java can get something similar using the assert construct but is limited by the extensive use of mutability (just as in the previous example) and lack of preprocessing.

Why use it?

First of all, if you are thinking now: “Well, I do TDD or UT, I have full coverage: I don’t need DBC!” you would be factually wrong.

DBC is complementary to unit testing, and it provides value whether you have a testing infrastructure in place or not.

DBC tests the application while it runs, where UT – even a comprehensive end-to-end test – will only check a selected scenario.

One of the main strengths of UT (at least design-wise) is that it’s a form of black-box testing: it ensures that the test subject produces the expected outcome in a set scenario, without delving into the object’s state.

DBC, on the other hand, ensures that your application is internally coherent at runtime as it checks the internal state, and it’s an inherently low-cost approach.

Consequently, you can easily practice DBC in situations where UT and TDD have a prohibitively high cost/benefits ratio, like legacy code or poorly designed applications.

Why is DBC not popular?

If DBC is so good, why isn’t it as popular as TDD or UT?

One of the reasons – I think – is that Test-Driven Development and Unit Testing are both safety nets and design techniques.

DBC – on the other hand – helps the developer to think about the scope of each function but does not lead to clean code.

I suspect – however – that this is only part of the reasons.

I think the main reason why we don’t use it is that – as developers – we tend to be complicit with our code.

It’s the same reason we don’t do assertive programming: we are deeply uncomfortable with the idea of making our code crash, even if we are sure it’s not doing the right thing.

We root for our code, beyond reason.

We think:

Wait…

Is my method unexpectedly receiving an empty list?!

Well, let’s still give it a chance!

Go on anyway, "boolean checkNonEmptyList(List arguments)": I believe in you!

Exemplifying the first week of my current job, I was doing pair-programming with a senior team member. The guy is reviewing my code.

At some point, he sees a (rather tame) assertion I had put in one of my methods. He looks at me aghast and mutters:

We don’t put assertions in the code. We don’t do this.

As of now and that I know, assertions are still taboo in my workplace (a workplace which is – to be crystal clear – a place full of very respectable and capable developers).

Checks are still made of code

I’ll play the devil’s advocate at this point.

There is at least a good reason to look at DBC with distrust: the checks you are adding in your code are – of course – still code.

And like any code, it will contain bugs and it will fail on occasion, so the idea of adding a check that may actually add a bug to your code does not win a popularity contest.

Sure, you can be careful all you want but, eventually, your application will crash due to a bogus contract.

Is then DBC still worth it? YES. The number of bugs you’ll catch with DBC fairly exceeds the bugs you will introduce, and finding one of the latter contributes to your understanding of your code.

Yet, this is probably a (more reasonable) explanation of why this technique is less used and why I respectfully disagree with those who would leave all DBC checks on in production by default.

Conclusions

“Design by Contract” should be in every programmer’s toolbox: it forces you to think about the scope of your code, provides runtime testing, and is cheap to implement.

Like everything in this world, it isn’t devoid of downsides, but the benefits far outweigh the risks.