Shulou(Shulou.com)06/03 Report--

This article will explain in detail the example analysis of the subjective and objective comparison between Kotlin and Java. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Kotlin

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

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

Unfortunately, although there have been many articles about Kotlin, there is not much objective information, and many developers are still pondering whether moving to Kotlin is the right path.

For the rest of this article, I'll try to provide a better list of things to consider when evaluating Kotlin as an alternative to Java.

Subjective comparison between Kotlin and Java

Statements like "Kotlin is better than Java", "Kotlin is more readable than Java" and "Kotlin is faster than Java" are not supported by relevant and accurate data, so they all fall into the subjective category.

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

There are the following problems with the subjective judgment of developers:

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, views based on these judgments only reflect developers' previous biases. Different developers may have very different biases, so just because some developers think Kotlin is a good (or bad) Java replacement doesn't mean other developers think so.

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

The fallacy of subjective judgment

To illustrate the misunderstandings that can be caused by subjective judgment, let's take a closer look at a very common subjective perception:

Kotlin is more readable than Java-- countless articles on Web

In theory, it is possible to design an experiment to measure the difference in readability between Kotlin and Java, but as far as I know, no one has actually carried out such an experiment. As a result, so far, there is no data to support this view.

The syntax of Kotlin 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 Web

In this sentence, "better grammar" is another subjective judgment, which itself is debatable, but in order to avoid argument, we assume that the grammar of Kotlin is indeed better. But does this mean that Kotlin is more readable?

To observe the effect of grammar on readability, please read this "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's made up 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 is a big difference between them, I find it very difficult to read 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 which language it uses, it is not difficult for me to read.

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

The same is true of programming languages.

When we start to use a new language, it will be difficult for us to understand the source code for a while, and we need to carefully understand each syntactic structure. However, as we read and write more code for a particular language, 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 myself have had this experience in many languages: Verilog, Bash, Perl, Tcl, Lisp, Java.

Based on my experience with the above language, I can tell you that if one adapts to Lisp code and no longer notices parentheses, then compared to Java, Kotlin syntax can not have a negligible impact on readability, even if it is "better".

Now that we're talking about this topic, I'll share my subjective judgment on the factors that affect the readability of the source code.

After reading the code written by other developers in many languages (the above lists only the languages I have mastered at some stage; all the languages I have used are more than this), I have come 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.

Therefore, my subjective judgment based on my own experience is that the readability of the source code has nothing to do with the language of choice, it depends on the skills of the code writer and the skills of the reader (the skills of the writer are more important).

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

Objective comparison between Kotlin and Java

In contrast to subjective comparison, objective comparison uses quantitative indicators to measure or evaluate the advantages of Kotlin over Java.

The idea of using one set of criteria to objectively prove whether one programming language is better than another 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 can't make a precise direct comparison, can we compare Kotlin and Java objectively? Yes! We can still assess the positive and messaging impact of switching from Java to Kotlin, then compare the results and discuss their impact.

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 do not 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 idealized setting that is easy to explain. 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 his book Code Complete, we can break down software building activities into three sub-activities: detailed design, coding and debugging, and development testing.

Kotlin has little impact on detailed design sub-activities (which are usually independent of the specific object-oriented programming language of choice), so Kotlin and Java need to make the same effort in this section.

As far as I know, Kotlin has not proposed anything revolutionary about developing test sub-activities. As a result, the same effort is required to develop tests.

All that's left is coding and debugging sub-activities.

If we replace Java with Kotlin, how much work can I save in coding and debugging activities? This is a difficult question to answer, and this number can vary greatly from programmer to programmer (some programmers use Java more efficiently). However, since we are evaluating the best-case scenario, we might as well assume that switching from Java to Kotlin increases developers' productivity during the coding and debugging phase by an average of 10%.

A 10% increase in productivity is an unrealistic and surprising number. Even if we enter all the code manually in a text editor, that's not realistic. Considering the function of IDE today, this number is even more unrealistic. Considering that some developers are more efficient with Java, this number doesn't make any sense.

I don't mind using such a number that is both unrealistic and beneficial to the Kotlin assessment, because I know that no matter how unrealistically positive effects it has on the results of the assessment, once we put aside some of these "ideal assumptions", the negative effects will offset those positive effects.

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

The following picture, from Code Complete, shows the proportion of various activities of a software project:

The small project is based on construction activities. Larger projects require more architecture, integration, and system testing to ensure project success. 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 this picture from Code Complete, in a larger software project (more than 10K lines), coding and debugging account for less than 20% of the total project workload.

Therefore, in a larger software project, we assume a 10% increase in coding and debugging efficiency, 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-year * 12 * 4 * 5 * 0.02 = 24 (person-day)

If we can really reduce the project workload by 24 people-days, it would be a good reason to switch from Java to Kotlin. It should be recalled, however, that the above positive assessment was ideally based on unrealistic assumptions.

In the real world, switching to another programming language has an inevitable impact, which we will assess and compare with the above idealized assessment.

Developers prepare

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

In fact, although Kotlin and Java are very similar, developers still need some time to learn, and then some time to adjust their development practices and tools. Preparation time varies from person to person: some developers can complete the switch in three or four days, while others take 10 days or more.

Let's be optimistic that the average developer can switch from Java to Kotlin in just five days.

A project that takes five man-years to complete will have three to five developers (at best). The average switching time for each developer is 5 days, which takes a total of 15 to 25 man-days for a project.

The amount of work saved by switching to Kotlin (optimistically) 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 particular 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 of the skills associated with the old programming language can be applied to the new language, but the rest of the skill is 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 tool experience (LTEX)

This indicator is used to measure the experience of project teams developing software systems or subsystems using programming languages and software tools. Software development includes the completion of requirements, presentation design and analysis, configuration management, document extraction, library management, program style and formatting, consistency checking, planning and control, and so on. In addition to project programming language experience, project support toolset experience can also affect development efforts. If you have less than 2 months of experience, you will get a very low rating, and if you have 6 months or years of experience, you 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 combination of "major performance decline" into "wasted 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 the comments in version 1.1.2, it was even pointed out that this "patch" release introduced destructive (backward incompatible) changes.

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

So, compared with Java, Kotlin is an unstable and immature language-how does moving to Kotlin affect the project? To answer this question, I will use the "platform volatility" work factor from the Cocomo 2 evaluation model:

Platform volatility (PVOL) here the term "platform" is used to refer to complex hardware and software (OS, DBMS, etc.) used by software products to perform tasks. If the software developed is an operating system, then the platform is computer hardware. If you are developing a database management system, then the platform is hardware and operating system. If you are developing a web text browser, the platform is the network, computer hardware, operating system, and distributed information base. The platform includes compilers or assemblers needed to support the development of software systems. As shown in the following table, if there is only one major change to the platform every 12 months, the rating will be very low, and if there is a major change every 2 weeks, the rating will be high:

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 programming languages because all the projects that lead to the Cocomo2 model use stable languages.

Because compilers and assemblers belong to this working factor, we can also infer programming languages and related tools.

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

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

Looking at the law of decline in 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, then with Kotlin, the workload becomes 1044 person-days, while the total workload using Java is 984 person-days.

Choosing to use Kotlin instead of Java to implement such a project increases the total workload by 60 man-days.

Language and tool instability causes more than twice as much extra work as switching to Kotlin.

Combine all the factors

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

Based on the above assessment, if the project is implemented by developers with an average of 1 years of Java development experience using Java, the total effort is:

5 person-year * LTEX (Java) * PVOL (Java) = 984 (person-day)

If the same project is implemented using Kotlin by developers with little experience in Kotlin development, the total effort is:

5 person-year * LTEX (Kotlin) * PVOL (Kotlin) * 0.98+T_ramp_up=1115+5*N_developers (person-day)

It is estimated that the additional workload caused by choosing Kotlin to replace Java is 131+5*N_developers (person-day).

Assessment consideration

In the course of the evaluation discussion, we came up with convenient single-point values of workload related to Kotlin and Java.

But in fact, single point values are not estimates at all-they're just guesses. A real estimate must have an associated uncertainty. In other words, the estimate represents a range of possibilities, not a single point value.

We ended up using single-point values instead of ranges because I chose the best value for Kotlin from the estimated range and converted all estimates to single-point values.

For example, when discussing the impact of Kotlin on coding and debugging activities, I chose the maximum productivity increase of 10% from the estimated range of possibilities [- 5% 10%]. In other cases, when we discussed the average time for developers to switch to Kotlin, I chose the smallest five days from the estimated range of possibilities [5 days, 21 days].

In addition, we use the work factors specific to the Cocomo2 estimation model. These factors are not universal truths, and in the most general cases, there should be associated uncertainties. I give Kotlin a higher rating than I actually think it deserves, and I hope to eliminate that uncertainty in this way.

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

Keep in mind that because we have compressed the estimate to the single point value that is most beneficial to Kotlin, other possible results will show greater Kotlin switching overhead. Therefore, of all the possible results, the single point value we described above is the most beneficial to Kotlin.

This is the end of the article on "example Analysis of subjective and objective comparison between Kotlin and Java". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.