I was thinking, what about training an AI model to...

# javascript

[Edoardo Luppi]

I was thinking, what about training an AI model to translate TypeScript declarations to Kotlin externals?
Doesn't sound like a totally crazy idea.

[eygraber]

Isn't that just a transpiler?

[Edoardo Luppi]

Well, sometimes you can't transpile 1 to 1, there are places where the Kotlin code must be adapted to make it bareable/working.

And writing a perfectly working transpiler takes a lot of time. Especially considering TS evolves very fast.

[eygraber]

I haven't checked in a while, but I guess dukat still doesn't always work?

[hfhbd]

A translator should always return the same transpiled program for a given input, especially when the transpiled code isn’t checked manually but part of your generated sources executed each build.
If you want to use an AI model, you should make it reproducible, which is currently not the case of the current models, eg ChatGPT returns different results for the same input prompt.

[Arjan van Wieringen]

Not everything is a nail

[Edoardo Luppi]

part of your generated sources executed each build

That would be out of scope. Having a transpiler work that reliable takes years.
I currently translate d.ts files using Karakum since Dukat is way outdated, and the result is always something that doesn't compile. Getting the generation to compile requires investing weeks into Karakum plugins, which are still undocumented and using untyped JS.

[Edoardo Luppi]

If an AI can give me a decent starting point, at least I don't have to lose too much time fixing code myself.

[Reuben Firmin]

I agree with this - it would be a great AI project for JetBrains to take on. Could be a simple webapp that they host which looks at a github repo or npm listing and dumps out a kotlinjs binding that gets you started. It's probably the biggest unsolved pain point in using KotlinJs

[Arjan van Wieringen]

The problem with Dukat and transpiling from Typescript is that the expressivity in Typescript is waaaaaay larger then Kotlin can support. Think about how crazy you can get with Union types for instance. Or Omit and Pick types.

I remember a KotlinConf 19 talk about thisb

[Edoardo Luppi]

That's why you need a model that can be trained over time. Doing it manually or via a manually coded tool will always be painful

[Arjan van Wieringen]

No that isn’t the problem. The problem is that there is no way you can fit the Typescript types on the Kotlin language. It works for the most basic types yes. But that’s it

[Arjan van Wieringen]

There are things like Dependent Types. Or type literals. Or union types. The union types can cause your Kotlin generation to blow up

[Edoardo Luppi]

Types like Omit/Pick, or unions, can definitely be reproduced in Kotlin. But it takes a human to do it.

I know because I had to create VS Code externals and there is a bunch of that stuff.

[Arjan van Wieringen]

I didn’t say you can’t, but you cant do it reliably. An AI model helps for the grunt work but there are a lot of types that just don’t map to any Kotlin equivalent

[Edoardo Luppi]

If you can train the model on existing "mappings", it may be able to output decent code. Having it compile immediately is a non goal, having it output decent code that doesn't require days to fix is the goal.

[Arjan van Wieringen]

That isn’t the problem. The problem is that the type system of Typescript is orders of magnitude more expressive that Kotlins. You just can’t map it for all but the most easy ones.

[Edoardo Luppi]

And I know it, but as I wrote you can circumvent the limitations in various ways. The same ways an AI model could be trained on. Overloads, interface hierarchies, extension functions, etc.

[Arjan van Wieringen]

Well, feel free to try ;) I love being proven wrong especially for something so useful. However I tend to lean to the conclusion that the effort is not worth the result. Dukat was heavily focused on by JB in 2019 and they didn’t make it. Maybe AI might help, but the there is a fundamental mismatch in expressiveness. And you can monkeypatch it how you want, but imho that only results in unwieldy APIs.

https://resources.jetbrains.com/storage/products/kotlinconf2019/slides/Thursday/Aud%2015/S.%20Aigner,%20The%20State%20of%20KotlinJS.pdf

[Edoardo Luppi]

I mean, if the effort wasn't worth the results we wouldn't have gotten all the types under kotlin-wrappers.
Definitely non an easy job, but with patience and compiler plugins, a human can do it. A standalone tool, maybe.

[Arjan van Wieringen]

That’s fair

[Arjan van Wieringen]

So there is your training set ;)