Edit (07/10/2015) : This message was unfair and written with an agressive tone. I've removed it so that the discussion can happen in a correct way, in the rest of this Thread. I deeply apologize to the JB Kotlin team. My next message on this thread reflects the true meaning of my concerns.
It will take me some time to compose an answer. Please be patient, your voice have been heard.
Other members of the community are welcome to express their opinion on the issue.
I think that's a bit harsh. I've submitted feedback on a couple of occasions where the decision has gone against me and it's frustrating. But my take on it is this:
The Kotlin team are language designers who have spent several years thinking about the design and presumably weighing up all the trade-offs. Whereas I’m an interested onlooker who has experience of a few languages and has dabbled in Kotlin.
When they make a decision I don’t like I have to trust (and hope) they’re doing it because they have used Kotlin more extensively than me and thought about the pros and cons a lot more deeply than I have. When I make an argument and they don’t buy it I can only assume my argument wasn’t convincing enough compared to the other factors I haven’t thought about.
It’s also worth noting they asked for feedback; there wasn’t any promise it would be a democratic vote. That wouldn’t be a good way to design a coherent language.
I’ve been following Kotlin since the beginning and my impression is that feedback has often been listened to and has helped shape the language.
You are right, Chris, this is harsh, and I apologize for the tone in the message. I do recognize that the work on Kotlin is tremendous and my message was by no way a rejection of the Kotlin team or their work. I think that the guys at JB are doing a fantastic work and that Kotlin is, by far, the most enjoyable language that I've worked with. So, once again, I'm sorry that my message came out aggressive.
So let me rephrase so we can debate in a less tense fashion.
First I want to re-iterate that this is not specifically about a feature (in this case, the operator keyword) but the way I feel our feedback are being received and handled. For this, I take the operator keyword example.
In this case, as I’ve stated in my message, the community have largely expressed themselves against the idea.
What really bothers me is not that JB have kept the idea itself, it’s that I haven’t seen any acknowledgment of our disagrement. Neither in the blog post that anounces Kotlin M14, nor in the forum.
Something like “We recognize that most of the comments regarding the operator keyword were negative, but after careful consideration, we decided that it was the right course of action for Kotlin”.
Of course, I recognize that JB themselves must have internally the largest Kotlin code-base. And of course, I do agree with you, Chris, when you say that when they make a decision I don’t like I have to trust (and hope) they’re doing it because they have used Kotlin more extensively than me and thought about the pros and cons a lot more deeply than I (we) have.
But what really bothers me is that I don’t feel that our voices are heard when we are asked to speak.
And once again, just to be clear, I think that asking our opinion on every features is probably not the right course of action. What Kotlin needs is a 1.0. And I do not believe in the vertues of democracy for Kotlin (at this moment in its conception).
But I do think that when asking for our opinion, JB should give us the impression that our feedbacks are taken into account, especially when so many feedbacks are negative.
I know this is an important word, but I haven’t found a smaler one : I often feel a sense of light contempt in the way JB communicates about Kotlin. Just a touch, but enough to iritate me.
You know, when the default in Kotlin went to public and that we had to check our entire code base overnight. Nobody was even aware that it was going to happen. Or when they annouce the operator keyword, that was thoroughly argumented against in the comments without real acknowlegement.
I personally invested a lot in kotlin. I have written the application of the startup that employs me entirely in Kotlin. I’ve had to fight to make my bosses accept my decision, because they were really afraid of it. I write kotlin code everyday, whether it’s in said application or in one of the open source kotlin libraries I maintain.
And I’m by no means an exception. Just look at the forum, the slack channels or the blog. The kotlin community is live. It is small but invested. We are invested because Kotlin is a such a great product and that we believe in it.
So there we have it, maybe a touch of acknowlegement of our opinion, maybe a way to give us a sense of participation on even minor language decision, maybe just a way to tell us our voices were heard.
Finally, Kotlin JB guys, thanks for the great things that you give us. Of course I do not agree with everything that you do or more specifically how you do it, but I do remember that kotlin is there for free, and I have you to thank for it 
Personally, I'd hate for a handful of "votes" on a blog post determine the outcome of language features.
With design in general, there’s usually a trade-off for every feature - it takes a SME, experience and analysis to make a call.
The Kotlin team show they are making such decisions with due care (e.g. Picking public as the default visibility was partly based on usage analysis. Or the recent proposal for marking return values in lambdas included a sample diff from the Kotlin codebase).
We also have the evidence that the language is pretty awesome after 3 years of difficult decisions (the Kotlin designers haven’t always got it right the first time, but have subsequently fixed the pain points. e.g. annotating nulls in Java libraries).
Actually, that’s my biggest fear as we head towards 1.0 - that backwards compatibility will force us to live with mistakes. I hope backwards compatibility will be broken if required after 1.0 (with appropriate migrations of course).
To me the “Call for feedback” is more “Head ups - this is what is coming and are there any use cases we’ve missed?”.
The Kotlin team exists in a bit of a bubble (working mostly on Kotlin itself with their own toolchains), so I think as a communtity we can give valuable feedback and different perspectives.
I’m sure they’re listening - the fact that they’ve pivoted to support Android dev is an example of a major reaction to the community.
Cheers,
Andrew
Personally, I'd hate for a handful of "votes" on a blog post determine the outcome of language features.
That’s for sure, but that’s not my point. I’m not critisizing that they kept the idea, I’m critisizing the fact that I don’t feel that our disagreement (that was clearly not isolated) were heard nor acknowledged.
To me the “Call for feedback” is more “Head ups - this is what is coming and are there any use cases we’ve missed?”.
Well, that’s not how I understood it, and maybe that’s precisely my error. I did took time and investment to write such thourough feedbacks on the blog like other members because I thought they asked it, and that makes me feel implicated.
My two cents:
I think the Kotlin team has done an amazingjob walking the fine line between designing a new language while listening to the community’s feedback.
I understand it can be frustrating when the feedback you supply is not listened to but that doesn’t necessarily mean it’s being ignored: it could be the case that this feedback was considered and rejected.
Big props to Andrey and the team.
For what it's worth, in the past I've agitated for synthetic properties to be added and it didn't seem to be a priority at that time, not even for Kotlin 1.0. But they went ahead and did it recently anyway. I have no idea if the feedback of myself and others helped prioritise that feature, but it felt like it.
(My comment goes under this version of the message, because the essential issue has been made more clear here.)
First of all, thanks for your support and trust in Kotlin.
I’m focusing on these quotes:
> Something like "We recognize that most of the comments regarding the operator keyword were negative, but after careful consideration, we decided that it was the right course of action for Kotlin". > But what really bothers me is that I don't feel that our voices are heard when we are asked to speak. > But I do think that when asking for our opinion, JB should give us the impression that our feedbacks are taken into account, especially when so many feedbacks are negative. > I know this is an important word, but I haven't found a smaler one : I often feel a sense of light contempt in the way JB communicates about Kotlin. Just a touch, but enough to iritate me.
I think you are right, and it would be a lot better communication if we (actually, it should be "I", because I'm the person responsible for the language design) responded timely to all comments. I apologize for not doing so with your comments.
I’m not really keen on making excuses, but I’d like to convey the idea that there was no malice behind what happened. It’s just many factors unfortunately coming together at the same time. I think some explanation of why I request your feedback and use cases, and what we do with them would be relevant here. First off, language design is by no means a democratic procedure. Vote counting in blog comments does not happen and hopefully won’t ever. We request feedback to see what arguments people lay in favor or against certain decisions. These arguments help us to see what people like and dislike, and why. (Which of course doesn’t mean that we always agree with their reasoning, but even when disageeing, we can learn something about how to describe things in the docs and what to draw user’s attention to.) The use cases help us prioritize issues, especially those we don’t run into working on our own codebase(s).
To reiterate: I see your point and agree that it would be a lot better if I addressed every concern of every user that gives us feedback. Doing it is a little bit of an art that I haven't entirely mastered to date. I'll try to improve, and will take what you said above as a piece of advice. Thank you.Another thing. As, I think, I mentioned some time before: our top goal now is releasing 1.0 as soon as possible. And to do that we have to finalize the language, so that future versions don't cause high migration costs. To achieve this we lean strongly towards introducing restrictions, some of which may be lifted later. For example, that if we require a modifier on something in 1.0 and it turns out to be too inconvenient, we can make it optional later, and nothing will break. This is why controversial issues are nowadays often resolved with "forbid now, reconsider later" strategy.P.S. Frankly, it seems that keeping the design process even as open as it has been recently is may be a little too demanding of my time and energy. I'm trying to let people know as much as I can as early as I can, but I realize that it's often too little and too late. Regarding the infamous operators restriction, for example, it has been decided that we treat all Java methods as operators (effectively it is addressing the part of your blog comment that I didn't answer, while answering other parts), but I don't have time to write a blog post about this and other decisions. So far I've been choosing posting some updates over posting no updates.I hope that this answer works some more towards our mutual understanding.Thanks a lot, Andrey, for these words.
Here are my answers, quote by quote.
Please remember that I speak only for myself and what I feel.
I'm not really keen on making excuses, but I'd like to convey the idea that there was no malice behind what happened
Once again, I'm really sorry that my first message came out aggressive. I'm very sure that there is absolutely no malice in what you do. Once again, I'm a Kotlin fan :)
First off, language design is by no means a democratic procedure. Vote counting in blog comments does not happen and hopefully won't ever.
Everybody agrees.
To reiterate: I see your point and agree that it would be a lot better if I addressed every concern of every user that gives us feedback. Doing it is a little bit of an art that I haven't entirely mastered to date. I'll try to improve, and will take what you said above as a piece of advice. Thank you.
I don't really agree with you. Of course, answering thoroughly every blog comment would be nice but that was not what I had in mind. What I would have loved is a "round up answer". Something to acknowledge the feedback of the comunity as a whole and give answers as to what you are doing of it. Frankly, now that I know *why* you decided to keep the operator keyword even though most of the comments were against it, I'm "at peace" with the decision. Furthermore, knowing that you decided to treat all java methods as operators is a tremedous news because the majority of the negative comments regarding the operator keyword was regarding the Java compat. I believe that giving feedback on feedback is important. Most of the answers on the blog were not acknowledgements, but precisions on questions we had (which is also very important. I personally read every answers to the post to be sure not to ask duplicate questions). The distinction is important.
Again, I do not believe that you shouldn't have taken the operator keyword decision based on our comments. But I do believe that you should have told us why you did.
And it doesn't have to take a full blog post. Maybe just a section in the anoucement of Kotlin M14 acknowleging the comments of the two precedent call for feedback, summering what they tought you and what you will do with them.
Another thing. As, I think, I mentioned some time before: our top goal now is releasing 1.0 as soon as possible. And to do that we have to finalize the language, so that future versions don't cause high migration costs. To achieve this we lean strongly towards introducing restrictions, some of which may be lifted later. For example, that if we require a modifier on something in 1.0 and it turns out to be too inconvenient, we can make it optional later, and nothing will break. This is why controversial issues are nowadays often resolved with "forbid now, reconsider later" strategy.To me, those words are very important. I would have loved to see them on the blog post anouncing Kotlin M14. Especially since Kotlin M13, M14 and probably M15 are focused on taking our toys away from us (personally, the more a feature is experimental, the more I like it :p).
Frankly, it seems that keeping the design process even as open as it has been recently is may be a little too demanding of my time and energy. I'm trying to let people know as much as I can as early as I can, but I realize that it's often too little and too late. Regarding the infamous operators restriction, for example, it has been decided that we treat all Java methods as operators (effectively it is addressing the part of your blog comment that I didn't answer, while answering other parts), but I don't have time to write a blog post about this and other decisions. So far I've been choosing posting some updates over posting no updates.First of all, Thank you VERY MUCH for listening to us. I see your point. I don't have a go-to answer for this. I do however think that this issue should be resolved rather sooner than later. The kotlin community will (hopefully) grow, so will the user base, and we will continue to give as much feedback as we can. If we, as a community, can do anything to help, let us know ;)
I hope that this answer works some more towards our mutual understanding.
A lot. Thanks again for doing this.