I used to program in D heavily many years ago then stopped because, basically, the D ecosystem sucks. Amazing language but getting anything significant done was a PITA.

Anyways, I moved to Kotlin/android to write some apps about 2 months ago and made great progress(I did more in 2 weeks than I've done in a year of D programming and this includes learning the language, the IDE, etc). Everything just worked as expected and was simple to use. Maybe the biggest issue was figuring out all the Gradle BS but I eventually got the hang of it. I was able to get a simple app to view PDF, play audio, jni(using FFPEG), etc within about a week. This is unlike D where basically you have 3 different packages you have to use, hope they work, and then figure out how to get them to work in the system. With android basically it just works and all the boilerplate crap is basically abstracted out(it's designed for a modern system rather than some console based system that D was). The IDE is pretty nice too since it works well with the language.

In any case, it was a great experience for the first month or so but then when I started looking for more complicated "D like" features such as CT/meta programming they don't seem to actually exist... at least not in the way one thinks and seems to be quite limited.

It has runtime reflection which, for the most part, is your standard introspection on types. It's not as robust as D's reflection and not compile time but there are some nice features that work well for basic stuff.

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.

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?

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.

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.

On Thursday, 19 December 2024 at 06:04:33 UTC, Jo Blow wrote:

D is a better version of C++.

Hi Jo,

metaprogramming in Kotlin is possible by writing compiler plugins
see https://kt.academy/article/ak-compiler-plugin
or https://resources.jetbrains.com/storage/products/kotlinconf2018/slides/5_Writing%20Your%20First%20Kotlin%20Compiler%20Plugin.pdf

An alternative approach would be
https://www.baeldung.com/kotlin/kotlinpoet
"KotlinPoet is an open-source library that generates Kotlin source code."

Kind regards
Jürgen

On Thursday, 19 December 2024 at 11:13:38 UTC, Jürgen Reichmann wrote:

Yeah, I came across Poet when I was trying to see how to do metaprogramming. At the time I couldn't find anything and the link helps explain it but it's sorta like "whats the point". I can do that stuff just using strings. It might work out well for certain things(I imagine one can write a string mixin and stuff).

When I was trying to do anything with it the problem I was really having was that I needed to either generate or rewrite code. It seems Poet can't rewrite code but it can generate.

But the issue I was having was that to generate a piece of code I 1. needed to access the project code so I could "reflect" on it. 2. Add have the project then use that piece of code.

To generate the code I used a build task but then then it couldn't access the project code. I'd post the build task but I can't seem to find it but basically it just ran the kotlin code I was using to generate the file but it needed a type from my project to reflect over which I couldn't figure out how to get it to be able to see. To solve that I just started calling it in my app rather than the task and essentially manually did the work(luckily I rarely have to mess with it).

So basically there is a dependency issue here: To generate the code I need access to the project after it was partially built up to that point then needed to include that generated code. I thought I would try putting the dependencies part in a new module but it became a mess real quick.

It might be my own ignorance of how everything works but I don't think things like KotlinPoet will solve that since they are just a structured way of building code. It will still have the problem. D just works in this case as it automatically takes care of these intra-dependencies without issue.

On Thursday, 19 December 2024 at 06:04:33 UTC, Jo Blow wrote:

Maybe it is also worth to check Groovy meta-programming abilities (including AST and macros).

On Sunday, 22 December 2024 at 10:56:26 UTC, Sergey wrote:

https://www.baeldung.com/groovy-metaprogramming

That does look more "D" like and if it has things like traits and string mixins then I probably could get used to it. But I doubt it can interface with or replace Kotlin?

The main reason I use Kotlin is because of jetpack compose which is quite easy to use. Although I don't like the way it deals with state as it can be a PITA to figure what really is going on at times.

If, say, I could write UI code in Kotlin and then business end in Groovy and the compiler or IDE takes care of hooking everything up(just as if I were to write the business end in Kotlin) then I would likely use it.

That is, if I can import packages and types from one into the other implicitly then it will work.