5 ms·

Kotlin really is good and definitely an improvement over Java, but in my experience (like ~1 year) the language itself makes writing unreadable code too easy; i

by renke1 6y ago

Kotlin really is good and definitely an improvement over Java, but in my experience (like ~1 year) the language itself makes writing unreadable code too easy; it also doesn't help that IDEs like IntelliJ Idea often suggest shorter yet less readable alternatives because it's "idiomatic" Kotlin code. For perspectice, I am writing "enterprise software" and I am big fan of TypeScript.

jillesvangurp 6y ago
I find most intellij suggestions to be quite sensible. It basically teaches you idiomatic kotlin. I'd suggest not fighting the tools and letting them guide you. As for typescript, it's a nice step up from javascript but IMHO more of a gateway drug to other languages (like Kotlin).
- renke1 6y ago
  TypeScript really hits the sweet spot for me. A good type system (real union types, which Kotlin lacks), barely any special syntax to remember but still powerful enough. I do want nominal typing sometimes, though. Although I must admit that I wouldn't use TypeScript in the backend for the projects we work one (but I do for my personal projects).
  - tejinderss 6y ago
    > Although I must admit that I wouldn't use TypeScript in the backend for the projects we work one Can u elaborate on that? Why is TypeScript not suited for some projects?
    - renke1 6y ago
      For us particular, we heavily rely on fat frameworks like Spring (and sometimes Java EE) and there is nothing like that in TypeScript/JavaScript world. It boils down to not having classpath scanning, reflection and annotations in TypeScript, I guess. I don't want to defend these frameworks, though, they certaintly have their flaws, but it is what we use and it is often also what is teached in Germany. We also follow a domain-driven design approach for which we not yet have found a good way to implement in TypeScript (at least not on the "tactical" level). Edit: Also, people don't grok asynchronicity ;)
    - caoilte 6y ago
      last time I was working in Typescript (a year) ago, the date/time libraries were still disappointing and precision math libraries were very way too cumbersome. Both are well solved problems on the JVM and in other languages.
      - dvlsg 6y ago
        Luxon makes for a good date lib stop gap while tc39 works on something built-in that is (hopefully) a bit nicer. https://moment.github.io/luxon/ https://moment.github.io/luxon/ https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/
    - ragnese 6y ago
      For me, it's the Node ecosystem. The probability of even popular libraries having really basic bugs is way too high.
MrBuddyCasino 6y ago
Agree Kotlin gives a developer definitely more rope to hang himself with than Java, and not all IntelliJ suggestions are really "improvements". Biggest danger is, as always, being too clever and/or being a purist.
ImprobableTruth 6y ago
>suggest shorter yet less readable alternatives What do you mean exactly? I feel like Kotlin's brevity is what actually makes it a lot more readable than Java. With Java there's just often so much noise and fluff that doesn't actually mean much, obscuring what the program actually does. Could just be my personal preference, but I feel like in general I have an easier time understanding terse, dense code rather than spacious, verbose code.
- renke1 6y ago
  I can't give specific examples, but something along the lines of suggesting to replace an early return in the form of `if (…)` by something like `… ?:return`. The former alternative makes it way easier to spot on first glance where the functions bails out. The latter hides it in an assignment making it harder to see. I should say, though, that I am by no means an expert Kotlin developer; maybe I just have to get used to idiomatic Kotlin.
  - thu2111 6y ago
    Don't take idiomatic Kotlin too seriously. It's not Go where there's exactly one allowed way to do things. IntelliJ's suggestions go both ways - you can convert to short form and also back to long form automatically. It's that way for a reason: you're trusted to pick the right form on your own.
    - renke1 6y ago
      I'd agree in general, but that hardly works for larger teams or even multiple teams. This can probably be solved by a good linting tool, but I am not too familiar with the state of linting in Kotlin.
      - thu2111 6y ago
        The best linter for Kotlin is the IntelliJ inspector, which is very powerful. You can run inspections from CI builds using TeamCity, at least, probably other CI builds. You may also configure project defaults to trigger various patterns as warnings or errors. Even better, in the latest IntelliJ you can create new inspections from structural search, which is an AST based matching system. So you have a lot of flexibility to make your own lints and warnings without needing to write plugins. However, I think there's a more general issue here, which is that if you don't trust your team to write tasteful code, linters will be of limited use. It may be better to invest in more rigorous code reviews, trainings, style guidance, mentoring etc. I've spent five years managing technical teams using Kotlin (yep, early adopter!) and found most of them could handle it just fine. A little training goes a long way. The worst problems came from developers creating overly complex abstractions, not playing code golf.
on_and_off 6y ago
as somebody who has written a lot of java and kotlin, often I prefer the most explicit option. Code will be mostly read, not written, so if something will make a junior (or in some cases even seasoned) dev scratch their head to be understood, it is best avoided. EG Often I prefer writing an "if != null else" instead of chaining takeIf{}s.

by renke1 6y ago

jillesvangurp 6y ago

I find most intellij suggestions to be quite sensible. It basically teaches you idiomatic kotlin. I'd suggest not fighting the tools and letting them guide you. As for typescript, it's a nice step up from javascript but IMHO more of a gateway drug to other languages (like Kotlin).

renke1 6y ago
TypeScript really hits the sweet spot for me. A good type system (real union types, which Kotlin lacks), barely any special syntax to remember but still powerful enough. I do want nominal typing sometimes, though. Although I must admit that I wouldn't use TypeScript in the backend for the projects we work one (but I do for my personal projects).
- tejinderss 6y ago
  > Although I must admit that I wouldn't use TypeScript in the backend for the projects we work one Can u elaborate on that? Why is TypeScript not suited for some projects?
  - renke1 6y ago
    For us particular, we heavily rely on fat frameworks like Spring (and sometimes Java EE) and there is nothing like that in TypeScript/JavaScript world. It boils down to not having classpath scanning, reflection and annotations in TypeScript, I guess. I don't want to defend these frameworks, though, they certaintly have their flaws, but it is what we use and it is often also what is teached in Germany. We also follow a domain-driven design approach for which we not yet have found a good way to implement in TypeScript (at least not on the "tactical" level). Edit: Also, people don't grok asynchronicity ;)
  - caoilte 6y ago
    last time I was working in Typescript (a year) ago, the date/time libraries were still disappointing and precision math libraries were very way too cumbersome. Both are well solved problems on the JVM and in other languages.
    - dvlsg 6y ago
      Luxon makes for a good date lib stop gap while tc39 works on something built-in that is (hopefully) a bit nicer. https://moment.github.io/luxon/ https://moment.github.io/luxon/ https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/
  - ragnese 6y ago
    For me, it's the Node ecosystem. The probability of even popular libraries having really basic bugs is way too high.

MrBuddyCasino 6y ago

Agree Kotlin gives a developer definitely more rope to hang himself with than Java, and not all IntelliJ suggestions are really "improvements". Biggest danger is, as always, being too clever and/or being a purist.

ImprobableTruth 6y ago

>suggest shorter yet less readable alternatives What do you mean exactly? I feel like Kotlin's brevity is what actually makes it a lot more readable than Java. With Java there's just often so much noise and fluff that doesn't actually mean much, obscuring what the program actually does. Could just be my personal preference, but I feel like in general I have an easier time understanding terse, dense code rather than spacious, verbose code.

renke1 6y ago
I can't give specific examples, but something along the lines of suggesting to replace an early return in the form of `if (…)` by something like `… ?:return`. The former alternative makes it way easier to spot on first glance where the functions bails out. The latter hides it in an assignment making it harder to see. I should say, though, that I am by no means an expert Kotlin developer; maybe I just have to get used to idiomatic Kotlin.
- thu2111 6y ago
  Don't take idiomatic Kotlin too seriously. It's not Go where there's exactly one allowed way to do things. IntelliJ's suggestions go both ways - you can convert to short form and also back to long form automatically. It's that way for a reason: you're trusted to pick the right form on your own.
  - renke1 6y ago
    I'd agree in general, but that hardly works for larger teams or even multiple teams. This can probably be solved by a good linting tool, but I am not too familiar with the state of linting in Kotlin.
    - thu2111 6y ago
      The best linter for Kotlin is the IntelliJ inspector, which is very powerful. You can run inspections from CI builds using TeamCity, at least, probably other CI builds. You may also configure project defaults to trigger various patterns as warnings or errors. Even better, in the latest IntelliJ you can create new inspections from structural search, which is an AST based matching system. So you have a lot of flexibility to make your own lints and warnings without needing to write plugins. However, I think there's a more general issue here, which is that if you don't trust your team to write tasteful code, linters will be of limited use. It may be better to invest in more rigorous code reviews, trainings, style guidance, mentoring etc. I've spent five years managing technical teams using Kotlin (yep, early adopter!) and found most of them could handle it just fine. A little training goes a long way. The worst problems came from developers creating overly complex abstractions, not playing code golf.

on_and_off 6y ago

as somebody who has written a lot of java and kotlin, often I prefer the most explicit option. Code will be mostly read, not written, so if something will make a junior (or in some cases even seasoned) dev scratch their head to be understood, it is best avoided. EG Often I prefer writing an "if != null else" instead of chaining takeIf{}s.