5 ms·

There is a lot of reasons to prefer Java (Disclamer: I don't use Kotlin all that much). First, there is really not that much reason to use Kotlin for the type

There is a lot of reasons to prefer Java (Disclamer: I don't use Kotlin all that much). First, there is really not that much reason to use Kotlin for the type of applications that would normally be written in Java. When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin. It is more difficult to find people with experience to work on Kotlin. Kotlin is slower than Java, but for most applications it shouldn't really matter (in that if you make it your focus you are probably wasting time while you could be doing something more worthwhile). To develop in Kotlin well, you should also know Java. So now you really need to know two languages. Let's face it, people who go to work with Java projects are not exactly cream of the crop (and I am saying this after working with Java for the past 20 years). Java has some excellent frameworks (ie. Spring), documentation and guidance (ie. stack*) on how to structure your application that makes it much easier for a junior developer to start writing new service and for everybody to understand existing code (because it all looks alike). As a tech lead this lets me focus on other stuff rather than telling developers how to write a controller, how to read configuration file, how to structure your database layer, etc. And bunch other reasons...

qsort 5y ago
I agree with the gist of your comment, but this: > Let's face it, people who go to work with Java projects are not exactly cream of the crop is a bit of a weird take. If you're saying that most people working in software engineering aren't "exactly cream of the crop" to begin with, then you probably have a point (I'm a java dev as well, by the way), but I don't see how the programming language changes the equation.
- tga 5y ago
  http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html True in 2004, probably still true to some extent in 2021.
  - deleted 5y ago
    [deleted]
  - felipemnoa 5y ago
    So how do you resolve the paradox where a person works in Python and Java? Trust me, they exist. And not only those languages, but a bunch others.
  - qsort 5y ago
    That's still likely to be somewhat true, but it isn't really about programming languages, it's about new/niche technologies vs. established technologies. By the same logic, Python would now also be in the 'uncool' group, since everyone and their mother uses it.
    - watwut 5y ago
      I think that it was never true. People always find ways to feel superior over random things and the above article was written to please certain kind of readers. > if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. During whole my career, I have found that there are always new things to learn. Learning is not limited to picking new language. And if you work in more popular language, no matter which one, there are always new framerworks, libraries, security issues, performance optimizations, approaches, tools to integrate with, algorithms, you name it. What he is saying there is either that picking new language matters more then the above. I don't find that convincing. > So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor. Is a programmer with aesthetic preference against java really inherently superior? I find that whole section low on arguments and high on colorful emotions appealing metaphors.
      - loopz 5y ago
        Not coding in java is often about preference and choice. Not sure where the superiority comes from.
  - 5y ago
- ttiurani 5y ago
  Indeed. * Most software is done in teams. * If the code is good, it will be in use for a long time. * Hence if you want to work on software that matters, you will often work with a language that is not your one true love. Me and my extremely brilliant collegues in my current project write Java, because that's the language the team has chosen. The language, when it's one of the major ones, has no significance.
FpUser 5y ago
>"Let's face it, people who go to work with Java projects are not exactly cream of the crop" Here, fixed it for you: Let's face it, people who go to work with any software projects are not exactly cream of the crop. This is natural. You have bad performers, meh performers (a majority) and top performers (a minority) and it goes like this in almost every area of human's productive activity.
- lmilcin 5y ago
  Different type of developer is drawn to different types of languages and different types of projects. Developers who barely can write loops don't go write games in C++. They are much more likely to go write corporate backends in Java because corporations are notoriously very bad at sorting who is good and who is bringing negative value.
  - FpUser 5y ago
    Game developers have their own meh level. It is just different from that of corporate backend developers.
felipemnoa 5y ago
>>> Let's face it, people who go to work with Java projects are not exactly cream of the crop You can apply that saying to any language or project. The fact you are biased against Java is a bit disturbing. I know it is cool to be a Java hater but why? Your comment reminds me of this: https://xkcd.com/378/ https://xkcd.com/378/
- theaeolist 5y ago
  At the university where I teach we used to have two year 1 intro to programming courses: Java and OCaml. The weaker students overwhelmingly preferred Java and the stronger students OCaml. I don't think that was a statistical anomaly in a 200+ size class.
  - qsort 5y ago
    With all the due respect, that's apples to oranges. It's unsurprising that stronger students prefer OCaml, because it's objectively the more interesting (or at least the more intellectually stimulating) language. When we're talking about programming languages as engineering tools, a whole lot of ancillary issues must be taken into account. Is the language performant enough? Is the tooling good enough? Does it have good library support? What about C integration? Is it easy do build and deploy? Java vs. OCaml is precisely a great example of this conundrum: OCaml is objectively the better language by a mile, Java has objectively better support by a mile.
    - lmilcin 5y ago
      I think you both agree, you just guys don't see it. I don't know if OCaml is better than Java because I don't use OCaml. But in general, the better you are at development the greater choice you have. And also better developers on average prefer more powerful tools because for them the steep learning curve is not prohibitive and because they can recognize value of using more powerful tool. Weaker developers are basically happy they can program at all and most weak developers to settle on the first programming language they learn. Want to filter out poor developers? Don't hire anybody who only knows single programming language well. Not because knowing two languages makes you better but because you put effort in learning another language which means you had the curiosity, perseverance and ability to do it. Learning a programming language when you are good developer is no issue -- I do it in passing just to solve some particular problem and move on. If you are poor developer learning a language might be major effort and accomplishment you may not want to pay for again. I personally know of no good developer who only knows single language.
tablespoon 5y ago
> When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin. I've never used Kotlin, but this is exactly my experience with Groovy. Ten years ago, my department had some Groovy enthusiasts that pushed it heavily, but now we have a bunch of Groovy systems where the majority of the development staff are NOT Groovy enthusiasts, and many are either new hires or low-cost offshore devs with only Java backgrounds. Now all Groovy provides us is the opportunity to experience new classes of bugs that we probably wouldn't see if they systems were written in Java [1]. Generally, I think long lived systems should be written in some kind of "lowest common denominator" language. That's likely to be more easily maintained long in the future. They especially should NOT be written in some other language where someone can get by by pretending it's the LCD language, since that an invitation for bugs wherever the other language violates LCD language assumptions. [1] My favorite is one where a previous entry-level guy wrote a loop, declared the control variable as a STRING, then used ++ to increment it. Instead of failing fast, Groovy "made sense" of this by interpreting that last char of the string as a char, incrementing that, then coercing the whole thing back to an int for the comparison. This worked, UNTIL the control variable had to go past 9, after which the increment resulted in a ':' and the coercion back to an int started failing in prod.
- svachalek 5y ago
  The name Groovy brings back some old nightmares. Any time a language has syntax reduction as a main feature, it's just optimizing the generation of tech debt. (Real advances come through safely bundled abstractions, not typing speed)
- imtringued 5y ago
  >My favorite is one where a previous entry-level guy wrote a loop I'll be honest. I barely write any sort of loop in groovy. I just checked. One of my projects had 1 for loop and zero while loops. Everything else was done with findAll, collect, each etc.
  - 5y ago

qsort 5y ago

I agree with the gist of your comment, but this: > Let's face it, people who go to work with Java projects are not exactly cream of the crop is a bit of a weird take. If you're saying that most people working in software engineering aren't "exactly cream of the crop" to begin with, then you probably have a point (I'm a java dev as well, by the way), but I don't see how the programming language changes the equation.

tga 5y ago
http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html True in 2004, probably still true to some extent in 2021.
- deleted 5y ago
  [deleted]
- felipemnoa 5y ago
  So how do you resolve the paradox where a person works in Python and Java? Trust me, they exist. And not only those languages, but a bunch others.
- qsort 5y ago
  That's still likely to be somewhat true, but it isn't really about programming languages, it's about new/niche technologies vs. established technologies. By the same logic, Python would now also be in the 'uncool' group, since everyone and their mother uses it.
  - watwut 5y ago
    I think that it was never true. People always find ways to feel superior over random things and the above article was written to please certain kind of readers. > if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. During whole my career, I have found that there are always new things to learn. Learning is not limited to picking new language. And if you work in more popular language, no matter which one, there are always new framerworks, libraries, security issues, performance optimizations, approaches, tools to integrate with, algorithms, you name it. What he is saying there is either that picking new language matters more then the above. I don't find that convincing. > So a language that makes source code ugly is maddening to an exacting programmer, as clay full of lumps would be to a sculptor. Is a programmer with aesthetic preference against java really inherently superior? I find that whole section low on arguments and high on colorful emotions appealing metaphors.
    - loopz 5y ago
      Not coding in java is often about preference and choice. Not sure where the superiority comes from.
- 5y ago
ttiurani 5y ago
Indeed. * Most software is done in teams. * If the code is good, it will be in use for a long time. * Hence if you want to work on software that matters, you will often work with a language that is not your one true love. Me and my extremely brilliant collegues in my current project write Java, because that's the language the team has chosen. The language, when it's one of the major ones, has no significance.

FpUser 5y ago

>"Let's face it, people who go to work with Java projects are not exactly cream of the crop" Here, fixed it for you: Let's face it, people who go to work with any software projects are not exactly cream of the crop. This is natural. You have bad performers, meh performers (a majority) and top performers (a minority) and it goes like this in almost every area of human's productive activity.

lmilcin 5y ago
Different type of developer is drawn to different types of languages and different types of projects. Developers who barely can write loops don't go write games in C++. They are much more likely to go write corporate backends in Java because corporations are notoriously very bad at sorting who is good and who is bringing negative value.
- FpUser 5y ago
  Game developers have their own meh level. It is just different from that of corporate backend developers.

felipemnoa 5y ago

>>> Let's face it, people who go to work with Java projects are not exactly cream of the crop You can apply that saying to any language or project. The fact you are biased against Java is a bit disturbing. I know it is cool to be a Java hater but why? Your comment reminds me of this: https://xkcd.com/378/ https://xkcd.com/378/

theaeolist 5y ago
At the university where I teach we used to have two year 1 intro to programming courses: Java and OCaml. The weaker students overwhelmingly preferred Java and the stronger students OCaml. I don't think that was a statistical anomaly in a 200+ size class.
- qsort 5y ago
  With all the due respect, that's apples to oranges. It's unsurprising that stronger students prefer OCaml, because it's objectively the more interesting (or at least the more intellectually stimulating) language. When we're talking about programming languages as engineering tools, a whole lot of ancillary issues must be taken into account. Is the language performant enough? Is the tooling good enough? Does it have good library support? What about C integration? Is it easy do build and deploy? Java vs. OCaml is precisely a great example of this conundrum: OCaml is objectively the better language by a mile, Java has objectively better support by a mile.
  - lmilcin 5y ago
    I think you both agree, you just guys don't see it. I don't know if OCaml is better than Java because I don't use OCaml. But in general, the better you are at development the greater choice you have. And also better developers on average prefer more powerful tools because for them the steep learning curve is not prohibitive and because they can recognize value of using more powerful tool. Weaker developers are basically happy they can program at all and most weak developers to settle on the first programming language they learn. Want to filter out poor developers? Don't hire anybody who only knows single programming language well. Not because knowing two languages makes you better but because you put effort in learning another language which means you had the curiosity, perseverance and ability to do it. Learning a programming language when you are good developer is no issue -- I do it in passing just to solve some particular problem and move on. If you are poor developer learning a language might be major effort and accomplishment you may not want to pay for again. I personally know of no good developer who only knows single language.

tablespoon 5y ago

> When I look at Kotlin code in my org most of it looks like Java with some very slight, cosmetic differences. The reality is overwhelming majority of people writing Kotlin is Java developers and overwhelming majority of those continues what they were doing in Java but now in Kotlin. I've never used Kotlin, but this is exactly my experience with Groovy. Ten years ago, my department had some Groovy enthusiasts that pushed it heavily, but now we have a bunch of Groovy systems where the majority of the development staff are NOT Groovy enthusiasts, and many are either new hires or low-cost offshore devs with only Java backgrounds. Now all Groovy provides us is the opportunity to experience new classes of bugs that we probably wouldn't see if they systems were written in Java [1]. Generally, I think long lived systems should be written in some kind of "lowest common denominator" language. That's likely to be more easily maintained long in the future. They especially should NOT be written in some other language where someone can get by by pretending it's the LCD language, since that an invitation for bugs wherever the other language violates LCD language assumptions. [1] My favorite is one where a previous entry-level guy wrote a loop, declared the control variable as a STRING, then used ++ to increment it. Instead of failing fast, Groovy "made sense" of this by interpreting that last char of the string as a char, incrementing that, then coercing the whole thing back to an int for the comparison. This worked, UNTIL the control variable had to go past 9, after which the increment resulted in a ':' and the coercion back to an int started failing in prod.

svachalek 5y ago
The name Groovy brings back some old nightmares. Any time a language has syntax reduction as a main feature, it's just optimizing the generation of tech debt. (Real advances come through safely bundled abstractions, not typing speed)
imtringued 5y ago
>My favorite is one where a previous entry-level guy wrote a loop I'll be honest. I barely write any sort of loop in groovy. I just checked. One of my projects had 1 for loop and zero while loops. Everything else was done with findAll, collect, each etc.
- 5y ago