Hacker News Reader

Comment by pawadu | Hacker News Reader

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.

View on HN

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.

Does Scala/sbt still take 5 years to compile moderately sized apps?

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.

> Kotlin is much easier to read and understand than Scala.

No. It's not.

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).

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).

It has improved somewhat. Also with incremental compilation, compile times aren't really an issue.

It's down to 4 years give or take.

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.

I think it is on par with other "slow" language compilers that perform to inference: Kotlin, Swift, Haskell

The incremental compilation is pretty good.

ICE BURN

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!).

> 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.

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.

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?

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.

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.

Why not? Why should a developer need to go through hoops like saving a string to a file then performing IO to load the string into a test case? What's the advantage of moving a string literal into a non-source file?

If I'm trying to test how my system will parse a specific JSON case into a domain object, isn't it easier to read if my test case is completely expressed on the screen?

The I/O will happen anyway, either at the start of the test when loading the compiled test program WITH the big chunk of a string or when reading it from disk, of course you'll add a bit of latency for opening the file itself but it's a very small price to be paid for maintainability.

Even when I develop in Python with multiline strings I use fixture files to better organise my code.

Edit: removed an "even" before maintainability that was part of a first draft.

This is just nonsense not everything will go into a file. Somethings are easier to read on the test itself. It's a case by case problem and choosing is a great asset.

The caretakers of Java strayed. Adopting goofy dynamic and lambda features, trying to attract the cool kids was a mistake.

They should have stuck to their original mission of reducing programming mistakes and boosting productivity.

String processing, a la perl, Python, is something every single developer does every day. We need multilines, intrinsics, first class regexes, etc. every day.

They should have made 'utf8', 'utf16', etc first class scalars, reducing the memory footprint of java.lang.String, and everything reliant on String, ages ago.

They should have increased conciseness, a la Kotlin, Ceylon, Nice, Boo (minus the duck typing), ages ago.

I'm also eager for lightweight objects (value types?), a la Kava, which I think has been pushed back to JDK 10.

Reply on news.ycombinator.com