Kotlin — IDE-Oriented Programming
Programming languages are classified into paradigms based on their features, most famously in the debate of object-oriented vs functional vs procedural programming.
What actually happens in the industry often differs from academics, including the more-or-less jokingly:
- hype-driven development (using hyped tech for no reason, for example blockchain, NoSQL, or microservices; see also cargo cult programming)
- voodoo programming (poking randomly at source code until the thing works; this is the main paradigm PHP programmers use)
- Excel-based programming, where crucial business logic is kept inside of Excel sheets that have no version control and can easily be tampered with
Today I would like to propose a new paradigm I noticed, and argue how Kotlin (un)intentionally excels in it.
IDE-Driven Development
I have already extolled the virtues of IDEs in “What I Wish My Computer Science Degree Taught Me About Programming”. Early on, “a developer wrote an application in a text editor, saved it, exited the editor, ran the compiler, wrote down the error messages on a pad of paper, and then traced back through the code again”. We have come a long way since then, with 1991’s Microsoft Visual Basic being considered the first real IDE, but I would argue that early Java IDEs (Eclipse 2001, IntelliJ 2001, NetBeans 1997) had the most profound impact on how we do development today.
Quoting this article:
There’s an old joke: If you build something even an idiot can use, only an idiot will use it. IDEs took programming out of the realm of arcane coding books as thick as a phone book and reduced many hours of work to just a few clicks.
Did it democratize programming, or enable bad programming? A little of both, say the veterans.
Java took the world by storm in the late 90s. Java proposed object-oriented programming, which envisioned a complex program broken down into modular encapsulated classes that could easily be swapped out. Managers started viewing developers the same way, as interchangeable with anyone from the large Java developer pool.
IDEs enabled Java developers to autocomplete their way through picklists (containing all the methods defined on a given object which match your query) to a working program. The IDE also automatically handles the build system, adds imports, and formats your code. The IDE type-checks your arguments, so even an unskilled programmer can just poke and prod at their program until the IDE is happy (another instance of voodoo programming). Whenever I see another post about a senior developer who couldn’t solve FizzBuzz in an interview, I blame IDEs.
From Russia With Love
Enter Kotlin. It was April 2020 and I was out of a job when I first heard of Kotlin. It kept popping up in StackOverflow job ads, especially at companies I really wanted to work for. So I made a small demo app with Kotlin in Android Studio (which has since turned into Mundraub Navigator, a real app with 50K downloads). It fixes many of Java’s problems, like its verbosity, its lack of null-awareness, primitive types, and checked exceptions. It also adds string templates, operator overloading, and range expressions.
Kotlin’s main developer is St. Petersburg-based JetBrains, who just happen to be in the business of making a suite of the world’s finest and most-used IDEs:
Most of them are implemented in Java, and Kotlin came about as a way to become more productive in their own development process (I mean, they are probably already using IntelliJ to develop IntelliJ), while maintaining full compatibility with their existing Java codebase.
However, JetBrains — for better and for worse — created a language that only makes sense in the context of their own IDEs. Let me explain.
Dot-Based Programming
Compare the following Kotlin snippet to the equivalent Python:
solution.sortedBy { it.second }.map { it.first }.toString()
str([x[0] for x in sorted(solution, key=lambda x: x[1])])You will notice how Kotlin has key functions defined as method on the list while Python has a global built-in, for example a.sorted() vs sorted(a), a.maxOrNull() vs max(a), a.toString() vs str(a). Transformations will end up as a long chain of calls a.map {...}.sorted().toString() vs nesting in Python str(sorted(map(...))).
What is the benfit of this? Simply tack on a dot at the end of an expression and the IDE’s picklist will activate and help you find the thing you want, whereas in Python you need to know all the function names “ahead of time”, and you need to mentally match all round and square brackets to each other.
Extension functions
Kotlin also allows you to define extension functions (which don’t get permanently attached to the object, only your code can use them essentially), so now even your helper functions can be used in dot-based style:
fun <T> List<T>.toPair(): Pair<T, T> {
if (this.size != 2)
throw IllegalArgumentException(“List is not of length 2!”)
return Pair(this[0], this[1])
}val myList = listOf(7, 9)
val myPair = myList.toPair()
I even saw a creative use of this in the kohttp library, where an HTTP GET function was an extension of the String type:
"http://whatthecommit.com/index.txt".httpGet()More dots
You can even write infix operators like this. The following is legal Kotlin, calculating (3–5) * 2 = -4 (don’t do this):
3.minus(5).times(2)I even find myself increasingly writing for-loops in dot-based style:
cardInfos.forEach { it.submitted = true }for (cardInfo in cardInfos)
cardInfo.submitted = true
Type and name hinting
The IDE adds additional information about variable/argument names and types (in grey), making Kotlin code much more readable in your editor than for example on GitHub or the Kotlin Playground:
Android Studio reveals that the third argument to “getFromLocation” is called “maxResults”, which is much more informative than a bare “1”. You can also see that the argument passed to the block on line 6 has the default name “it” and the type “Address”. You can get even more type info by hovering over variable names or typing new code in.
Python has similar mechanisms (including the very cool feature that any function argument can be called using its name as a keyword), but this requires the developer to explicitly add them every time (which they likely won’t do); the editor won’t give you any hints. For example, this silly little helper function could be improved by adding annotations:
def concat_lists(a):
return sum(a, [])
def concat_lists(a: list[list]):
return sum(a, start=[])Conclusion
Java ushered in the age of cookie-cutter business app programming, and (with its simpler set of features compared to C++) was ideal for static analysis, moving the industry from obscure terminal-based text editors towards (too) easy to use graphical IDEs.
Kotlin was designed together with the IDE it would be used in, making it part of the language in a way. This breeds some exciting features, but also makes the language harder to use without it.
Thanks to Kotlin, I no longer have to choose between a great language (Python) and great IDE support (Java).
