Haxe as a first job programming language?

Job Postings
1

I’m a lecturer in a university. I’m thinking about using Haxe for my courses.
The main question if this knowledge will be valuable for the students after their graduate?

When I think about employment as a Haxe programmer. It seems that employers want mature ones with years
of experience who can teach others in the company to the cross-platform programming philosophy.

Does anybody need juniors or inters who know Haxe? Especially, remote interns or workers?
If yes what knowledge and experience should such juniors have besides Haxe?

1 Like
2

Aim for a good measure of timelessness

Students should still go to university to learn stuff that they won’t learn in an internship. For example, Lisp (Scheme or Clojure) - regardless of how exotic it is - would be a great addition to a CS curriculum. To this day, SICP is one of the best introductory courses out there. You can show it to people with 20 years of experience and they still find it insightful. University creates a space to sharpen your mind and fill it with timeless knowledge in a way that won’t be possible on your job.

Is Haxe a tool that allows for this? It depends on what you teach. The cross platform aspect of Haxe is neither unique these days, nor is it suited for university. There’s a dozen of platforms you can target and each come with their very own idiosyncrasies. If you try to teach all of them, your students will have learned nothing. Pick one and teach about it. My suggestion is frontend JS (perhaps fullstack, if you can make the time) -
they will pick up a highly sought after skill. Teach about the concrete platform in conjunction with FP, OOP, macros, enums. Stuff that shapes your ability to formulate elegant solutions to challenging problems.

Education versus Training

This difference is something to be aware of. Education tells people about how something is done. Training lets people do something in a non-critical environment, with supervision, guidance and feedback.

Some universities educate their students about Java or some other thing that they think employers will want in candidates. It doesn’t matter. What employers really want are trained developers. Very few students come out of university with much training - even as far as just software engineering is concerned, let alone software development at large.

Just to make this clear: If you learn how to be a carpenter, then by the time you finish your apprenticeship, you will have worked on actual products that will be sold to actual customers. Studying CS is usually nothing like that.

If you want to prepare your students for software development, you should try to expose them to at least some aspects of how it’s done in the real world.

Let me present a crazy idea to you, in hopes that you can salvage something useful to you:

The “perfect” software development curriculum

After you have some basic programming skills, you start working on two projects:

  1. A fresh project. Something with a small initial scope, that can still be fun. You will work on this thing within a small team for the whole time that you study. If you hack stuff together, you will suffer. You will strive to reduce that suffering. You will learn about team work and code reviews and all that. About version control and issue tracking. As you learn more about different programming techniques, you will start refactoring. As you break things while refactoring, you will learn about the usefulness of tests to guard you against regressions. As you will get used to writing tests, you’ll notice that writing them before the code can actually be a nice thing (it’s not for me, but some people swear it’s awesome, so why not expose your students to a chance to have the same revelation).

    Important: there must be some mechanism by which requirements evolve over time. That’s what software development is like. It’s easy with well factored code and a nightmare otherwise. You cannot teach this with typical homework assignments, where the problem is well defined and the solution is. That’s not how it works in the real world.

  2. An existing one. Because in all likelihood, as a junior or intern, you will join some team that will already work in some specific way and will carry around technical debt and what not. Assuming the project is in not too bad of a shape, you can see things that work well. A test suite, a CI, documentation. All that. Somebody else’s fresh project will have turned into this thing. There will be “senior” students who have been with the project for long. They can already learn how to mentor juniors, how to make onboarding easy and the code base approachable. All that.

Now, why do this in a university at all? Well, the difference is, that on the job you have hard time constraints, which result in missing tests not being written, badly needed refactoring being skipped etc. You can execute things well.

(work on the fresh project should probably start one semester later than work on the existing project).

There are many problems with this of course:

  1. How do you convince your faculty to follow such a crazy plan? It’s not like everyone has to be part of it. But enough of the curriculum must be dedicated to this. Working on a project for 2h a week will not get you anywhere.
  2. How do you even grade this? This is really a tough one. You could definitely ask the students to evaluate one another.
  3. How do you come up with compelling projects that yield something presentable within a few weeks but can continue to evolve for years.
  4. To what degree will you allow students to switch between projects? Allowing students to abandon a project could be a good thing, so long as the students can give good reasons.
  5. How do you not make life miserable for the students who just want to be told what to do and get a diploma so they can find a decently paid cosy job with computers?

But solving these is well worth the effort: your students will certainly be ready for the job - some probably even above junior level. Chances are also good that some nice open source code comes out of this. You can send your employers a GitHub portfolio, that shows that you have years of experience of working on a long running project. They can literally look at your code.

The choice of language will then become quite irrelevant, but I think it should be:

  1. managed - there is a lot to be said for learning about managing your memory, but
  2. statically typed - I don’t think I have to explain that
  3. multi-paradigm - you want to allow the students to explore many different techniques in the same project and to see for which problems they are suited and for which ones they aren’t

Haxe ticks all the boxes. So do other languages. Pick something that you know really well, so you can focus on teaching things that transcend language barriers.

9 Likes
3

Juraj, thank you very much for your ideas about the education process. I totally agree with you!

What about a case if a graduate student / a first year developer likes Haxe ecosystem and wants to start working in this area? Is there any possibility to start other than being an indie dev?

4

Sorry, I had forgotten about this. So to answer you question:

For one, there are a bunch of companies hiring Haxe developers, but chances are this will involve relocation.

Personally, I started using Haxe as a freelancer, subcontracted by various web agencies. They usually have projects that are small and short lived enough that they don’t necessarily care for the tech used, so long as you can deliver and iterate fast.

My first projects were haxe/flash, where it didn’t make that much of a difference. One would trade quite some interoperability with Flex and Flash CS for a bit of extra punch Haxe would provide (this was still Haxe 2 at the time).

But as the mobile web started to rise (and as a result flash started to decline), I moved to haxe/php, which went really well. Normal web agency projects would often turn into a disaster as clients tend to make quite a few last minute change requests and the copy pasta you would usually get from PHP devs at the time was not made to withstand this, while a Haxe code base handled it like a breeze.

Later I started taking on haxe/js projects almost exclusively (front and back end). Of course in all projects, the proposition to use Haxe is met with some degree of resistance. From my experience, this resistance cannot be broken by iterating Haxe’s features and advantages and what not. A lot of people have interest in using Haxe try to convince their clients, employers and team mates in this manner, but cannot get through. The only way to do it, is to actually tangibly show how and why Haxe is better. This requires a firm understand of both the language and the target platform. If you can teach your students that, I think their chances are good :slight_smile:

4 Likes
5

The problem I have met so far is that most programmer around me doesn’t really care about robustness but only want to get the job done right away.
They might use TypeScript, because all the extern definitions are out there already. But with Haxe most likely you have to DIY.
They don’t care about macro, as reflections could already do the job.

And I agree with Juraj’s crazy teaching plan. University shouldn’t really just output programmers but software architects which has a high-level of view of the whole problem, while programmers usually just focus on solving tasks right in front of them.

6

This is actually an opportunity. When a project starts, TypeScript devs will take the better part of a day to even configure their build process and pick their dependencies. In that time you can haxelib install coconut.vdom and actually build a POC that speaks for itself.

In the last agency that I convinced to use Haxe, I put together over a weekend what they had planned for the first 6 weeks (and that was pre-coconut, I might add). But to be able to got at that speed, you need a firm grip not only of haxe, but of HTML and CSS (ideally an expressive preprocessor).

As you’ve said it yourself, there’s no convincing people with language features (unless they are easy to present in a truly impressive way). You can however make a strong point when actually showing the emergent effect of putting these features together: a workflow that delivers at a breath taking pace.

3 Likes
7

OK, Juraj. Now, you’ve got a compelling story to put together. How about a video of getting a reasonably useful web page up and running in a couple of hours? Is that doable? If so, Phil and you should get it done and published on YouTube and the Haxe web site’s main page.

I think that some compelling demos can really turn some heads and make a real impression on the market.

-Eric

2 Likes
8

How about a video of getting a reasonably useful web page up and running in a couple of hours? Is that doable?

The challenge of making a useful web page is not a technical, but a human one. What is your message? Who is your audience? How are you going to guide them? Which kind of visual aesthetic is in alignment with the feeling that you’re trying to evoke?

Once you have those things figured out, done the actual writing and the design you can probably get it online in a couple of hours, although you’ll spend most of them fiddling with CSS. At which point a static generator might be just fine.

9

You are absolutely right. But what we need here is the technical demonstration of how easy it is to build a site. :slight_smile: Content and design are not the realm of Haxe; speed of implementation is what will sway developers – and that is our audience.

Think about how and why Ruby on Rails became popular overnight: All at once, non-database developers could get a database app written in no time. That’s the type of thing that we need Haxe to do. And, if we can show Haxe as a “full stack” solution (which it is), we can hit the buzzwords that startup CEOs are looking for, and simultaneously lift the value of Haxe developers in the marketplace.

I’m thinking about this in terms of Haxe being a “big fuzzy unknown” to web developers. We need some concrete examples that turn that unknown into “That was easy!”

2 Likes
10

And, now I realize that we (I) have taken this topic off-point.