Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Java to Kotlin and Back Again

allegro.tech

Post reply on HN
Print view View original

161–170 of 199 posts

Re: From Java to Kotlin and Back Again

#161

Post by zaphirplane »

lmm wrote: post #129
__sr__ wrote: post #117

Earlier quoted context omitted.

Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible? Simple, they all serve a particular purpose. Scala serves a particular purpose, so does Kotlin. I have found Kotlin to be an easy to use modern language which the JVM ecosystem was IMO lacking. That said, I am not a…

> Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible? Because C++ and Python aren't safe enough, Haskell is too hard to learn, and Lisp is too flexible to maintain. Or maybe you weigh the factors differently and wouldn't use Java, and would pick one of those language…

> Because C++ and Python aren't safe enough

I wonder what langauages are used in aircraft jets, military, space industry, pace makers ... etc

Re: From Java to Kotlin and Back Again

#162

Post by zaphirplane »

lmm wrote: post #115
kllrnohj wrote: post #104

Earlier quoted context omitted.

> then why would you adopt it when it's missing important features compared to Scala Such as?

At the concrete/immediate level, a nice way to do error handling when you want errors to include a detail message (i.e. a Result/Either-like) - most languages that offer Option-like types let you use a type like that the same way, but in Kotlin the nice ?. syntax only works for "null". Even Java checked exceptions are a better answer for that use case than anything in Kotlin. Proper immutable types for e.g. collectio…

> Kotlin has a bunch of syntaxes that could be reused for this - .?, async/await

Kotlin seems to have reused the hell out of the poor :

Re: From Java to Kotlin and Back Again

#163

Post by zaphirplane »

lmm wrote: post #99
__sr__ wrote: post #45

Is it me, or does the article feel like it is written by someone who didn’t actually bother to learn Kotlin. Instead they learnt the bare minimum syntax and tried to write Java in Kotlin. The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? > I have my favorite set of JVM languages. Java in /main and Groovy in /test are…

> The author complains a lot about how Kotlin is different from Java. Err.. it is a new language — it is supposed to be different — otherwise why bother? Kotlin advocates try to have it both ways. If it's a full new language, to be evaluated as a full language, then why would you adopt it when it's missing important features compared to Scala? The narrative is that it's a set of small enhancements to Java that are ea…

Scala has way to many features to be loved and most people that actually know Scala will tell you most users of Scala are not taking advantage of its features or abusing the ones they know. Go on the other hand a very popular language ( yeah yeah ) probably due to its small feature set

Re: From Java to Kotlin and Back Again

#164

Post by jscissr »

jscissr wrote: post #103
singularity2001 wrote: post #65

Earlier quoted context omitted.

JS does

Actually no, all keys are strings in JS, and if you use something that isn't a string as a key, it is converted to a string (unless you meant Maps[1], which don't use object notation). [1]: https://developer.mozilla.org/docs/Web/JavaScript/Reference/...

Ok, I forgot Symbol, so you were correct.

Re: From Java to Kotlin and Back Again

#165

Post by eeperson »

kllrnohj wrote: post #151
lmm wrote: post #147

Earlier quoted context omitted.

I must admit I don't entirely understand how your approach works, but it seems like it requires all the functions you want to use in transactions to live on MyTransaction (even if only as extension methods)? I want to be able to write normal functions including quite high-level ones that take some business objects and return MustHappenInTransaction[SomeOtherBusinessObject], and pass these return values through generi…

typealias MustBeInTransaction = MyTransaction.() -> Unit fun makeObject(i: Int): MustBeInTransaction { return { /* do something with i or whatever in a transaction */ } } fun test() { var genericArray = arrayOf(1, 2, 3).map { makeObject(it) } //genericArray.forEach { it() } // fails to compile transaction { genericArray.forEach { it() } } } Like that?

It is interesting to see that is possible in Kotlin. I just learned a lot about receivers (as an aside, do you know where I can find better documentation? The best I could find was a stack overflow post).

I think this issue with this is what happens when you combine DB transactions with async queries with errors and null handling? It seems like you have to combine 4 different mechanisms in order to do this (receivers, async/await, try/catch, if(null)). Is there some way to do this all with receivers? It seems like they don't really compose.

The 'command' version in Scala could be written roughly the same way for any combination of the 4 features (the types would just change). For example you could write your original example as:

    def test() {
        // update() compiles but doesn't do anything to the DB
        val helloDBOperation = for {
            result1

Re: From Java to Kotlin and Back Again

#166

Post by V-2 »

Sir_Substance wrote: post #145
jhall1468 wrote: post #119

Earlier quoted context omitted.

> The colon operator is contextless It has a type after. Always. Even assuming that's not enough for it to click, that Google search took all of 3 seconds and you are now typing ":" over "extends" thousands upon thousands of times. If you honestly thing one of those takes more time than the other, you haven't really thought this through. This is a silly argument.

>and you are now typing ":" over "extends" thousands upon thousands of times That's blatant hyperbole, and also a worthless argument. How many times have you typed "int"? Should we replace it with a symbol? Maybe go back to space-cadet keyboards[1]? J is a language built around symbols for maximum programming speed. It's not an esolang, it's real and usable, and recently updated. Here's a very simple J function: resu…

"result=: {&((65 97+/~i.2 13) |.@[} i.256)&.(a.&i.)

Very efficient, minimum keystrokes. Can you tell me what it does?"

Well; can you tell me what this means? :) https://www.publicdomainpictures.net/pictures/20000/velka/si...

Obviously there are extremes on both sides of this spectrum... It's subjective where the perfect compromise between being explicit and being concise lies. Some languages value the former more (like Pascal or Python...), others are more terse. It's always a trade-off.

"Fundamentally, programming languages are for people, not computers"

Of course, but that doesn't mean the correlation here is as simple as "the more verbose, the better". Otherwise than you imply, verbosity does have its own inherent cost too. It increases the cognitive load on the reader, who now needs to process more text to the same effect, as the meaning-to-text ratio drops.

"Keystrokes are /not/ the expensive or dangerous part of programming, we shouldn't be optimising our languages to reduce them"

It's not about keystrokes though, since code is read much more often than written. Every piece of code written once will be read several times eventually.

So would you prefer eg. begin..end to curly braces? Would you prefer "AND" to "&"? Even wordy language such as Java have been heavily optimized to save space.

It's obviously subjective, but the programming community "votes with their feet", and if you look eg. at the "most loved languages" StackOverflow poll - https://insights.stackoverflow.com/survey/2018/#technology-m... - it doesn't make an impression like wordiness is what people are after in a programming language.

Re: From Java to Kotlin and Back Again

#167

Post by microsuck »

I understand there are a few valid reasons not to use Kotlin, but this article is blown up with a lot of trash arguments.

> ... so you need to scroll

Maybe you should indent your functions properly?

> How much time do you need to find the return type of this method?

0 seconds. It's literally right below...

> Simply, the neat syntax for collection literals is what you expect from a modern programming language, especially if it’s created from scratch.

Then don't compare statically typed languages with Python or JavaScript

> First, you need to type and read this noisy colon between names and types

How much time do you spend on typing and reading semicolons?

> Back to C++ syntax? For me it’s confusing.

Are you only able to write Java? Is it really that hard for a veteran to switch between languages?

Re: From Java to Kotlin and Back Again

#168

Post by Sharlin »

V-2 wrote: post #69
Sharlin wrote: post #60

Earlier quoted context omitted.

So you can emulate map with language features like that. But what about other combinators? filter, flatMap/andThen, etc? Plus of course combinators have the advantage that once you realize that optionals, lists, futures and so on have a common structure, you only need to learn the interface once.

filter, flatMap etc. are provided as extension functions for collections - see http://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collectio...

Yeah, but to me not having Optional with the same interface, and instead language-level syntax for working with nullables, does smell like bad design.

Re: From Java to Kotlin and Back Again

#169

Post by anad7 »

I've said it earlier, I am saying it again. "Kotlin enthusiasts or rather PR representatives cannot stomach criticism", this is quite visible on the blog itself and here on HNews.

Consult with your CEO, CTO and/or Director of Engineering before switching to Kotlin, there may be things you might not be aware of, think 20 years ahead and think objectively about the pros/cons before heeding to advice of the enthusiasts, they won't be there to help you when your app behaves unexpectedly, or if your tech debt increases or when you are unable to find people willing to work with your messed up code base, remember there's no reverse Kotlin to Java converter built into IntelliJ.

My advice is to sit it out and wait for Java to evolve, which shouldn't be far away, in the meanwhile enjoy writing your code in Java in which you have your actual work experience(8+ years in my case), which has books and resources dedicated to help you understand the pitfalls, design patterns and every trick out there since 22+ years of its existence. Besides I would recommend developers to not waste their time on a language which piggy backs on JVM, many other languages which did that or are doing it have failed, Kotlin won't be an exception. Instead use Java to learn and write complicated Data Structures and Algorithms and learn technologies like Machine Learning, Neural Networks and AI etc to increase your job prospects.

Re: From Java to Kotlin and Back Again

#170

Post by lmm »

zaphirplane wrote: post #161
lmm wrote: post #129

Earlier quoted context omitted.

> Why would you use Java when you could use C++ which has a ton of extra features? Or Haskell which has a lot of neat abstractions? Or Python which is super easy to use? Or Lisp which is extremely flexible? Because C++ and Python aren't safe enough, Haskell is too hard to learn, and Lisp is too flexible to maintain. Or maybe you weigh the factors differently and wouldn't use Java, and would pick one of those language…

> Because C++ and Python aren't safe enough I wonder what langauages are used in aircraft jets, military, space industry, pace makers ... etc

Often "C" but with enough additional tooling on top to qualify as a distinct language (by which I mean: you can't just pick up a random C library - or a random C programmer - and expect to be able to work with them in that environment). Sometimes Ada. Sometimes others. Sometimes a heterogeneous stack that might include Python in some non-safety-critical parts.
Post reply on HN