markusfisch / ShaderEditor

Android app to create GLSL shaders and use them as live wallpaper
https://play.google.com/store/apps/details?id=de.markusfisch.android.shadereditor
MIT License
924 stars 137 forks source link

Proposal: Introducing Kotlin for New Features #199

Open AntonPieper opened 3 months ago

AntonPieper commented 3 months ago

I'm working on implementing the file-based projects feature from #191 and wanted to propose using Kotlin for new features. Kotlin's interoperability with Java means we can introduce it incrementally without needing to migrate existing code.

Would you be open to adding Kotlin code for new features while leaving existing Java code as is? I'm happy to discuss guidelines to ensure consistency.

markusfisch commented 3 months ago

Well, that escalated quickly 😆 And doesn't really come as a surprise after the build script conversion 😉

Now, my concern about introducing Kotlin (as a second language) isn't technical, but about consistency and friction. I firmly believe that using two languages in a comparatively small project like this would be an unnecessary complication. Suddenly, everyone has to know two languages to understand, debug and maintain the project. Technically, of course, this is feasible, but it's clearly not optimal.

For me, any programming language is just a tool that becomes almost irrelevant once you get used to it. Just like a pen when you're writing something. A bad analogy, I know, but maybe you can understand what I mean. For that reason, I don't think it matters that much whether this app is written in Java or Kotlin. I care more about consistency and readability (in the sense of least surprise) than language features.

But that shouldn't stop you from doing what works best for you! I really appreciate the work you are putting into this project and you are really moving it forward. So if really want to implement new features in Kotlin, then please go ahead! It could just happen that I silently convert these parts back to Java 🙈😂 Or the whole thing to Kotlin…

AntonPieper commented 3 months ago

I completely understand your point 👍. While I’m comfortable with Java, Kotlin’s ability to achieve the same functionality with less syntactical overhead is quite appealing. The language’s concise syntax and modern features could streamline the code and make it more maintainable.

Would a full migration to Kotlin be worth considering? This could help simplify the project by sticking to one language. It’s a bit like switching pens in the middle of an exam, if I can borrow your analogy. With IntelliJ's Java-to-Kotlin conversion tool, the process could be semi-automatic, with some manual adjustments needed afterward, which I could handle.

That said, before moving in that direction, I’d prefer to focus on refactoring the parts of the code that use deprecated features, like the old camera API, startActivityForResult, etc., to ensure the codebase is current before making any major changes.

markusfisch commented 3 months ago

A complete migration to Kotlin would indeed be the better option. The problem with this is that any automatic conversion will not produce idiomatic Kotlin code, but rather Java to Kotlin formulations (been there, done that 😉 ). So we would end up with quite cumbersome code (which because of this may even be less appealing to maintain) and would have to invest more time to really take advantage of Kotlin. Also, don't forget that any change that big could also introduce new bugs. And all this effort wouldn't even be noticeable to users, so you could argue that it would be wiser to invest that time in additional features.

But I certainly see your point, and if I were to start this app today, I would do it in Kotlin. I really like Kotlin and prefer it to Java. But I find it hard to justify the time and complications it takes to translate a working codebase just to have a nicer syntax. The way I see it, keeping this in Java means less trouble and faster compilation times 😉 At least for now. At some point in the future the move to Kotlin is probably inevitable, I have to admit.

That said, before moving in that direction, I’d prefer to focus on refactoring the parts of the code that use deprecated features, like the old camera API, startActivityForResult, etc., to ensure the codebase is current before making any major changes.

Yes, that would make totally sense! 👍 Especially because we're on minSDK 21 now.