On 30.03.2013 05:58, Nick Sabalausky wrote:
> On Fri, 29 Mar 2013 18:45:33 +0100
> Paulo Pinto <pjmlp@progtools.org> wrote:
>
>> On 28.03.2013 07:13, js.mdnq wrote:
>>> I would like to get into writing apps for android and would like to
>>> choose D for this if it is mature enough.
>>>
>>> What is the D progress on the android?
>>>
>>> I see that at least others are interested but not finding a ton of
>>> information:
>>>
>>> http://forum.dlang.org/thread/20120204203109.26c9a80b@jpf-laptop?page=1
>>
>> Please note that native development in Android has a second class
>> status.
>>
>> Support is only available as a means to bring "legacy" C and C++ code
>> to the platform.
>>
>> The few Android APIs available to languages outside the Dalvik world
>> are actually wrappers around JNI calls.
>>
>
> That's actually something that's been rolling around in my head for
> months, and now that it's brought up again, I have to just go ahead and
> say it:
>
> What...the *FUCK* is Google thinking???
>
> How is it *possible* that the one company in the word that's been
> known, more than any other, for recruiting as many of the supposedly
> best and brightest developers in the world as they possibly can,
> portrayed by approximately...everyone in the world...as being
> practically a developer's utopia, with nary a pointy-hair in sight, and
> the streets paved with latte, can be so incredibly dumb as to decide
> "Hey, let's make our system API be *JVM-only* (ok, "JVM-knockoff",
> whatever, like it even matters) and marginalize native in general, and
> shit all over the idea of being anything more than halfway Posix"??
> Even *Apple* isn't that goddamn stupid, for crap's sakes, and *Apple*
> was never a developer's company, it was run by a dicatoring *salesman*!
> A drugged-out fucking *salesman* for fuck's sakes, and even *they*
> didn't botch things up *that* badly!
>
> Not only that, but this is the same - apparently schizophrenic -
> company that's been trying to push the *Google* **NATIVE** **CLIENT**,
> ie NaCl!!
>
> [Just insert a mental image right here of Lewis Black's trademark
> freak-out saying "What...the...FUUUCK?!?']
>
> Sheesh.
>
> Sorry, had to get it outta my system...
>

Personally my issue is another one.

I don't mind that they use Java (the language), but I think that instead of having the effort of implementing Dalvik, they could
have implemented a native code compiler instead.

This way the platform would be fully native.

This is Microsoft current approach, regardless of C++ or .NET, since
Windows Phone 8, everything is compiled to native code.

As for POSIX compatibility, it is oversold. You only have APIs for
command line applications and daemons, and like any standard, it has
undefined behaviors, with each vendor having a different idea what POSIX
means.

Nowadays they could even support Go in the platform, but the Android group does not seem to care that much (issue was created by me).

http://code.google.com/p/android/issues/detail?id=39482

--
Paulo

On Sat, 30 Mar 2013 07:47:56 +0100
Paulo Pinto <pjmlp@progtools.org> wrote:

> On 30.03.2013 05:58, Nick Sabalausky wrote:
> > On Fri, 29 Mar 2013 18:45:33 +0100
> > Paulo Pinto <pjmlp@progtools.org> wrote:
> >
> >> On 28.03.2013 07:13, js.mdnq wrote:
> >>> I would like to get into writing apps for android and would like to choose D for this if it is mature enough.
> >>>
> >>> What is the D progress on the android?
> >>>
> >>> I see that at least others are interested but not finding a ton of information:
> >>>
> >>> http://forum.dlang.org/thread/20120204203109.26c9a80b@jpf-laptop?page=1
> >>
> >> Please note that native development in Android has a second class status.
> >>
> >> Support is only available as a means to bring "legacy" C and C++ code to the platform.
> >>
> >> The few Android APIs available to languages outside the Dalvik world are actually wrappers around JNI calls.
> >>
> >
> > That's actually something that's been rolling around in my head for months, and now that it's brought up again, I have to just go ahead and say it:
> >
> > What...the *FUCK* is Google thinking???
> >
> > How is it *possible* that the one company in the word that's been known, more than any other, for recruiting as many of the supposedly best and brightest developers in the world as they possibly can, portrayed by approximately...everyone in the world...as being practically a developer's utopia, with nary a pointy-hair in sight, and the streets paved with latte, can be so incredibly dumb as to decide "Hey, let's make our system API be *JVM-only* (ok, "JVM-knockoff", whatever, like it even matters) and marginalize native in general, and shit all over the idea of being anything more than halfway Posix"?? Even *Apple* isn't that goddamn stupid, for crap's sakes, and *Apple* was never a developer's company, it was run by a dicatoring *salesman*! A drugged-out fucking *salesman* for fuck's sakes, and even *they* didn't botch things up *that* badly!
> >
> > Not only that, but this is the same - apparently schizophrenic - company that's been trying to push the *Google* **NATIVE** **CLIENT**, ie NaCl!!
> >
> > [Just insert a mental image right here of Lewis Black's trademark freak-out saying "What...the...FUUUCK?!?']
> >
> > Sheesh.
> >
> > Sorry, had to get it outta my system...
> >
> 
> Personally my issue is another one.
> 
> I don't mind that they use Java (the language), but I think that instead of having the effort of implementing Dalvik, they could have implemented a native code compiler instead.
> 
> This way the platform would be fully native.
> 
> This is Microsoft current approach, regardless of C++ or .NET, since Windows Phone 8, everything is compiled to native code.
> 

Exactly. It just makes no sense how they see such little point in native. They've created a *real* machine that exists almost entirely to run a *virtual* machine. WTF is the point of that, if not to deliberately waste both hardware and developer resources? And on a portable, too - one of the top places where efficiency is particularly important.

> As for POSIX compatibility, it is oversold. You only have APIs for command line applications and daemons, and like any standard, it has undefined behaviors, with each vendor having a different idea what POSIX means.
> 
> Nowadays they could even support Go in the platform, but the Android group does not seem to care that much (issue was created by me).
> 
> http://code.google.com/p/android/issues/detail?id=39482
> 

I find this part particularly hilarious:

"the Go compilers only generate static executables right now. Which means: ... - These programs *cannot* run in a Dalvik VM."

You've got the Go team which has historically been staunchly opposed to dynamic linking, and the Android team ten miles in the opposite direction. Classic corporate "left-hand vs right-hand" discrepancy. Makes them sound like Sony or MS.

I hate this decision, too, but in case you wander, initial rationale for restricting everything to VM was an attempt to fight device h/w fragmentization and avoid necessity to build different application versions for different devices.

Failed attempt, obviously.

Apple have never needed that though as they 100% control device hardware their OS runs on.

%s/wander/wonder/g

On 30.03.2013 10:43, Dicebot wrote:
> I hate this decision, too, but in case you wander, initial rationale for
> restricting everything to VM was an attempt to fight device h/w
> fragmentization and avoid necessity to build different application
> versions for different devices.
>
> Failed attempt, obviously.
>
> Apple have never needed that though as they 100% control device hardware
> their OS runs on.

You can achieve this by bytecodes that get compiled on the fly at installation time.

This is how Windows Phone 8 works, by using an offline compiler on Windows Store to compile .NET to native code, thus you only install
native code, there is no JIT on the devices.

Or how Windows CE used platform neutral binaries, known as Common
Executable Format (CEF).

Nowadays I think the best way is a mixture of JIT + AOT, similar to what
functional programming languages offer.

--
Paulo

I have always wondered how it is done by Win 8. It requires knowledge of every single released device from Microsoft side, isn't it? How will it scale?

On Saturday, 30 March 2013 at 09:55:27 UTC, Dicebot wrote:
> I have always wondered how it is done by Win 8. It requires knowledge of every single released device from Microsoft side, isn't it? How will it scale?

Doesn't it only require knowledge of every architecture? And supporting ARM and x86 would cover a great majority of devices. They could improve performance by targeting specific versions of the architecture, such as ARMv7 or x86_64, but even without that, performance would likely be better than that of a JIT.

On 2013-03-30 08:26, Nick Sabalausky wrote:

> You've got the Go team which has historically been staunchly opposed to
> dynamic linking, and the Android team ten miles in the opposite
> direction. Classic corporate "left-hand vs right-hand" discrepancy.
> Makes them sound like Sony or MS.

That's one thing Apple is good at, having the different parts of the company work together. They don't care if a particular device sells less because of another device, as long as they sell more combined.

-- 
/Jacob Carlborg

On Sat, 30 Mar 2013 10:53:31 +0100
Paulo Pinto <pjmlp@progtools.org> wrote:

> On 30.03.2013 10:43, Dicebot wrote:
> > I hate this decision, too, but in case you wander, initial rationale for restricting everything to VM was an attempt to fight device h/w fragmentization and avoid necessity to build different application versions for different devices.
> >
> > Failed attempt, obviously.

Which begs the question, "Why haven't they noticed this and stopped treating native as second-class?"

> >
> > Apple have never needed that though as they 100% control device hardware their OS runs on.
> 
> You can achieve this by bytecodes that get compiled on the fly at installation time.
> 
> This is how Windows Phone 8 works, by using an offline compiler on Windows Store to compile .NET to native code, thus you only install native code, there is no JIT on the devices.
> 

Unless the bytecode is both comparable to LLVM and has an escape hatch to include real pre-compiled binary data, then that still bugs me.

STill a huge improvement over Android, though. Well, except that the user has to use Win8 ;)

Am Fri, 29 Mar 2013 22:39:52 +0100
schrieb "jerro" <a@a.com>:

> > Some time ago there was a post on the newsgroup of someone that had a working GDC which would output ARM binaries and he even converted the most important parts of druntime to work for android to. But unfortunately I can't remember where that was.
> 
> Johannes Pfau has a GDC fork with Android support here: https://github.com/jpf91/GDC/tree/android
> 
> and build scripts that build NDK with D support here: https://github.com/jpf91/gdc-android-scripts

But it's probably horribly outdated now ;-)
I'll have to revisit this when shared library support is stable.