Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 171 posts at DZone. You can read more from them at their website. View Full User Profile

Kotlin: Hackery Made Elegant

  • submit to reddit

I have an open mind about languages. I love the new features in O-C and like a lot of stuff in C++ 11.

Recently, on StackOverflow, I weighed in on a question tagged Design Patterns and said instance of was considered a sign of bad design. Almost everyone on the thread was like ‘says who?‘ Really? So I went and got a link that mentioned it as the first language anti pattern to avoid, and the main guy was still like ‘that doesn‘t prove a thing.‘

Just saw an article mentioned on Twitter looking at VM languages, clicked on it, and it‘s about Kotlin this time, the JetBrains language. The author starts by saying ‘it sure does deliver on the elegant code promise,‘ and shows this abomination:

when (stream) {
is Reader -> stream.close()
is Writer -> stream.close()
is InputStream -> stream.close()
is OutputStream -> stream.close()
is Socket -> stream.close()
else -> System.err.println("Unable to close object: " + stream)

How does this code make any sense? If it‘s anything close, otherwise, throw an error?

File under:

  1. Fitness function in languages today is did the ADHD coder have to type fewer symbols? yes? good, no? bad.
  2. ‘Design‘s a drag, who said goto was bad? You know, the good thing about goto is, you tell the computer to do something and it just does it.‘

Who‘s working on languages that are going to solve problems that have been around forever?? Like nulls? or having to reconstruct graphs at child nodes? I like Categories in O-C, but I would like to see them made into Traits that are a little less universally-glommed functions.

If you like these types of language innovations, my recommendations are learn how to type faster and use IDE shortcuts more.


Published at DZone with permission of Rob Williams, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)