Answering all the big questions about who, what, when, and why.
Please note that this is highly forward-looking; it speaks in present tense, but most of this stuff won't be true until some point in the future.
What is Epoch, exactly?
Epoch is designed to be a full-featured general purpose programming language, similar to C, Lisp, and so on. One of the main targets is high-productivity development, meaning that Epoch supports a host of modern language features that make it highly expressive and powerful.
First and foremost, Epoch is a pragmatic language. We're all about getting work done in the real world. This guides every facet of the language's design, and is our core and most sacred philosophy. Some things may be deemed interesting but not useful enough to be first-class language concepts; but, for the most part, if it helps get stuff done, it's going to be richly supported in the language.
What is Epoch's execution model? Where can I run Epoch code?
Epoch is currently hosted by a virtual machine known as Fugue. The Fugue VM includes a parser front end which reads raw Epoch code, and a serialization system that outputs raw bytecode for the VM itself. The goal is for Fugue to act as a reference implementation of the language, and a bootstrapping system for getting things off the ground.
Once the language gains some momentum, Epoch will be execution model agnostic. Running in a VM/interpreter like Fugue is a possibility, but we'd like to see native code compilation and other such features eventually. More on that later on, though.
In short, there's nothing saying Epoch can't be used as an embedded scripting language, or a full native compiled language, or anything in between. We aim to be as flexible as possible, in keeping with our pragmatic philosophy.
When can I use this mystical language?
Right now.
We are committed to keeping regular updates of the language available. This means that the latest version of the language, with all its capabilities, features, and of course flaws, is always floating around ready to be used. This journal is currently the best place to keep up with the project, so if you're interested in picking up the language, hang around here a lot.
More realistically, we aim to support real-world development as quickly as possible. As of this writing the language is largely just an experimental toy, but with the advent of Release 6 (two releases from now) we intend to support full Win32 development. Of course a large amount of work still needs to go into development of a language library, but real-world work will definitely be possible Very Soon.
I also plan to have a fairly rich version of the language (and a demo game or two) ready in time for GDC 2009. So be sure to attend GDC and get one of my demo CDs from me if you're interested in the project!
What platforms can I use Epoch on?
As many as we can get [wink]
Realistically - Win32 is our primary focus, since Win32 is the biggest client for software at this point in time. However, we intend to write ports of Fugue to run on Linux, BSD, and possibly even Mac OS X at some point in The Distant Future. This is subject to time constraints on the part of the project's authors, of course.
However, in the long term we'd like to see Epoch become generic enough to run on pretty much any platform. Again, more on that in a bit.
Who exactly is this mysterious "we"?
Well, ok, fine, it's just me... for now. But I hope to sucker more people in entice more followers soon enough, and hopefully we'll see a community develop around the language quickly. This is one of the big reasons why pragmatism and real-world applicability are so important - if nobody can use it to get real work done, nobody will join the development community.
So why bother creating a new language anyways? Aren't there enough good languages already?
This is the big issue, and it's something that's been weighing heavily on my brain for quite some time now. I think there are plenty of good languages for current computing paradigms. However, I envision a very large paradigm shift in the near future, and I don't currently see any languages which are suitable for taking advantage of the hardware architectures that will come "next."
Specifically, I'm talking about asymmetric multiprocessing. Currently, we see machines with multiple identical CPU cores, all doing their thing. This is fine in principle, but doesn't scale past a few cores, because eventually there isn't enough stuff going on on the computer to keep all the cores busy.
In short, I envision a change towards many "miniature" CPUs, each of which specializes in certain types of processing. One CPU core might look like a modern CPU, with branch prediction, out of order execution, and so on. Another core might look like a GPU, or even like Cell with its SPU architecture. Generally speaking, we will start to see diversification in the way cores are designed.
Programming for such hardware will be similar to current multithreaded programming, but with key differences. For one thing, it will be particularly important to be able to give "hints" as to which processor code should run on. Some code is well-suited to a modern CPU architecture; other code runs best on a GPU-style massively parallel architecture. Some rare code even runs well on the Cell [wink]
While we are seeing some general support for this kind of thing with language annotations like OpenMP and languages like CUDA, there still isn't a really robust, first-rate language out there with first-class support for asymmetric multiprocessing.
So the intention of Epoch is to provide a language that is both modern and rich, while forward-looking to the next generation of AMP-style hardware that is more or less inevitable.
Concluding Thoughts
That pretty much sums up the important details about Epoch. I need to refine the "elevator pitch" a bit so I can explain the concept of the language briefly to someone new to the concept, but the gist of it is pretty much nailed down. I've had a couple of years to perfect it, after all [grin]
You may send your cash, your soul, and/or any other tribute to me via PM or comment here on my journal.
