www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The DeRailed Challenge

reply kris <foo bar.com> writes:
'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?
Feb 09 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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...
Feb 09 2007
next sibling parent reply Pragma <ericanderton yahoo.removeme.com> writes:
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

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
Feb 09 2007
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
Feb 09 2007
prev sibling parent Nicolai Waniek <no.spam thank.you> writes:
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.
Feb 09 2007
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
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
Feb 09 2007
parent Alan Knowles <alan akbkhome.com> writes:
Gregor Richards wrote:

 kris wrote:

 'DeRailed' is a project intended to compete in the space where RoR as




.. snip snip ...

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


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


It's now called GtkD ;)

Glade support is already there - although I don't think auto-connect is 
do-able without at least runtime reflection.

There's also libgda (www.gnome-db.org) bindings in svn, although I've 
not tested much more than running a few queries so far.

A 'official' release should be in the pipeline soon.

Regards
Alan
Feb 10 2007
prev sibling next sibling parent reply BLS <Killing_Zoe web.de> writes:
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
Feb 10 2007
next sibling parent Robby <robby.lansaw gmail.com> writes:
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
Feb 10 2007
prev sibling parent kris <foo bar.com> writes:
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.


Absolutely. That's the effort currently under way :)


 
 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


We'll likely try to push some of that down to a lower level if we can; 
get it out of the client code if possible.


 
 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.


Yes, agreed.



 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
Feb 10 2007
prev sibling parent reply Robby <robby.lansaw gmail.com> writes:
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?
Feb 10 2007
next sibling parent reply Brad Anderson <brad dsource.org> writes:
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:












}


 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?
Feb 10 2007
parent reply Kevin Bealer <kevinbealer gmail.com> writes:
Brad Anderson wrote:

 Robby wrote:


...

 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.
 


In addition to this, there is the 'mainstream acceptance' problem.  Most 
business folk would be reluctant to something like "the gimp", "dapper 
drake" or "estupido" as a publically visible name.  Not necessarily that 
they don't get the humor aspect, but the basic fact of business is that 
you need to interface both with people who have or 'get' your sense of 
humor and those who don't.  You simply can't afford to cut out the 
second group.

"Ruby on Rails" is an upbeat name, 'DeRailed' is a cool name to people 
like me, but would implies a 'failed project' to a lot of people, 
unfortunately.  This won't be important to CIOs, but it will be 
important to marketing and would probably keep someone like Chase 
Manhattan from ever putting a "powered by derailed" sticker on their 
website.

(For that matter, if someone I didn't know at a party asked me how I did 
a painting, I would say "the gnu image manipulation program" and 
probably not mention the acronym.)

Kevin
Feb 10 2007
parent reply kris <foo bar.com> writes:
Kevin Bealer wrote:

 Brad Anderson wrote:
 

 Robby wrote:


 
 ...
 

 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.


 
 In addition to this, there is the 'mainstream acceptance' problem.  Most 
 business folk would be reluctant to something like "the gimp", "dapper 
 drake" or "estupido" as a publically visible name.  Not necessarily that 
 they don't get the humor aspect, but the basic fact of business is that 
 you need to interface both with people who have or 'get' your sense of 
 humor and those who don't.  You simply can't afford to cut out the 
 second group.
 
 "Ruby on Rails" is an upbeat name, 'DeRailed' is a cool name to people 
 like me, but would implies a 'failed project' to a lot of people, 
 unfortunately.  This won't be important to CIOs, but it will be 
 important to marketing and would probably keep someone like Chase 
 Manhattan from ever putting a "powered by derailed" sticker on their 
 website.
 
 (For that matter, if someone I didn't know at a party asked me how I did 
 a painting, I would say "the gnu image manipulation program" and 
 probably not mention the acronym.)
 
 Kevin



It's just a "working" name; nothing more. There's plenty of time to 
change it :)
Feb 10 2007
next sibling parent reply Kevin Bealer <kevinbealer gmail.com> writes:
kris wrote:

 Kevin Bealer wrote:

 Brad Anderson wrote:


 Robby wrote:


 ...


 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.


 In addition to this, there is the 'mainstream acceptance' problem.  
 Most business folk would be reluctant to something like "the gimp", 
 "dapper drake" or "estupido" as a publically visible name.  Not 
 necessarily that they don't get the humor aspect, but the basic fact 
 of business is that you need to interface both with people who have or 
 'get' your sense of humor and those who don't.  You simply can't 
 afford to cut out the second group.

 "Ruby on Rails" is an upbeat name, 'DeRailed' is a cool name to people 
 like me, but would implies a 'failed project' to a lot of people, 
 unfortunately.  This won't be important to CIOs, but it will be 
 important to marketing and would probably keep someone like Chase 
 Manhattan from ever putting a "powered by derailed" sticker on their 
 website.

 (For that matter, if someone I didn't know at a party asked me how I 
 did a painting, I would say "the gnu image manipulation program" and 
 probably not mention the acronym.)

 Kevin


 
 
 It's just a "working" name; nothing more. There's plenty of time to 
 change it :)


Yes - and sorry if the above seems over-critical.  I just see "regular" 
people cringe every time I mention "the gimp", and it reminds me that 
there is a cultural schism. ;)

Kevin
Feb 11 2007
parent reply kris <foo bar.com> writes:
Kevin Bealer wrote:

 kris wrote:


[snip]

 It's just a "working" name; nothing more. There's plenty of time to 
 change it :)


 
 
 Yes - and sorry if the above seems over-critical.  I just see "regular" 
 people cringe every time I mention "the gimp", and it reminds me that 
 there is a cultural schism. ;)
 
 Kevin



Don Knuth states:  "The most important thing in the programming language 
is the name. A language will not succeed without a good name. I have 
recently invented a very good name and now I am looking for a suitable 
language"

Jesting aside, I tend to agree that a name can potentially make or break 
a product. In retrospect, and considering the original timeframe, do you 
suppose "Oak" would have generated as much interest without a name 
change to "Java" ?
Feb 11 2007
parent Kevin Bealer <kevinbealer gmail.com> writes:
kris wrote:

 Kevin Bealer wrote:

 kris wrote:


 [snip]

 It's just a "working" name; nothing more. There's plenty of time to 
 change it :)



 Yes - and sorry if the above seems over-critical.  I just see 
 "regular" people cringe every time I mention "the gimp", and it 
 reminds me that there is a cultural schism. ;)

 Kevin


 
 
 Don Knuth states:  "The most important thing in the programming language 
 is the name. A language will not succeed without a good name. I have 
 recently invented a very good name and now I am looking for a suitable 
 language"
 
 Jesting aside, I tend to agree that a name can potentially make or break 
 a product. In retrospect, and considering the original timeframe, do you 
 suppose "Oak" would have generated as much interest without a name 
 change to "Java" ?


Right -- I think there is a spectrum of vegetable names as used by products:

Trees - boring, you can't even eat them.  Oak is the most boring tree.
Greens - like cabbage; you can eat them, at least in theory
Colored Vegetables - a little better, tomatoes, corn are popular
Spicy vegetables - hot peppers, etc, much better
Slightly mind altering veggies - coffee, tobacco, tea.
Actual narcotics - poppies, cocaine, etc. --> too much


Now, for most products you probably want a name that is somewhere in the 
hot pepper or coffee range.  You could name a sportscar the "salsa". 
Tea leaves are like coffee but have a 'tame' reputation, and tobacco is 
kind of gotten itself a bad name lately.

Then there's "substance D". http://en.wikipedia.org/wiki/Substance_D

Kevin

(Okay.. It's time for me to either go to sleep, or wake up -- whichever 
I'm not already doing.)
Feb 11 2007
prev sibling next sibling parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On Sat, 10 Feb 2007 18:57:38 -0800, kris wrote:


 Kevin Bealer wrote:
 
 
 It's just a "working" name; nothing more. There's plenty of time to 
 change it :)


What about the name "Deployed" ??
Feb 12 2007
parent kris <foo bar.com> writes:
Knud Soerensen wrote:

 On Sat, 10 Feb 2007 18:57:38 -0800, kris wrote:
 
 

Kevin Bealer wrote:


It's just a "working" name; nothing more. There's plenty of time to 
change it :)


 
 
 What about the name "Deployed" ??



That'll happen when we finish it <g>
Feb 12 2007
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
kris wrote:

 
 
 It's just a "working" name; nothing more. There's plenty of time to 
 change it :)


DeRailleur ?

I'm not sure whether I'm joking or not.
Feb 13 2007
prev sibling parent kris <foo bar.com> writes:
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. :)
 


Notice the quotes around "killer" -- metaphor only :)



 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.


That's the kind of abstraction I'd like to see also.



 

 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.


HTML is one of the options; but not the only one. Pragma wrote an 
eloquent and informative post on this topic.


 

 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?


Definately; thanks!


 

 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?




Someone already has :)  Seems there's a group opinion forming that 
ActiveRecord is a really nice way to go. That's a great writeup;
Feb 10 2007