3 ms·

> Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. So if my understanding, including that bytecode generation requires

by Ralith 14y ago

> Once again, there's nothing wrong with jvm output. It's "better" for the reasons you say. So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? I don't intend to critique their decisions; I'm interested in why they made them. Their reasoning might well teach me something. > providing source code in java/c++ is critical for ... various mobile app stores. Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++?

benatkin 14y ago
Why should it be predominately C++, in order to have an easy time being reviewed? There's plenty of C++ code in the iOS App Store. I know a couple of people who've developed most of the code for their iOS apps in Visual Studio. They were computer vision apps with just a little bit of GUI toolkit code.
jdonaldson 14y ago
> So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? They might. It's just not what they've chosen to do first. > Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++? Well, we're talking the iOS app store here. Objective C is the main language, but Apple also supports c++ xcode projects, which Haxe can produce. The reason why Haxe targets c++ is because it can provide garbage collection through the Boehm libs, and (in general) can be made to fit better with the Ecmascript nature of the Haxe language. Google is much less restrictive in terms of supported languages, but their java toolkit is very polished. I also think that source code generation also lets you understand better what the compiler is doing, and how to best take advantage of it. Right now, the java target is very early, but it already has a clever way of handling reflection that is much faster than the standard method. It was interesting to me to read through the generated output, even if it was a little ugly.

by Ralith 14y ago

benatkin 14y ago

Why should it be predominately C++, in order to have an easy time being reviewed? There's plenty of C++ code in the iOS App Store. I know a couple of people who've developed most of the code for their iOS apps in Visual Studio. They were computer vision apps with just a little bit of GUI toolkit code.

jdonaldson 14y ago

> So if my understanding, including that bytecode generation requires a comparable amount of effort, why didn't they do that? They might. It's just not what they've chosen to do first. > Really? I wasn't aware of that. Are we talking Apple's and Google's? What app store's catalog is predominately C++? Well, we're talking the iOS app store here. Objective C is the main language, but Apple also supports c++ xcode projects, which Haxe can produce. The reason why Haxe targets c++ is because it can provide garbage collection through the Boehm libs, and (in general) can be made to fit better with the Ecmascript nature of the Haxe language. Google is much less restrictive in terms of supported languages, but their java toolkit is very polished. I also think that source code generation also lets you understand better what the compiler is doing, and how to best take advantage of it. Right now, the java target is very early, but it already has a clever way of handling reflection that is much faster than the standard method. It was interesting to me to read through the generated output, even if it was a little ugly.