search

IRC-Llamas / cardlogic

Library for handling custom card game rules, starting with poker.
Apache License 2.0
2 stars 0 forks source link

Polyglot project design. #8

Open wodencafe opened 2 years ago

wodencafe commented 2 years ago

Makes this a polyglot project, which has its trade-offs, but I'd sure be happy.

Out of curiosity, what does this mean, if anything, for the prospects of a full Kotlin rewrite? I know some of the llamas crowd has strong negative opinions about Java, and Kotlin might possibly be more attractive to some of them.

If someone is willing to do the work, sure. Or if we want to just compile incrementally side by side with Java and Kotlin. My suggestion would be then to separate the Java and Kotlin into separate subprojects, so that we can have full polyglot cross-compilation, and so that each subproject is aware of the others, regardless of their language. In this scenario, we could have subprojects for each language we can support: Scala, Groovy, Kotlin, Java, Clojure, etc.

I think it makes the most sense to keep the interfaces in Java, in their own subproject, and if we were to rewrite, or if we just want to expand with new logic in other languages, a contributor can implement the interfaces in whatever language they desire.

Thoughts?

Originally posted by @wodencafe in https://github.com/IRC-Llamas/cardlogic/issues/6#issuecomment-1179583214

TheDaemoness commented 2 years ago

I actually am against supporting more than 2 languages without a very specific reason to do so. Otherwise, I'd have pushed for Scala 3 before Kotlin.

By adding multiple languages, you make it that much harder for one person to be able to work on any part of the codebase. This is especially the case with rarer languages like Scala, Clojure, Groovy (yes, Gradle build scripts use Groovy by default, but how many people are actually skilled with Groovy?). For a project that's supposed to be easy to get into for randoms in an IRC community, that's a problem.

However, I'm okay with Kotlin being a part of the project. It's probably the easiest-to-learn (for Java devs) major JVM-targeting language, and it provides quite a few benefits over vanilla Java.

wodencafe commented 2 years ago

@TheDaemoness Fair enough. Perhaps this should focus on how best to implement Kotlin as a development alternative to standard Java.

We can revisit the idea of further polyglot exploration (other languages) when we can identify a compelling use case.

TheDaemoness commented 2 years ago

Update: #36 exists following some talk on IRC about adding Groovy.

Teasing aside, I think it could be alright for writing tests. We're not strict about TDD, so it's not critical that tests and code be able to be written by the same people. There are undeniable benefits, but it's not like we can't write the tests in a separate pass.

There's also been a soft agreement to start porting the domain classes to Kotlin. I'll be doing that over the next few days.

I think this is the limit of what's reasonable for polyglot in this project.