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
