Hello Calcite Team, I believe products are advancing through constant improvements rather than freezing codebase. Why does nobody consider Kotlin as an opportunity to improve Calcite? Indeed, most of the replies sound like: "I don't want to learn Kotlin because it requires extra efforts, etc, etc."
Sincerely, Igor On Tue, Dec 17, 2019 at 4:20 PM Michael Mior <mm...@uwaterloo.ca> wrote: > Le mar. 17 déc. 2019 à 03:30, Vladimir Sitnikov > <sitnikov.vladi...@gmail.com> a écrit : > > > > 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. > > I'm not Kevin, but removing a language is quite different from > introducing a new language. I wasn't around when Quidem tests were > introduced, but I assume that similar concerns would have been raised. > > > > > 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. > > Agreed on those points. I'm not convinced though that having another > language tests are written in will simplify code review. It may be > true for someone equally literate in Java and Kotlin that in some > instances, Kotlin tests will be easier to read. However, we know our > current contributors are reasonably fluent in Java. I'm not sure about > Kotlin. > > > 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. > > Assuming you understand, Kotlin, yes. I agree it's not exactly > introducing a new language, but I think using Kotlin in tests is quite > different from using it in build scripts. We expect most contributors > to write tests. If build script editing is a bit less accessible, I > think that's less of a concern. > > > > > 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. > > I don't think anyone was discussing rewriting everything in Kotlin. > But I think that's a straw man. Rewriting some things in Kotlin still > has some of the same disadvantages. > > > > > Vladimir >
