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

[Adrian]

Am 06.12.2011 18:00, schrieb 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:
>>
>>> 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.
> 
>

IMHO haXe->D is more interesting than D->haXe.

[OT] As a side point from a not yet D developer, but someone who looks
at the language with great interest, but also someone with a commercial
responsibility: I am missing big projects developed in D and the most
logic project would be the compiler itself! I know this has been
discussed a million times before, but...

>>>
>>> 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 pro of this approach would be, that there is a second haXe
implementation, even if it is bound only to D.
The downside would be, that there is the risk of incompatibilities of
the compilers, leading to 2 different dialects, which would force the
users of both, only to use the subset of the languages. I have this
situation on the object pascal side with freepascal and Delphi, which
are very the same but still different. If you code for both, you can't
use new language features (and "new" means sometimes many years)

Reading your second post, I feel that the risk for the haXe language is
real:

> There is another upside to my approach, though: It gives me the ability to 
> add optional features without Cannasse's approval. Sometimes he can 
> be...(how can I say this diplomatically?)...a bit stubborn in refusing to 
> even consider or discuss reasonable requests. He seems to like his "Denied 
> Because I Said So" stamp . Couple off the top of my head examples:


Yes it is sometimes frustrating when the leaders of certain development
(like the Canasses, Brights, Alexandrescus etc.) seem to be stubborn in
some cases. But I think otherwise we wouldn't have such nice
developments like D or haXe and many others - they have to be!

But the decision for a second haXe compiler shouldn't be driven by such
feelings, even if I agree that:

> var dyn:Dynamic = "foo";
>     var i:Int;  // Statically-typed **INTEGER**!!
>     i = dyn;


should be compiled as:

i = cast(dyn, Int);

but it could be handled like that by the runtime as well. Dynamic
languages like JS don't do it, but a D target could - even if
implemented in OCaml.

IMHO a way to avoid dynamics at all (at least reduce the need), would be
much better! And here is haXe going in the right way with its macros.

Most of the need for dynamics comes from accessing data from foreign
sources like databases. If the structure of these sources is known at
compile time, you don't need dynamics at all. You only have to check at
startup of the application if the schema matches to the schema at
compile time.