View mode: basic / threaded / horizontal-split · Log in · Help
February 09, 2007
The DeRailed Challenge
'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?
February 09, 2007
Re: The DeRailed Challenge
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...

For instance, why would you need late binding?
And reflection support?
And what does a GUI have to do with web development? Unless you mean an 
HTML generation engine...


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...
February 09, 2007
Re: The DeRailed Challenge
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
February 09, 2007
Re: The DeRailed Challenge
I don't know RoR, but

Frits van Bommel wrote:
> And reflection support?

You may use reflection to write a persistence layer for a database
application. For example, in Delphi you got access to the Runtime Type
Information (RTTI) with which it is possible to develop some sort of
reflection. Going a step further, it is possible to develop database
components such like a ClientDataSet that contains objects (usually they
just contain a copy of the database-query structure. For example if you
make a "select name, familyname from customer", you may access the
fields in the clientdataset by .fieldByName("name").AsString and so on)
and access its properties the same way as with regular datasets:
objectdataset.fieldByName("MyObjectProperty").AsInteger = 10;
something like that. Then you may concentrate on the objects and let the
software do the persistence on its own and you may directly map objects
into relational databases.

I didn't have a look at D's runtime type information capabilities, but
if there are none, it would be a _really_ nice feature to have - beside
Delphi's "class of " feature to do something like that:

[delphi code]
type
 TBaseItem = class(TObject, ...)
   property ...
 end;
 TBaseItemClass = class of TBaseItem;

 TSpecializedItem = class(TBaseItem)
   // something special
 end;


// constructor for a list that gets a "class of" type to create it's own
items:
constructor TMyList.create(AItemClass: TBaseItemClass);
begin
 ...
end;


// create a list:
myList = TMyList.create(TSpezializedItem);

// the following code then creates an item of type TSpecializedItem
myList.addItem();
[/delphi code]



Well this is possible with D, but a few other ways: use a delegate, use
a template, use an object factory. for the last one:

[D code]

class BaseItem
{
   // ...
}

class SpecializedItem
{
   // ...
}

class List
{
   this (ItemFactory factory)
   {
       // get an item
       factory.getItem();
   }
}

class ItemFactory
{
   BaseItem getItem() { ... }
}



class SpecializedItemFactory : ItemFactory
{
   override BaseItem getItem() { return new SpecializedItem(); }
}


[/D code]

But this seems to be code redundancy as you either have to write a
template for each item or derive a new "ItemFactory" for each item type.
February 10, 2007
Re: The DeRailed Challenge
Pragma wrote:
> Frits van Bommel wrote:
>> 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...
[snipped explanation of modern web development]

In addition to abstracting out the annoyances of generating dynamic web 
pages, web frameworks also provide various back-end tools. This 
especially means abstracting away database interaction, and can also 
mean abstracting away the caching of arbitrary data. (memcached is a 
marvelous piece of software, and any web framework worth its salt should 
support it.)

Abstracting away database interaction usually means writing an ORM 
(object relational mapping), which is itself a problem which thrives on 
reflection support. I've experimented with this in the past, and D's new 
mixins might even help. (Also, I believe Gregor Richards is adding some 
sort of reflection trickery to Rebuild, though he'd have to be the one 
to talk about that.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
February 10, 2007
Re: The DeRailed Challenge
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.
> 
> 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).

DDL where the OS doesn't have decent shared libraries, shared libraries 
otherwise. Note that the only OS that D runs on that doesn't have decent 
shared libraries is Windows. DLLs are awful. .so files can be loaded at 
runtime with dlopen, have no GC problems, no exception problems, no 
typeinfo problems ... they're basically superior in every way.

> 
> 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.

For the interested, 
http://svn.dsource.org/projects/tango.tools/trunk/tools/rodin/

> 
> 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.

Perhaps Glade's XML support could be built into duit?

> 
> <SNIP>

 - Gregor Richards
February 10, 2007
Re: The DeRailed Challenge
kris schrieb:

> 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.

Hi Kris,
DB Frontend and Backend design is my bread and butter job, so I guess I 
am qualified enough to say that connecting to, and querying a DB is not 
enough.  Data Encapsulation and Data Binding is needed in order to 
create Frontend (WEB/Desktop) applications.

The Java folks allready have a solution, which depends NOT (nessesarily) 
 on JDBC. IMO this set of classes can be easily established in D. 
(since Tango)
I would like to encourage you and the DDBI team to have a look at:

http://swinglabs.org/docs/frameworks/databuffer/index.jsp
HTH, Bjoern

A personal note
Having a visual 2 way database design and maintenance tool using DDBI 
creating data encapsulation and binding code based on f.i. a databuffer 
api will make the DSL discussion obsolete.
next (the redux discussion)
Andrei is a Nerd, in no case he is a pragmatic programmer; Of course a 
financial Institute like M. Chase will not modify the DB design 2 times 
a week, but 1) there are more dynamic markets and 2) during the 
development life cycle, means  from version 0 to 1 this happens quit 
often and it is a pain to writing hard-wired db code.

Bjoern
February 10, 2007
Re: The DeRailed Challenge
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?
February 10, 2007
Re: The DeRailed Challenge
comments inline :)

BLS wrote:
> kris schrieb:
> 
>> 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.
> 
> Hi Kris,
> DB Frontend and Backend design is my bread and butter job, so I guess I 
> am qualified enough to say that connecting to, and querying a DB is not 
> enough.  Data Encapsulation and Data Binding is needed in order to 
> create Frontend (WEB/Desktop) applications.
> 
> The Java folks allready have a solution, which depends NOT (nessesarily) 
>  on JDBC. IMO this set of classes can be easily established in D. (since 
> Tango)
> I would like to encourage you and the DDBI team to have a look at:
> 
> http://swinglabs.org/docs/frameworks/databuffer/index.jsp
> HTH, Bjoern
> 
Ugh, Please no ;)

IMO an ORM wrapper shouldn't ever care about creating a database. If you 
need the functionality I would say it could be a secondary concern in a 
secondary package.

There are several tools out there to create your tables, columns, etc. 
Most of which are very tailored (read, performance inclined) which would 
take a lot of machinery (and thus man hours) in perfecting. Then you're 
looking at the implementation, which will be cumbersome.


Secondly, I think the following
// abstracted away
struct Person
{
	char[] name;
	Address address;
}
struct Address
{
	char[] street;
	char[] city;
}

// written code
Person p;
Address a;
with (a)
{
	street = "1600 Penn Ave.";
	city = "Wash DC";
}
with(p)
{
	name = "BrightOne";
	address a;
}
People.save(p);
Person[] peeps = People.find(1,2,3);
Person[] peeps2 = People.find("name = 'bright one'");
Looks a lot cleaner, could be cleaned up a bit though.
> A personal note
> Having a visual 2 way database design and maintenance tool using DDBI 
> creating data encapsulation and binding code based on f.i. a databuffer 
> api will make the DSL discussion obsolete.

Unless you want to define in code every little detail, there will need 
to be some version of a DSL to allow legacy applications to absorb 
conventions used by an abstraction implementation. A DSL could be in 
pure D code though, and -run, it doesn't have to be a totally different 
language all together.
> next (the redux discussion)
> Andrei is a Nerd, in no case he is a pragmatic programmer; Of course a 
> financial Institute like M. Chase will not modify the DB design 2 times 
> a week, but 1) there are more dynamic markets and 2) during the 
> development life cycle, means  from version 0 to 1 this happens quit 
> often and it is a pain to writing hard-wired db code.
> 
ugh
> Bjoern
February 10, 2007
Re: The DeRailed Challenge
Robby wrote:
> 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. :)

I agree, and don't like the DeRailed name.  It would serve no purpose any
longer, if the project were to far surpass RoR in feature/function/acceptance.

>> 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.

http://www.dsource.org/forums/viewtopic.php?t=2283

Specifically, what you're searching for is tupleof:

# class Model(T) : IModel {
#     IField[] fields;
#     this() {
#         T self = cast(T)this;
#         foreach (i, f; self.tupleof) {
#             static if (is(typeof(f) : IField)) {
#                 self.tupleof[i] = new typeof(f);
#                 this.fields ~= self.tupleof[i];
#             }
#         }
#     }
}

>> 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?
> 
> 
>
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home