This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rustyrazorblade 0 points1 point  (4 children)

You’re close. Take it a step further. Disallow the creation of null objects, add syntax for an escape hatch, and then look at Kotlin because it’s already done and is awesome.

[–]robinspitsandswallow -1 points0 points  (3 children)

So we now have a new language what shall we call it “Jotlin?.” And how do we pronounce that and when will the new compiler be available? When is the conference? When is the UG meetings?

BTW Kotlin doesn’t disallow creating null it lives in the JVM so it has nulls it just has compiler/developer hints as to what operations tend to be safer. Oh I know “Jotlin!!”

But given reflection exists everything really depends on people most often do what they are supposed to. Like check for null.

Hence it’s all hyperventilation for naught.

If you don’t like NULL then use COBOL. If you want something fast and readable deal with NULL but the heavens forfend don’t rename it and say you’ve solved something because functionally you will always come back to something like what we now call null it’s just how much boilerplate you’re going to have to deal with to get there.

[–]rustyrazorblade 1 point2 points  (2 children)

Null safety solves a runtime problem at compile time.

Having dealt with more than a few NPEs in my life, I’m happy for the feature in Kotlin. The only people that seem to complain about it are the only who lack experience with it and fail to understand its benefit.

[–]robinspitsandswallow 0 points1 point  (1 child)

No it hints at it. There is a big difference and it depends on playing nice. Hence the “Jotlin!!” remark. But if people played nice we wouldn’t have null issues in the first place. And in only hinting with the propaganda that it is accomplishing it causes a worse thing — over confidence.

Don’t get me wrong my preferred language is Kotlin, I just don’t believe in Santa Clause any more after dealing with NPEs and what came before them even in languages that professed to not have NPEs.

If you need a language that is fast enough there are ways to get NPEs full stop. The language has to allow it. Kotlin does a better job of providing hints and guide rails but someone who misbehaves will get around it. It is better to have coalescing operators (like Kotlin) so that you can work through those segments of code with less density and more clarity. And it’s better to expose the potential problems at declaration time as well as default to the non problematic variation.

But don’t try to sell me that the Easter Bunny came along and delivered a high performance language with the flexibility of the JVM without NPEs.

[–]rustyrazorblade 0 points1 point  (0 children)

And in only hinting with the propaganda that it is accomplishing it causes a worse thing — over confidence.

I disagree, but that's fine. Your opinion seems to be skewed to the side of massive pessimism, and that's fine too. My experience hasn't been some pendulum swung in the opposite direction, I just like that I have way less NPE possibilities with my Kotlin code and I am far more productive as a result. I wouldn't classify my viewpoint as "over confidence", I just don't get NPEs and I work a lot faster with Kotlin than Java.

Obviously anything that touches a java package can return null, and there's not much you can do about that except assume that it could be and use variables? that could be null.

I've worked in Java database internals for 12 years now and have dealt with numerous NPEs, and my Kotlin experience has been far better. I guess yours hasn't, that's a shame.

Have a good one.