>
> Kevin, what is your opinion on removing Quidem language?
>

Completely unrelated to the topic at hand. This is specifically about
Kotlin.

It is sad you mention "code readability" as "little benefit currently" item.


Please don't put words into my mouth. I have nothing wrong with improving
code readability, but this is subjective. Adding an entirely new language
for some minor code readability improvements is a poor tradeoff. The cost
to maintain the new language easily outweighs the multiline strings.
Switching tests from one language to another and reformatting removes the
history for that file. This makes it much harder to maintain tests over
time.

It is not introducing a brand new language. The very same language is used
> in the build scripts.
>

This is a circular argument. You could say that the build scripts language
is not new since its in a few tests. This doesn't lend any credibility to
keeping Kotlin. It is a new language to Calcite. It was added recently
therefore new.

Those are two different items. The discussion re $ is still open, and
> there's no clear answer yet.
> At the same time, in the very same thread, there were explicit opinions
> that "tests that do not use $ might still benefit from improved
> readability".
> The change in [2] is not related to the $-discussion, so I don't see
> whypeople relate them.


The subject of the email was "[DISCUSS] Tests vs multiline strings" and
every response was against the change. The change made in
https://github.com/apache/calcite/commit/b93ec5a9edb7459696385e6adad67b92b6d406d7
is
explicitly switching from Java to Kotlin for multiline strings. The only
substantial change between the two files is the multiline strings. This
absolutely is related to the email thread where 9 replies were against the
change.

The clear answer was do not do it. It is not still open. It is not wait
longer for more people to chime in. It is not wait a bit and push the
change in anyway. It is not start another thread to try to force a change
it. The clear response was do not do it. The change was still made anyway.

It looks like you express an opinion on "let's rewrite everything in
> Kotlin" rather than "let's pick the proper tools on a case by case basis".


This is completely false. This is putting words into my mouth again. This
is not a quote I said in either case.

I am basing my opinion on the amount of friction this has caused in the
community. Multiple email threads where the support to add Kotlin was never
there to begin with means that it is not a perfect tool. Picking any tool
over the community feedback is short term thinking.

Kevin Risden


On Tue, Dec 17, 2019 at 3:30 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Kevin>Focusing on the technical side of things, I agree that introducing a
> new
> Kevin>language is of little benefit currently
>
> Kevin, what is your opinion on removing Quidem language?
> Focusing on the technical side, it is a standalone language.
> The language is not Java, it has limited tooling, it has a limited set of
> users, it has 0 or so questions on StackOverflow and so on.
>
> Kevin>I agree that introducing a new
> Kevin>language is of little benefit currently
>
> Keeping tests easy to read, easy to edit, easy to create, easy to debug,
> and easy to maintain is hard.
> Making tests easy to read simplifies code reviews that pay off in the long
> run.
> It is sad you mention "code readability" as "little benefit currently"
> item.
>
> Kevin>surprised that a change went in to
> Kevin>switch to Kotlin especially after the discussion that is happening on
> the
> Kevin>mailing list.
>
> Those are two different items. The discussion re $ is still open, and
> there's no clear answer yet.
> At the same time, in the very same thread, there were explicit opinions
> that "tests that do not use $ might still benefit from improved
> readability".
>
> The change in [2] is not related to the $-discussion, so I don't see why
> people relate them.
>
> Kevin>I agree that introducing a new
> Kevin>language is of little benefit currently
>
> It is not introducing a brand new language. The very same language is used
> in the build scripts.
> The language was designed for interoperability with Java, and it does
> improve things if used appropriately.
>
> For instance, tests like
>
> https://github.com/apache/calcite/pull/1657/commits/0d6bec4140da46af07d58cf07a5e682d61529603#diff-7a7027c499b6e4f5e7448b7b971052f1R85-R94
> are
> much easier to read and update than similar tests in Java.
>
> Note: Kotlin tests are still regular JUnit5 tests, so they get proper
> statistics in the CI outputs like test count, skipped test count, failure
> count, test duration.
>
> Kevin>In my opinion there are more negatives than positives
> Kevin>currently.
>
> What your opinion re Kotlin is based on besides angst and "introducing a
> new language"?
> I can easily relate how the items play for writing tests COBOL, but, well,
> I hope we don't consider that :)
>
> Kotlin is a modern language with good tooling.
> It was designed for smooth Java interop which plays well for maintenance.
> The code is easy to read, and it is copy-paste friendly in the same way as
> almost any other language we currently have in the source repository.
> So newbies could copy-paste Kotlin code or Java code or Quidem code.
>
> For instance, people might still create tests in Java and call methods
> written in Kotlin. They might create "pure Java" tests if they like.
> They might even create Quidem tests, but they won't be able to call
> Java/Kotlin methods (and/or extend classes) then.
>
> It looks like you express an opinion on "let's rewrite everything in
> Kotlin" rather than "let's pick the proper tools on a case by case basis".
>
> Currently, there are valid reasons against migrating all the tests to
> Kotlin, and I guess we have never discussed that.
> At the same time, we are not discussing "rewrite everything in Kotlin"
> here.
>
> Vladimir
>

Reply via email to