5 ms·
About one and a half year ago we also decided to give kotlin a shot. After a few months my opinion was similiar to yours. Extension-functions, yeah! Anyway, no
by tommyage 7y ago
About one and a half year ago we also decided to give kotlin a shot. After a few months my opinion was similiar to yours. Extension-functions, yeah!
Anyway, nowadays you wouldn't see me making the same statements anymore.
My first issue appeared when I was maintaining an Android app written in Java. I needed an library for some functionality. The only maintained ones were kotlin-libs. But interoperability, right? I didn't hesitated to include it. There is no way to use or extend functionality with typealiases in your java code.
IntelliJ can compile Kotlin into Java and it is easily accessible. But there is no adb debugger for kotlin.
Null Safety is just overhead imho. I know when it is appropriate or neccessary to check for null, otherwise i can get rid of it. And its more easily grep-pable the Java way.
Writing Kotlin is not so fluent as one would guess, the tooling only fools you, that it is. You can easily make use of actions like typing pfi (extends to public final int) for java aswell. But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything.
Additionally, i do not like the implicit type on member property declarations used by almost anybody. The benefit of typing less boilerplate becomes annoying when reading sources outside your ide.
Boilerplate in my opinion is code i need to write by myself. When it is generated by any IDE, i do not bother about it. We are so familiar with Java that we can abstract this boilerplate when reading sources.
Spelling Kotlin to somebody via telephone is also strange for me.
I stopped promoting Kotlin as a Java killer. Code style is too different between different developers.
And why are we creating the same libraries once again?
- t-writescode 7y agoAre you sure there’s no debugger? I’m pretty sure I’ve debugged code in Kotlin from inside Android Studio running on an emulator.
- tommyage 7y agoYes, provided from android studio, but via adb there is only jdb available
- deleted 7y ago[deleted]
- nemetroid 7y ago> But when your property changes from nullsafe to nullable, you need to rewrtiging eeevverything. Isn't the fact that you have to be explicit about null the main feature of explicit null safety?
- tommyage 7y agoYes, it is, but the domain req. can change, requiring to handling an nullable result
- thu2111 7y agoIsn't that the one big situation where null safety really shines? Something that used to be required is now optional, so, you need to visit all the use sites to figure out what a sensible behaviour is when the data isn't there. Without null safety that could be quite tricky, especially when combined with type inference. The value could be stored and used only later, for instance. The compiler flagging where those fields are used without a null check is convenient, it tells you exactly where to insert new code to handle the missing data.
- tommyage 7y agoThank you, I shall be more precise when giving any comment. Honestly, I have not considered the advantages from null-safetyness (rated anything..) properly before posting. I just wanted to rant about kotlin, since i hear too many prayers about it and my gud (stomach) tells me different. I am not able to put it into words, yet. I really appreciate your hint. Anyway, you are absolutely right and I am glad @jach posted an link (above) regarding my intuition (@shoutout). When I learned programming (with Java, 3 yrs. ago) my mentor pointed out that i included too null-checks, even though i was familiar with the entire code base. Just after reading a post on this platform I realized his real intention: Sometimes (most often!) we needlessy check for null. Since then, forcing me to check anytime for null feels wrong and kotlin is forcing me to do so. Eventually I just wanted to mention downsizes which comes into my way when using kotlin daily.. Thankfully..!
- hota_mazi 7y ago> I know when it is appropriate or neccessary to check for null Anyone who thinks they can do better than a compiler for code safety is probably very new to this profession.
- tommyage 7y agoI did not want to claim this. But there are times where you can be sure that the nullable object is not null. You got the double-exclamation-point (!!) for this. But some calls to Android-facilities doesnt accept this, so the IDE notifies you about an var, which could have changed at this point in time. Resulting in multiple !! in the same scope of function.
- distances 7y agoFor me !! is a bad code smell. It is appropriate sometimes, but very rarely. Usually you can write it better with ?.let/apply/also/etc scope functions. Assigning it to temporary val can be done as a workaround for doing !! twice, but as said, probably needs a scope function instead. Same with vars, they are still needed every now and then but most of a clean codebase is hopefully vals and immutable data classes.
- tommyage 7y agoThe thing with scope functions is, you are doing nothing if it is null, returning default (even magic..) value or throwing an unchecked exception, even though you want to force your colleague to handle his failure accordingly
- distances 7y agoYou can always do something else for the null case, but this totally depends on the context. Hard to say anything generic. Throwing an error is always an option too if the value is expected.
- int_19h 7y agoThe whole point is to force you to think about your assumptions every time you write that "!!". It might be annoying, but it's less annoying than debugging an obscure user-reported NPE later on.
- jariel 7y agoI find there's nary such a thing as Kotlin. You always get Kotlin+Java and in the end always two languages to support. It's odd to shift gears all the time, with two sets of syntax tools etc.. I found that despite Java's plainness ... it's robust and I don't worry about 'how fast I can express myself' I'm more concerned about readability and Java is still ok there.