Move to Kotlin?

General Discussions
#141

[quote=“phunni,post:139,topic:59074”]
As princecc said, it’s mostly about the framework and API you are using, how you have to do the architecture of your application. There are some limiations/common workarounds for problems other platforms don’t suffer that are related to the JVM, but I won’t emphasize this too much now.

As for your question: Yes, you are totally free, within the bounds of Kotlin of course. Since Kotlin is a objectfunctional language at its core, you have the well-known foundation of object orientation. Additionally, there are first class functions and a strong std lib for functional stuff. If you want to design your application in a very pure functional way, than there might be better alternatives out there. Even if you always want to use the most complex programming patterns to solve every problem with absolute perfection…than maybe the whole JVM is not your best choice. If you only talk about web frameworks, with Kotlin you can pretty much use everything Java can use, so you have concepts like function as a server, servlet apis, spring for good old mvc applications, Sinatra-like web frameworks…and Kotlin is very useful for DSL stuff, if you would want to be that flexible.

#142

[quote=“princec,post:122,topic:59074”]
Const indicates a compiletime constanct. For example you could share a String between annotations, which isn’t possible in Java. Shamelessly taken from the Kotlin docs:


const val SUBSYSTEM_DEPRECATED: String = "This subsystem is deprecated"

@Deprecated(SUBSYSTEM_DEPRECATED) fun foo() { ... }

To prevent the next question :slight_smile: : Const is a soft keyword that has a meaning in a context. It can’t stand alone and isn’t a reserved keyword in that meaning.

#143

What makes you think you can’t use String constants with annotations in Java?

#144

You are right, i was confused here. What does const actually do at all :smiley: someone knows?

Edit: ah okay, const is used to not let the value become a property i think.

#145

[quote]Edit: ah okay, const is used to not let the value become a property i think.
[/quote]
?
It just means the value of the statement is determined at compilation time and thus is able to be used in other things that are determined at compilation time, like annotations.

#146

Yes, that’s clear, but what would be the reason to it not just be a val, if val is final too? I think it’s because val and var are always properties and there are not field semantics, don’t you think?

#147

They are both final but val is not given a value at compile time, whereas const is, so you can’t use a non const val in an annotation (or another similar application). I’m not sure what you mean by field semantics, too :stuck_out_tongue:

#148

Well I moved to Kotlin about 2 weeks ago and I certainly don’t regret it ! Just look at this method I made to create BitmapFonts


    private fun generateFont(fontPath: String, params: FreeTypeFontParameter.() -> Unit): BitmapFont {
        val generator = FreeTypeFontGenerator(Gdx.files.internal(fontPath))
        val parameter = FreeTypeFontParameter().apply { params() }
        val result = generator.generateFont(parameter)

        generator.dispose()

        return result
    }

Now with this method I can elegantly create fonts objects like so


val fontTitle: BitmapFont = generateFont("Jukebox_HUD/Franklin Gothic Book.ttf") {
        size = 14
        color = Color.RED
        borderColor = Color.BLACK
        borderWidth = 0.4f
}

val fontDirectory: BitmapFont = generateFont("Jukebox_HUD/Franklin Gothic Demi Cond.ttf") {
        size = 18
        color = Color.BLUE
}

Ok the string parameter may not be elegant (enum would be better I guess) but you get the point of what I want to show !

#149

Very nice indeed :slight_smile:

I think you could change

val parameter = FreeTypeFontParameter().apply { params() }

to

val parameter = FreeTypeFontParameter().params()

The extension function is available via dot notation on any instance of the extension function’s class :slight_smile:

#150

Oh right ! I’ll test that tonight !

#151

I think we can simplify even further the method


private fun generateFont(fontPath: String, params: FreeTypeFontParameter.() -> Unit): BitmapFont {
        val generator = FreeTypeFontGenerator(Gdx.files.internal(fontPath))
        val parameter = FreeTypeFontParameter().apply { params() }
        val result = generator.generateFont(parameter)

        generator.dispose()

        return result
    }

to


private fun generateFont(fontPath: String, params: FreeTypeFontParameter.() -> Unit): BitmapFont {
        val generator = FreeTypeFontGenerator(Gdx.files.internal(fontPath))
        val parameter = FreeTypeFontParameter().params()

        return generator.generateFont(parameter).also { generator.dispose() }
}

I’m pretty sure it works but I’m not home so I can’t test rn

EDIT: After testing on the online compiler, this seems to work, and


return generator.generateFont(parameter).also { generator.dispose() }

can even be replaced by


return generator.generateFont(parameter).apply { generator.dispose() }
#152

Wanna play?


private fun generateFont(fontPath: String, params: FreeTypeFontParameter.() -> Unit) = 
    with(FreeTypeFontGenerator(Gdx.files.internal(fontPath))) {
        generateFont(FreeTypeFontParameter().params()).also { dispose() }
    }
#153

Oh nice one ! :slight_smile:

#154

By adding two typealiases


typealias FontGen = FreeTypeFontGenerator
typealias FontPar = FreeTypeFontParameter

and by having a shorter method name (generateFont -> newFont) I can now have this


private fun newFont(fontPath: String, params: FontPar.() -> Unit) = with(FontGen(Gdx.files.internal(fontPath))) {
    generateFont(FontPar().params()).also { dispose() }
}
#155

Slowly you start giving people reasons to hate Kotlin again xD

#156

I prefer dumb code. Smart code requires brainpower to read and write. Dumb code is understandable at 12 AM, and that’s what matters :wink:

#157

Exactly. Code should be understandable by a sub-mediocre (your 9-to-5-don’t-want-to-learn-new-stuff sort of) developer, since that is what the vast majority of the companies owning that code will have to work with.
You certainly DO NOT want any “cleverness” in your code which only you will be able to wrap your head around in a reasonable amount of time.
That is why I probably will never use Kotlin on a customer’s site. Just like JavaScript it provides sooo many opportunities to have “cleverness” sleak its way into your code and have people tinker about how they would cleverly design every single code line. And then you are basically screwed.
Java has a very good way of giving you not many opportunities to be clever and to make your code less understandable. I think missing operator overloading and extension functions is a remarkable plus in favor of Java.

#158

[quote=“KaiHH,post:157,topic:59074”]
I think those are two Bad examples for your otherwise probably correct view. The operator overloading in kotlin is also known as “Sane” operator overloading and can make your and your reader’s live really much easier while it doesn’t support the ugly stuff. Extension functions basically the same thing, no magic here.

The confusing thing is probably the functional style method chaining (lets be honest, most of the functional stuff ist bad from a typical Java programmer’s point of View) in combination with those implicit receivers kotlin has where you “have multiple this”. One should not overuse Any feature Just to make the code less symbols for the Sake of it. Nevertheless powerful tools for many situations where you can improve readabiliy a lot with them.

#159

All of the functional stream stuff in Java is pretty hard to understand by looking at it to be honest. This has always been the main problem with functional programming in general - to understand what it is doing you pretty much have to evaluate the bloody thing in your own head first which rather defeats the object somewhat.

Cas :slight_smile:

#160

I don’t think that it is a problem with Java in particular, although I agree that functional stuff in Java is even uglier than it would be with for example Scala or Kotlin. Functional programmers always think in patterns that already solved all problems you can have. You just have to put in the right functional pattern and you decleratively solved the problem. Like some people don’t like over-generifying things in object oriented programming, regular C-like-languages programmers don’t like that functional programming is exactly this in essence. My assumption is, that it is not hard any more, if you know the vocabulary. While Java’s vocabulary is very small, which I really like about Java, Kotlin’s is just a bit larger… a hand full of std functions for chaining stuff that you can learn in one or two days and you can read most of the stuff without having to think about it at all. But I understand if people want to limit the alphabet to a minimum, because that makes life easier.