I actually started programming in a round about way; I really started by building my own electronic circuits from transistors, capacitors, resistors and other components re-purposed from things like broken VCRs that I used to buy in bulk from markets when I was a kid. Initially my main use for computers in that regard was actually to design circuits, but soon actually writing logic rather than building it became a far easier and more expressive medium - plus I was never particularly good at soldering, so not having burnt fingers all the time was another bonus.
I got a job straight out of college working for a small startup specializing in mobile applications, and this was way before mobiles were wide spread - were talking WindowsCE and PalmOS. After that job I started working in London for a medical company and finally decided to go freelance.
I still work for medical and pharmaceutical companies and so, by proxy, work for the NHS, the United Kingdom’s National Health Service, but still in a freelance/contractor manner.
I really like it. Its challenging work on a grandiose scale, and since its medical nature there is a genuine feeling of accomplishment and importance. I also get the best of both worlds by being a contractor in that I don’t get any of the negative aspects of “office politics” or “corporate away days” but maintain a professional and highly technical contact network all from my Barcelona base.
Even though I do work freelance, one of the main companies I work for is INPS (In Practice Systems) which is part of the Cegedim group.
Currently I don’t, however, I’m hoping that this is something that will change in the coming future.
Most of my development I do on windows, therefore the IDE I use the most is FlashDevelop. Ive heard that you can use Eclipse and IntelliJ also and Ive been meaning to try them out (I use them a lot for other non-Haxe work), but honestly, I’ve never had a problem with FlashDevelop and thus never had a real need to look for alternatives.
On Linux I use Visual Studio Code simply because FlashDevelop doesn’t work there without Mono and Visual Studio Code seems to work just fine for what I need it to do.
I suppose, like most people, the main additional software is more in the form of libraries from HaxeLib which is, of course, an invaluable part of the Haxe eco-system. I think its probably my favorite part of Haxe really (as well as macros!). The abstract nature of Haxe means there is a little bit of everything in HaxeLib and it also sometimes feels that Haxe attracts some of the most talented and “problem oriented” developers than any other community.
I recently bought a new computer:
- OS: Microsoft Windows 10 Home (x64)
- CPU: Intel® Core™ i7-6700K CPU @ 4.00GHz (4.00GHz)
- Memory: 15.9 GiB Total
- Storage: 931.0 GiB
- Card: NVIDIA GeForce GTX 970
Its as simple as its cross platform nature. There are of course a lot of cross platform languages out there, but one that transpiles to so many native targets and doesn’t use a VM is by far the most useful feature of Haxe to me.
Apart from being cross platform its probably the syntax. Its very straight forward but also powerful and feels very mature.
Over the years, like most devs, Ive used a variety of languages and platforms - most of which either required different codebases or run inside a virtual machine (like Java).
I use Java a lot, its quite rare to not find a machine that doesn’t have a Java VM on it (but it does happen) and for server side where you have control its not a huge deal. However, there is still issues with versions of VMs and bytecode you are running on them. Its certainly not the same thing as natively transpiling via C++ to a
.exe. And lets just not talk about SWING.
I don’t know if I would categorize it as “ticking me off”, but I’m always surprised at how niche Haxe is. Ive spoken to a lot of developers about Haxe and the response is usually the same: “I don’t understand why this isn’t well known” or “how isn’t this a big thing” - I think it could be because, again, Haxe itself is so abstract it doesn’t solve a specific problem, or set of problems, its far more generic which means there is no “killer app” if you will.
I agree, the foundation has been doing great work solidifying what Haxe does and what it is, improving the documentation, subsites like
code.haxe.org are a great addition. Also Mark Knol’s work on improving the UI and UX across the various HF sites is awesome.
No clue. More of an observation than a criticism. Its certainly felt like Haxe has been gaining momentum lately, and success stories like TiVo highlight this quite clearly. I also think that there is potential for libs like HaxeUI to lower the entry bar a little and make it a little easier for people to “dip their toe” into the Haxe pool.
Definitely agree with more libraries like HaxeUI. NME, then OpenFL and similar libraries, Kha etc definitely have lead to an increase in users, they solve a lot of the inherent cross platform issues for the coders. I think HaxeUI v2 or similar will do the same.
I think the main ones I haven’t used (or used much) are the PHP, Java and C# targets.
I would probably say that I use more than one target simply because that is what I needed Haxe for initially. Building the same code for mobiles, browsers and desktop applications. Ive also looked at the solutions for using Haxe as a web server and needless to say, when
haxeui.org gets a much needed make over it will be using one of these.
Primarily mobile, desktop & browser - So really, all of them.
I’m pretty interested in the new “HL” target, which as far as I understand is a C target. I have no actual need for it per se but I think some interesting possibilities could come from it.
Just get stuck in. Its a mature language and there is next to nothing to “trip you up”. The syntax is familiar and the standard lib is more than rich enough. In fact, I see no reason at all that Haxe couldn’t happily be used for some-ones first language on an educational level.
Well, there is a plethora - I think all of the “render” libraries are impressive in their own way. The HXCPP lib is of course invaluable. Ufront also seems great.
This probably goes without saying, but its UI.
There are a number of libs available in the terms of either custom drawn components or externs to another lib, but I personally think in the spirit of Haxe as a sort of “everything” type of language it would be nice to be able to pick it up and not really have to choose a UI system - I use choose tentatively as you would of course need to choose in some respect - but not having to rewrite an application half way through because you realize the jQuery externs weren’t the right choice to start with is more what I mean. A universal way to access different renderers or UI externs essentially.
Again this is really hard to quantify. I think its quite rare to find a bad use. The render and game frameworks all seem great. Ufront seems very well put together. Most extern libs seem pretty full. Pretty much every time I read the news letter I come away going “hmmm, clever” or “hmmm, I like that”.
I don’t really think I’m in a position to comment. I wouldn’t know the first thing about running a “Foundation” or how to “spread Haxe across the lands”. It could be my imagination or simply the fact that I’ve been using Haxe much longer now and so feel a little more “involved” in the community, but it feels to me that the HF and Haxe in general have made pretty huge steps in garnering more general interest. Whether its a direct strategy or not.
Coffee and extremely late nights / early mornings. :)
At the risk of sounding like a broken record it is again the people who write and maintain all these libs, the core compiler team, the mountains of help you can see littered over the net by the usual suspects. There is a real feeling of “can do” in the Haxe community I feel.
I suppose this is easy one: I of course quite like HaxeUI - even more so with Version 2 around the corner. I also think the
hxWidgets lib is a pretty useful addition in its own right.
Version 2 of HaxeUI will certainly be featured in a few things I’m currently mulling over. And
hxWidgets itself forms the base of a backend for HaxeUI2.
Yes. Ive worked on a number of projects that aren’t mine in a paid freelance or consultancy capacity. Probably more importantly, I know of others who have written commercial products using HaxeUI and thats great to hear.
v2, has gained a lot of attention for its native backends, whats been the biggest challenge for you in
Probably most of it. In order to add a new backend I had to first learn how that target framework did things. I’m no OpenGL expert and don’t have any game writing experience or anything like that. So there was certainly a learning curve for pretty much each thing I knew I needed to implement. It was for that reason that I initially chose the 3 frameworks to target as being the most different from each other: OpenFL, Flambé and Kha.
Once those three were functional I was pretty confident that I had a pretty flexible candidate framework and new backends were “pretty easy” to support. Including native/hybrid ones.
There was also the standard developer despair of “what am I even doing rewriting all of this” at 5 a.m. Thankfully that seems to have subsided mostly now.
One of the more complex backends was the pure HTML5 backend, it has no framework dependency at all and outputs a DOM tree (i.e, not canvas drawn). Apart from the fact that there is no real render to speak of, from HaxeUIs perspective its just building DOM nodes, it was also that it was always going to be the backend that opened up haxeui-core to native versions of components, as HTML supports them.
For something so complex and from seeing your previews on Twitter, has testing been an issue and do you test for visual regressions?
This is something I’ve been toying over, and the simply answer is not at all yet. More than visual regressions I would love to have a cucumber / gherkin like test framework which could be used to functionally test a UI… something like:
When I click the button "Button 1"
Then the text in "Text 1" should be "something else"
This is a great way to functionally test applications, but needs a way to access the component tree.
The main thing is of course to simply get an alpha out. I was originally not going to release anything until the functionality of HaxeUI version
1 had been implemented in version
2. However, thats not really feasible and I have a “cut off point” in my head where there wont be any new components and all focus will go into a release. My main focus at the moment is to clean up and stabilize the API and get some documentation written.
I have some other pretty big ideas for tooling and application frameworks written around HaxeUI, but really these are just ideas at this point.
In a nutshell, I’m going to go over some of the things about version
1 of HaxeUI that essentially led to the total rewrite which will be version
2 and use that as a base to introduce version
2 and its features.
Apart from the other talks which I watched last year and found interesting its probably as simple as putting faces to names.