The DeRailed Challenge

[kris]

'DeRailed' is a project intended to compete in the space where RoR has 
been successful. We believe an RoR "killer" will do wonders for D as a 
language, in terms of publicity and potential widespread adoption.

To get there we need to surmount some hurdles. This is simply an 
overview, not a detailed analysis:

1) D is a statically compiled language; it doesn't have the late-binding 
support of a language like Ruby or Python. We need to find a way of 
enabling late-binding of code & symbols, in a manner that is seamless to 
a user/developer. DDL is a project targeted at exactly this issue, but 
it's a thorny problem to address. Some help from the compiler itself 
would go a long way to making this a reality (on linux, this currently 
appears to be resolvable).

2) Full reflection at run time is something D lacks. We need this to 
properly enable late-binding to the extent we feel is needed. There's a 
side-project under way right now to address this particular issue.

3) a GUI front end, capable of being generated on the fly, yet 
sufficiently powerful and extensible. We've been investigating various 
existing technologies and approaches.

4) A back-end interface, to the DB. DDBI currently looks like a 
reasonable solution, and there's  work currently under way to make it 
much more useful.

5) A runtime platform, with clustering support. We can leverage various 
tools from the Mango project.

The big question for us right now is this: in what manner might a 
compile-time DSL (or set thereof) make life significantly easier for 
either a user/developer, or for us whilst constructing this tool?

The DSL(s) in question should adhere to all the usual stipulations about 
being transparent, working cleanly with a debugger etc. They would also 
have to provide value above and beyond what might be enabled by a 
separate (non compile-time) domain-specific tool. To illustrate, one DSL 
suggestion might be some limited form of GUI? However, there are better 
tools available for exactly that domain, which expose a richer 
environment than we could hope to achieve via a compile-time 
implementation. Please keep this particular aspect in mind.

What do you think? Can you come up with something?