Steering a big ship
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.)