"Adrian" <adrian.remove-nos...@veith-system.de> wrote in message news:jbkkpf$cut$1...@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.