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