The DeRailed Challenge

[Pragma]

Frits van Bommel wrote:
> 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.
> 
> Perhaps, for those of us with not more than a vague idea of what Ruby on 
> Rails even is, you should also explain why it's such a big deal?
> All I know about it is that it has something to do with websites and it 
> seems to be considered the "killer app" for Ruby...
> 

I've done some research here, so I'll be happy to fill in the blanks. :)

> For instance, why would you need late binding?

Late binding is key for resource management of code in server environments.  Ultimately, it is a way to save time and 
space for both developers and servers alike.   True dynamic binding (a mode that lets you *unbind* at runtime and share 
symbolic information bi-directionally) has been out of reach for windows systems running outside of VM's.  Java, .NET 
and anything ELF based can already do this.  So there's a gap that D can fill.

A more concrete example would be something like D Servlet Pages.  Much like how JSP's function, you would upload a .d or 
.dsp file to a webserver, and it will compile, load and link the .obj file at runtime.  The loaded code is then a part 
of the server, and can respond to HTTP requests or whatever you like.

> And reflection support?

This dovetails in with the above.  Runtime load & link is all fine and dandy, but it's almost useless when you have to 
go querying for symbols by their mangled name (it's what linkers speak after all).  Having a known handle for reflection 
info makes things a snap - and has the potential to make the runtime linkage itself completely invisible.

Other, more common uses fall down to various forms of introspection for debugging, serialization and remoting (RPC).

> And what does a GUI have to do with web development? 

I'm not 100% sure what Kris is talking about here.  In the interest of discussion, I'll hazard a guess.

If you look at the OSS landscape, where it intersects with web development, you'll find that there are a few niches that 
are dominated by very expensive tools:

- composing Flash applications and animations
- 100% rich application development in HTML/Javascript

There are line-command tools that do this, but no freebies (as in beer & speech) that support a GUI for the same tasks.

 > Unless you mean an HTML generation engine...

That could be part of it.  Personally, I think it wise to steer clear of this in particular since there are *many* more 
nuts-and-bolts that should be in place first.  Furthermore, it's an area where D really can't touch yet.  Unless this 
project co-opts an existing client-side framework for rich applications, the workload here will be tremendous.

I say "can't touch yet" since nobody has developed a browser or "application container" like Flash that takes advantage 
of D's unique properties.  A complete D-coded client-server pair would make a very interesting RAD environment. (of 
course, any new client software suffers from that good-old bootstrap issue...)

> 
> 
> Note: I have never done any kind of server-side scripting, nor any web 
> development at all besides some basic HTML and copy-pasting (and on one 
> occasion slightly modifying) some javascript...

For yourself and all interested in this thread: there's really nothing to it.  Forget about what runs where, and what 
language it's in.  The problem here is the utter lack of standardization across browsers and how to reach the biggest 
possible audience online in the shortest (development) time possible.

The hard part for web development is knowing where the various tools fail to meet the standards they implement (CSS, 
HTML, Javascript, J2EE, etc), and how to best compensate for that.  Anybody who has had to use "that @#%@-ing other 
browser" for specific websites, can appreciate the kinds of compromises that are made.  It's either: make a bland site 
that is sure to run everywhere (feature poor), or make an awesome site that only looks perfect in IE7 for Windows.  For 
WWW deployments, the latter isn't a very wise option.

Now, the part relevant to this thread:

Increasingly, people are realizing that the only way to "code once and deploy everywhere" with 100% certainty is to _not 
use HTML & Javascript at all_ by abstracting it away with something else entirely.

Enter RoR, GWT, Flash9 w/Flex, Coldfusion Tag Libraries, JSP Tag Libraies, various JS libraries, and so on.

Any Ruby on Rails competitor will need to provide a server framework and a Javascript framework that ultimately make 
generating good-ol HTML easy (this is easy), while invisibly compensating for all those little non-compliances in 
browser behavior in the output (this is *very* hard).  Bonus points for an implementation that doesn't bog down client 
machines, kill browsers, or leave oddball browsers (Opera on the Wii?) out in the cold.

The axiom for such toolkits is that the more you invade the server and client spaces, the more complete (end-to-end) 
your solution, and hence the "easier" it is to get consistent, solid results.  The corollary is that the more you do 
this, the bigger the toolkit and hence the more work it is to get it done.  This is why Kris mentioned GUI tools and all 
the other points.

-- 
- EricAnderton at yahoo