On Thursday, 19 December 2024 at 06:04:33 UTC, Jo Blow wrote:
But there have been several cases when I have asked others about trying to do certain "compile time" things in Kotlin that say it can't be done. It seems that there is actually no compile time programming in Kotlin(and I guess Java too?)? That at best one has to work in some DSL like thing that uses a "plugin" but things that make D shine because you can just get shit done, usually several ways, doesn't exist. Things like string mixins, CTFE, etc. D would be an amazing language to use if it was integrated into android studio like Kotlin.
Those features are exactly what makes D such a difficult language to provide good support for in an IDE. Even things that are trivial in languages like Kotlin, like removing unused imports, can't be easily done in D (I was told that in a discussion about why that didn't work at all with D).
Kotlin and Java have always taken IDE integration seriously and would not add a feature that "breaks" the IDE, even if that makes compile-time programming impossible. Reflection is heavily used by frameworks, but nearly never in application code, exactly because it makes IDE support and static analysis impossible.
Anyways, the entire point of this point is to ask this question: Is anyone who is pretty familiar with Kotlin and it's compile time programming willing to explain what the heck is really going on with it and why it seems so different to D's?
As someone coming the opposite way, D metaprogramming looks like pure magic. It's mind blowing (and so completely underrated, Zig is getting all the attention for having something similar but still less powerful). But yeah, the cost of those features seem to be bad IDE support, which kind of sucks, for sure.
Kotlin has annotation processors, like Java, which are about the only metaprogramming you can do outside of just writing code that explicitly generates source code (which you can do easily enough with https://github.com/palantir/javapoet for Java, or the Kotlin spinoff: https://square.github.io/kotlinpoet/
This is the current Kotlin solution: https://kotlinlang.org/docs/ksp-overview.html
As far as I know, almost no one uses this though. People are happy to just NOT do anything at compile-time, I guess it's hard to believe that if you come from D, but it's indeed possible.
The way I see D's metal language was that essentially anything that was "defined at compile time" could be treated as a program at compile time and all the compile time information would be filled in as such since it could. If code could be determined to be completely well-defined at compilation then it could simply be "executed"(evaluated) at compile time(in a first pass). Kotlin doesn't seem to have anything like this. It doesn't even have string mixins or eval without including a kotlin compiler inside the language.
Correct. Kotlin and Java people would be horrified of those features, I think :D
Again, because of IDE and tooling support.
I'm wondering if it would be worth the effort to try to get D to work with android studio since it can compile to all those. E.g., write the jetpack compose code in kotlin and hook up the business in with D somehow. If it wasn't too much trouble and worked well then this might give one the best of both worlds. JNI is a bit of a PIA when trying to call java from C because one has to use reflection for every aspect and it is very long winded. This probably could be simplified greatly with some D meta programming.
You're absolutely correct that with D, you could easily generate stuff like JNI bindings.
But notice that JNI is going to be replaced with a new solution: https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html
This is still in preview but you may want to look at it if you find JNI too horrible.
Regarding whether D could be a good option for Android, I very much doubt it. You can't remove the nice tools people are used to in the Java/Kotlin world, if you try you will get a very large backlash... and I'm afraid D will never have as good tools even if it some day gets huge corporate backing because the language was not designed to allow that to be possible (maybe it is possible, but I doubt it's actually feasible - correct if I am wrong), from the list of features it is very clear that was absolutely never a high priority concern.
