In my mind, taking your toy Forth from implemented in C, assembler, or what have you, to metacompiled is transformative. I struggled at first, making a few abortive attempts. But when I finally did it, it was a revelation.
I emailed this to Lee. I guess it can go here too.
---
I have been fortunate to have worked professionally with Forth recently. It was so fun! But I still struggle to point out exactly why I like Forth, and why and how it's different. Your essay is fresh take, which is good.
To me, maybe the most important lessons are.
1. Eschew complexity (sometimes to a fault), and
2. Improve the code by redefining the problem. Look at things from another angle. (I hate to say it, but think out of the box.)
Much of Forth falls out from these principles. E.g. people are quick to point out Forth is a stack based programming language. Which is true enough, but to me it's kind of beside the point. The point is the language does away with local variables (redefine the problem) to lay the ground for a much simpler implementation (eschew complexity).
Yes, there's REPL. But why? Because Forth is (or can be) a programming language, operating system, compiler, and command line rolled into one. Heaps of layers and components done away with.
The list goes on. Once you internalize this, the veil falls from your eyes, and you see how much needless complexity stands in your way in most other languages, operating system, tools, apps, ... it's everywhere.
Because Zork was written on the MIT Dynamic Modeling PDP-10. MDL was an important part of the software ecosystem on that computer, but Lisp wasn't. On the other MIT PDP-10 computers, Maclisp reined.
Was there any particular reason they did that, or was it just a random coincidence (that was the team that wrote it and the hardware they had access to was that particular machine and that particular machine ran MDL, otherwise, it would have been MACLISP)? Was there anything about MDL that helped with writing an adventure game?
Jazelle worked for its target market (or at least, I've never seen anyone claim otherwise).
But its target market wasn't "faster java". Instead Jazelle promised better performance than an interpreter, with lower power draw than an interpreter, but without the memory footprint and complexity of a JIT. It was never meant to be faster than a JIT.
Jazelle made a lot of sense in the early 2000s where dumb phones where running J2ME applets on devices with only 1-4MB of memory, but we quickly moved onto smartphones with 64MB+ of memory, and it just made more sense to use a proper JIT.
---------
JavaStation might as well been vaporware. Sure, the product line existed, but the promised "Super JavaStation" with a "java coprocessor" never arrived, so you were really just paying sun for a standard computer with Java pre-installed.
I briefly worked in a team that implemented a JVM on a mobile OS (before the iPhone) and one of the senior devs said Jazelle was in effect very inefficient because of all the context switching between ARM mode and Jazelle mode.
Turned out a carefully tuned ARM JVM was in practice th best
The JavaStation is what led me to this. They sucked, Java OS sucked, and the whole idea was DOA precisely because they didn't do something like this and instead decided to make a shitty sparc machine for the 5 people that wanted a Java branded thin client
I never understood why AOT never took off for Java. The write once run anywhere quickly faded as an argument, the number of platforms that a software package needs to support is rather small.
Developers pay for tools gladly when the pricing model isn’t based on how much money you’re making.
I’m happy to drop a fixed 200e/mo on Claude but I’d never sign paperwork that required us to track user installs and deliver $0.02 per install to someone
Especially not if those kind of contracts don't survive an acquisition because then your acquisition is most likely dead in the water. The acquirer would have to re-negotiate the license and with a little luck they'd be screwed over because they have nowhere else to go.
That is something that I never understood, that that's even legal. You enter into an agreement (let's call it a contract, because that's how the other side treats it) and then, retroactively they get to pull the rug right out from under you.
I made the 'FOSS all the way' decision somewhere in '96 or so but unfortunately our bookkeeping system and our own software package only worked on Windows (this was an end-user thing) so we had to keep one windows machine around. I was pretty happy when we finally switched it off.
The funny thing is that I wouldn't even know where to start to develop on/for mac or windows, Linux just feels so much more powerful in that sense. Yes, it has some sharp edges but for the most part it is the best thing that could have happened to the world of software development.
I have done native cross-platform projects in https://wxwidgets.org/ and https://quasar.dev/ . Fine for basic interfaces, but static linking on Win64 gets dicey with lgpl libraries etc. YMMV
For iOS targets, one must use a MacOS environment with a non-free Apple developer account.
Personally, I like Apache 2.0, and standard quality of life *nix build tools. Everything Windows runs off a frozen VM backing image KVM COW file now, as even Microsoft can no longer resist the urge to break things. =3
Depends on the use-case, anyone that has seen the commercial host scaling cost of options like MATLAB usually ported to another language. lesson learned...
Commercial licensing is simply a variable cost, and if there is another FOSS option most people will make the right call. Some commercial licenses are just Faustian bargains, that can cost serious money to escape. =3
If we ignore gcj was never production ready, and basically the only good case that Red-Hat sponsored was to compile Eclipse, which was usually slower than
using the JIT anyway.
And that around 2009, most of the team left the project, some went to OpenJDK, others elsewhere, while GCC kept it around because gcj unit tests stressed parts of the GCC that weren't tested by other frontends, until the decision came to remove it completly.
As side note, I expect a similar outcome to gccgo, abandoned since Go added generics support.
Actually you do indirectly, via Windows licenses, Office, Azure, Visual Studio Professional and Ultimate licenses, C# DevKit.
Also you are forgetting AOT first came with NGEN, .NET Native, commercial, and on Mono side, Xamarin had some price points for AOT optimiztions, if I recall correctly.
However this is a moot point, you also don't pay for GraalVM, OpenJ9, or Android.
> I never understood why AOT never took off for Java.
GraalVM native images certainly are being adopted, the creation of native binaries via GraalVM is seamlessly integrated into stacks like Quarkus or Spring Boot. One small example would be kcctl, a CLI client for Kafka Connect (https://github.com/kcctl/kcctl/). I guess it boils down to the question of what constitutes "taking off" for you?
But it's also not that native images are unambiguously superior to running on the JVM. Build times definitely leave to be desired, not all 3rd party libraries can easily be used, not all GCs are supported, the closed world assumption is not always practical, peak performance may also be better with JIT. So the way I see it, AOT compiled apps are seen as a tactical tool by the Java community currently, utilized when their advantages (e.g. fast start-up) matter.
That said, interesting work is happening in OpenJDK's Project Leyden, which aims to move more work to AOT while being less disruptive to the development experience than GraalVM native binaries. Arguably, if you're using CDS, you are using AOT.
It simply defaults to an open world where you could just load a class from any source at any time to subclass something, or straight up apply some transformation to classes as they load via instrumentation. And defaults matter, so AOT compilation is not completely trivial (though it's not too bad either with GraalVM's native image, given that the framework you use (if any) supports it).
Meanwhile most "AOT-first" languages assume a closed-world where everything "that could ever exist" is already known fully.
I'm not sure how much Hotspot can do this, but JIT means you can target different CPUs, taking advantage of specific extensions or CPU quirks. It can also mean better cache performance because you don't need branches to handle different chips, so the branch is gone and the code is smaller.
We did see a recent attempt to do hardware-based memory management again with Vypercore, but they ran out of money.
I think part of the problem with any performance-related microarchitectural innovation is that unless you are one of the big players (i.e. Qualcomm, Apple, Intel, AMD, Nvidia) then you already have a significant performance disadvantage just due to access to process nodes and design manpower. So unless you have an absolutely insane performance trick, it's still not going to make sense to buy your chip.
They have the volume as well, if you do carve out a niche they’ll just add it and roll over you.
That’s held for decades though I think it only really worked when computers where doubling in speed every 12-18 months, for a while they scaled horizontally (more cores) over radical IPC improvements so we might see the rise of proper co-processors again (but nothing stops the successful ones getting put on die, like Strix Point is already heading).
As an Amiga romantic, I’d say we have no illusions about a late-80s Amiga being a good idea if it existed today. But it captured my imagination (and at just the right age) like nothing else.
