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


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


 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

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.
 

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

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.
 

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.
 

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.
 

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.
 

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.
 

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.

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.

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.

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.

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.

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.

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:

 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:

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

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.

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.

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.

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.

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.

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
prev sibling parent 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