What I found to affect my productivity in Kotlin

21

What @vladimir_schneider is saying makes sense. I’m not speaking from experience, but just saying their expressions make sense, I feel that I identify with them, and I have the same concerns. The things @yole has said feel dismissive and like they were missing the point.

First off, it seemed like @yole was saying that non-specific feedback is not helpful. That is completely wrong and is very typical engineering miss-thinking. To point out that in general, the refactoring and formatting tools are not nearly as good as Java’s and that this is holding them back from wanting to use it is not undetailed enough to be helpful, it is actually more helpful than filing a bunch of issues for each individual problem they experienced because it points out an underlying problem or problem theme. Why bother to file a bunch of issues they happened to run into if anyone using these tools would run into many of their own issues easily with real world use? This makes it seem like there is a lack of dogfooding with Kotlin, or as @vladimir_schneider inferred, new Kotlin development is taking priority over quality IDE support.

Of course there are limited resources and things must be prioritized and the prioritization will never be perfect. But Kotlin is a language made by JetBrains, and they are the leader in making the best IDEs. Many people will assume this means Kotlin will have just as good as, if not better IDE support than Java. If the experience ends up being different than that, it will be an unexpected turnoff. Kotlin language features should be developed in tandem with, and by the same team as, those providing IDE support. Every new Kotlin feature should not be considered out of beta until the team feels they have out of beta IDE support that equals or rivals what you would experience with Java.

If the people working on the language features are not the same people making the tools to help use them in the IDE, there will be a lack of synergy. The language and the IDE are not unrelated tools, they share a very tight relationship. I actually think this concept of having the same people develop both, should be taken a step further. The IDE support should be added first, or at least simultaneously, as new language features are developed, as a way of aiding the language designers to think in terms of how the language will be used from an IDE. This will help them see relationships they would otherwise miss, and ensure an overall high quality experience, rather than just a high quality language. Why wait for feedback from users when you can be your own users and get the feedback from yourself first?

That leads back to the point about asking for specific feedback from users. That is only helpful when what you are lacking in general is detailed feedback from users. If we can see you seem to already be overwhelmed with specific feedback that you don’t have enough time to keep up with, this does legitimately demotivate people from providing specific feedback, and leads naturally to the idea that general feedback would be more helpful. There are only so many very specific things a team can address at once, but they can also continually improve their mindset and project management philosophy, which is the type of feedback being offered here. Both areas of feedback should be welcome, yet both do have a limit in what can be prioritized for improvement by the team at any given time.

Anyway, I realize this is an old thread, and things have probably improved, somewhat. But unless the team has changed to a more dogfooding mindset and the language and IDE are developed together to provide a desired experience, I don’t expect things will ever get better enough, or at the very least it will take a very, very long time.

22

I think we can safely assume that jetbrains knows exactly which refactorings are not implemented for Kotlin, but are implemented for Java. They may even know for each tool how often they are used (through metrics). What they don’t know is which of the missing refactorings are considered showstoppers. Given the fact that you don’t often hear the people that are happy general complaints are of limited practical value in decision making and prioritization.

23

@pdvrieze

That’s kind of my point though. Why bother to report things we can safely assume they already know? And yet for some reason that was the response from JetBrains to this post, to report each of these details to them.

Also you are completely ignoring what I already explained. I already explained exactly why I think “general complaints” can be of practical value, so to simply say that I am wrong without bother to explain how is the true remark of little value.

I also disagree with the idea that there would necessarily be very specific missing refactorings that are show stoppers. There is also death by a thousand needles. Every little piece of tooling that is supported better in Java than it is in Kotlin is one more reason to think productivity would be higher in Java than in Kotlin, and it all adds up.

Uncle Bob talks about how programmers are quick to jump at the latest shiny language just because the language is incrementally better. He points out how amazingly productive you can be in Java largely because of the IntelliJ IDE. So even if the new language is better in incremental ways, that is not a good enough reason to switch to it.

I also find it strange that when someone reports their productivity is lower in Kotlin for these reasons, one of the responses was basically that they are not getting reports that this is stopping most people from using Kotlin… Seriously, read that again, do you see what I’m saying? Their response to “I’m concerned that the tooling is making me less productive” was “people are not reporting being concerned about the tooling making them less productive”. So lets say someone else having this problem does their due diligence by searching for this already being reported instead of making a duplicate report, how likely are they to say anything after reading that kind of response?

1 Like