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:
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.
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:
- 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.
- How do you even grade this? This is really a tough one. You could definitely ask the students to evaluate one another.
- How do you come up with compelling projects that yield something presentable within a few weeks but can continue to evolve for years.
- 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.
- 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:
- managed - there is a lot to be said for learning about managing your memory, but
- statically typed - I don’t think I have to explain that
- 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.