Platforms are not languages to me. Languages don’t deal with security, file operations, threads, and so on. Languages are syntaxes people use to develop tools on platforms.
Platforms stack, vaguely. The LAMP stack is a classic example: The server is Linux running Apache, content-specific sub-platforms are developed on top of PHP or Perl for Apache to use, data sub-platforms are developed on top of MySQL for the PHP/Perl code to use, and the machine code programs (the OS included) rely on a hardware platform of some sort or another.
Platforms also target other platforms and hide them away. For instance, a PHP coder hardly cares about the instruction set in use on the machine, ’cause the interpreter takes care of that. It’s easy to write a simple PHP script that doesn’t really care what the hardware, the OS, the server, etc. look like. In this case, PHP itself may be all we’re thinking about. In that case I’d say that PHP is our platform.
The reality today is that platforms and languages are developed symbiotically. Innovative general-purpose platform concepts spawn new languages suited for them, like Erlang. Languages which intend to support multiple platforms just end up defining their own. Most platforms can’t be perfectly translated into each other, so ports of platform-defining languages can only be sparse or imperfect, and when it comes down to it, one’s choice of platform determines one’s language options.
Many programmers, including myself, prefer to choose languages not based on the platforms they target but based on their smoothly adapting syntax as project-specific needs come up. Languages which support extensible syntax, like most lisps, are ideal for this purpose, since they hold an implicit infinity promise that they’ll eventually be every bit as beautiful and convenient as every other language, if people only bother to develop the necessary syntax extensions.
But customizable languages fall short today. People are used to developing programs that target just one platform—the runtime of the language they’re writing in—and that makes customizable languages only as flexible as the one runtime they’re limited to.
For a language to have an inflexible runtime is important for code reuse, but if we’re going to have a convenience-and-aesthetics language that’s capable of continuing to build momentum over the next, say, 100 years (Arc’s shtick), we need a language that will target 100 years of platforms we haven’t invented yet. Therefore, the platform the language code runs in and the platform it targets (usually) won’t be the same.
Instead, the language needs to encourage a development process that’s like writing a compiler or build script, where the code produces project artifacts like binaries and other-language scripts, and those are all that’s deployed.
If we start with a “compiler” that just outputs what it’s told to output, then writing code generators in the language will already be at least as convenient as writing the code manually, so the infinity promise will already fulfilled, albeit unimpressively. Templating languages are a step beyond this even, but flat string concatenation is an ineffective way to go forward. Instead, I believe the customizable language’s core focuses should be on AST manipulation, parsing, dependency resolution, and other compiler duties.
This is the direction I’ve been taking Blade and Penknife, my own programming languages. Platform innovation is well and good, but I believe truly general-purpose languages are nothing if not homes for syntax innovation.