Google-backed Kotlin Gains Adoption in Open Source Android Apps; Scientists Say It Has Improved Code Quality (theregister.co.uk) 86
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.
Re: Fewer lines of code = fewer bugs (Score:1)
Possibly. Print hello world in assembly. Print hello world in basic. Which program would you suspect is more likely to have bugs?
Comment removed (Score:5, Informative)
Re:It depends on how you get fewer (Score:4, Informative)
As an interesting aside, replace def with val and both of your examples are valid Kotlin syntax.
Re: (Score:1)
So? JetBrains freely admits it created Kotlin by taking the best features from multiple languages. It's a very pragmatic and polished language.
Imo, the strong typing alone makes it much better than Groovy (compare for example the Kotlin variant of Gradle script with the Groovy one).
Re: (Score:2)
Re: (Score:2, Informative)
Your Groovy examples in modern pure Java:
Optional.ofNullable(someList).ifPresent(list -> list.forEach(item -> something(item)));
String x = Optional.ofNullable(myMap) .map(map -> map.get(someString)) .orElse(DEFAULT_VAL);
Re:It depends on how you get fewer (Score:5, Insightful)
Yeah, nobody writes Java write that. Its unreadable and unmaintainable. You write a freaking if statement and a loop. That way people can understand what you're trying to do, and can easily edit it if what the loop needs to do changes. You example would be immediately rejected in any code review.
Re: (Score:1)
You write a freaking if statement and a loop.
I hate people that write the if statement, if your code doesn't take null as valid input let it throw instead of hidding the callers error. I see null checks like I see empty catch blocks, they make it near impossible to find bugs in a larger codebase.
Re: (Score:2)
Because I like my code to not crash in production. There are cases where null is unrecoverable and then letting it throw is acceptable. But it generally isn't the case.
Re: (Score:3)
Please do. I know every place I worked they were not allowed, because they led to higher maintenance cost and time lost in debugging. They're less reada
Re: Fewer lines of code = fewer bugs (Score:1)
As a big fan of software quality (Score:4, Insightful)
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.
Very good tests are very good (Score:4, Insightful)
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.
Re: Very good tests are very good (Score:2)
Can detect some crashes, true. Test oracle problem (Score:2)
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.
Re: (Score:2)
One thing that makes code smell a particularly useless metric is that many categories of "smells" can be eliminated by simply not using object oriented languages.
Is the reduced level of "smells" from using Kotlin over Java is because of quality, or because the "smell" cargo cult mostly concentrates on Java-like languages and Kotlin is doing things a bit differently in ways that conventional smell detectors cannot detect?
Re: (Score:2)
And use what, a functional language? That's probably the biggest smell of all.
Re: (Score:1)
very nicely put! a smell test reveals quality
Re: As a big fan of software quality (Score:3)
POST THE FUCKING REAL SOURCE (Score:1)
At least link the source which is the Arxiv paper here [arxiv.org].
We don't come to /. to read a summary of a headline which links to a summary on another site summarizing someone elses summary.
Re: (Score:2)
https://memecreator.org/static... [memecreator.org]
Comment removed (Score:3)
No jetbrains (Score:2)
Can you use this without Jetbrains?
Re: (Score:3)
Absolutely.
Re: (Score:2)
Uh, computer scientists aren't scientists...
(Source: Am a computer scientist.)
Scientific Method [sciencebuddies.org]
1) Ask a Question: Will this program I just wrote compile?
2) Background Research:
2.1) Previous experience with programming language
2.2) Previous experience with type of problem
2,3) Quality of Understanding of CS concepts
3) Form a hypothesis: First time to compile: no. Estimate X syntax errors and Z semantic errors per Y lines of code.
4) Experiment: Perform compile.
5) Analyze Results
6) Iterate on Experiment. (Fix errors, refine understanding.)
7) Present findings (Boss, it
Re: (Score:2)
Excercise for the student: Replace each of your bullets with a pornographic reference. Can we now conclude that porn is science?
Re: (Score:2)
> Can we now conclude that porn is science?
Why porn and not sex?
Porn is research. Sex is applied engineering.
Checked Exceptions. (Score:5, Interesting)
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.
Re: (Score:3)
I'll tell you why checked exceptions are a stupid idea: they pollute the method interface with irrelevant information (i.e., what checked exceptions might get thrown).
What is irrelevant about that? Do you prefer your interfaces to be undocumented and discoverable only by "trial and error and too bad if your test cases didn't cover enough unexpected use cases" in other ways as well, or just for the exceptions?
Re: (Score:2)
Re: (Score:2)
Haskell uses checked exceptions. The clang code base also used them (error classes with destructor that asserts if they are not checked)
Re: (Score:1, Troll)
CheckedExceptions have been considered a language flaw in Java for a very long time by a large percentage of its users. Examples of problems with them:
*Writing throws statements on each function causes propagation up the chain and leads to either being forced to catch Exception or have functions with a half dozen throws on it.
*Removing the necessity of throwing on any function in the change causes massive changes to all callers, which is time consuming and causes unnecessary churn. Especially bad with lib
Re: Checked Exceptions. (Score:2)
Re: (Score:2)
You didn't describe checked exceptions, you described typed exceptions. Nobody complains about exceptions having type that can be compared against. Checked exceptions are the list of exceptions in the throws argument that are checked against at compile time.
Re: (Score:2)
You didn't describe checked exceptions, you described typed exceptions. Nobody complains about exceptions having type that can be compared against
You obviously misunderstood. I was explaining how to solve your problems with checked exceptions.
Checked exceptions are the list of exceptions in the throws argument that are checked against at compile time.
There are people who don't like checked exceptions because they would rather pretend errors don't happen. You can't write reliable software if you live in this kind of fantasy world. You need to think about what happen if there's an error.
Re: (Score:2)
No, you were showing you didn't know what you were talking about. You tried to defend a feature while describing a totally different feature.
Re: (Score:2)
Re: (Score:2)
You can't write reliable software if you don't consider all possible exceptions when you are writing the software.
That's bullshit. Worst comes to worst the program crashes safely. with a nice stacktrace to tell you what happened. Checked exceptions are valid in a few, very few cases. In all other cases, all they add is clutter.
Let's take something like SQLException. Ok, what are you supposed to do if your SQL is fucked up? You can't recover from it, so you either wrap it in a non-checked exception or you throw it up the chain, exasperating the crud code that needs to deal with it.
What do you do if you get an IOExceptio
Re: (Score:2)
Re: (Score:2)
Ok, I gave you the benefit of the doubt the first time when you mentioned security and then switched to reliability. But now here you are again talking about security. Java is not C. In Java, when you get an exception your program crashes. In C, if you don't check return codes your program silently continues running.
You complained about the other poster ignoring your argument, and that's exactly what you did to me. I never said you should ignore what can go wrong. I said in the vast majority of cases, check
Re: (Score:2)
Most of those complaints are due to developers being unwilling to write their own exceptions when they write code. If you tried to use checked exceptions without being willing to author your own, they would be an absolute nightmare.
Let's say you're writing a library that transfers data from an XML file to a database. If you have client-facing methods that throw SAXException, IOException, and SQLException, you're doing it wrong. When you design your interface, you also need to write your own exceptions, e
Re: (Score:1)
Re: (Score:2)
How do unchecked exceptions fix the things you mentioned? Sure, it's a pain to do proper error handling, but I have never seen any programming language in which error handling is effortless. At least with checked exceptions, the compiler will alert you to unhandled situations.
Deciding that you won't bother to do proper error handling is fine if you're working on some tool that you only use yourself. But if your code is going to be part of a large complex system, you're trading a bit of development speed now
Re: (Score:1)
I personally think checked exceptions have made me a better programmer, forcing me to think harder about all the things that could go wrong. The argument you hilighted about "bad programmers" abusing the exception handling with a catch-all is just dumb, grasping for an excuse and agree that bad programmers will always find ways to mess things up. It's not like exception handling is rocket science.
Re: (Score:2)
Kotlin - only a slight improvement (Score:1)
Why not write in Haskell and eliminate ALL bugs?