71–80 of 185 posts
I've switched from Scala to Kotlin after 8y of Scala. There are some things I miss (e.g. Options and Futures) but Kotlin feels much more focused on real world problems. And Gradle is so much easier than the monster that is SBT.
With dart news in the past 4 years, the knee-jerk reaction has been that Google will abandon it, which unfortunately means that not much discussion ever went to its merits. Adopting the language has provided a huge productivity boost for me and many other developers, in or outside Google.
I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problem…
> If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." I think that is wrong approach. Kotlin has nothing special or innovative, everything was already here. But it is well balanced and industrial strength (something like java). It is simply good workhorse for mo…
It's the least sexy name for a programming language this century
Earlier quoted context omitted.
Is the reasoning that you then don't have to test what happens if you pass a parameter of the wrong type to a function?
The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
Earlier quoted context omitted.
The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!
I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.
I am a bit in a hurry, so I acknowledge I only quickly scanned the article. But it struck me as damning by faint praise. Like a waiter advising, "Choose the chicken parm. It doesn't have any bones, all the salmonella has been cooked out, and it doesn't have any bad flavor." If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problem…
I'd blame the author for this. He's obviously not a salesperson. To me it seems more like he's a coder who found a new-ish language and he's happy that it solves some of his problems that he's encountered.
>If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce."
For me this was pretty open/shut. Kotlin usage appears to rely upon a lot of side projects. I rarely find that beneficial. Too many cooks.
Earlier quoted context omitted.
Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.
I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.
Earlier quoted context omitted.
> If I'm going to be successfully pitched a programming language, I will need to see its power of expression or be shown how it solves some problems that other languages don't address well. Some "special sauce." I think that is wrong approach. Kotlin has nothing special or innovative, everything was already here. But it is well balanced and industrial strength (something like java). It is simply good workhorse for mo…
Now that JDK8 has made Java more expressive, and Oracle's trolling has come to nothing, I expect Kotlin and Ceylon to fade away. If you want Java, just use it, already.
Kotlin is unquestionably a very large improvement over plain old Java. I fear it might be very hard to make the Android community adopt it massively though, unless Google pitches in and supports it officially.
And this was done without any official support for Google because... it's not necessary: Kotlin works out of the box. Which is one of Kotlin's strengths.