Kotlin
Kotlin is a relatively new JVM language, and JetBrains has been actively developing since 2011.
Over the years, the language has received increasing attention in the Android community and has become the hottest topic in Android development after the Google IO 2017 conference. The conference announced that Android officially supports Kotlin.
Unfortunately, while there are already many articles about Kotlin, there is not much objective information, and many developers are still thinking about whether moving to Kotlin is the right path.
In the rest of this article, I will try to provide a more complete list of things to consider when evaluating Kotlin as an alternative to Java.
Subjective comparison between Kotlin and Java
"Kotlin is better than Java", "Kotlin is more readable than Java", "Kotlin development speed is faster than Java", statements like this lack the support of relevant accurate data, so they are all classified as subjective views.
A subjective view is formed when an individual developer makes one or more subjective judgments about topics related to Kotlin or Java.
There are problems with the following subjective judgments of developers:
There are no quantitative indicators associated with subjective judgment.
There are great biases in subjective judgment.
The bias of subjective judgment varies greatly among developers.
Since there are no quantitative metrics associated with subjective judgments, the perspectives based on these judgments only reflect the biases that developers have had before. Different developers may have very different biases, so it doesn't mean other developers think so, too.
Moreover, since there are no objective indicators, subjective differences cannot be objectively eliminated, which often leads to "war of words".
Fallacy of subjective judgment
To illustrate the misunderstandings that subjective judgments can lead to, let us take a closer look at a very common subjective view:
Kotlin is more readable than Java - countless articles on the Web
In theory, it is possible to try to design an experiment that measures the difference in readability between Kotlin and Java, but as far as I know, no one is really doing such an experiment. Therefore, as of now, this view has no data support.
Kotlin's syntax is one reason why many developers praise its readability. Their logic is as follows:
Kotlin has better syntax, so it is more readable - countless articles on the web
In this sentence, "better grammar" is another subjective judgment, which is itself debatable, but to avoid arguments, we assume that Kotlin's grammar is indeed better. However, does this mean that Kotlin is more readable?
To observe the effect of syntax on readability, read this paragraph of "text":
At the beginning, this "text" is difficult to understand, but slowly, it becomes easier to read. If you read it two or three times, you won't notice that it is composed of non-standard letters. To be precise, letter replacement is not a syntactic change, but it does show that appearance rarely becomes a barrier to readability for skilled readers.
We can also extend this example to natural language. I understand three completely different languages. Although they differ greatly, I find it very difficult to read text in either language when I don't understand the words used in the text. Once I knew the words that make up the text and became familiar with the context – no matter what language it was in, I didn’t have a hard time reading it.
Therefore, for me, the choice of language does not affect readability, just understand the content and context.
The same is true for programming languages.
When we start using a new language, we will have a while of difficulty in understanding the source code and need to carefully understand each syntactic structure. However, as we read and write code for a specific language more and more, we gradually become familiar with the syntax of that language, and at some point we will no longer pay attention to the syntactic structure.
I have had this experience in multiple languages myself: Verilog, Bash, Perl, Tcl, Lisp, Java.
Based on my experience with the above languages, I can tell you: If a person adapts to Lisp's code and no longer notices brackets, then Kotlin's syntax cannot have an unnegligible impact on readability compared to Java, even if it is "better".
Since we are discussing this topic, I will share my subjective judgment on factors that affect the readability of source code.
After reading code written by other developers in many languages (the above lists only the languages I am proficient in at a certain stage; I have used more languages than this), I came to the following conclusion: If developers can write code that is both readable and understandable in one language, they can usually write code that is both readable and understandable in other languages as well.
Therefore, the subjective judgment I made based on my own experience is that the readability of the source code has nothing to do with the language chosen, and that depends on the skills of the code writer and the skills of the readers (the skills of the writer are more important).
If you still think subjective views are representative, at least read and think about what Robert “Uncle Bob” Martin thinks in this blog post.
Objective comparison between Kotlin and Java
In contrast to subjective comparisons, objective comparisons use quantitative indicators to measure or evaluate where Kotlin has advantages over Java.
The idea of objectively proving whether a programming language is better than another with one set of standards is very attractive, but there is a problem: As far as I know, there are no general objective indicators related to programming languages.
Given that we cannot make precise and direct comparisons, can we objectively compare Kotlin and Java? able! We can still evaluate the extent of the positive and messaging impact of switching from Java to Kotlin, then compare the results and discuss their impact.
To evaluate the best results Kotlin can produce, we will make the following assumptions:
Developers can switch to Kotlin immediately;
After switching to Kotlin, developers don't lose any skills (for example, developers with two years of Java development experience can magically gain two years of Kotlin development experience);
Kotlin is as stable as Java;
Kotlin tools are as mature as Java tools.
In fact, none of the above assumptions are reasonable, but at the beginning, there is an ideal setting for easy explanation. Then, we will put aside these assumptions and discuss the impact of real-world effects.
Kotlin best results estimates
Following the model proposed by Steve McConnell in Code Complete, we can break down software construction activities into three sub-activity: detailed design, coding and debugging, and development and testing.
Kotlin has little effect on designing sub-activity in detail (this activity is usually independent of the specific object-oriented programming language chosen), so Kotlin and Java need to put in the same effort in this section.
As far as I know, Kotlin has not proposed anything revolutionary about the development test sub-activity. Therefore, the same is true for developing testing.
All coding and debugging sub-activity are left.
If we replace Java with Kotlin, how much work can I save in coding and debugging activities? This question is difficult to answer, and this value varies greatly between programmers (some programmers use Java more efficiently). However, now that we are evaluating the best situation, we might as well assume that switching from Java to Kotlin can increase the developer's productivity by an average of 10% during the coding and debugging phases.
A 10% productivity increase is a surprisingly unrealistic value. Even if we manually enter all the code in a text editor, that is unrealistic. Considering the current functions of IDEs, this value is even more unrealistic. Considering that some developers use Java more efficiently, this value makes no sense.
I don't mind using such a value that is both unrealistic and favorable to Kotlin's assessment, because I know that no matter how unrealistic positive it has on the assessment results, once we put aside some of the "ideal assumptions" in it, the resulting negative impacts will offset those positive effects.
So, in terms of coding and debugging, we have increased by 10% - how fast are we delivering our products to our customers?
The following picture is from the book Code Complete, showing the proportion of various activities of software projects:
The small project of the picture focuses on construction activities. Larger projects require more architecture, integration and system testing to ensure the project is successful. This picture does not show requirements because unlike other activities, requirements work is not a direct program function. (Albrecht 1979; Glass 1982; Boehm, Gray, and Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora, and McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000)
Code Complete, Second Edition
According to this image from Code Complete, in a larger software project (more than 10K lines), encoding and debugging account for less than 20% of the total project workload.
Therefore, in a larger software project, the coding and debugging efficiency we assumed is 10%, which can only reduce the total workload required to complete the project by 2%.
For example, a project that takes 5 people to complete for years (this is a relatively large Android project), 2% of the total workload is:
5 people - year * 12 * 4 * 5 * 0.02 = 24 (people - day)
If we really could reduce the project workload by 24 people-days, it would be a good reason to switch from Java to Kotlin. However, we should remember that the above positive assessment was derived in ideal situations and was based on unrealistic assumptions.
In the real world, switching to another programming language has an inevitable impact, which we will evaluate and compare with the idealized evaluation mentioned above.
Developer preparation
To evaluate the best case scenario, we assume that developers can switch from Java to Kotlin immediately.
In fact, while Kotlin is very similar to Java, developers still need to spend some time learning and then spend some time tweaking development practices and tools. Preparation time varies from person to person: Some developers can switch between three or four days, while others can take 10 days or more.
Let's be optimistic, on average, each developer can switch from Java to Kotlin in just 5 days.
A project that takes 5 people years to complete will have 3 to 5 developers (in the best case). The average switching time for each developer is 5 days, so that a project takes 15 to 25 person-day switching time in total.
The effort saved by switching to Kotlin (optimistic estimate) seems to be about the same as the total effort required for switching.
Developer skills loss
The ability to work efficiently in a specific programming language is a skill.
We have discussed one aspect of this skill (code readability), but there are many others. When switching from one language to another, some skills related to the old programming language can be applied to the new language, but other parts of the skill are lost.
To evaluate the impact of loss of programming language skills on project workload, we will use the "Language & Tool Experience" factor derived from the Cocomo2 evaluation model:
Language and Tool Experience (LTEX)
This metric is used to measure the experience of project teams developing software systems or subsystems using programming languages and software tools. Software development includes using tools to complete requirements, expression design and analysis, configuration management, document extraction, library management, program style and formatting, consistency check, planning and control, etc. In addition to project programming language experience, the experience of project support toolsets can also affect development efforts. Experience below 2 months will get a very low rating, and experience below 6 months or years will get a very high rating, see the table below:
I don't know what kind of decline this is, how many projects have been affected, but my brain automatically translated the combination of "significant performance decline" into "wasted many hours of development time."
Also, if you read the comments on the posting notes, you will notice that many people are having migration issues. In the comments on version 1.1.2, some even pointed out that this "patch" release introduced destructive (backward incompatible) modifications.
In contrast, if you read the release notes of Oracle JDK8, you will find that it is relatively stable. Most of the modifications are security improvements.
Therefore, Kotlin is an unstable and immature language compared to Java - what will migration to Kotlin have on the project? To answer this question, I will use the "platform volatility" working factor from the Cocomo 2 evaluation model:
Platform Volatility (PVOL) Here the term "platform" refers to the complex hardware and software (OS, DBMS, etc.) that are called when a software product performs tasks. If the software developed is an operating system, then the platform is computer hardware. If the database management system is developed, then the platform is the hardware and operating system. If the network text browser is developed, then the platform is the network, computer hardware, operating system and distributed information library. The platform includes compilers or assemblers required to support the development of software systems. As shown in the following table, if the platform only changes once every 12 months, the rating will be very low, and if there is a major change every 2 weeks, the rating will be very high:
Cocomo2 Model Definition Manual
You may have noticed that the programming language does not appear directly in the description of this working factor, but compilers and assemblers appear. In my opinion, this description does not explicitly include the programming language because all projects that derive the Cocomo2 model use a stable language.
Since compilers and assemblers belong to this working factor, we can also infer programming languages and related tools.
Based on this rating range of platform volatility, Java should be 'verylow', while Kotlin should be 'low' or higher. Kotlin may have a higher rating because it relies internally on other tools, increasing the risk of compatibility issues.
Since "verylow" does not provide a working factor, we need an estimate.
Looking at the decreasing rule of the factor from "veryhigh" to "low", I think we can assume with confidence that the score of "verylow" is not higher than 0.82.
Based on these assumptions (in favor of Kotlin), if a project requires a rated workload of 5 people per year, then using Kotlin will become 1,044 people per day, while the total workload of using Java is 984 people per day.
Choosing to implement such a project using Kotlin instead of Java will increase the total workload by 60 people.
The extra work caused by language and tool instability is more than twice as much as the work reduced by switching to Kotlin.
Combining all factors
The project I discussed as an example requires a rated workload of 5 people per year.
According to the above evaluation, if the project is implemented using Java by a developer with an average of 1 year of Java development experience, the total workload is:
5 people-year*LTEX(Java)*PVOL(Java)=984(people-day)
If the same project is implemented using Kotlin by a developer with little experience in Kotlin development, the total workload is:
5 people-year*LTEX(Kotlin)*PVOL(Kotlin)*0.98+T_ramp_up=1115+5*N_developers(Human-Heaven)
It is estimated that the additional workload caused by choosing Kotlin to replace Java is 131+5*N_developers (man-day).
Evaluation precautions
During the evaluation discussion, we came up with convenient single-point value for workload related to Kotlin and Java.
But in reality, single-point values are not estimates at all - they are just guesses. The real estimate must have an associated uncertainty. In other words, estimates represent ranges of possibilities, rather than single point values.
We ended up using single point values instead of ranges because I chose the most favorable value for Kotlin from the estimation range and converted all estimates into single point values.
For example, when discussing the impact of Kotlin on coding and debugging activities, I chose the maximum productivity boost value of 10% from the estimated range of possibilities [-5%, 10%]. In other cases, when we discuss the average time the developer switches to Kotlin, I chose the smallest 5 days from the estimated range of possibilities [5 days, 21 days].
In addition, we used the working factor dedicated to the Cocomo2 estimation model. These factors are not universal truths, and in the most general case, there should also be related uncertainty. I assigned Kotlin a higher rating than I actually thought it deserved, and I hope to remove that uncertainty in this way.
Needless to say, the single point value we get is not 100% correct. To get a more complete estimate, we can use the real estimate for MonteCarlo simulation. Through this technique, we can observe the distribution of possible results and figure out which results are most likely to occur.
Remember that since we compress the estimates into the single point value that is most favorable for Kotlin, other possible results will show a greater Kotlin switching overhead. Therefore, of all possible results, the single point value we described above is most favorable to Kotlin.
summary
At the beginning of the article, we show some subjective judgments that may be misleading to developers’ comparison of programming languages.
Next, we discuss the difficulties in objectively comparing programming languages and conduct a series of estimates to figure out the total workload required for the Kotlin stack and Java stack to complete the software project. When performing estimation, we always use the most favorable value of Kotlin in the estimation range.
Through our analysis, switching from Java to Kotlin seems to result in an increase in the total workload required to complete a software project.
More work means that businesses need to spend more money to switch to Kotlin to get the same features, while users need to wait longer to get the product.
Some developers may be surprised and find this result not easy to accept.
After considering all the situations, Google finally decided to support KotlinAnroid development. Google may need considerable investment in this - is there no one in the Google Cloud Platform team able to do similar analysis to figure out the negative impact of switching to a new language?
I think Google employees are all very smart people and I believe they have done a very in-depth analysis before they decided to support Kotlin.
The above is all the content of this article about the subjective and objective comparison and analysis of Kotlin and Java. I hope it will be helpful to everyone. Interested friends can continue to refer to other related topics on this site. If there are any shortcomings, please leave a message to point it out!