• entries
625
1446
• views
1006491

# The Epoch Manifesto

Followers 0

330 views

The Epoch Manifesto

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.

0
Followers 0

Sounds interesting - I'll be looking for more details to see what it can (eventually) do. Do you have any 'big' picture details about the major language features that you want to support?
0

Hey lookin good
But how bout givin us an overview of what you plan to be in the standard/built-in library?

Also is there any example programs up for download that are written in Epoch?
Or any documentation on Fungue's bytecode?

Goodluck
0

Hey lookin good
But how bout givin us an overview of what you plan to be in the standard/built-in library?

Also is there any example programs up for download that are written in Epoch?
Or any documentation on Fungue's bytecode?

Goodluck
0

I'm hesitant to commit to any particular list of features this soon in the language's development, but I'd say it's safe to assume that most high-level modern features will make it. I'd like to at least hit the following, although this is purely speculative at this point:

• Full first-class functions including returning new functions, currying, partial function application

• Closures

• Exceptions

• Tail recursion elimination

• Automatic memoization for specially tagged functions

• Pattern matching

• Rich type constraints system

• Support for automatic type munging to mimic dynamic typing where desired

Plus of course any other niftiness that someone points out [smile]

RE: example programs - there are about a dozen examples packed with the Fugue distribution. Release 4 is currently available here. The bytecode is undocumented at the moment but it's serialized to an assembly-like format, so it's pretty easy to figure out.
0

Can you comment on how the concurrency will compare to Erlang, or languages that emulate the Erlang model such as Scala?
0

My concept at this point is to work heavily with code annotations, and make the parallelism explicit rather than implicitly built into the language design ala Erlang.

For example, I might mark a function as pure which means it isn't allowed to have any side effects, or selfcontained (or some better term) which means it may be implemented with side effects internally, but externally presents a pure functional interface (i.e. no side effects outside the function scope, and inputs always produce the same outputs). This makes it possible to write both imperative and functional code side-by-side.

Similarly, I plan on using code annotations to specify parallelism models. For example, there might be an OpenMP-style code block like the following:

vectorize
{
y = x + 1
z = q + 2
i = i + 2000.0
}

Another big candidate for a block type is thread which would automatically split a thread, execute the code in the block, and then close the thread when the block exits. Threading of course means the introduction of locking and lock-free structures, as well as interlocked variable accesses etc. I haven't decided yet how to mess with all that stuff, so we'll see how that shapes up.

There might be blocks for vectorization, dynamic loop unrolling via JIT compilation, and so on. I haven't really explored all these possibilities yet as I'm still focusing primarily on getting the base language into a development-ready state. Some of those features may end up like inline is in C++ - mostly a compiler hint, which the compiler is free to both ignore and to do on its own as it sees fit.

The other big piece is function annotations. Similar to pure, there will be tags like kernel and vectorizable which indicate code which is suitable for stream-processing cores and GPU-style cores, respectively. I still need to do some planning on how the data flow will work and interact between variously tagged pieces of code, but it should be pretty straightforward as far as the end-user (i.e. programmer) is concerned.

Does that answer your question, or did I totally miss what you're getting at? [smile]
0

## Create an account

Register a new account