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
