Andy Li’s Blog

Haxe Packages Arrived at Official Arch Linux and openSUSE Repositories

2016-02-02T00:00:00+08:00

Yes, our Haxe and Neko packages have arrived at official Arch Linux and openSUSE repositories!

Haxe in the Arch Linux “community” repository

There were already nice Haxe and Neko packages existed in the Arch User Repository (AUR), which is somewhat like a Ubuntu PPA, except that AUR stores only source tar balls. It means that people using the AUR will still have to get the tar balls and then build the packages. It is, therefore, time-consuming.

The Haxe and Neko packages are now moved to “community”, which is one of the Arch Linux official repositories, which stores both source and binary packages. The Arch Linux package management tool, pacman, can directly install built packages from those official repositories. Therefore, installing Haxe and Neko is now as easy as issuing a single command: sudo pacman -S haxe.

Packages in the “community” repository can only be submitted and maintained by “Trusted Users”. The Haxe and Neko packages are kindly maintained by Alexander Rødseth. I will also try assist him to update the packages when new versions are released.

Haxe in openSUSE Factory

I’ve created a devel project for Haxe in the openSUSE Build Service as mentioned previously. People can use that to install Haxe and Neko packages on openSUSE, but they were not openSUSE official packages.

After months of submissions and revisions, the Haxe and Neko packages are now accepted into openSUSE Factory. It means that if you’re using Tumbleweed, openSUSE’s rolling release, you will be able to install Haxe and Neko simply by sudo zypper install haxe.

Haxe ♥ Linux

As of now, we’ve packages for Debian, Ubuntu, Fedora, openSUSE, and Arch Linux. All the info and installation instructions of the Haxe Foundation maintained packages are documented in the haxe.org Linux Software Packages page.

According to the Haxe usage survey, we covered most users’ need. We will provide packages for other Linux distros when they become popular. If you want to create Haxe packages for other distros, go ahead and let us know when you’ve any question.

Haxe Usage Survey

2015-11-14T00:00:00+08:00

Last month I’ve sent to the Haxe mailing list and Twitter a short questionnaire in order to find out what operating systems our community is using or interested in using, such that I can ensure there is enough installer or package support. I’ve also added some questions on the other aspects of how Haxe is used, e.g. is it being used in professional works, which compilation targets are being used or interested in using etc.

I took this chance to have some hand-on experience with the Haxe Python target. I always wanted to use Haxe for data analysis during my PhD study. However, I’m not aware of any statistics package available to any of the Haxe targets available at that time. The Python target was released too late for my thesis. So, for my PhD, I used just vanilla Python and R, which were being used for the statistics courses I attended. Another reason to use the Haxe Python target this time is that I wanted to present this data analysis as a demo project in my talk in PyCon HK 2015, which happened during the last weekend.

I have pushed all the data together with the Haxe code I used for analysis and graph-plotting to a Github repository. Feel free to play with it :)

Result

I’ve collected 361 entries in about 2 weeks. After removing the invalid ones (people who just don’t know or not interested in Haxe) and the duplicated ones (people clicked submit twice, resulted in having entries filled with the same email address), there are 351 valid records. It clearly shows that our Haxe community is so active and cares so much about the development of Haxe. Thank you for all the helps!

The first thing I asked in the questionnaire is the experience on using Haxe, in particular is it being used for professional works. My hypothesis is that my questionnaire should reach more “serious” Haxe users and the ones who care to submit a response should also be the “serious” ones. The result meets my expectation and there are about half of the respondents using Haxe for professional works, as illustrated in the figure as follows:

Having more than 160 professional Haxe users participated in this survey is pretty impressive to me.

So, what is our community creating? It has been well-known that Haxe is popular among game developers. It is so popular to a point that for once all the top three winners of the Ludum Dare game jam were all using Haxe… Here the second question asks what kind of things Haxe is being used or interested in using Haxe to build:

As expected, most respondents are making or interested to make games with Haxe. But other than games, there are also high interests in using Haxe for mobile/desktop applications, web sites, and even software libraries and frameworks. It suggests that Haxe is indeed a general purpose language and we cannot ignore the interests outside of game development.

The next thing is to find out which compilation targets are being used or are generating interests. Historically Haxe was developed as a replacement of AS3, so I know that there were lots of people using it to create Flash contents. But given HTML5 is the current hype so I suspected there is huge interest in the JS target too. The result is as follows:

As expected, the JS target is the most used / interesting target. And it is somewhat surprising to me that the number of respondents who are interested in the C++ target is nearly as high as the ones who are interested in the JS target. I believe it is due to the high performance nature of C++, making it very attractive to be used to build everything other than the web. Since you’re interested in the C++ target, I think you will be happy to know that Hugh has been actively improving it all these years and there was a great performance improvement recently :)

The interests in the Java, C#, and Python targets are relatively low and I personally think that they should deserve more attention from the community. It is because there exist a large amount of solid libraries in those languages. For the Java and C# targets, we don’t even have to write externs but simply add a line of -java-lib/-net-lib and we can make use of any Java/C# libraries. Maybe the lower interests are caused by the lack of documentation and usage example, which I hope they will be improved.

Another information that can be extracted from the same question is the number of interested target per respondent. Given being multi-target as the most prominent Haxe feature, I suspect Haxe users are using or interested in more then one target. The result meets my expectation:

As shown above, over 90% of the respondents are using or interested in 2 or more targets. The result is pretty much a normal distribution and the mode is 3 targets.

We will then turns to analyze the development setup in the next question, which is to ask which versions of Haxe are the respondents using, or want to use / test. The result is plotted in the figure as follows:

Over 90% of the respondents are using or interested in using the 3.2 series. The interests of earlier versions are much less (< 10% of the respondents). It is good in the way that we can mainly focus on developing the latest version without the headache of backporting bug-fixes and features to the earlier versions.

Another interesting view to the data is the number of interested Haxe versions per respondent:

We can see that there is some interest in using more than one Haxe version (~20%), but the majority of respondents are interested in using only one version. That means it is not urgent to support installing multiple version of Haxe in a system, although it would be great to have a way to do so in the long run. HVM sounds promising although I haven’t tried. For testing purpose, one can easily setup a TravisCI build matrix with multiple Haxe versions.

For the installation method, I asked how Haxe was being installed:

As shown above, most respondents used the official installer from the haxe.org web site. There are some respondents used the third-party installer or script, which I suspect it is due to the fact that the haxe.org web site doesn’t provide a installer for Linux and people resorted to using the installer script provided by OpenFL. Given we now have Linux packages officially maintained by the Haxe Foundation, I think the OpenFL installer script can be deprecated and the usage of Linux package managers will be much higher soon. Self-remainder: I have to go to update the haxe.org download page to provide the Linux packages info.

Since I want to know what Haxe installation methods have to be improved, I also asked what installation methods are being used for general development tools. Particularly, I’m a big fan of using package managers, and that’s why I’m putting effort on improving Haxe in this aspect. But does the Haxe community want to use package managers?

As expected, most respondents prefer to use official installers, and they prefer package managers as well. Note that the number of respondents preferred to using package managers is higher than the number of respondents actually used package managers to install Haxe. It is because the Haxe packages were not updated until recently, so people opted to use another installation method. It means my recent effort in updating the Linux packages for the Haxe Foundation should be useful and you can start to use package managers to install Haxe as you wished now :) I’ve also considered providing a Haxe Docker image, but given the interest is extremely low so I will save my effort for other important things for now.

Let’s take a look at the OS families being used for Haxe development. Note that I’m investigating the usage of developer machines, which are the ones people install Haxe and do actually coding in. I’ve included the usual 3 major desktop OS families: Windows, Mac, and Linux/BSD. Out of interest, I’ve also added “mobile OSes” as the forth OS family, because I think mobile devices are popular and there may be people who want to code on a tablet. The result is illustrated as follows:

Surprisingly, the number of respondents who stated interest in using mobile OSes for Haxe development is higher than the ones of Mac and Linux/BSD. Turn out some people reported they had mistaken the question as the interest of developing for, but not on, the OSes. But still, even if we assume only half of the respondents understood the question well, there is still ~30% percent of respondents interested in developing on a mobile device!

The difference between Mac and Linux/BSD is also interesting. Overall, there is higher interest in Linux/BSD than Mac. But, if we only consider the respondents who use Haxe professionally (the green and dark green portions), the interest in Mac is slightly higher.

We then look into the interest in using individual versions of the OSes. The results for Windows and Mac versions are plotted as follows:

We can observe that most respondents are interested in using the latest three versions, but not the older ones. This will be a good information to know when considering installer OS version support.

For Linux/BSD, I asked for the interested distros instead of individual releases of each distro to reduce the number of options. The result is plotted as follows:

I know that Ubuntu is super popular. As shown in the figure, there is indeed high interest in doing Haxe development on it. My recent package updating effort already covered the two most requested ones here (Ubuntu and Debian, and in fact the PPA is also usable in Linux Mint). The distros that uses RPM are not very popular among our community, but I’ve covered Fedora and openSUSE anyway. I wasn’t aware of the popularity of Arch Linux, so this survey is proven useful to let me know about this. I’ve been told that there are nice packages existed in the Arch Linux AUR, and I will check and co-maintain the packages if possible.

Finally we come to the result of mobile OS versions:

As previously mentioned, since there were respondents mistaken this question, it is safer to consider this result as the general interest but not development specific. If we take a look at the world-wide market share of the mobile OSes, we can observe that the two rankings are basically the same.

Conclusion

The survey result serves my purpose well. It verified the usefulness of maintaining the Haxe packages across different OSes. It also gives nice information for prioritizing improvements to the supports of different OSes, Haxe versions, targets, and application domains.

I think it would be nice to have this kind of survey once for every few months, to understand how our community is evolving and to dig out more interesting information.

Haxe RPM Packages for Fedora and openSUSE

2015-11-01T00:00:00+08:00

After polishing the Debian/Ubuntu .deb packages, I’m now bringing Haxe to Fedora and openSUSE, which are very popular Linux distros that use the .rpm package format.

Haxe arrived in Fedora 23 and Fedora Rawhide

There was an effort on bringing Haxe to Fedora back in 2008. Richard W.M. Jones, who is an employee of Red Hat, packaged Neko 1.7.1 and Haxe 2.0. However, only Neko was accepted. There was somehow nobody to review the Haxe package and it was abandoned years after it was submitted. The good thing is that the Neko package is properly maintained since then and Neko 2.0.0 is already available since 2013 (Thanks Richard!).

Went through the weeks-long submission review process, I am happy to announce that Haxe 3.2.1 is now accepted and available in Fedora 23, which will be released on the coming Tuesday (2015-11-03), and Fedora Rawhide, which is the current development version of Fedora. Install Haxe on Fedora is now as simple as sudo dnf install haxe (as usual, Neko as a dependency will be installed too).

I’m trying to submit Haxe to Fedora 22 too. A re-build of Neko is needed and it is going through the update procedure. Once the Neko update is available in Fedora 22, I will build and submit Haxe. You may check this page to follow the ongoing update activities.

Submitting Haxe to openSUSE

For openSUSE, again there are nice people built a Haxe package. The status is pretty good: there are Neko 2.0.0 and Haxe 3.2.0 in the Games Project in the openSUSE Build Service. However, they are not part of the official releases of openSUSE in the sense that users have to use zypper addrepo ... before zypper install haxe. It is kind of like using a PPA in Ubuntu. And Haxe definitely deserves its own project outside Games, since we have a lot of Haxe users building all kinds of good stuffs other than making games.

I’ve created a new project in the openSUSE Build Service, devel:languages:haxe, to provide dedicated maintenance. I’ve already built Neko 2.0.0 and Haxe 3.2.1 there, and they can be installed to openSUSE 13.1, 13.2, Leap 42.1, and Tumbleweed. I’m still working on the submission to openSUSE Factory (the repository of their releases), but you can already install the packages by following the instructions in the haxe package page (click “Download package” at the top right corner).

What’s next?

Probably Arch Linux will be the next (and the last one in my current plan) Linux distro to receive official Haxe package. In fact, there are more Haxe users interested in using Arch Linux than Fedora and openSUSE combined, according to the Haxe usage survey I conducted recently. And talking about the survey, I’m working hard on polishing the data and plotting graphs using the Haxe Python target. The result will be published in this blog in the coming week, and I will present the analysis procedure as an example of using the Python target in my talk in PyCon Hong Kong.

Upcoming Haxe Talks: London JavaScript Community Online Meetup and PyCon HK 2015

2015-10-10T00:00:00+08:00

This is a busy speaking year for me :) I have presented CI for Haxe projects in WWX 2015, and then a HKOSCon 2015 talk on Haxe as a transcompilation technology. I will deliver another 2 talks in this and the follow month.

London JavaScript Community Online Meetup

I’m so glad to be invited by the London JavaScript Community to deliver a talk via video stream next week. It will be an online meetup, which means everyone will be free to join without geographic constraint. My talk will target people who are interested in web development, particularly in front-end, JavaScript-related technologies. I will introduce Haxe with a focus in its JS target.

The talk will be hosted on 15th October (Thursday) at 12:30pm UK time (convert to your timezone here). Sign up in the online meetup event page if you’re interested. Don’t forget to invite your friends too ;)

PyCon HK 2015

I’m also glad to announce that my talk proposal has been accepted by PyCon HK 2015, which is the first PyCon in Hong Kong. My Haxe talk will also be introductory, but obviously will shift the focus to the Haxe Python target. I will demonstrate how to interop between Haxe and Python, to utilize the rich and solid scientific Python libraries in the modern, statically-typed Haxe language, using some simple examples of data analysis and visualization.

PyCon HK 2015 will be held on 7-8 November 2015 (Saturday-Sunday) in Hong Kong Cyberport. My talk will be on day two, 15:40 - 16:20 (schedule). Buy a ticket if you’re interested to attend.

Debian Package and Ubuntu PPA for Haxe

2015-10-05T00:00:00+08:00

Since the previous month I’ve been working on Haxe to bring better supports for Debian/Ubuntu. There are still some tasks I would like to work on, but there are already some good stuffs that I want to let you know.

About Debian and Ubuntu

For people who don’t familiar with the Linux world, let me quickly introduce what are Debian and Ubuntu.

Due to the free and open source (FOSS) nature of Linux, there exist a lot of different versions (known as distributions) of Linux, created by different people with different goals. Debian is one of the earliest and largest (most packages available) distributions. One of the most well-known distributions based on Debian is Ubuntu, which also has a lot of downstream projects based on it, e.g. Linux Mint.

Both Debian and Ubuntu, together with most of the distributions that based on them, use the .deb file format for packaging software. The Debian project maintains a set of package repositories, which are also used by Ubuntu. Only the approved members can upload packages to those repositories. People who are not Debian developers/maintainers, but want to add or update a Debian package have to file a packaging request, or to go through its sponsorship/mentoring process. The concept is similar to git, in which a project owner merge pull requests to accept contribution.

Updating the Debian Haxe package

Long time ago there are some volunteers who packaged Haxe and Neko and had them uploaded to Debian. But sadly they have moved on and orphaned the packages. The Haxe package stayed in Haxe version 3.0.0, for 2 years since 2013. The Neko package was built with Neko 2.0.0, which is the latest stable release. However, there was a critical bug related to JIT in the Neko package, leading to haxelib being unusable in the 32 bit platforms.

Instead of waiting for another volunteer to update the package for us, I stepped in on behalf of the Haxe Foundation and have taken over the maintenance of the packages by going through its sponsorship/mentoring process. It was not trivial since I didn’t have much knowledge on Debian packaging, but eventually I’ve updated the Haxe package to provide Haxe 3.2.0, and the Neko package to include the JIT bug fix.

Debian packages being accepted will be available in the unstable repo at first. If there is no bug being reported in 10 days, the packages will be automatically synced to the testing repo, in which the next stable release of Debian will be based on. Our updated Haxe package has already been synced to testing. The updated Neko package is still in unstable only, and will be synced to testing in 2 days.

If you have a Debian stable release installed, and want to try out the updated Haxe and Neko packages in the testing/unstable repo, consult the APT Preferences article. If you’re using Ubuntu, we have an easier option for you: Personal Package Archives (PPA).

Ubuntu PPA

Personal Package Archives (PPA) as its name suggests, is a personal (third party) repository. Once a PPA is added to a system, the system can obtain software packages provided by the PPA via the standard apt-get command. Compared to the configuration required to get packages from Debian testing/unstable, using a PPA is much easier.

I’ve created an official launchpad account for the Haxe Foundation. In its stable releases repository, the latest versions of Haxe and Neko are provided to all the currently supported Ubuntu versions, which includes Ubuntu 12.04, 14.04, and 15.04. It also provides packages for the upcoming Ubuntu 15.10, which is scheduled to be released on 22nd Oct.

To use the PPA, run the commands as follows:

sudo add-apt-repository ppa:haxe/releases -y
sudo apt-get update
sudo apt-get install haxe -y
mkdir ~/haxelib && haxelib setup ~/haxelib

The -y options above suppress confirmation messages.

I’ve mentioned another PPA provided by eyecreate the first time I wrote about TravisCI. It was the best PPA available to obtain Haxe on Ubuntu, and he quickly updated the package every time we had a new Haxe release (Thanks!). However, if you’re using eyecreate’s PPA, I would recommend switching to the Haxe Foundation’s. It is because our packages are built as similar to the Debian ones as possible, such that it is easy to switch to use the Debian/Ubuntu ones when they’re provided by the next stable releases of Debian/Ubuntu. Moreover, security-wise, it is always safer to use the “official” PPAs for any software.

What’s next?

With the updated Debian package and official Haxe Foundation PPA, it is much easer for the Debian/Ubuntu guys to use Haxe. I will continue to package Haxe for other OSes, e.g. Fedora, which uses the .rpm format instead of the Debian .deb format. I also plan to add another PPA to provide automated snapshot builds of the Haxe development branch, which will let us test with the latest commits much easier.

Continuous Improvement on Continuous Integration for Haxe Projects

2015-09-02T00:00:00+08:00

Things have been moving fast! Since I have written about Travis CI the first time around 2 years ago, there are many news and improvements regarding to using CI services for Haxe projects.

WWX 2015 presentation

The video of my WWX 2015 talk, “Continuous Integration for Haxe Projects”, was released a few days ago. The key idea of my talk is that, CI is surprisingly easy to set up. We don’t even have to write tests - we can simply let the build service compile our code, and the mighty Haxe compiler is already able to catch all kinds of errors for us. I’ve also demonstrated how to set up Travis CI and AppVeyor for a hello world project. Additional links and details can be found in the slides.

Built-in Haxe support in Travis CI

As mentioned in my talk, earlier this year we’ve contributed Haxe support in Travis CI as one of its “community-supported languages”. Since then using Haxe in Travis CI is easier than ever. No need to figure out how to use a PPA or to use a install script. Just specify in .travis.yml that we want to use Haxe and optionally what version(s) we what to use as follows:

language: haxe
haxe:
  - "3.2.0"
  - development

Multi-OS testing

Previously Travis CI’s multi-OS feature is limited to selected repositories. One has to ask their staff to manually turn it on for specific Github repositories. Earlier this week, Travis CI made their multi-OS feature publicly available. It means that we can now test on both Linux (Ubuntu) and Mac OSX by adding an os section in .travis.yml as follows:

os:
  - linux
  - osx

Windows testing can be done on AppVeyor. Although Haxe is not pre-installed in AppVeyor’s environment, and there is no such concept of “supported languages”, we can still install Haxe easily using Chocolatey in the install section of appveyor.yml:

install:
  - cinst haxe -version 3.2.0 -y
  - RefreshEnv
  - mkdir C:\projects\haxelib
  - haxelib setup C:\projects\haxelib

By the way, AppVeyor has also rolled out a faster build environment, which is used by default for new free OSS accounts. The old environment was super slow that it was a pain to build hxcpp projects in it. With the new environment, building on AppVeyor is now as fast as using local machine or using Travis CI.

More docs and samples

I’ve created a Github repository, HaxeCI, as an example of using CI for a Haxe project. As of writing, it contains configurations for Travis CI and AppVeyor. It also demonstrates how to build and run for each of the Haxe targets in the CI environments. (Thank Andreas for the contributions regarding to the PhantomJS and Flash testing!)

If you haven’t started using CI, NOW is the best time to check it out!

TypeScript vs Haxe, Which is the Better Compile-to-JS Language?

2015-08-05T00:00:00+08:00

TypeScript is definitely one of the most well-known compile-to-JS languages nowadays. Designed as a superset of JavaScript, TypeScript brings in static-typing for writing large-scale application. Haxe is similar to TypeScript in many aspects, particularly its JS-like syntax, static-typing, and module system. Among the 9 Haxe compilation targets, the JS target was one of the oldest ones. It was introduced in March 2006, which was way before Microsoft released TypeScript in 2012. In fact, Haxe is a language that compiles to JS, ahead of everyone else including TypeScript (2012), CoffeeScript (2009), Dart (2011), and Java via GWT (May 2006). So I wonder, which is the better compile-to-JS language, the (relatively) new shiny TypeScript, or the good-old mature Haxe?

I have been using Haxe for years and I’m now a member of the Haxe Foundation, contributing to Haxe daily. So I can be considered as a Haxe expert. But I didn’t have much knowledge of TypeScript other than watched some presentations about it and read some docs on its website. To gain enough knowledge and experience of it to make the comparison as fair as possible, I took a MOOC course from edX, Introduction to TypeScript, and completed it. I went through the TypeScript handbook and most of the Github wiki pages. But nevertheless, I’m merely acknowledgeable. If there is any TypeScript experts reading this, feel free to point out my errors via commenting.

In this blog post, we compare the language designs of TypeScript and Haxe in a few areas in different levels. On the surface, we look at the two syntaxes, then discuss the underlying differences in semantics. The analysis follows by digging into the type systems and the way the two languages organize and generate code. Note that we compare only the major differences in language design - the comparison is not exhaustive. Particularly this post is missing in-depth discussion on tools (e.g. IDE), third party libraries, and communities.

Fight!

Syntax

TypeScript is designed as a superset of JS. That means, any valid JS code is also valid TypeScript code. This makes porting code between TypeScript and JS very easy, since they share exactly the same basic syntax constructs.

Haxe syntax is also very JS-like. But it is more technically correct to say that it is ECMAScript-like, or similar to ActionScript, since Haxe was historically built as an alternative to ActionScript for authoring Flash swf contents. Anyway, the basic syntax constructs are mostly equals to JS’s. One exception is the missing of classic C-style for-loop, i.e. for (int i = 0 ; i < 10; i++) {}, which is replaced by Iterator based for-loop, i.e. for (i in 0...10) {}.

On top of the JS syntax, TypeScript adds the ability to annotate types to variable, in the form of var str:string;. Haxe shares the same syntax, except all the types are first-letter upper-cased, i.e. var str:String;.

TypeScript has two way to write an Array type. Haxe only has one.

// TypeScript
var list:string[] = ["a", "b", "c"];
var list:Array<string> = ["a", "b", "c"];

// Haxe
var list:Array<String> = ["a", "b", "c"];

Although TypeScript and Haxe basic syntaxes look pretty much the same, but Haxe embodied a powerful functional programming concept that TypeScript/JS doesn’t - the Haxe syntax is expression-oriented, which means most of the constructs are expressions that can be evaluated to values. For things that we have to use a block ({}) in TypeScript/JS, we can use any expression in Haxe:

// Haxe

// function definition is an expression that
// the function body can be any expression, not necessarily {}
function add(a:Float, b:Float) return a + b;

// loops, including for-loops, are expressions that
// the loop body can be any expression, not necessarily {}
for (i in 0...10)
    trace("i is " + i);

// if-else is also an expression that takes expressions
if (isCool)
    trace("yay!");
else
    trace("nay...");

// you should have noticed all the above are expressions that takes expressions
// that means we can treat everything like puzzle pieces
function checkEvenOdd(ints:Array<Int>)
    for (i in ints)
        trace(
            if (i % 2 == 0)
                i + " is even!"
            else
                i + " is odd!"
        );

// Blocks are useless now?
// Nop, a block is a powerful expression too!
// It is evaluated as the last expression inside it.
// Here is an example that use try-catch expression together with block expressions.
var result =
    try {
        var a = computationThatMayThrow();
        finalComputation(a);
    } catch (exception:Dynamic) {
        rollBack();
        defaultValue();
    }

The rule of semicolons is another thing that the Haxe syntax is better than the TypeScript one. TypeScript features automatic semicolon insertion, which means semicolon is optional in a lot of cases. Douglas Crockford wrote it clearly, “semicolon insertion was a huge mistake”. Semicolons in Haxe is not optional, making it impossible to make mistake as follows:

// TypeScript
var add = function() {
  var a = 1, b = 2
  return
    a + b
}
console.log(add()) // undefined, why?

// the equivalent semicolon-inserted version:
var add = function () {
  var a = 1, b = 2;
  return;
    a + b;
}

// Haxe
var add = function() {
    var a = 1, b = 2;
    return
        a + b;
}
trace(add()); // 3

TypeScript and Haxe have similar syntaxes for functions, but there are some minor differences regarding to parameters. E.g. for optional parameter, notice the placement of ?:

// TypeScript
function greet(name?:string):string {
    if (name) {
        return "Hello, " + name;
    } else {
        return "Hello";
    }
}

// Haxe
function greet(?name:String):String {
    if (name != null) { // no implicit conversion to Bool
        return "Hello, " + name;
    } else {
        return "Hello";
    }
}

Rest parameter:

// TypeScript
function buildName(firstName: string, ...restOfName: string[]):string {
    return firstName + " " + restOfName.join(" ");
}

// Haxe does not allow writing function of variable-lengthed parameters.
// But it let us declare such functions when 
// writing extern using the special `haxe.extern.Rest` type.
extern class Namebuilder {
    public function build(first:String, rest:haxe.extern.Rest<String>):String;
}

Another function syntax difference is that TypeScript supports the ES6 fat-arrow function. Haxe does not has any equivalent short-handed syntax for functions. Nicolas Cannasse, the creator of Haxe, refuses to add such syntax, despite of being popularly requested. One major reason is that the Haxe function definition syntax is already pretty compact due to its expression-oriented nature. Moreover, with the help of macros, Haxe libraries (e.g. tink_lang and Slambda) can implement syntaxes similar to, or even shorter than the TypeScript/ES6 one.

// TypeScript
var evens = [1, 2, 3].filter(n => n % 2 == 0);

// Haxe

// built-in anonymous function definition syntax
var evens = [1, 2, 3].filter(function(n) return n % 2 == 0);

// tink_lang
var evens = [1, 2, 3].filter(n => n % 2 == 0);

// Slambda
var evens = [1, 2, 3].filter.fn(_ % 2 == 0);

TypeScript and Haxe also differ in writing the types of function. The one in TypeScript is easy to understand, because it looks very similar to the arrow function notation:

// TypeScript
var add:(a:number, b:number)=>number;

The Haxe one is unfortunately kind of a “wrong” choice, since it suggests there is auto currying or auto partial application, which is not supported by Haxe.

// Haxe
var add:Float->Float->Float; // A function that takes 2 `Float`s and returns a `Float`.
                             // Unlike those functional languages that use such syntax,
                             // it is NOT the same as `Float->(Float->Float)`,
                             // nor equals to `(Float->Float)->Float` in Haxe.

The syntaxes for class/interface definition of TypeScript and Haxe are slightly different:

// TypeScript
interface IGreeter {
    greeting:string;
    greet():string;
}
class Greeter implements IGreeter {
    // fields are public by default
    private hello = "Hello, ";
    greeting:string;
    constructor(message:string) {
        this.greeting = message;
    }
    greet() {
        // use of `this.` is mandatory when accessing fields
        return this.hello + this.greeting;
    }
}

// Haxe
interface IGreeter {
    // fields are public by default in interface def.
    var greeting:String;
    function greet():String;
}
class Greeter implements IGreeter {
    // fields are private by default in class def.
    public var greeting:String;
    var hello = "Hello, ";
    public function new(message:String) {
        greeting = message;
    }
    public function greet() {
        // use of `this.` is optional when accessing fields
        return this.hello + greeting;
    }
}

TypeScript also provides some syntactic sugar, named “parameter properties”, for writing classes. The following two class definitions are semantically the same, but the former is written using “parameter properties”.

// TypeScript

// class definition with "parameter properties"
class Person {
    constructor(public name:string, private secret:string) {

    }
}
// normal class definition
class Person {
    name:string;
    private secret:string;
    constructor(name:string, secret:string) {
        this.name = name;
        this.secret = secret;
    }
}

Haxe does not provides built-in short class syntax. But it can also be emulated quite easily with build macros. The Haxe libraries, dataclass and tink_lang, provide similar functionality with different syntaxes.

The ways TypeScript and Haxe define property get/setters are very different. The TypeScript one is straight forward. The Haxe one is pretty unique.

// TypeScript
class Person {
    private _name:string
    // if it is allowed to be read by the public, define the following
    get name() {
        return this._name;
    }
    // if it is allowed to be set by the public, define the following
    set name(v:string) {
        this._name = v;
    }
}

// Haxe
class Person {
    // property with getter and setter
    // @:isVar auto generates a private `name`
    @:isVar public var name(get, set):String;
    public function get_name() {
        return name;
    }
    public function set_name(v:String):String {
        return name = v;
    }

    // read-only from other classes, but can be set by itself
    public var gender(default, null):String;

    // constant read-only property
    public var type(default, never):String = "Person";

    // set-only property
    public var birthday(null, set):Date;
    function set_birthday(v:Date):Date {
        return birthday = v;
    }

    // property that derived from something
    public var age(get, never):Float;
    function get_age():Float {
        return computeAge(birthday);
    }
}

Overall, on the surface, TypeScript and Haxe are quite similar, with minor differences where one is slightly more verbose than the other, or the opposite. The significant differences are:

Haxe has better expression syntax.
TypeScript has better function type syntax.
TypeScript has more built-in short-hands for writing functions and classes.
Haxe is extensible by the use of macros, which may transform the semantics of specific expressions.

Although the syntaxes are mostly similar, the underlying semantics of the codes in the two languages can be quite different. We will discuss more about the semantic differences of the two languages in the following section.

Semantics

TypeScript and Haxe have different decisions on variable scoping. TypeScript, like JS, offers only function-level scope for var declarations. Haxe however provides block-level scope, which is also offered by most block-structured languages, like C/C++, Java, and C#. The difference is illustrated as follows:

// TypeScript
{
    var a = 1;
}
console.log(a); // ok, because `a` exist outside of a block

// Haxe
{
    var a = 1;
}
trace(a); // error: Unknown identifier : a

Generally, block scope is a better choice for a block-structured language. In fact, the creator of JavaScript, Brendan Eich, admitted that the design decision was made due to a lack of time.

Of course, the ES6 block scoped let declaration is also supported by TypeScript. But it is kind of a pity that TypeScript has to maintain the old scoping strategy of var and goes to support let instead of “fixing” var declaration directly like Haxe…

It is in a similar situation for the resolution of this. TypeScript follows strictly the JS behavior. When this is inside a function/method, it is resolved dynamically. this may not always point to an instance of the enclosing “class”, depended on how the function/method is called. Haxe “fixes” it to use the more natural lexical scoping, and making it always points to an instance of the enclosing “class”. The difference is illustrated as follows:

// TypeScript
class Counter {
    private i = 0;
    buggy(array:Array<any>) {
        array.forEach(function() {
            this.i++; // `this` is not the Counter instance...
        });
        return this.i;
    }
    // one way to fix this is to alias `this` to a local variable
    fixed1(array:Array<any>) {
        var that = this;
        array.forEach(function() {
            that.i++;
        });
        return this.i;
    }
    // another way is to use arrow function, which resolves
    // `this` in the natural way
    fixed2(array:Array<any>) {
        array.forEach(() => {
            this.i++;
        });
        return this.i;
    }
}

var ints = [1, 2, 3];
console.log(new Counter().buggy(ints));  // 0
console.log(new Counter().fixed1(ints)); // 3
console.log(new Counter().fixed2(ints)); // 3

// Haxe
class Counter {
    var i = 0;
    public function new(){}
    public function correct(array:Array<Dynamic>) {
        Lambda.iter(array, function(e) this.i++);
        return this.i;
    }
}
class Test {
    static function main(){
        var ints = [1, 2, 3];
        trace(new Counter().correct(ints)); // 3
    }
}

We can see another reason why Haxe does not need ES6 arrow functions like TypeScript/JS - this inside a function is resolved naturally by default.

Both TypeScript and Haxe have enum types, but they are different things. A enum type in TypeScript is just a finite set of values (integers to be exact). Enum in Haxe is a powerful functional programming construct called generalized algebraic data type (GADT), which is more like a finite set of types (not real types in Haxe, just the concept). We may think of the TypeScript enum can only supports a subset of what the Haxe enum supports. Both TypeScript and Haxe enums are often used with switch, which is also semantically different across the two languages as described next.

The TypeScript switch statement is the good old C-style switch, which is kind of like a fancy group of if-else statements. The Haxe switch expression is in fact yet another functional programming construct called pattern matching. Here are some examples illustrating the use enum and switch in TypeScript and Haxe:

// TypeScript
enum Color {
    Red,
    Green,
    Blue
};

// an Array<Color>
var colors = [Color.Red, Color.Green, Color.Blue];

switch (colors[0]) {
    // every case here is a *value*
    case Color.Red:
        console.log("Red");
        break;
    case Color.Red: // can never be reached, but is fine
        break;
    // missing `case Color.Green`, `case Color.Blue`, and `default`, but fine too
}

// Haxe
enum Color {
    Red;
    Green;
    Blue;
    Rgb(r:Int, g:Int, b:Int); // an enum "constructor" may have arguments
}

class Test {
    static function main() {
        // an Array<Color>
        var colors = [Red, Rgb(0, 0, 0)];

        // switch in Haxe is also an expression
        // note that there is NO fall-through, i.e. no `break` is needed
        var redValue = switch (colors[0]) {
            // every case here is a *pattern*, not a *value*
            // there will be compilation errors if there are missing or redundant cases
            case Red: 255;
            case Rgb(r, _, _): r;
            default: 0;
        }
        trace(redValue); // 255
    }
}

We can see that the Haxe switch is more powerful that it can match against and “extract” the arguments (or even fields or array items) of the given object. It also performs exhaustiveness and useless pattern check to ensure there is no missing or redundant cases.

TypeScript does not have pattern matching, yet, but it supports the ES6 destructuring declarations and assignments, which can be used for some of the pattern-matching use cases:

// TypeScript
var point = [100, 0, 0];
var [x, y, z] = point;
console.log(x); // 100
console.log(y); // 0
console.log(z); // 0

// Haxe
var point = [100, 0, 0];
switch(point) {
    case [x, y, z]:
        trace(x); // 100
        trace(y); // 0
        trace(z); // 0
    default:
        throw "It is not in the form of [x, y, z]";
}

By now we have discovered quite a few cases where TypeScript and Haxe give different semantics to the same syntax. We can see that TypeScript sticks to the JS standards as much as possible. Existing JS developers would pick up TypeScript without any fiction. Haxe however takes the other approach, “fixes” the JS design flaws and follows the behaviors used by other popular languages. As a result, developers with background other than JS would appreciate and less-likely to be surprised by the Haxe semantics. Moreover, Haxe also fuses functional programming concepts and JS-like syntax in a natural way.

Type system

TypeScript and Haxe feature similar basic types. TypeScript has boolean, number, string, Array, any, and void. Haxe has all of the TypeScript equivalents, Bool, Float, String, Array, Dynamic, and Void. In Haxe, there is also Int that does not exist in TypeScript. As previously mentioned, we have function types in both languages too.

We can create custom types in both TypeScript and Haxe. In TypeScript, we may use class/interface and enum. In Haxe, we have class/interface, enum, typedef, and abstract.

TypeScript uses a structural type system (duck-typing), in which all types can be expressed as interfaces. Types are compatible to each other as long as they have the same fields. We can assign anonymous object to a variable typed as a class instance:

// TypeScript
class Point {
    x:number;
    y:number;
}
var pt:Point = { x:0, y:0 } // ok

We can even implements, not only extends, a class:

// TypeScript
class Greeter {
    greet():string {
        return "hi";
    }
}
class ChineseGreeter implements Greeter {
    greet():string {
        return "你好！";
    }
}

The type system of Haxe is stronger. Duck-typing is only allowed when assigning to variables of structure types:

// Haxe

class Point {
    public var x:Float;
    public var y:Float;
    public function new():Void {}
}

typedef PointStruct = {
    x:Float,
    y:Float
}

class Test {
    static function main():Void {
        // A Point instance has the same structure as PointStruct.
        var p:PointStruct = new Point(); // ok

        // An anonymous object is typed as a structure.
        // It is not a Point instance even if they have the same structure.
        var p:Point = { x: 0, y: 0}; // error: { y : Int, x : Int } should be Point
    }
}

Unlike TypeScript/JS, there is no implicit conversion from most types to Bool/Float/Int in Haxe, except when using abstract. Some examples:

// TypeScript

/*
    Common uses of implicit conversion
*/

var inputStr = "";
if (inputStr) { // implicit conversion from string to bool
    // process
} else {
    alert("inputStr should not be empty");
}

var inputNum = 0;
if (inputNum) { // implicit conversion from number to bool
    // process
} else {
    alert("inputNum should be > 0");
}

/*
    Crazy stuffs
*/

// http://wtfjs.com/2014/01/11/multiplying-arrays-and-objects
[4] * [4] // 16
[] * [] // 0
[] * {} // NaN
[4, 4] * [4, 4] // NaN
({} * {}) // NaN

// Haxe

/*
    Be explicit most of the times.
*/

var inputStr = "";
if (inputStr == "") { // be explicit
    // process
} else {
    js.Browser.alert("inputStr should not be empty");
}

var inputNum = 0;
if (inputNum > 0) { // be explicit
    // process
} else {
    js.Browser.alert("inputNum should be > 0");
}

/*
    Compilation error when doing crazy stuffs
*/
[4] * [4]; // error: Array<Int> should be Int

Both TypeScript and Haxe offer compile-time type inference, but the Haxe one is slightly more sophisticated in the sense that it is able to infer type from the first use of the variable instead of just the initial value. It is illustrated as follows:

// TypeScript
var str;     // var without init value nor type annotation is typed as `any`
str = "abc"; // we can assign string to it
str = 123;   // we can also assign number to it later, since `str` is `any`

// Haxe
var str;     // var without init value nor type annotation is typed as `Unknown`
str = "abc"; // once we assign a String to it, `str` is typed as `String`
str = 123;   // error: Int should be String

Haxe heavily relies on static typing, so it tries to be strict as much as possible. It does not simply type a variable as Dynamic (the Haxe equivalent of any in TypeScript) when there is no init value nor type annotation. Instead, it will type the variable as Unknown (a monomorph), and will try to figure out the type in later usage of the variable. To declare a Dynamic variable, users have to explicitly state it (var thing:Dynamic;). Similarly, Haxe by default does not allow Array of mixed types, which is allowed by TypeScript:

// TypeScript
var array = ["abc", 123]; // the type of array is (string | number)[]

// Haxe

var array = ["abc", 123]; // error: Arrays of mixed types are 
                          // only allowed if the type is forced to Array<Dynamic>

var array:Array<Dynamic> = ["abc", 123]; // ok

// to get a union type like TypeScript's, use haxe.extern.EitherType
var array:Array<haxe.extern.EitherType<String, Int>> = ["abc", 123]; // ok

Static typing of TypeScript is made optional, such that all valid JS code is valid TypeScript code. TypeScript even allows compilation when there is a type error when using a properly typed variable:

// TypeScript
var author = {first:"Andy", last:"Li"};
author.birthyear = 1988; // error: Property 'birthyear' does not exist on type '{ first: string; last: string; }'.

Although there is an error above, the TypeScript compiler still outputs JS as follows:

// JavaScript
var author = { first: "Andy", last: "Li" };
author.birthyear = 1988;

The same code above in Haxe will cause an compilation error and no output is produced. But note that we can force the Haxe compiler to ignore the type error:

// Haxe
var author = { first: "Andy", last: "Li" };
untyped author.birthyear = 1988; // prefix with `untyped`

Unlike Haxe, TypeScript has a few unsound cases. For instance, function arguments should be contravariant, but they are bivariant in TypeScript.

We can see that, Haxe is even more “typed” (has strict and sound typing) than TypeScript. On the one hand, TypeScript being forgiving on typing may be handy when we know what we’re doing. On the other hand, I’m not sure if it is good because it will somehow encourage people to ignore type errors instead of typing the program properly. To be clear, optional typing is nice, but when type annotation exists and there is clearly a typing issue, the compiler should complain and stop. One historical example of being error-forgiving caused issues in the long term is Internet Explorer. IE was so forgiving that people didn’t care about syntax errors nor web standards… Well, error-forgiveness is good for end users, but bad for developers. Maybe it has become a Microsoft tradition - to encourage bad coding practice via forgiveness :(

Code organization and generation

TypeScript and Haxe employ different strategies for code organization and generation.

For code organization, TypeScript is as flexible as JS. A .ts file may contain statements as well as functions and class definitions. We can optionally use the module systems, which there are three of them, internal, external, and the ES6 modules. Internal modules are similar to namespaces. External modules are used when we want to output files in either the node.js (CommonJS) way or the require.js (AMD) way. The ES6 modules are effectively the external modules with a different syntax. All of the module systems are able to export variables, functions, and types, and can be mixed and matched at will.

Haxe follows the more restrictive Java approach for code organization. It does not allow expressions (including functions) to be place in the top-level. Instead, Haxe expressions are held by types (mainly classes) contained in a .hx file (i.e. a module). Each module may contain more than one type. The main entry point of a Haxe program is a static main function of a class specified by the user.

For file organization, TypeScript allows the .ts files to be placed in anywhere. We may instruct the TypeScript compiler to generate one .js file for each .ts file, or to concatenate multiple .ts output into a single .js file. To reference other types declared in another .ts file, insert a special comment /// <<reference path="path/to/file.ts" /> or use import and require, depending on what module system we’re using.

Haxe again follows the Java approach for file organization. It enforces a folder structure according to the use of packages/modules. e.g. If there is a module, net.onthewings.HelloWorld, it must be located in a file named HelloWorld.hx in the folder net/onthewings/ within one of the class paths searched by the Haxe compiler. The Haxe compiler compiles all the source files into a single .js file. Referencing other modules is done by using import.

Other than the different handling of “modules”, different levels of optimization can be found in the outputs of TypeScript and Haxe. TypeScript does not do much fancy optimization when transpiling TypeScript code to JS code. It is mostly a one to one mapping, except it has to generate code to implement features that are missing in traditional JS (e.g. arrow function is compiled to normal function when targeting ES3/5). Haxe, however, is able to perform a number of advanced optimizations. For example, dead-code-elimination removes unused code to reduce output size and improve runtime performance. Inlining directly inserts user-specified function bodies in place of calls to them, effectively reduces number of function calls for runtime performance improvement. The experimental static analyzer available in Haxe 3.2 is able to perform constant propagation and expression-level dead-code-elimination.

TypeScript and Haxe continues to follow their design strategies consistently in the area of code organization and generation. TypeScript wants to be as flexible as and similar to JS. It supports all the JS code organization methods. It maintains a trivial mapping between source code and generated JS code. Haxe, however, borrows the concepts of other popular compiled languages. It enforce a single sensible source directory structure and generates only a single JS file by default. It is able to perform various optimizations on the program.

Conclusion

TypeScript and Haxe are similar in many aspects. They are both statically typed languages that are able to compile to JS. They have similar JS-like syntax and features.

However, at the core, TypeScript and Haxe have different design philosophies. TypeScript is a superset of JS. It means it cannot modify the existing JS syntax and semantics. It adds a static type system and some new constructs (e.g. “proper” class/interface). It is not interested in optimizing the program in any way. Haxe looks like JS, but is more similar to other popular compiled languages like Java/C# regarding to semantics, the use of types, code organization, and optimizations. It also brings in a lot of advanced functional programming concepts.

Which is the better compile-to-JS language? It depends. Existing JS developers will favor TypeScript as they are more similar in many ways. They can utilize their existing skills immediately. Non-JS developers with backgrounds like Java/C# or even from the functional programming world will appreciate Haxe more since it fixes a lot of weirdness of JS.

Personally I would of course recommend Haxe over TypeScript. Not only because that is the language I use, but also because outside of the compile-to-JS context, TypeScript is nothing… But Haxe is able to target not only JS, but also Java, C#, C++, PHP, Python, Flash (AS3/swf), and Neko ;)

Including External JS Lib in Haxe Output

2015-07-22T00:00:00+08:00

One missing feature of the new Haxe std jQuery extern from the old one is the ability to embed jQuery directly into the Haxe JS output. Although often it is better to use a CDN, which may improve page loading performance by allowing parallel downloads and increasing the chance of cache-hits (as well as other reasons), sometimes it is just handy if the Haxe compiler could embed jQuery into the JS output such that we don’t have to add another line of <script> tag in our HTML file.

Turn out I was not able to port that feature to the new extern that easily. Let’s take a look at how the old extern did it. The magic lies within the __init__ method, which has a macro function call as follows:

haxe.macro.Compiler.includeFile("js/jquery-latest.min.js");

So, yeah, if you didn’t know, now you have learned that we have a macro named includeFile to include any external file into the JS output. The function was implemented in pure Haxe, and was quite simple, so lets go through its source code together:

public static macro function includeFile( fileName : Expr ) {
    /*
        Extract the input, `fileName`, as a String.
    */
    var str = switch( fileName.expr ) {
    case EConst(c):
        switch( c ) {
        case CString(str): str;
        default: null;
        }
    default: null;
    }
    if( str == null ) Context.error("Should be a constant string", fileName.pos);

    /*
        Load the file content into variable `f`.
    */
    var f = try sys.io.File.getContent(Context.resolvePath(str)) catch( e : Dynamic ) Context.error(Std.string(e), fileName.pos);

    /*
        Return an expression, which is in the form of `untyped __js__("file_content")`.
        Note that it can be written in a simpler way using expression reification:
        ```
        return macro untyped __js__($v{f});
        ```
    */
    var p = Context.currentPos();
    return { expr : EUntyped( { expr : ECall( { expr : EConst(CIdent("__js__")), pos : p }, [ { expr : EConst(CString(f)), pos : p } ]), pos : p } ), pos : p };
}

In short, the macro function loads the file content and injects it directly using __js__. As a function to inject simple JS code, it is simple and elegant. However it is not really suitable for including JS libs due to how Haxe generates JS code, which looks like this:

// Generated by Haxe
(function (console) { "use strict";
/*
    1. classes generation, e.g. class inheritance, methods etc. 
*/
/*
    2. __init__ of all classes
    jQuery will be embeded here
*/
/*
    3. static variables generation
*/
Test.main();
})(typeof console != "undefined" ? console : {log:function(){}});

Firstly, we notice that Haxe wraps everything in a closure by default. It avoids global variables being exposed to the outside world. Inside the closure, we enable strict mode, which improves performance and eliminates JS silent errors by changing them to throw errors. It is good for Haxe since its JS output is compatible with strict mode. But the JS lib we want to include may not. In fact, recent versions of jQuery are incompatible with strict mode. The out-dated jQuery version 1.6.4, which is included by the old extern, just happens to be strict mode compatible, ironically. That’s why this problem didn’t surface until I try to update jQuery.

Secondly, classes generation comes before the __init__s, which is the place where JS libs are embedded. It means that Haxe generated classes cannot inherit from classes of the external JS libs. It is not a problem for jQuery, since we do not often inherit from it, but it could be a problem if we want to use a JS lib that is structured using a more OOP approach.

To solve these issues, we have to find a way to place the external files before everything generated by Haxe, including the closure. And since it depends on how Haxe JS code generation works, we have to modify the compiler source. The good news is, I’ve just done that so you don’t have to :)

I’ve added a new optional argument to haxe.macro.Compiler.includeFile, named position, for us to specify the position of where the injection takes place. There is three possible values, Top (default), Closure, and Inline. Inline is the old behavior, which inject the file content at the call site of includeFile. The two new positions are illustrated as follows:

// Generated by Haxe
/*
    new include position: `Top`
*/
(function (console) { "use strict";
/*
    new include position: `Closure`
*/
/*
    1. classes generation, e.g. class inheritance, methods etc. 
*/
/*
    2. __init__ of all classes
*/
/*
    3. static variables generation
*/
Test.main();
})(typeof console != "undefined" ? console : {log:function(){}});

Problem solved! The default position, Top, is outside of the closure, not in strict mode, and it is before everything else.

As a bonus, we can now call includeFile within a hxml file, like so:

-js Main
-main Main.js
--macro includeFile('path/to/dependencies.js')

It could be useful if you use npm or bower to manage JS dependencies. We can concatenate all the dependencies into a single file and pass it to includeFile. I’m still experimenting with this approach. So, more on that later.

New jQuery Extern arrived at Haxe Standard Library

2015-07-02T00:00:00+08:00

jQuery has been ~~one of~~ the most popular JavaScript library in the world. To help existing JS developers switch to Haxe for a modern language with accurate static typing, a complete and up-to-date jQuery extern is necessary.

As I’ve mentioned in the previous post, I’m working on updating the jQuery extern in the Haxe standard library. Today, I’ve just committed the initial work to the Haxe repo. The new extern is generated by the same script that powers jQueryExtern. The resulting extern matches perfectly with the latest jQuery API (1.11.3 / 2.1.4). And since it is generated, we can update the extern very easily when there is a new jQuery release (I used less than an hour for each of the previous updates to jQueryExtern).

The differences between the old and the new externs are detailed at Github issue #4377, where you may report any migration issue or provide any feedback. Go ahead and get a development build of Haxe and play with the new extern!

I’m Now Working for the Haxe Foundation!

2015-06-23T00:00:00+08:00

Yeah, I’ve completed my PhD and I’m now working for the Haxe Foundation!

My 4-year-long PhD has come to an end

I started my PhD in the School of Creative Media (SCM), City University of Hong Kong right after I’ve completed my Bachelor degree there. I entered the field of mobile interface design and computer graphics with the help of my supervisor, Dr. Hongbo Fu. Two of my major research projects are BezelCursor and EZ-Sketching. The former is a screen cursor that helps people to use only one hand to operate a large mobile device, in which part of the touchscreen may not be covered by the limited thumb reach area. The latter is a image tracing system that automatic refines drawing strokes based on the features of the underlying image. You may take a look at my thesis if you’re interested.

Doing a PhD was very challenging to me. Yes, I had already learned some regular computer science stuffs during my Bachelor degree study, but I was not really ready to read research papers, to write equations with weird symbols, and to properly analyze experiment results with statistical procedures. With my PhD completed now, I can say that mastering those research skills is super useful and rewarding. There are a lot of interesting research papers being presented in conferences which I don’t think I would ever pay attention to if I were not a researcher.

However, although doing research is cool, it is still a bit different to what I enjoy most - coding. Computer science researchers do not really spend all their time on coding, not even on doing “real” research works. They have to spend a large portion of their time on publishing papers. Although the papers are of course valuable to the public, the whole academic publishing process is somewhat frustrating to me. The top academic conferences, like SIGGRAPH, often have very low acceptance rates (~20%). Papers have to be really “exciting” and “ground-breaking” in order to be published there. But you know, most research may not be such interesting or such a breakthrough, yet can still be valuable in many ways. For example, publishing a paper on a new algorithm that can solve complex problems may be cool, but providing and maintaining a solid open source implementation is equally (if not more) important. I’ve seen a lot of researchers keep working on new stuffs (in order to keep publishing papers), but spend little effort in maintaining their software/code, reducing the chance of people using their research outputs.

Working for the Haxe Foundation

As mentioned above, I value maintaining open source software very much, so it is very cool for me to work on Haxe in full-time. :)

I have been using Haxe for 5 years. I have published a few libraries, like jQueryExtern and hxSerial. At some point I’ve also published hxOpenFrameworks and used it to create generative graphics. At that time Haxe wasn’t very stable and the C++ target was still young. I decided to contribute directly to the Haxe repository since it is definitely the most important part of the Haxe ecosystem. The Haxe compiler (and its standard library) has to be robust and stable such that third party libraries and frameworks, like hxOpenFrameworks and OpenFL, can be built on top of it. In my free time during my PhD study, I introduced continuous integration (CI) to the Haxe repositories. It is satisfying to see the Haxe unit tests are now being run for all the 9 targets on both Mac/Linux, Windows, as well as browsers.

Since I had defended my PhD thesis, I was available to attend WWX 2015, in which I presented CI to the Haxe community (my presentation slides). Using TravisCI and AppVeyor is so easy that I really want to see every Haxe projects on Github to use them. During the conference I talked with Nicolas about working for the Haxe Foundation, and he was happy about it! So, yes. I am now financially supported by the Haxe Foundation to maintain and develop for Haxe in full-time!

The very first task that I’ve just started to work on is to upgrade jQuery support in the Haxe standard library. The build-in support was added back in 2011. It has never been a complete extern. A lot of APIs are missing, including parseXML, some overloaded versions of bind/unbind, on etc. Also, it has been staying at jQuery 1.6.4 for a long time (latest version as of writing is 1.11.3). My jQueryExtern library has been complete and up-to-date, which is even being mentioned in the haxe.org website. I’m now modifying jQueryExtern’s generation script to generate a new set of externs for the standard library, maximizing compatibility between old and new version of the externs. jQueryExtern itself will be maintained as a drop-in replacement of the new standard library extern, to provide addition functionalities. Initial implementation will be completed soon and I will ask for your feedback once it is ready.

For every month, I will work on a specific task, like the jQuery support upgrade. I will also work on other haxe-related things concurrently, e.g. updating the Haxe Chocolatey package, fixing CI issues, writing docs, and try to wrap my head around OCaml and start fixing compiler bugs. I will also speak at local and nearby conferences and meet-ups, to introduce Haxe to other developers. For instance, I am going to speak at the Hong Kong Open Source Conference 2015 this week. I will keep posting a blog post weekly, to publicly report the progress. So stay turned if you’re interested in what I’m working for Haxe.