Re: Haxe (From: Java Scala - new thread: GUI for D)
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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
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... :-(
Re: Haxe (From: Java Scala - new thread: GUI for D)
Danny Wilson da...@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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
Adrian adrian.remove-nos...@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 any deliberate deviations (such as #105), such things will be purely optional. Anything else is to be considered a bug in HaxeD.
Re: Haxe (From: Java Scala - new thread: GUI for D)
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 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. 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).
Re: Haxe (From: Java Scala - new thread: GUI for D)
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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
Nick Sabalausky a@a.a wrote in message news:jblhn8$1vis$1...@digitalmars.com... 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: 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. Note that first one, #106, is NOT my usual X requires JS complaint. This 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... That #105 in particular is pretty nasty. Haxe supports static typing and 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; After I explained all of that to commenters #1 and #3, Cannasse pulled out 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!@!!!
Haxe (From: Java Scala - new thread: GUI for D)
Adrian adrian.remove-nos...@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++ and soon Java and C# with one language. Typesafe with type inference, 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 to that end, you mentioned Java and C# targets are coming to Haxe? Well, 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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
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.
Re: Haxe (From: Java Scala - new thread: GUI for D)
Adam Ruppe destructiona...@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.)
