6 ms·

I love Java. I think it has changed the world for the better. That being said, I just can't get excited about new language features now that I have discovered

by pawadu 9y ago

I love Java. I think it has changed the world for the better. That being said, I just can't get excited about new language features now that I have discovered Kotlin. It is essentially Java but with a much smarter compiler and a more modern and sane syntax.

lmm 9y ago
Similarly, I can't get excited about Kotlin's features because they're all things I've been using for 5 years already in Scala.
- koolba 9y ago
  Does Scala/sbt still take 5 years to compile moderately sized apps?
  - pawadu 9y ago
    Kotlin syntax is a well-thought subset of Scala. The designers basically removed everything that made Scala slow to process and hard to optimize. As a side-effect, Kotlin is much easier to read and understand than Scala.
    - scalatohaskell 9y ago
      > Kotlin is much easier to read and understand than Scala. No. It's not.
    - lmm 9y ago
      They've had to add back a lot of things piecemeal as they realised they'd missed important use cases for Scala's more general features as they tried to "simplify" them. The language's history so far suggests the original design was far from well-thought, and I expect that trend to continue in a more visible way post-1.0. (E.g. as applications get larger you tend to need to understand the reasons for why something didn't happen, so you move from Option on to using an Either-style type that carries some information in the failure case. But Kotlin is hardcoded around using null to express absence and it's impossible to migrate from that to something that includes a reason).
      - wiradikusuma 9y ago
        That's what I feel as well. I feel that Scala started "too big" and gets "slimmed down" over time (like, implicit is now not-so-recommended), while Kotlin goes the other way around. I still prefer Scala whenever possible, but Kotlin really shines for Android (I tried Scala, I couldn't stand build time on top of the already-long Android build).
  - PedroBatista 9y ago
    It's down to 4 years give or take.
  - tasuki 9y ago
    It has improved somewhat. Also with incremental compilation, compile times aren't really an issue.
  - edejong 9y ago
    I've programmed Scala professionally for the last 4 years. The compiler used to be rather slow, but nowadays, it is fast enough for my taste. Just be careful with the cake-pattern, which slows down compilation substantially. Also, I notice that, as I write type-safe code, I don't usually compile that often and, when it compiles, it is likely correct.
  - paulddraper 9y ago
    I think it is on par with other "slow" language compilers that perform to inference: Kotlin, Swift, Haskell The incremental compilation is pretty good.
- beachbum8029 9y ago
  ICE BURN
forinti 9y ago
I used to like Java when it was simpler. Generics I thought were great, but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language. And I still can't have multiline strings (on a language used for Web programming!).
- _pmf_ 9y ago
  > but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language None of the new features has anything to do with dynamic languages[0]. Streams and lambdas are still statically typed. [0] Well, there is DynamicInvoke, but this is not a Java feature, but a JVM feature.
- jitix 9y ago
  The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy. I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.
  - vonmoltke 9y ago
    Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?
    - jitix 9y ago
      Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.
  - creepydata 9y ago
    Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.
deleted 9y ago
[deleted]

by pawadu 9y ago

lmm 9y ago

Similarly, I can't get excited about Kotlin's features because they're all things I've been using for 5 years already in Scala.

koolba 9y ago
Does Scala/sbt still take 5 years to compile moderately sized apps?
- pawadu 9y ago
  Kotlin syntax is a well-thought subset of Scala. The designers basically removed everything that made Scala slow to process and hard to optimize. As a side-effect, Kotlin is much easier to read and understand than Scala.
  - scalatohaskell 9y ago
    > Kotlin is much easier to read and understand than Scala. No. It's not.
  - lmm 9y ago
    They've had to add back a lot of things piecemeal as they realised they'd missed important use cases for Scala's more general features as they tried to "simplify" them. The language's history so far suggests the original design was far from well-thought, and I expect that trend to continue in a more visible way post-1.0. (E.g. as applications get larger you tend to need to understand the reasons for why something didn't happen, so you move from Option on to using an Either-style type that carries some information in the failure case. But Kotlin is hardcoded around using null to express absence and it's impossible to migrate from that to something that includes a reason).
    - wiradikusuma 9y ago
      That's what I feel as well. I feel that Scala started "too big" and gets "slimmed down" over time (like, implicit is now not-so-recommended), while Kotlin goes the other way around. I still prefer Scala whenever possible, but Kotlin really shines for Android (I tried Scala, I couldn't stand build time on top of the already-long Android build).
- PedroBatista 9y ago
  It's down to 4 years give or take.
- tasuki 9y ago
  It has improved somewhat. Also with incremental compilation, compile times aren't really an issue.
- edejong 9y ago
  I've programmed Scala professionally for the last 4 years. The compiler used to be rather slow, but nowadays, it is fast enough for my taste. Just be careful with the cake-pattern, which slows down compilation substantially. Also, I notice that, as I write type-safe code, I don't usually compile that often and, when it compiles, it is likely correct.
- paulddraper 9y ago
  I think it is on par with other "slow" language compilers that perform to inference: Kotlin, Swift, Haskell The incremental compilation is pretty good.
beachbum8029 9y ago
ICE BURN

forinti 9y ago

I used to like Java when it was simpler. Generics I thought were great, but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language. And I still can't have multiline strings (on a language used for Web programming!).

_pmf_ 9y ago
> but the new features just seem like attempts to shoehorn features of dynamic languages onto a business language None of the new features has anything to do with dynamic languages[0]. Streams and lambdas are still statically typed. [0] Well, there is DynamicInvoke, but this is not a Java feature, but a JVM feature.
jitix 9y ago
The multi line issue pisses me off on a daily basis, esp when writing tests that deal with JSONs. It's so much readable with multi line strings in python and groovy. I usually use groovy for my fun/toy projects but at my day job writing enterprise code the tests have huge JSON building blocks before the actual assertion happens.
- vonmoltke 9y ago
  Why not embed the JSON as a file in the test resources and read it in during the test setup? Is there a particular reason it needs to be embedded in the source code of the test?
  - jitix 9y ago
    Its to maintain context. If a developer is looking at a large test code then it becomes difficult to switch back and forth between 10s of JSON files and the main test code. Having the input, output and the test data in the same file is much more convenient.
- creepydata 9y ago
  Um, you really should be loading that sort of text/data from an external resource rather than embedding it in source code. Those sort of text blocks really don't belong in source code.

deleted 9y ago

[deleted]