9 ms·

Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experie

by rattray 10y ago

Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go. I agree about the documentation – I think it's one of the biggest reasons the language has seen such little adoption given its benefits. I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. Kotlin is developed by Jetbrains, so of course they're used to IDE-driven-development, and have a financial stake in people using their products for development. But coming from scripting languages, this sort of documentation gap was a real turn-off for me.

Bromskloss 10y ago
What is it that makes you not having to write so many tests?
- smt88 10y ago
  A decent type system
- iends 10y ago
  Static typing.
  - Bromskloss 10y ago
    Is the reasoning that you then don't have to test what happens if you pass a parameter of the wrong type to a function?
    - bbcbasic 10y ago
      The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
      - Bromskloss 10y ago
        I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.
        bbcbasic 10y ago
        I can't speak for anyone else but I believe so yes.
        iends 10y ago
        Yes. When writing JS you have to explicitly do a lot more validation.
- StavrosK 10y ago
  Without looking, I'm guessing static typing.
eropple 10y ago
> I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all of Maven, Gradle, and SBT, I dropped Kotlin into a Maven project, side-by-side with Java, with a cursory glance at the documentation--"oh, it's another pre-compile-step thing". (Which I then consume via IntelliJ, because IntelliJ imports Maven projects nicely, but Maven allows others to use their IDE of choice.) The pre-compile-step thing sucks, I'll be the first to say that, and it's a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably. I prefer to use multi-module Maven projects and separate out Java and Kotlin--or Scala, for that matter--code into separate ones. But that's a different beast entirely from the initial bootstrap when learning.
- rattray 10y ago
  > your unfamiliarity with the JVM Correct! > a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably A bummer to hear – though I'm glad it's not just me. I tried using Kotlin with the Play Framework and did not have a great time. The hot-reloading features of Play didn't work with Kotlin at all, even with my attempts to `touch` a Java file whenever my Kotlin file changed (presumably they're recompiling more intelligently than I was). Perhaps having SomeController.java and SomeController.kt in parallel, where the former imports the latter, and receives a `touch` or similar whenever the Kotlin file changes, might work? Or would you recon such a project to be a fool's errand?
  - eropple 10y ago
    Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.
    - EtienneK 10y ago
meddlepal 10y ago
I agree the documentation needs work and I am using Kotlin in prod. JetBrains please take note!
- voddan 10y ago
  Could you please elaborate on what needs improving in the docs? Btw, the whole kotlinlang.org is OSS, and you can correct things you don't
winstonewert 10y ago
What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.
- sanderjd 10y ago
  Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
  - dmichulke 10y ago
    I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
    - bbcbasic 10y ago
      I don't see how this reduces the need for a test that the wrong type is handled correctly.
      - dmichulke 10y ago
        The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
        mac01021 10y ago
        And you don't need tests to make sure the assertions are there?
cageface 10y ago
Absolutely. Dynamic languages only seem terse because you don't see all the associated test code inline. I've been programming in a mix of dynamic and statically typed languages for more than 15 years now and I'll take a modern statically typed language over a dynamic language any time if I have my choice. It's a lot harder to design a static type system that's both expressive enough to be pleasant to use and strict enough to be useful. But we're getting there in modern languages like Rust, Kotlin, Swift etc.
voddan 10y ago
"integrate Kotlin files into a Java project without using IntelliJ" - compilation of a mixed project is not a trivial tasks, many things must be set up. A detailed description of this takes a chapter in a book. That's the reason one should use build tools, be it Ant, Maven, or Gradle. The process of setting them up without an IDE is narrowly described in the docs https://kotlinlang.org/docs/tutorials/build-tools.html https://kotlinlang.org/docs/tutorials/build-tools.html

by rattray 10y ago

Bromskloss 10y ago

What is it that makes you not having to write so many tests?

smt88 10y ago
A decent type system
iends 10y ago
Static typing.
- Bromskloss 10y ago
  Is the reasoning that you then don't have to test what happens if you pass a parameter of the wrong type to a function?
  - bbcbasic 10y ago
    The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
    - Bromskloss 10y ago
      I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.
      - bbcbasic 10y ago
        I can't speak for anyone else but I believe so yes.
      - iends 10y ago
        Yes. When writing JS you have to explicitly do a lot more validation.
StavrosK 10y ago
Without looking, I'm guessing static typing.

eropple 10y ago

> I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all of Maven, Gradle, and SBT, I dropped Kotlin into a Maven project, side-by-side with Java, with a cursory glance at the documentation--"oh, it's another pre-compile-step thing". (Which I then consume via IntelliJ, because IntelliJ imports Maven projects nicely, but Maven allows others to use their IDE of choice.) The pre-compile-step thing sucks, I'll be the first to say that, and it's a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably. I prefer to use multi-module Maven projects and separate out Java and Kotlin--or Scala, for that matter--code into separate ones. But that's a different beast entirely from the initial bootstrap when learning.

rattray 10y ago
> your unfamiliarity with the JVM Correct! > a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably A bummer to hear – though I'm glad it's not just me. I tried using Kotlin with the Play Framework and did not have a great time. The hot-reloading features of Play didn't work with Kotlin at all, even with my attempts to `touch` a Java file whenever my Kotlin file changed (presumably they're recompiling more intelligently than I was). Perhaps having SomeController.java and SomeController.kt in parallel, where the former imports the latter, and receives a `touch` or similar whenever the Kotlin file changes, might work? Or would you recon such a project to be a fool's errand?
- eropple 10y ago
  Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.
  - EtienneK 10y ago

meddlepal 10y ago

I agree the documentation needs work and I am using Kotlin in prod. JetBrains please take note!

voddan 10y ago
Could you please elaborate on what needs improving in the docs? Btw, the whole kotlinlang.org is OSS, and you can correct things you don't

winstonewert 10y ago

What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.

sanderjd 10y ago
Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
- dmichulke 10y ago
  I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
  - bbcbasic 10y ago
    I don't see how this reduces the need for a test that the wrong type is handled correctly.
    - dmichulke 10y ago
      The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
      - mac01021 10y ago
        And you don't need tests to make sure the assertions are there?

cageface 10y ago

Absolutely. Dynamic languages only seem terse because you don't see all the associated test code inline. I've been programming in a mix of dynamic and statically typed languages for more than 15 years now and I'll take a modern statically typed language over a dynamic language any time if I have my choice. It's a lot harder to design a static type system that's both expressive enough to be pleasant to use and strict enough to be useful. But we're getting there in modern languages like Rust, Kotlin, Swift etc.

voddan 10y ago

"integrate Kotlin files into a Java project without using IntelliJ" - compilation of a mixed project is not a trivial tasks, many things must be set up. A detailed description of this takes a chapter in a book. That's the reason one should use build tools, be it Ant, Maven, or Gradle. The process of setting them up without an IDE is narrowly described in the docs https://kotlinlang.org/docs/tutorials/build-tools.html https://kotlinlang.org/docs/tutorials/build-tools.html