Another programming language? Really?

The world is a glut of programming languages these days. Every year a new one comes up...and (despite marketing assurances) they're all more or less the same. Clients ask us to use a new one, we spend an hour or two learning it, then we work in it. Or, more commonly, we get things working with a language we prefer, and then port it to the fashionable language when we have the design and implementation complete.

Al is different. It's a language like nothing you have ever seen before.

Al is designed for software architects. It is not easy to get started in. Al requires determining your object/class/component models up front. Al rewards "good design", and severely punishes bad design. Which is a hard thing to get used to, as nobody (not even us!) always starts with good design. Al is built for refactoring, as every complex software project always needs refactoring -- better to do it as a matter of course, rather than wait until your codebase is unmaintainable and requires a year-long refactor project (or full rewrite). Al is strongly typed -- maybe even excessively typed -- and requires you to understand the difference between objects and references (pointers), and know when you want one versus the other. It expects you to understand the machine code into which your high-level code translates -- in other words, it would probably be classified as a "systems" PL, like C/C++ or Rust.

So if the bar is, admittedly, high, the benefits are proportionally great. When code compiles, you've already worked out 90% of the bugs -- and we've often had the experience of compiled Al code working the first time it runs, which is unheard of in programming. (We often joke: when it seems to work the first time, that means something is extremely wrong. And it has always been the case...until Al, when it's only sometimes the case.) Debugging support is built in to the lowest levels of Al: logging, tracing, debugging, profiling, and even process state snapshotting and rewinding. Refactoring is a dream. Componentized development, modules, packages, code sharing and re-use -- again built-in from scratch, all done in a way that makes it easiest for the developer to integrate software components. As much work as possible -- much more than is common than other PLs -- is intentionally pulled in to the compiler. We let the compiler take care of all of the tedious work, so that the developer is able to focus on the difficult work which is the essence of writing successful software.

We have written a complete Al compiler (in Python -- not in Al yet, though that may not be far off). "Complete" in the sense that our compiler does everything, from text parsing to linking to (machine) code generation. Runtime support required for Al executables is next to nothing -- we require no OS support, so system calls, no libc or equivalent. Al code runs on R20s, the new OS we are building from scratch -- and of course runs in the context of modern OS (using a simple C-based loader).

Al is the latest incarnation of a software development process and toolkit that we've been evolving for over 15 years. Historically this has been in the form of meta-tools in support of other languages (C, C++, Java, Python, etc), relying heavily on code generation, internal libraries, and coding style. On each iteration, we learned from previous mistakes, and attempted new techniques to solving problems (with varying degrees of success). Ultimately, Al is the result of this experience and experimentation.

Although we are using it internally, Al is still in relatively early development. The core language feels solid, and now the main thing we need is practice working within it. If you're curious about Al and would like more details, let us know.