Subjective and objective comparative analysis of kotlin and Java

Kotlin

Kotlin is a relatively new JVM language, and JetBrains has been actively developing it since 2011.

Over the years, the language has attracted more and more attention in the Android community, and has become the hottest topic in the Android development field after the Google IO 2017 conference. The conference announced that Android officially supports kotlin.

Unfortunately, although there are many articles about kotlin, there is not much objective information. Many developers are still wondering whether moving to kotlin is the right way.

In the remainder of this article, I'll 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 is faster than Java". Statements like this lack the support of relevant accurate data, so they are classified as subjective opinions.

Subjective perceptions are formed when individual developers make one or more subjective judgments about topics related to kotlin or Java.

The subjective judgment of developers has the following problems:

There are no quantitative indicators associated with subjective judgment. There is a great bias in subjective judgment. The bias of subjective judgment varies greatly among developers. Since there are no quantitative indicators associated with subjective judgments, the views based on these judgments only reflect the biases that developers have had before. Different developers may have very different biases, so just because some developers think kotlin is a good (or bad) Java alternative does not mean that other developers think so.

Moreover, without objective indicators, subjective differences cannot be eliminated objectively, which often leads to "war of words".

Fallacy of subjective judgment

To illustrate the possible misunderstandings caused by subjective judgment, let's carefully examine a very common subjective view:

In theory, you can try to design an experiment to measure the readability difference between kotlin and Java, but as far as I know, no one really carried out such an experiment. Therefore, so far, this view has no data support.

Kotlin's syntax is one reason many developers praise its readability. Their logic is as follows:

In this sentence, "better grammar" is a subjective judgment, which is debatable in itself, but in order to avoid debate, we assume that kotlin's grammar is indeed better. But does this mean that kotlin is more readable?

To observe the effect of grammar on readability, please read the following "text":

At first, this "text" is difficult to understand, but slowly, it will become easier and easier to read. If you read it two or three times, you won't notice that it is composed of non-standard letters at all. To be exact, letter substitution is not a syntactic change, but it does show that appearance is rarely an obstacle to readability for skilled readers.

We can also extend this example to natural language. I know three very different languages. Although there are great differences between them, I find it very difficult to read the text in any language when I don't understand the words used in the text. Once I know the words that make up the text and become familiar with the context - no matter what language it is in, I have no difficulty reading it.

Therefore, for me, the choice of language does not affect readability, as long as I understand the content and context.

The same is true for programming languages.

When we start using a new language, it will be difficult for us to understand the source code for some time, and we need to carefully understand each syntactic structure. However, as we read and write more and more code in a specific language, we gradually become familiar with the grammar of that language. At some time, we will no longer pay attention to the syntactic structure.

I have had this experience in many languages: Verilog, bash, Perl, TCL, lisp, Java.

Based on my experience in using the above language, I can tell you that if one adapts to LISP code and doesn't notice parentheses, kotlin's syntax can't have a negligible impact on readability compared with Java, even if it is "better".

Since we are discussing this topic, I will share my subjective judgment on the factors affecting the readability of source code.

After reading code written by other developers in many languages (the above only lists the languages I am proficient in at a certain stage; I have used more than this). I draw the following conclusion: if developers can write code with good readability and Understandability in one language, they can usually write code with good readability and Understandability in other languages.

Therefore, my subjective judgment based on my own experience is that the readability of the source code has nothing to do with the selected language, which depends on the skills of the coder and the readers (the skills of the coder are more important).

If you still think subjective opinions are representative, at least read and think about Robert "Uncle Bob" Martin's views in this blog post.

Objective comparison between kotlin and Java

In contrast to subjective comparison, objective comparison uses quantitative indicators to measure or evaluate kotlin's advantages over Java.

The idea of objectively proving whether one programming language is better than another with a set of criteria is very attractive, but there is a problem: as far as I know, there are no general objective indicators related to programming languages.

Considering that we cannot make an accurate direct comparison, can we objectively compare kotlin and Java? Yes! We can still assess the extent of the positive and message impact of switching from Java to kotlin, then compare the results and discuss their impact.

In order to evaluate the best results that kotlin can bring, we will make the following assumptions:

Developers can immediately switch to kotlin;

After switching to kotlin, developers will not lose any skills (for example, developers with two years of java development experience can magically obtain 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 is reasonable, but at the beginning, there is an idealized setting for illustration. Then, we will put aside these assumptions and discuss the impact of real-world effects.

Kotlin best result estimation

Following the pattern proposed by Steve McConnell in code complete, we can decompose the software construction activity into three sub activities: detailed design, coding and debugging, and development and testing.

Kotlin has little impact on the detailed design sub activity (this activity is usually independent of the specific object-oriented programming language selected), so kotlin and Java need to make the same effort in this part.

As far as I know, kotlin has not proposed anything revolutionary for the development of test sub activities. Therefore, the effort required to develop and test is the same.

There are only coding and debugging sub activities left.

If we replace java with kotlin, how much work can I save in coding and debugging activities? It's hard to answer this question. This value will vary greatly among different programmers (some programmers use Java more efficiently). However, since we are evaluating the best case, we might as well assume that switching from Java to kotlin can increase the productivity of developers in the coding and debugging phase by an average of 10%.

A productivity increase of 10% is an unrealistic and surprising figure. Even if we manually enter all the code in a text editor, it is unrealistic. Considering the functions of today's IDE, this value is even more unrealistic. Considering that some developers use Java more efficiently, this number makes no sense.

I don't mind using such an unrealistic and favorable value for kotlin's evaluation, because I know that no matter how unrealistic positive impact it has on the evaluation results, once we put aside some of the "ideal assumptions", the negative impact will offset those positive effects.

So, 10% improvement in coding and debugging -- how fast do we deliver products to customers?

The following picture is from the book code complete, showing the proportion of various activities of the software project:

Figure small projects are dominated by construction activities. Larger projects need more architecture, integration and system testing to ensure the success of the project. This diagram 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 the picture from code complete, in a large software project (more than 10k lines), coding and debugging only account for less than 20% of the total workload of the project.

Therefore, in a large software project, we assume that the coding and debugging efficiency can be increased by 10%, which can only reduce the total amount of work required to complete the project by 2%.

For example, for a project that takes 5 person years to complete (this is a relatively large Android project), 2% of the total workload is:

5 person years * 12 * 4 * 5 * 0.02 = 24 (person days) if we can really reduce the project workload by 24 person days, this will be a good reason to switch from Java to kotlin. However, we should remember that the above positive assessment is based on unrealistic assumptions.

In the real world, switching to another programming language will have an inevitable impact. We will evaluate this impact and compare it with the above idealized evaluation.

Developer preparation

To assess the best case scenario, we assume that developers can immediately switch from Java to kotlin.

In fact, although kotlin is very similar to Java, developers still need to spend some time learning and then spend some time adjusting development practices and tools. The preparation time varies from person to person: some developers can complete the switch in three or four days, while others need 10 days or more.

Let's be optimistic. On average, each developer can switch from Java to kotlin in only five days.

A project that takes 5 person years to complete will have 3 to 5 developers (in the best case). The average switching time for each developer is 5 days, so a project needs a total of 15 to 25 person days.

The amount of work saved by switching to kotlin (optimistic estimate) seems to be about the same as the total amount of work required for switching.

Loss of developer skills

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 other aspects. 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 will be lost.

To assess the impact of the loss of programming language skills on the project workload, we will use the "language and tool experience" factor derived from the cocomo2 evaluation model:

Language and tools experience (ltex)

This indicator is used to measure the experience of project teams developing software systems or subsystems in using programming languages and software tools. Software development includes requirements, expression design and analysis, configuration management, document extraction, library management, program style and formatting, consistency check, planning and control, etc. In addition to the project programming language experience, the experience of project support toolset will also affect the development work. Experience less than 2 months will get a very low rating, and experience of 6 months or more years will get a very high rating, as shown in the table below:

I don't know what kind of recession this is and how many projects have been affected, but my brain automatically translates the collocation of "major performance recession" into "wasting many hours of development time."

In addition, if you read the comments in the release notes, you will notice that many people are experiencing migration problems. In 1.1 In the comments of version 2, some even pointed out that this "patch" release introduced destructive (backward incompatibility) modifications.

In contrast, if you read the release notes of Oracle jdk8, you will find that it is relatively stable. Most of the changes are in terms of security improvements.

Therefore, compared with Java, kotlin is an unstable and immature language -- how will the migration to kotlin affect the project? To answer this question, I will use the "platform volatility" working factor from the COCOMO 2 evaluation model:

Cocomo2 model definition manual

You may have noticed that the programming language does not appear directly in the description of the working factor, but there are compilers and assemblers. In my opinion, this description does not explicitly include a 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.

According to this rating range of platform volatility, Java should be rated "verylow" and kotlin should be rated "low" or higher. Kotlin's rating may be higher because it relies internally on other tools, increasing the risk of compatibility problems.

Since "verylow" does not provide a working factor, we need to estimate it.

Looking at the decreasing law of the score of this factor from "veryhigh" to "low", I think we can safely assume 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 person years, the workload with kotlin becomes 1044 person days, while the total workload with Java is 984 person days.

Choosing to implement a project using kotlin instead of Java will increase the total workload by 60 person days.

The extra work caused by language and tool instability is more than twice the work reduced by switching to kotlin.

Integrate all factors

The project I discussed as an example requires a rated workload of 5 person years.

According to the above evaluation, if the project is implemented in Java by developers with an average of 1 year of java development experience, the total workload is:

5 person years * ltex (Java) * pvol (Java) = 984 (person days)

If the same project is implemented with kotlin by developers with little kotlin development experience, the total workload is:

5 person years * ltex (kotlin) * pvol (kotlin) * 0.98 + T_ ramp_ up=1115+5*N_ Developers (person day)

It is estimated that the additional workload caused by selecting kotlin to replace Java is 131 + 5 * n_ Developers (person day).

Assessment considerations

During the evaluation discussion, we obtained a convenient single point value of workload related to kotlin and Java.

But in fact, single point values are not estimates at all -- they are just guesses. Real estimates must have an associated uncertainty. In other words, estimates represent the range of possibilities, not single point values.

We finally used the single point value instead of the range, because I chose the value most favorable 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 improvement of 10% from the estimated probability range [- 5%, 10%]. In other cases, when we discussed the average time for developers to switch to kotlin, I chose the minimum 5 days from the estimated possibility range [5 days, 21 days].

In addition, we use the cocomo2 estimation model specific working factors. These factors are not universal truths. In the most general case, there should also be associated uncertainty. I gave kotlin a higher rating than I actually thought it deserved, and I hope to eliminate this uncertainty in this way.

Needless to say, the single point value we obtained is not 100% correct. In order to get a more complete estimation, we can use the real estimation for Monte Carlo simulation. Through this technique, we can observe the distribution of possible results and find out which results are most likely to occur.

Remember that other possible results will show greater kotlin switching overhead because we compress the estimation to the single point value that is most favorable for kotlin. Therefore, of all possible results, the single point value we described above is the most favorable for kotlin.

Summary

At the beginning of the article, we showed some subjective judgments that may mislead developers in comparing programming languages.

Next, we discuss the difficulties of objectively comparing programming languages and make a series of estimates in order to find out the total workload required by kotlin stack and Java stack to complete software projects. When performing estimation, we always use the value in the estimation range that is most conducive to kotlin.

Through our analysis, switching from Java to kotlin seems to increase the total workload required to complete the software project.

More work means that enterprises need to spend more money to get the same functions when switching to kotlin, and users need to wait longer to get products.

Some developers may be surprised that this result is not easy to accept.

After considering all the circumstances, Google finally decided to support the development of kotlin anroid. In this regard, Google may need considerable investment - can no one in the Google cloud platform team do similar analysis to find out the negative impact of switching to a new language?

I think Google employees are very smart people, and I believe they have conducted a very in-depth analysis before deciding to support kotlin.

The above is all about the subjective and objective comparative analysis of kotlin and Java in this paper. I hope it will be helpful to you. Interested friends can continue to refer to other related topics on this site. If there are deficiencies, please leave a message and point out!