Slashdot Mirror
Google-backed Kotlin Gains Adoption in Open Source Android Apps; Scientists Say It Has Improved Code Quality (theregister.co.uk)
Kotlin, which Google blessed last year as an alternative to Java for programming Android apps, has already made its way into almost 12 per cent of open source Android apps, and in so doing has elevated their code quality. From a report: So we're told by computer scientists Bruno Gois Mateus and Matias Martinez, affiliated with University of Valenciennes in France, who observed that Google at the end of 2017 said Kotlin had infiltrated more than 17 per cent of Android apps developed with its IDE, Android Studio 3.0. Kotlin is an open source statically typed programing language that targets the JVM, Android, JavaScript (transpiling to ES5.1) and native platforms (via LLVM). JetBrains, the company that created it, contends Kotlin is more concise and more type-safe than Java. It estimates that apps written in Kotlin require about 40 per cent less code than they would with Java. With fewer lines of code, in theory, one can expect fewer bugs. In a paper distributed through pre-print service ArXiv, "An Empirical Study on Quality of Android Applications written in Kotlin language," Mateus and Martinez describe how they gathered 925 apps from the open source F-Droid repository, measured the amount of Kotlin code in each, and analyzed the code for "smells" as an indicator of code quality.
WRONG.
And I say that as someone who is a big fan of Kotlin...
What this Kotlin smells
Seriously.
As a big fan of software quality, who has long studied how to make better quality software, my experience is that they can be a pretty good indicator.
The smells don't always indicate a problem right there where the smell is (though they often do), they often tell you something about the skill and care with which the software was developed.
To stretch an analogy, the smell of rotting meat is largely due to the aptly named putrescine. That's the smell that tells you something is wrong. Putrescine isn't particularly toxic. Putrescine, the smell, is an indicator that something dangerous such as serratia is likely present.
At least link the source which is the Arxiv paper here.
We don't come to /. to read a summary of a headline which links to a summary on another site summarizing someone elses summary.
Kotlin has a lot of the advantages of Scala, but without the C++-like complexity that Scala can bring to the JVM (and without C++'s performance or hardware hooks).
It's proof that you can have a language about as concise as Python, but with clean static typing.
In Java, it's common to check if a list is null before iterating over it avoid a NPE. In Groovy we can do this:
someList?.each { item -> something(item) }
The null-safe operator ? tells the Groovy compiler to write that null check for me and quietly disregard the call to "each" if it fails.
I see colleagues use Map.get and then either forget to check for null values or add an extra 1-2 lines of code. In Groovy we can do:
def x = myMap[someString] ?: DEFAULT_VAL
Another simple example, but the "elvis operator," ?: means "if the conditional statement to my left is truthy, return its value and assign to x otherwise use the value to my right."
These are simplistic examples, but in Java they happen all the time.
Testing is a great thing. Unit tests typically can tell you that something seems to work under a particular set of conditions, with particular inputs, ignoring concurency and all those other annoying little real-life inconveniences. That's very useful.
Most commonly, unit tests let you confirm that given normal, anticipated inputs that are supposed to work, under the normal, anticipated conditions that the programmer had in mind when he wrote the code and tests, it more or less works. What we frequently fail to test is failure. What if the input is empty? What of it has multiple values? What if the person's name is a million characters long? You CAN write unit tests for such cases; most people don't.
A useful excercise is to make a table of all possible inputs to a small function, including empty or null inputs, with the expected result. Then test every possible set of inputs. Obviously, that's only feasible for functions with a small number of inputs, and ideally one output. That level.pf testing can guarantee correctness. Any less cannot. It can only ensure that what the programmer was thinking when they wrote the test matches with when they wrote the code.
Can you use this without Jetbrains?
http://saveie6.com/
Uh, computer scientists aren't scientists...
(Source: Am a computer scientist.)
Android app dev here. Learning Kotlin, I started off being thoroughly excited about it, especially the nullity checking and other general code safety features. Then I got to the bit about it not having checked exceptions and now have a very mixed opinion.
The arguments against checked exceptions seem to be that 1.) most languages don't have them, 2.) bad programmers will just throw and catch the base "Exception" class everywhere, and 3.) bad programmers will screw up interfaces and the like by putting implementation-specific exceptions in the contract rather than writing appropriate exception classes.
Bad programmers write bad code, and will continue to write bad code. I guess if we "fix" the problem by having good programmers write bad code too, it will technically make the bad programmers average.
Going to try using it on a new project (that won't have checked exceptions as a key component of its design, like my existing stuff) and hope for the best. I still can't get over this seeming like two steps forward, three steps back. I hope I'm wrong, as it otherwise appears to be a great improvement compared to Java.
This approach where they evaluate code based on code smells sounds similar to what some people used to evaluate C++ code based on searching for void* pointer usage. Basically it's bullshit evaluation. They shouldn't declare some code bad simply because it uses some language primitive that the programming language is providing and then declare that another language is better when it _doesn't_ provide the feature at all. I.e. they declare that simply because people need to implement the feature differently, that the code would be somehow better.
Lets declare any superficial code evaluation strategy as bullshit.
He's got the best words and by principle never fails.
Did they account for developer experience, skill, andage of the app? People adopting Kotlin are likely to be more interested in programming langugages than the average developer, and the applications likely to be newer,
Why not write in Haskell and eliminate ALL bugs?
So you can smell the goodness or badness of your apps.
True, fuzzing can sometimes tell you that the program crashes, or does certain other things. It can't tell you that the program never crashes. It can't tell you if the program operates correctly. See the test oracle problem.
Article is beyond dumb.
Generally people who tend to pick up newer languages are more better and more confident of their coding skills (not always.... it's a generalisation)..... so the "scientists" (seriously???!?) are just jumping to conclusions on weak logic.