4 ms·

Not talking about the interesting naming or the circumstances around this particular implementation, what do the people on HN think about the concept of such tr

Not talking about the interesting naming or the circumstances around this particular implementation, what do the people on HN think about the concept of such transpilation? I recall taking a course in university about model driven programming - the idea of creating an abstract representation of logic, interfaces and other system components and then generating either full implementations or stubs in multiple languages was an interesting one, even if implementations were really hard to get right. In practice, i've mostly only seen one language specific model driven design tools, like JHipster (https://www.jhipster.tech/ https://www.jhipster.tech/) or the likes of JPA be reasonably successful, since there's a lot of problems with supporting abstractions across different languages and runtimes, but what has been the experience of others in that regard?

wheybags 5y ago
Super relevant use case: you are making an app for multiple platforms, say iOS and android. You have some common logic, but for the most part the apps are separate, native apps. This would let you write the common part once, without needing to do something like drop down to c++ and then do native interop from swift and Java.
- KronisLV 5y ago
  If the logic is standalone (e.g. algorithms, data structures, validations etc.), then that's indeed a really good approach! But in my experience, you oftentimes have to work with libraries and ecosystem components which are platform dependent. In those cases, the cross platform code would only work when these ecosystem components are also written in that particular language. Now, it can work with Xamarin Forms, React Native or similar technologies with very specific use cases, but it feels like any other, more generic attempts at getting something like that working are doomed to fail (e.g. when you don't have a cross platform solution in place, for example, different ways to access DB on different platforms, or different ways to make web requests etc., or even interact with device capabilities or handle permissions).
- skohan 5y ago
  I feel like this is a use-case which sounds a lot better on paper than it actually is. Mobile apps in my experience tend to be shaped quite heavily by the system API and UI frameworks they are built on top of. When you talk about the "common part", usually this is like the networking layer and models maybe, which tends to be very simple and takes like a half hour to write in the first place. Even if there is a little duplicate work, it's still better to have the whole app implemented in the native language and frameworks, rather than having some odd bits which don't work with the same tooling for example and are harder to debug.
- bsaul 5y ago
  i'm exactly in this situation : have an ios swift app and wonder what's the best way to get it to android. Swift and kotlin are so similar i wonder if there isn't a possibility to generate at least the type definitions from one to the other. That would let me ensure that the code design at least stays in sync (at least for the model layer)
junon 5y ago
It's not a new idea. I believe one of the longer-standing projects is Haxe.
skohan 5y ago
I find it very cool. I was thinking recently of something similar, and it's interesting to see it in practice. I can imagine there might be some serious tradeoffs in terms of making something which has to be interoperable with all these different target languages.
yeputons 5y ago
Transpiling is a cool idea. Although erasing syntax differences between languages is easy, erasing semantic differences is extremely hard. The simplest example being garbage collection: if you transpile to C, you have to track garbage yourself and collect it. You either end up leaking some memory, double-freeing, writing your own GC or prohibiting some code to be transpiled to C. There are more subtle ways. For example, overflow of signed 32-bit int is: * Well-defined in Java. I assume in C# as well. * Well defined differently in Python: it starts doing arbitrary precision arithmetics. * Well defined differently in JavaScript, because there are no integers, only IEEE 754-like 64-bit floating point numbers. * Completely undefined behavior in C and C++. See the "Signed overflow" section at https://en.cppreference.com/w/cpp/language/ub https://en.cppreference.com/w/cpp/language/ub and https://godbolt.org/z/y4vIi1 https://godbolt.org/z/y4vIi1 specifically, if you assume reasoning about undefined behavior is allowed in general case.
- rightbyte 5y ago
  When generating C you can quite easily cast all signed to unsigned, do the operation, and cast back, if you want to avoid signed overflow.
  - mek6800d2 5y ago
    Except that doing so does NOT avoid signed overflow. You're converting effectively w-1 bits of precision (plus a sign bit) to w bits of precision, doing the calculation, and then converting w bits of precision back to w-1 bits of precision -- that only works for a limited range of input values. Using int32_t and uint32_t, try adding -2147483648 and -1. The arithmetic result should be -2147483649, but a program converting back and forth between signed and unsigned will produce 2147483647 -- wrong answer and wrong sign.
    - MauranKilom 5y ago
      You do avoid "signed overflow" in the sense of the C and C++ specifications by working on unsigned numbers. "signed overflow" is UB, "unsigned overflow" is not. Of course you will never be able to obtain an unrepresentable value (such as -2147483649) through a workaround, and if you cast back to signed you get the wrapped result (which, indeed, may have an unexpected sign). But the point of transpiling to operations on unsigned numbers is to avoid UB, not to escape basic computational bounds.

wheybags 5y ago

Super relevant use case: you are making an app for multiple platforms, say iOS and android. You have some common logic, but for the most part the apps are separate, native apps. This would let you write the common part once, without needing to do something like drop down to c++ and then do native interop from swift and Java.

KronisLV 5y ago
If the logic is standalone (e.g. algorithms, data structures, validations etc.), then that's indeed a really good approach! But in my experience, you oftentimes have to work with libraries and ecosystem components which are platform dependent. In those cases, the cross platform code would only work when these ecosystem components are also written in that particular language. Now, it can work with Xamarin Forms, React Native or similar technologies with very specific use cases, but it feels like any other, more generic attempts at getting something like that working are doomed to fail (e.g. when you don't have a cross platform solution in place, for example, different ways to access DB on different platforms, or different ways to make web requests etc., or even interact with device capabilities or handle permissions).
skohan 5y ago
I feel like this is a use-case which sounds a lot better on paper than it actually is. Mobile apps in my experience tend to be shaped quite heavily by the system API and UI frameworks they are built on top of. When you talk about the "common part", usually this is like the networking layer and models maybe, which tends to be very simple and takes like a half hour to write in the first place. Even if there is a little duplicate work, it's still better to have the whole app implemented in the native language and frameworks, rather than having some odd bits which don't work with the same tooling for example and are harder to debug.
bsaul 5y ago
i'm exactly in this situation : have an ios swift app and wonder what's the best way to get it to android. Swift and kotlin are so similar i wonder if there isn't a possibility to generate at least the type definitions from one to the other. That would let me ensure that the code design at least stays in sync (at least for the model layer)

junon 5y ago

It's not a new idea. I believe one of the longer-standing projects is Haxe.

skohan 5y ago

I find it very cool. I was thinking recently of something similar, and it's interesting to see it in practice. I can imagine there might be some serious tradeoffs in terms of making something which has to be interoperable with all these different target languages.

yeputons 5y ago

Transpiling is a cool idea. Although erasing syntax differences between languages is easy, erasing semantic differences is extremely hard. The simplest example being garbage collection: if you transpile to C, you have to track garbage yourself and collect it. You either end up leaking some memory, double-freeing, writing your own GC or prohibiting some code to be transpiled to C. There are more subtle ways. For example, overflow of signed 32-bit int is: * Well-defined in Java. I assume in C# as well. * Well defined differently in Python: it starts doing arbitrary precision arithmetics. * Well defined differently in JavaScript, because there are no integers, only IEEE 754-like 64-bit floating point numbers. * Completely undefined behavior in C and C++. See the "Signed overflow" section at https://en.cppreference.com/w/cpp/language/ub https://en.cppreference.com/w/cpp/language/ub and https://godbolt.org/z/y4vIi1 https://godbolt.org/z/y4vIi1 specifically, if you assume reasoning about undefined behavior is allowed in general case.

rightbyte 5y ago
When generating C you can quite easily cast all signed to unsigned, do the operation, and cast back, if you want to avoid signed overflow.
- mek6800d2 5y ago
  Except that doing so does NOT avoid signed overflow. You're converting effectively w-1 bits of precision (plus a sign bit) to w bits of precision, doing the calculation, and then converting w bits of precision back to w-1 bits of precision -- that only works for a limited range of input values. Using int32_t and uint32_t, try adding -2147483648 and -1. The arithmetic result should be -2147483649, but a program converting back and forth between signed and unsigned will produce 2147483647 -- wrong answer and wrong sign.
  - MauranKilom 5y ago
    You do avoid "signed overflow" in the sense of the C and C++ specifications by working on unsigned numbers. "signed overflow" is UB, "unsigned overflow" is not. Of course you will never be able to obtain an unrepresentable value (such as -2147483649) through a workaround, and if you cast back to signed you get the wrapped result (which, indeed, may have an unexpected sign). But the point of transpiling to operations on unsigned numbers is to avoid UB, not to escape basic computational bounds.