At the moment I'm a full-time Go developer and part-time Haxe enthusiast. But a year ago my life was entirely different. I was a retired business executive, who hadn't programmed for ten years. The Go and Haxe languages led me to fall in love with programming again. I am grateful to them both.
What hardware do you use?
MacBook Pro for everyday, MacBook Air for travelling, and an old laptop running Ubuntu for fun.
What software do you use?
For Haxe: Sublime Text 3, Chrome, and the command line. But I'm no expert.
Where do you get your inspiration?
At home, first thing in the morning! Just after waking up, I often find myself writing down ideas that are buzzing round my head. The sub-conscious mind is an amazing source of inspiration.
Which creatives/developers/artists do you admire most?
I admire simplicity, because the most elegant solution to a design problem is always the simplest. The Go ecosystem developers have made writing concurrent code simple. The Haxe ecosystem developers have made writing portable code simple. If only I could put them together in some way...
What contributions are you proud of?
My TARDIS Go to Haxe transpiler project is only really a proof-of-concept, so I think my best contributions are yet to come.
Did your contributions bring you work opportunities?
Yes, my current freelance work came as a direct result of speaking publicly about TARDIS Go.
Do you use them in your projects?
Not yet, but making TARDIS Go a usable and reliable software tool is a personal goal.
How did you get started with Haxe?
I was writing some specialist educational software. To keep my costs under control, I wanted the same user interface code to run on all of the devices students use. Looking around, only Haxe, OpenfL/NME/Lime held the promise of being able to do this in a truly open-source way.
But I also wanted to write my software in Go, and so I got sidetracked into writing my transpiler.
What problem does Haxe solve for you?
I want to write a single set of Go code that works in every environment I need it to. But while server-side Go implementations are already operating at Google-scale, client-side Go implementations are currently patchy. So transpiling my Go code into Haxe and using the OpenFL API offers the tantalizing prospect of writing truly cross-platform client-side code.
What tips or resources would you recommend to a new Haxe user?
Do not depend on the documentation. If a library function is not working as you expect, read the source code. This is also a great way to learn the language.
What Haxe libraries are you impressed by?
OpenFL, NME and Lime, without them, Haxe would not be so practically useful.
What problem would you like to see solved by a new or existing Haxe library?
I would like to see the work I have started with the TARDIS Go runtime blossom into a library for automated code generation. It would provide a consistent low-level API across all of the Haxe targets, with poly-fill functions where required for:
What is the best use of Haxe you've come across?
So far the games industry have been the biggest users of Haxe, but it is now time for the ecosystem to move into the mainstream.
What do you see for the future for Haxe/OpenFL?
Obviously I would like to see Go as a Haxe target, complete with a Go implementation of the Haxe standard library. Go has most of the advantages of C++, without the disadvantage of the very slow compilation times. It also has excellent concurrency support built into the language and a well-proven http server built into the runtime. It would provide a very strong server-side Haxe implementation.
But beyond that, my dream for Haxe is as the hub of a giant transpiler project, allowing code in one language to be translated into another. So not just Go->Haxe->JS, but also JS->Haxe->Go, or FORTRAN->Haxe->C# etc.
There would be two main objectives, both of which should save users money:
To achieve this, Haxe would need to be generated by language compilers, instead of specific target object/assembler code. But since many compiler tool-chains and languages (like Go) already contain libraries to implement the front-end of a compiler, only the Haxe code-generation element needs to be written for each language.
And some languages share the same compiler chain, for example LLVM (C/C++/Objective-C natively, plus projects for Ruby, Python, Haskell, Java, D, PHP, Pure and Lua targeting LLVM) and GCC (C, C++, Objective-C, Fortran, Java, Ada, and Go), so writing Haxe code generation for these compiler chains would be very time-efficient.
I realize that due to practical considerations, only a sub-set of each language may be able to work in this way, and that the auto-generated Haxe code will be much larger than if it was hand-translated. But provided that the supported language sub-set is large enough to be useful, and that the target environment is fast enough to cope with a little inefficiency, a Haxe-based universal language translator would be very valuable tool.
So valuable in fact, that Haxe, with its universal language translator and cross-platform API, would become an essential part of every software developer's toolkit.
Sell your wwx2014 session!
If you're interested in making Haxe a more significant force in the software industry, come and hear me speak.
What is the best part of wwx for you?
As I've not attended WWX before, please come and ask me this question during the event, I'm looking forward to meeting you!