Jump to page: 1 2 3
Thread overview
The DeRailed Challenge
Feb 09, 2007
kris
Feb 09, 2007
Frits van Bommel
Feb 09, 2007
Pragma
Feb 10, 2007
Kirk McDonald
Feb 09, 2007
Nicolai Waniek
Feb 10, 2007
Gregor Richards
Re: The DeRailed Challenge (glade/libgda in Gtkd/duit)
Feb 11, 2007
Alan Knowles
Feb 10, 2007
BLS
Feb 10, 2007
Robby
Feb 11, 2007
kris
Feb 10, 2007
Robby
Feb 10, 2007
Brad Anderson
Feb 11, 2007
Kevin Bealer
Feb 11, 2007
kris
Feb 11, 2007
Kevin Bealer
Feb 11, 2007
kris
Feb 11, 2007
Kevin Bealer
Feb 13, 2007
Knud Soerensen
Feb 13, 2007
kris
Feb 13, 2007
Charles D Hixson
Feb 11, 2007
kris
February 09, 2007
'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
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
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
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
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
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
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
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
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
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