141–150 of 199 posts
Earlier quoted context omitted.
A bit too far I'd say. I'd probably happily work with him.
I have seen his other posts and he is a smart guy. No idea what bit him with Kotlin though...
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…
A useful IDE, much faster compile time, lower cognitive load in daily usage.
And on the other direction, the bytecode generated by the Kotlin compiler also has these Java nullability annotations (it uses the org.jetbrains annotations package), so for instance Dagger2 can know that a type is nullable from the presence of the @Nullable annotation.
If your code already uses @NotNull/@Nullable everywhere, introducing Kotlin to your code base becomes easier. As a bonus, IDEs can sometimes use these to warn you of potential null pointer mistakes in your code.
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 opening lines set the tone for the article
He also wrote:
> we decided to stick with Groovy in /test (Spek isn’t as good as Spock).
If they were going to switch from the legacy language for /main code (i.e. from Java to Kotlin), why didn't they also switch from the legacy language for /test code too (i.e. from Apache Groovy to Kotlin) instead of dismissing it with "Spek isn't as good as Spock". And if they use Gradle, why not switch from Groovy to Kotlin for build scripts also.
Earlier quoted context omitted.
>Why is ":" problematic exactly? It's more concise. Anyone, including non-java programmers, can make an educated guess at what the "extends" keyword does to a java class. The colon operator is contextless. Unless someone tells you or you've coded in c++/c#, you can't know for sure what it means without googling it. Here's a case in point, my biggest bugbear with the nim documentation. When you first see nim code, you…
> 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.
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:
result=: {&((65 97+/~i.2 13) |.@[} i.256)&.(a.&i.)
Very efficient, minimum keystrokes. Can you tell me what it does?
Fundamentally, programming languages are for people, not computers. Otherwise, we'd all be coding in assembly. Keystrokes are /not/ the expensive or dangerous part of programming, we shouldn't be optimising our languages to reduce them. Optimising languages to reduce miscomprehension is the future, that's where expensive developer time and business risk is concentrated.
Preferring to type a colon instead of the word "extends" is, bluntly, the sort of thing you solve with a custom autohotkeys file.
In any case, it's a minimal gain either way with the : operator, that kind of decision won't make or break any language. But this is the internet and if we're going to argue over something so trivial, I'm going to argue that on the most nitpicky level, "extends" is clearly a better choince than ":".
[1] Space-cadet keyboards are really cool
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…
Needless to say after my 2nd round with swift it clicked, and then clicked again and again in different ways as the months rolled on. Never looked back.
Earlier quoted context omitted.
> Re immutable: If you're doing functional why does this matter? "true" immutable vs. just an immutable view should only matter if the object is retained by the function it's passed to, but now we're talking object state rather than pure functions. For the same reason that being able to write val rather than var matters. With perfect discipline you can write pure functional code in any language, but in practice (and…
You can do something like this: class MyTransaction { fun begin() {} fun commit() {} } fun MyTransaction.query() {} fun MyTransaction.update() {} inline fun transaction(tblock: MyTransaction.() -> R): R { val t = MyTransaction() t.begin() try { return t.tblock() } finally { t.commit() } } fun test() { // update() doesn't compile, no such method val hello = transaction { query() update() query() "Hello" } println("$he…
"Kotlin changed the extends keyword into the : operator, which is already used to separate variable name from its type. Back to C++ syntax? For me it’s confusing." Not only C++; C# also. It's not very hard to confuse the author, is it :) I understand it's different from Java he's used to, but that doesn't mean one can hold every such difference against Kotlin. Not being Java isn't in and of itself a fault of a langua…
Earlier quoted context omitted.
steep learning curve does seem laughable. If you know Java, you can be start writing kotlin after a couple of hours with the kotlin koans. My main pain point with kotlin is that I generally have a good idea of how my code will look like as bytecode (like this feature will need an intermediate object, so let's use this instead in this very big loop). In kotlin, it is a bit more of an uncharted territory, even with the…
I've had the same complaint before, for sure--when writing very perf-conscious, GC-sensitive stuff I still might hop over to Java because I do understand its exact behaviors a little better. But, as you mentioned, the bytecode viewer helps a lot.
Especially with one that is constantly evolving like kotlinc.
Some of the bad practices of 5 years ago have devolved into cargo cults and the compiler can actually handle these cases fine now.
So I guess that this is not that great of a reason to choose either Java or Kotlin.
In both cases, if performances are critical and lacking, you will have to whip out systrace and look at the bytecode.