Epoch, as a project, is going to shift directions.
Up until now my big focus has been on getting the parallel processing side of things up to speed. All of the hype and most of the prose on the project web site has, until this point, centered around the idea of a language that can do really amazing things with automatically running code on the most appropriate level of hardware.
I now consider that aspect of the language to be "done," not in the sense that it is complete and needs no further work, but in the sense that I've accomplished what I set out to do, which is to build a proof-of-concept that indicates that my ideas of hint-based execution relocation are sound and can be used for real computational purposes. Yes, the demo is a trivial vector addition, but the cross-compiler is rich enough to permit just about anything you could want to cram onto a GPU (at least via CUDA). If I took the time to wire up some of CUDA's built-in library functions, it'd be a very, very solid platform.
I have always presented Epoch as a language whose time has not yet come. Even at the very beginning, when the seeds of the Foo Language started to sprout here in my journal, I knew that I was working on a problem that hasn't actually become a problem yet. My original goal was to have a solution ready, so that when the problem truly started causing issues for real-world development, Epoch would be there as a natural and easy choice for transitioning into a new development paradigm.
The problem that originally inspired Epoch's creation was, to put it bluntly, that C++ sucks for writing large-scale software. Embedded scripting languages are the most visible symptom of this issue. DSLs abound nowadays, and rightly so - but the infrastructure on which domain-specific systems are built is shaky, to say the least.
One of the main reasons I enjoy GDC is getting a sort of pulse of the industry and how people feel about our toolkits. There seems to be a lot of consensus that C++ is in fact a horrid language, and most people who have reached that conclusion are actively casting about for something more suitable. One of the big concepts that sparked Epoch in the beginning was doing a language that inherently invited programmers to build DSLs; and the single most oft-repeated wish I heard at GDC this year was for a language that could do exactly that.
Programmers are ready for a better way to work. The climate still isn't quite perfect for a mass language switch-over, but that's fine; it'll take some time to posture Epoch so that it is ready to step into that gap once it opens.
The way I see it, Epoch needs three things now, roughly in order of how I will work on them:
- A truly rich meta-programming system for building and working with DSLs within the context of the language itself
- A proper object model for improving the language's domain representation capabilities
- A rich set of tools for doing real-world development in Epoch
My goal at this point is to reimplement the existing Epoch language in terms of itself, using metaprogramming features. I've already started redefining the grammar and retooling the parser to work on this principle; it may affect the way that syntax looks, but I'm more than willing to live with that. Once Epoch is rebuilt, I will have the metaprogramming tools at hand to build the object model precisely the way I want to (which I'm starting to get really excited about - stay tuned for details on how I plan to build object modelling into the language).
Lastly, and possibly most critically, once the domain-modelling stuff is in place, I can start working on building an IDE for the language itself, which will hopefully bring us up to a level where exploring the language is a low-risk venture for newcomers.
So there's the big spiel; I'm still working through whatever nasty infection I picked up in my travels, so don't expect much out of me for the next couple of days. (But yes, I am still working on GDC coverage and will start getting that posted ASAP.)
On the C++ note, I used to like it more than I do today, even though I've always had a "use-only-the-language-features-I-need-for-the-solution" philosophy. After being in close contact to bad C++ code for some years, I've been enjoying the blissful programming experience of pure ANSI C for my solutions.
For a down-to-earth example, (more) generic programming in pure C uses void pointers and function pointers abound, but that's cool, because it's about all the language offers. If you want to do it in C++, there are better ways than void*'s and such, _but_ there's a can of worms waiting around the corner. There are cans and worms in C, but they can fit in my head all at once; if you can do that with C++, pray tell!
I'm rambling. Back to topic...
I've recently read some posts from Greg Pfister's The Perils of Parallel, including one on parallel languages (it's a series of 3 posts, actually). This comes to mind when I think about your work (from the blog):
So it's good that you do have in mind that an excellent set of tools to accompany Epoch is an absolute must for good adoption.