www.digitalmars.com         C & C++   DMDScript  

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

reply "Nick Sabalausky" <a a.a> writes:
"Adrian" <adrian.remove-nospam veith-system.de> wrote in message 
news:jbhr5j$1n9t$1 digitalmars.com...
 Yes it is - but did you ever tried haXe ? IMO it is the best cross
 platform language around - you target JavaScript, Flash, PHP, NEKO, C++

 compiled and code completion support from the compiler.
Haxe is great. The documentation isn't always so good, the language itself could admittedly be better (it absolutely pales in comparison to D, but then, so do most languages), but it's better than JavaScript, and it absolutely beats the SHIT of out of AS2 and PHP (as much as I hate JS, my hatred towards PHP, FlashIDE and AS2 is at least 10x that). The main "real world work" project I've been working on for awhile has had requirements of Flash, and shared web hosting (which generally implies PHP). The Flash requirement is due to things that JS just can't handle well even now, and definitely couldn't have handled back at the project's start. Very early on, I switched development from PHP/AS2 to Haxe and have never looked back. 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... <shameless plug>: so is D... :) HaxeD: http://www.dsource.org/projects/haxed It's not at a usable point just yet, but the basics are in place, and at this point it's mostly just a matter of continuing to translate each of the different types of statements, expressions, declarations, etc. Details of the current status are on that homepage. (Haxe's macro system is a low priority for me right now though, unless someone else wants to work on that). 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 :/ 2. I already have a parsing framework in D ( http://www.semitwist.com/goldie/ ) and figured dogfooding would be a good idea.
Dec 05 2011
next sibling parent Tobias Pankrath <tobias pankrath.net> writes:
 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.
That's what Google Web Toolkit makes possible for Java. It's like SWT for WEB plus easy connections to server.
Dec 05 2011
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Nick Sabalausky Wrote:
 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...
What kind of code is it? The main reason for the javascript api thing in my web.d is to help minimize the pain of duplication, by keeping it all on the server, but still having easy client side interface. Then basically your js is just event glue to various server side functions. Of course, it keeps the JS down to size... but doesn't actually let you run code on the client written in D.
Dec 05 2011
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
Adam Ruppe Wrote:
 Of course, it keeps the JS down to size... but doesn't actually let you
 run code on the client written in D.
Unless your client is a real application, of course :P I did a Qt app using the modules from a work web app earlier in the year. I interfaced with Qt via a message passing layer which converted signals and slots into C calls - which were implemented in D. So, new widgets would be written in C++ (QtD was close but not quite good enough for me to use), but the core was still D.
Dec 05 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam Ruppe" <destructionator gmail.com> wrote in message 
news:jbj23n$p68$1 digitalmars.com...
 Nick Sabalausky Wrote:
 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...
What kind of code is it?
Flash. A demo of it is here: www.attentionworkout.com (Pardon the voiceovers, that's a requirement that's outside of my control.) Basically, there's a series of "activities" that are (by necessity) Flash SWFs (but written in Haxe). These activities collect as much performance information as possible (including various timings, and in the case of the Radio, a log with enough info to "play back" the performance and re-interpret it however desired.) The whole thing was designed to be used in clinical trials on the elderly (which it's currently going through), so data collection/analysis, correctness/reliability, and compatibility were important concerns. (And naturally, flashiness and polish were lower priorities, which is why it...umm...doesn't exactly compete with PopCap in those regards.) For the most part, the shared PHP-server/Flash-client code is things like: - Data structures for all the results data. - Various utility functions (Such as a lerp function. And a string->int function that actually works consistently on server/client and doesn't have the other weirdness of Haxe's built-in string->int. And other such util funcs that's aren't in Haxe's std lib). - Identifiers for and URL-building for various URLs involved in the program. Even the flash apps need to refer to specific URLs now and then. - Much of the code in the custom error-notification system (which automatically logs and emails us about things like unhandled exceptions in both the server and client-side code). This includes the Exception classes. The client version will notify the server instead of recording to log/DB/email directly, but other than that it's mostly the same code on both sides. - The code which takes a log of exactly what happened (and when) during the Radio activity, and gives it an accuracy ranking between 0% - 100%. This, of course, needs to be consistent in both PHP and Flash. We could just simply record the 0% - 100% result the flash app shows to the user, but then we'd lose the ability to re-analyze the old performace data if we decide we want to change the algorithm (well, we *could*, but we'd be forced to do it in flash). Basically the shared code, aside from reducing duplication (which has well-known problems), helps to keep simple things simple, helps with consistentcy, and helps us keep our options open (hell, at some point I could probably even make it work on an iOS browser without rewriting all the client code).
 The main reason for the javascript
 api thing in my web.d is to help minimize the pain of duplication,
 by keeping it all on the server, but still having easy client side
 interface.

 Then basically your js is just event glue to various server side
 functions.


 Of course, it keeps the JS down to size... but doesn't actually let you
 run code on the client written in D.
Yea, actually, I don't use Haxe for JS at all. Like you, I prefer keep my JS usage minimal and hand-tuned, and don't want to pull in a ton of JS libs just to do simple DHTML tricks. (Of course, once JS/HTML5 advance to a point where they can be used as an alternative to Flash, then I'd be more likely to use Haxe->JS for those purposes.)
Dec 05 2011
prev sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
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. Together with a increasing number of target languages it fits almost everywhere. Currently I use the following setup for my development: - a web and database server written in pascal (Delphi) - all server modules written in haXe/neko - client - server communication via haXe - GUI client modules written either in Delphi with a small neko layer for the communication, or in haXe/Javascript in an embedded browser.
 <shameless plug>:
 

 so is D... :)
 
 HaxeD: http://www.dsource.org/projects/haxed
interesting - the last time I looked, I thought the project is abandoned.
 It's not at a usable point just yet, but the basics are in place, and at 
 this point it's mostly just a matter of continuing to translate each of the 
 different types of statements, expressions, declarations, etc. Details of 
 the current status are on that homepage. (Haxe's macro system is a low 
 priority for me right now though, unless someone else wants to work on 
 that).
 
 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. 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).
Dec 06 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Adrian" <adrian.remove-nospam 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>:


 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.
Dec 06 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jblhn8$1vis$1 digitalmars.com...
 "Adrian" <adrian.remove-nospam veith-system.de> wrote in message 
 news:jbkkpf$cut$1 digitalmars.com...
 Am 05.12.2011 18:56, schrieb Nick Sabalausky:
 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).
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: http://code.google.com/p/haxe/issues/detail?id=106 Forum thread links have JS that screws up "open link in new tab/window" http://code.google.com/p/haxe/issues/detail?id=105 Assigning from a Dynamic silently subverts type system and corrupts var. is something that breaks standard browser behavior *with* JS on, and is a trivial fix with no downside (at least none that he was willing to actually share). Of course, that's just unrelated website stuff, but... also has a Dynamic type. But take a look at this: var dyn:Dynamic = "foo"; var i:Int; // Statically-typed **INTEGER**!! i = dyn; Guess what? Not only does the compiler accept that, but there is no runtime-check either. My *statically-typed integer* now contains a *string* ("foo")!! Yes, seriously. And with *no* explicit casts or "unsafe" or anything. Of course, the fun doesn't stop there: dyn = "5"; i = dyn; i += 10; // Looks like integer addition trace(i); // Wheee!!! Output: 510 Granted, one could argue that you should be able to this without any run-time baggage if you chose to (for instance, if you *know* that dyn is really an Int). But Haxe ALREADY has "Unsafe Cast" which DOES EXACTLY THAT!: // From the official docs on Unsafe Cast: // "...the cast call will not result in any runtime check, // but will allow you to "loose" one type." i = cast dyn; his "Denied" stamp along with a message that clearly misunderstood much of the issue. </rant> So anyway, with my own Haxe implementation, I can just add an optional "-sane" switch to enable either a runtime or compile-time check...And nobody can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA! !!!
Dec 06 2011
parent reply Danny Wilson <danny decube.net> writes:
Nick Sabalausky wrote:

 So anyway, with my own Haxe implementation, I can just add an optional
 "-sane" switch to enable either a runtime or compile-time check...And nobody
 can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA! !!!
HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D But, have you looked at the new haXe macro output feature?: http://haxe.org/api/haxe/macro/jsgenapi You could write a D generator macro which acts as a JS target. Probably alot less work too. I find it unfortunate D -> haXe is so complex, as I'd much rather write my code in D. If only D was as multiplatform as haXe... :-(
Dec 08 2011
parent "Nick Sabalausky" <a a.a> writes:
"Danny Wilson" <danny decube.net> wrote in message 
news:jbrjp6$n54$1 digitalmars.com...
 Nick Sabalausky wrote:

 So anyway, with my own Haxe implementation, I can just add an optional
 "-sane" switch to enable either a runtime or compile-time check...And 
 nobody
 can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA! !!!
HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D
Heh :)
 But, have you looked at the new haXe macro output feature?: 
 http://haxe.org/api/haxe/macro/jsgenapi

 You could write a D generator macro which acts as a JS target. Probably 
 alot less work too.
I'm happy with the progress I'm making so far on with my approach, but that is an interesting idea.
 I find it unfortunate D -> haXe is so complex, as I'd much rather write my 
 code in D. If only D was as multiplatform as haXe... :-(
Yes, me too. Definitely. I would still like to get around to that sometime. This Haxe->D will probably help give me some good language converstion experience, though.
Dec 08 2011
prev sibling parent reply Adrian <adrian.remove-nospam veith-system.de> writes:
Am 06.12.2011 18:00, schrieb Nick Sabalausky:
 "Adrian" <adrian.remove-nospam veith-system.de> wrote in message 
 news:jbkkpf$cut$1 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>:


 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.
Dec 07 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Adrian Wrote:
 [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...
How big is big? My app is up to about 75,000 lines of D2 (including my D libs), which isn't gigantic but it does a lot of things and needs to be ready for use and changes almost every day.
Dec 07 2011
parent Adrian <adrian.remove-nospam veith-system.de> writes:
Am 07.12.2011 15:16, schrieb Adam Ruppe:
 Adrian Wrote:
 [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...
How big is big? My app is up to about 75,000 lines of D2 (including my D libs), which isn't gigantic but it does a lot of things and needs to be ready for use and changes almost every day.
I meant a community driven project of course. And the only projects, which are useful for every D user and therefor have lot of contributers are the compiler itself and maybe an IDE with debugger.
Dec 08 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Adrian" <adrian.remove-nospam veith-system.de> wrote in message 
news:jbnmoo$2seg$1 digitalmars.com...
 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)
That's true, but FWIW, I do intend to place a very strong emphasis on compatablity with the official Haxe. (It even accepts Haxe's command line params to the extent possible, and I plan to support .hxml files.) As far as optional. Anything else is to be considered a bug in HaxeD.
Dec 07 2011