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

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

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 :)

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

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;

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

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" ?

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

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" ??

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>