Haxe (From: Java > Scala -> new thread: GUI for D)

[Nick Sabalausky]

"Adrian" <adrian.remove-nospam at veith-system.de> wrote in message 
news:jbkkpf$cut$1 at digitalmars.com...
> Am 05.12.2011 18:56, schrieb Nick Sabalausky:
>
>> In that project, Haxe's ability to compile the same code, in the same
>> language, down to both server-side (PHP) and client-side (Flash8) has 
>> been
>> an *enormous* benefit. Just that one ability alone, even without the fact
>> that Haxe beats the snot of out both AS2 and PHP. I also use a
>> slightly-hacked version of the HaxeIgniter framework (could be better, 
>> but
>> it's not bad and it gets the job done).
>>
>> That said, I have been chomping at the bit to switch to D (and Adam's 
>> clever
>> web framework) for my server-side code. I've pretty much managed to 
>> convince
>> my client to eventually let us switch to a host that allows 
>> native-compiled
>> CGI. The only problem now is that that would rule out the possibility of
>> sharing code between both server and client - Which is *NOT* something I
>> want to give up...
>>
>
> That is exactly my point. HaXe' s ability to share the same code on
> client and server side is one of it's killer features.

Absolutely!

>> <shameless plug>:
>>
>> So to that end, you mentioned Java and C# targets are coming to Haxe? 
>> Well,
>> so is D... :)
>>
>> HaxeD: http://www.dsource.org/projects/haxed
>>
>
> interesting - the last time I looked, I thought the project is abandoned.
>

Nah, I'm pretty hell-bent on getting this working[1]. It's just that 
sometimes real-world gets in the way. But I plan to use this for my main 
real-world project, so that's helping keep the priority up.

[1] ...Unless I could get Dax (ie, D -> Haxe) working before finishing 
HaxeD, which I would have preferred, but that's definitely not going to 
happen: I've decided to put Dax on indefinite hold b/c it's a *much* more 
difficult problem: partly because D's features are more-or-less a superset 
of Haxe's, and partly b/c Dax is currently based on DDMD which has proven to 
be an unsustainable approach to accessing DMD from D.


>>
>> Why did I write the whole thing from scratch in D as a separate tool,
>> instead of just adding D support to the official Haxe codebase? Ehh,
>> possibly-questionable reasons:
>>
>> 1. Because I looked at Haxe's source and decided I didn't feel like 
>> figuring
>> out OCaml before getting started :/
>>
>
> yes OCaml is another beast. My idea was to take the source of Hugh
> Sandersons C++ target and adopt it to D. For me, D is a much more
> logical target for haXe, because many of the language features fit
> better together. The problem I see with your solution is, that haXe
> evolves very fast and a D target written in OCaml would benefit from
> this, whereas a target written in D is always behind.
>

Yea, that is definitely the downside of my approach. OTOH, Haxe still 
doesn't evolve as fast as, say, D. And I'm optimistic that once I have it 
100% working, updates shouldn't be too difficult. Most of the changes in 
each Haxe release are either in the std lib, neko-related, or bug-fixes, 
none of which would be applicable to HaxeD (as far as the std lib, HaxeD 
will have a copy of the std lib that may add some "#if d" directives where 
applicable, and those would need to get merged wih each Haxe release, but 
that shouldn't be too hard).

> The last few months I am looking at D as a replacement for Delphi at
> least at the server side (which would be a major task rewriting the
> database server), but I am twisted at the moment, because I am not sure
> if D is mature enough ( and/or me good enough to master if not).
>

Personally, I think it is. FWIW.