The DeRailed Challenge

[Robby]

comments inline
kris wrote:
> '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.
> 
How about before it starts we leave the term killer out of it and come
back to alternative. Not that I don't think D can supply a better
toolkit, but when I read killer I think of 'ipod killer (zune), windows
killer (some linux distro)' etc. There isn't any reasons to encourage
defensiveness from the start. :)
> 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.
> 
This would be nice, one problem domain I seem to run into is getting
all of the fields + their types of a struct. Something like
for(field in struct)
	field.'get type'
would help my cause a lot.
> 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.
> 
Like others I'm really not sure where this is going. If it's about html
generation I have a few ideas on it.
> 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.
> 
I fully understand DDBI's intent (to bring a common database idiom over
to D (I couldn't count the languages that have a similar syntax), but it
does tend to be cumbersome when looking at derailed. The binding
experience they've already plowed through will be invaluable though ;)
> 5) A runtime platform, with clustering support. We can leverage various 
> tools from the Mango project.
> 
may google zed shaw and mongrel to get some information on some ideas
pertaining to this?
> 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.
> 
I'm coming from an activerecord point of view, (I'm trying to look into
that aspect first), and personally I don't think there needs to be a dsl
  for it. Well, maybe a little:), but I'll come to that in a second.


Actually, mid draft I threw something together
http://www.dsource.org/projects/tango/wiki/DeActive
Give it a looksee.


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