www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D : Not for me anymore

reply BLS <nanali wanadoo.fr> writes:
...Building a deep hole to create something great(Don).... Nice picture 
indeed.

D is unique :
Compared to Java/C#/Nemerle D is weak. (just have a look on the 
yield/iterator, reflection  discussions)
(we will have it in D 2.0  ~2008,  just a calculation)


D has an active community offering  a growing list of libraries ... :
We are talking about wrappers respective dead projects and let's be 
generous 10+ new entries in the D newsgroups within 24h is not that much....

D is quit popular :
So you think that D is ~#15 on tiobe really means somethink ? *Show me 
some real world applications written in D*. Let's say only 10.

But what makes me angry and keeps me away from using D from now on ,is 
that all suggestions regarding a *std.lib framework* build by the 
community are simply ignored by the Seniour D architect.

That's it.
Björn
Oct 14 2006
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
What can I say?  When it comes to D, you have to like it and want
it enough.  Most of the people here have discovered this.  What you
say is not new: I'm afraid several key D players have ridden off
into the sunset for similar reasons.

But I'm much more encouraged now compared with the past.  D has
made excellent strides not just because of Walter but because of
energetic, talented, and creative community that continues to
grow.  Contrary to what you say, it's far from doom and gloom.  In
fact, D has never been better, a fact that made me even more
surprised at your post; if you had been around a year or two ago,
things would have looked much more depressing than they do now. ;D

As far as wrappers go, any language that wants to start
with /something/ is best to start by using what's already tried,
tested, and true.  D does this, and, in the process, makes it self
immediately applicable to almost any task.  It would be a waste to
do otherwise.  As D gets more publicity, there is no doubt that new
D native libraries will be the order of the day.  I have no worries
about this.  In fact, I get more eager to see this happen every day.

As to the std.lib framework "by the community, for the community",
have patience, you never know what can happen.  Question is: how
much do you want that? ;)

-JJR
Oct 14 2006
parent BLS <nanali wanadoo.fr> writes:
Well John you make me smile, I really enjoy your kind of humor.
It's 3 pm in the morning here in france, but I found your answere quit 
refreshing. So here's the answere.
Okay :
What picks on my nerves is the waste of human resources and 
intelligence, just because Walter is not willing to coordinate and 
delegate std.lib work to the community.

Maybe it's because D hasn't still reached 1.0. (beside, wonder why)
*To offer something concrete, we allready have :*

deprecated
{
	void oldFoo();
}

//so what about ...

future
{
	yield ....	
}

/* Has to pass the semantic analyses but will produce no code.
    (means only D Front End Development required)
    Enables feature freeze without stand still and  std.lib development.
*/


Björn



John Reimer schrieb:
 What can I say?  When it comes to D, you have to like it and want
 it enough.  Most of the people here have discovered this.  What you
 say is not new: I'm afraid several key D players have ridden off
 into the sunset for similar reasons.
 
 But I'm much more encouraged now compared with the past.  D has
 made excellent strides not just because of Walter but because of
 energetic, talented, and creative community that continues to
 grow.  Contrary to what you say, it's far from doom and gloom.  In
 fact, D has never been better, a fact that made me even more
 surprised at your post; if you had been around a year or two ago,
 things would have looked much more depressing than they do now. ;D
 
 As far as wrappers go, any language that wants to start
 with /something/ is best to start by using what's already tried,
 tested, and true.  D does this, and, in the process, makes it self
 immediately applicable to almost any task.  It would be a waste to
 do otherwise.  As D gets more publicity, there is no doubt that new
 D native libraries will be the order of the day.  I have no worries
 about this.  In fact, I get more eager to see this happen every day.
 
 As to the std.lib framework "by the community, for the community",
 have patience, you never know what can happen.  Question is: how
 much do you want that? ;)
 
 -JJR

Oct 14 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
BLS wrote:
 That's it.

I know how you feel. I've been here for the last 5 or 6 years. And _every_single_year_ we've actually and honestly believed that _next_ year, that's when D 1.0 comes out and we'll take over the world. Yes, really. On the other hand, only this month Lua got into the top 50 on Tiobe. And I've always thought that Lua is a lot more famous than D. ! (Could it simply be their just impressive web presence?) There are other languages that have stagnated. Take Euphoria as an example. It had great promise a few years ago. It could have been all that Visual Basic programmers never did even understand to dream about. And it has been the motivator for quite a few improvement suggestions in this NG throughout the years. (Multiple return values, guarded range types, etc.) Either Rob Craig got a Real Life, or the development simply got bigger than a single person could handle. (Oh, holy God of Bits, don't ever let that happen to Walter!) Euphoria has an applications oriented group of regular users (whereas the corresponding D crows is more library oriented), an interesting web framework including excellent meritocracy handling, and generally a more professional and dynamic looking web presence. And Rob released the entire thing to Open Source a few weeks ago:
 After considering various ways to make a big impact
 on the future of Euphoria for v3.0, including various schemes
 to partially open up the source while still retaining some
 income, I have finally decided to make Euphoria completely
 free of charge, and completely open source.
 
 This will cost me money, but I can't see the current
 system going on much longer, where a whole programming
 language community is dependent on one guy to add features, 
 fix bugs etc. The amount of code that I have to maintain
 has been steadily growing over the years, and I have to 
 admit that my progress has been slowing.

((http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=9&fromYear=B&toMonth=9&toYear=B&postedBy=rds&keywords=%22sep+19%22)) Going back to BLS's feelings, maybe D is in the same spot as Euphoria, in a couple of years: either release the whole thing to the PD or face immediate extinction. --- To the more positive side: never did I think we'd be on Tiobe as #15 before 2010! Never did I think we'd ever fare as well as we've done on the Language Shoot-Out. Never did I think folks like Alexandriescu would pay truckloads of expensive brain-cell-hours for the good of D. And I thought it'd be like 5 years from now before we ever get amazing folks like Pragma and Don with us. (Of course not forgetting everybody else!) --- So, D is just getting air under its wings. Right now is a time for a discontinuation in D's history. But I do understand the frustration and anger -- that maybe a few others too feel as strongly as you do. One alternative is to just shrug and go away. Then, after (say) 18 months, one could come an pay us a visit and see if we've gotten anywhere in the meantime. This is not actually as stupid an idea as it sounds off hand. The 18 months should give one some perspective, and the distance from D might let one see the competition and other alternatives more clearly and in proportion.
Oct 14 2006
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
I think things would be better if only Phobos would be hosted at some 
open-source repository, preferably sourceforge.

Perhaps we can already do that? Walter, can somebody put Phobos on 
sourceforge? And by can I mean, is s/he allowed to?

L. 
Oct 14 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
If it can't be put in sourceforge, surely it could be put into a 
versioning repository (svn, cvs, etc.) of some sort.

Since it seems like digitalmars.com has a fairly reasonable hosting 
arrangement, this might even be possible using the current server and 
hosting company.

I think this has come up before, and Walter wasn't really interested in 
that.  I've really found version control systems as being a huge way to 
improve software quality and developer cooperation, though (even if only 
Walter had write access.)

-[Unknown]


 I think things would be better if only Phobos would be hosted at some 
 open-source repository, preferably sourceforge.
 
 Perhaps we can already do that? Walter, can somebody put Phobos on 
 sourceforge? And by can I mean, is s/he allowed to?
 
 L. 
 
 

Oct 14 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Unknown W. Brackets wrote:
 If it can't be put in sourceforge, surely it could be put into a 
 versioning repository (svn, cvs, etc.) of some sort.
 
 Since it seems like digitalmars.com has a fairly reasonable hosting 
 arrangement, this might even be possible using the current server and 
 hosting company.
 
 I think this has come up before, and Walter wasn't really interested in 
 that.  I've really found version control systems as being a huge way to 
 improve software quality and developer cooperation, though (even if only 
 Walter had write access.)
 
 -[Unknown]

I'd prefer sourceforge, where it will be seen by more people. dsource is nice and has certainly done a lot for D, but it makes us look like some sort of cult. L.
Oct 17 2006
next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Tue, 17 Oct 2006 02:09:38 -0700, Lionello Lunesu  
<lio lunesu.remove.com> wrote:

 Unknown W. Brackets wrote:
 If it can't be put in sourceforge, surely it could be put into a  
 versioning repository (svn, cvs, etc.) of some sort.
  Since it seems like digitalmars.com has a fairly reasonable hosting  
 arrangement, this might even be possible using the current server and  
 hosting company.
  I think this has come up before, and Walter wasn't really interested  
 in that.  I've really found version control systems as being a huge way  
 to improve software quality and developer cooperation, though (even if  
 only Walter had write access.)
  -[Unknown]

I'd prefer sourceforge, where it will be seen by more people. dsource is nice and has certainly done a lot for D, but it makes us look like some sort of cult. L.

What?!!! -JJR
Oct 17 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
John Reimer wrote:
 Lionello Lunesu  
 I'd prefer sourceforge, where it will be seen by more people.

 dsource is nice and has certainly done a lot for D, but it makes us 
 look  like some sort of cult.

What?!!!

LOL! I'm not entirely sure he doesn't have a point. (At least partially.)
Oct 19 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Thu, 19 Oct 2006 13:10:31 -0700, Georg Wrede <georg.wrede nospam.org>  
wrote:

 John Reimer wrote:
 Lionello Lunesu
 I'd prefer sourceforge, where it will be seen by more people.

 dsource is nice and has certainly done a lot for D, but it makes us  
 look  like some sort of cult.


LOL! I'm not entirely sure he doesn't have a point. (At least partially.)

Just maybe... but I was hoping not. :D -JJR
Oct 20 2006
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
John Reimer wrote:
 On Thu, 19 Oct 2006 13:10:31 -0700, Georg Wrede 
 <georg.wrede nospam.org>  wrote:
 
 John Reimer wrote:

 Lionello Lunesu

 I'd prefer sourceforge, where it will be seen by more people.

 dsource is nice and has certainly done a lot for D, but it makes us  
 look  like some sort of cult.

What?!!!

LOL! I'm not entirely sure he doesn't have a point. (At least partially.)

Just maybe... but I was hoping not. :D

The thought never occurred to me that it was cult-like. My thoughts were 1) cool! I can find (most) all of D related projects in one place 2) cool! These guys are serious enough about this to setup their own sourceforge 3) cool! It's not s***forge! Sourceforge is popular (and I use it a lot) but there's very little excellence there. It's free and well-known. That's about it all it's got going for it. Various services are frequently down or unusably slow. And it would be hard to imagine worse web interfaces than the ones they've designed for just about every aspect of project management and distribution. --bb
Oct 20 2006
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
John Reimer wrote:
 On Thu, 19 Oct 2006 13:10:31 -0700, Georg Wrede 
 <georg.wrede nospam.org>  wrote:
 
 John Reimer wrote:

 Lionello Lunesu

 I'd prefer sourceforge, where it will be seen by more people.

 dsource is nice and has certainly done a lot for D, but it makes us  
 look  like some sort of cult.

What?!!!

LOL! I'm not entirely sure he doesn't have a point. (At least partially.)

Just maybe... but I was hoping not. :D -JJR

Oh, also pooling code is also something that seems to be popular with other easy-to-use languages. Perl has CPAN, Python has the "cheese-shop", Ruby has Rubyforge, ... but I guess those are all cults now that I think of it. :-P --bb
Oct 20 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
PHP has PEAR and PECL.

Sometimes projects written in these languages even have forges.  Like Mambo.

-[Unknown]


 John Reimer wrote:
 On Thu, 19 Oct 2006 13:10:31 -0700, Georg Wrede 
 <georg.wrede nospam.org>  wrote:

 John Reimer wrote:

 Lionello Lunesu

 I'd prefer sourceforge, where it will be seen by more people.

 dsource is nice and has certainly done a lot for D, but it makes 
 us  look  like some sort of cult.

What?!!!

LOL! I'm not entirely sure he doesn't have a point. (At least partially.)

Just maybe... but I was hoping not. :D -JJR

Oh, also pooling code is also something that seems to be popular with other easy-to-use languages. Perl has CPAN, Python has the "cheese-shop", Ruby has Rubyforge, ... but I guess those are all cults now that I think of it. :-P --bb

Oct 24 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Lionello Lunesu wrote:

 Unknown W. Brackets wrote:
 If it can't be put in sourceforge, surely it could be put into a
 versioning repository (svn, cvs, etc.) of some sort.
 
 Since it seems like digitalmars.com has a fairly reasonable hosting
 arrangement, this might even be possible using the current server and
 hosting company.
 
 I think this has come up before, and Walter wasn't really interested in
 that.  I've really found version control systems as being a huge way to
 improve software quality and developer cooperation, though (even if only
 Walter had write access.)
 
 -[Unknown]

I'd prefer sourceforge, where it will be seen by more people. dsource is nice and has certainly done a lot for D, but it makes us look like some sort of cult. L.

I guess more non-D people might come by for projects at sourceforge, but then a project there don't get visibility until activity grows (and among the 1 million projects there, some have quite a lot of activity). I totally disagree with the other statement. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Oct 20 2006
prev sibling next sibling parent "nobody_" <spam spam.spam> writes:
 D is quit popular :
 So you think that D is ~#15 on tiobe really means somethink ? *Show me 
 some real world applications written in D*. Let's say only 10.

My first encounters with D: http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html http://homepage2.nifty.com/isshiki/
Oct 14 2006
prev sibling next sibling parent reply rm <roel.mathys gmail.com> writes:
BLS wrote:
 ...Building a deep hole to create something great(Don).... Nice picture
 indeed.
 
 D is unique :
 Compared to Java/C#/Nemerle D is weak. (just have a look on the
 yield/iterator, reflection  discussions)
 (we will have it in D 2.0  ~2008,  just a calculation)
 
 
 D has an active community offering  a growing list of libraries ... :
 We are talking about wrappers respective dead projects and let's be
 generous 10+ new entries in the D newsgroups within 24h is not that
 much....
 
 D is quit popular :
 So you think that D is ~#15 on tiobe really means somethink ? *Show me
 some real world applications written in D*. Let's say only 10.
 
 But what makes me angry and keeps me away from using D from now on ,is
 that all suggestions regarding a *std.lib framework* build by the
 community are simply ignored by the Seniour D architect.
 
 That's it.
 Björn
 

to become a *really* popular language (as-is used in lot's of big projects) a language has to have good libraries available. D has really easy linkage to all C libraries, if I'm not mistaken. That's good for a multi-language environment. But to position D against (well not against against :-) ), D needs to come with batteries included, or at least have some standard/best practices libraries available (I doubt a formal standardization is needed). Those batteries could be just wrappers around existing library in other languages. I doubt whether this is a good choice, because of the dependencies on other languages, build tools, ... If other reasonings can/need be give, please do so .. So back to libraries for D in D :-) What could be the reasons the Senior Darch is *ignoring* this? - he doesn't see a need for it (right now) => so it's low on his priority list - he doesn't have the resources to coordinate such an effort - he's planning to release D 1.0 before starting to think on libraries => are we talking about specifications for libraries => are we talking about a specific implementation (license?) - building libraries when important features are still being added => that might be regrettable in the not to distant future => when do you start with "standard" libraries, when do you stop evolving the language - are we talking about minimal batteries, or full blown batteries? OTOH, "Not for me anymore", I've been here a few years back, and I must say that the current DMD/GDC compilers are quite impressive. In my eyes they start to mature quite nicely. En tout cas, merci to Walter, who is putting a lot of his personal resources (time, energy, ...) in developing a real evolution in in the C branch of programming languages. roel
Oct 15 2006
next sibling parent reply =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
rm wrote:
 So back to libraries for D in D :-)
 What could be the reasons the Senior Darch is *ignoring* this?
 - he doesn't see a need for it (right now)
    => so it's low on his priority list
 - he doesn't have the resources to coordinate such an effort
 - he's planning to release D 1.0 before starting to think on libraries
    => are we talking about specifications for libraries
    => are we talking about a specific implementation (license?)
 - building libraries when important features are still being added
    => that might be regrettable in the not to distant future
    => when do you start with "standard" libraries, when do you stop
 evolving the language
 - are we talking about minimal batteries, or full blown batteries?

The biggest problem with writing libraries now is that they may need to be partly rewritten after every big change in the language in order to take advantage of all the new possibilities. Walter is a true compiler expert, but I think he wants to leave the development of libraries to those who are more experienced with different kinds of frameworks. Besides, he already has more than enough work in extending the language and maintaining the compiler. I've been here since 2003. What bugs me the most is that D (the language) still does not have an up-to-date roadmap anywhere. Ok, many of us know what features are postponed to 2.0, but for a newcomer things look pretty confusing. http://digitalmars.com/d/future.html is always a bit out of date. Something like http://trac.edgewall.org/roadmap would be bit more illustrative.. :) There has also been a lot of talk about 1.0. It feels frustrating that even Walter doesn't know when to release it. It's not like the end of world if 1.0 is going to be buggy or fundamentally broken - there's always room for maintenance releases (1.x). A stable release means feature freeze - there's no such thing as a 100% bug free program. But seriously, I think D has never been as good as it is now. Keep up the good work, Walter!
Oct 15 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

What I'm mindful of is I endorsed DWT as the official D gui library, which promptly killed it.
Oct 15 2006
next sibling parent freeagle <dalibor.free gmail.com> writes:
Walter Bright wrote:
 Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

What I'm mindful of is I endorsed DWT as the official D gui library, which promptly killed it.

I think that one of the most important issues with choosing DWT as an official GUI library was, and still is, that it's not yet crossplaform. That had to turn away people using GDC and *NIX OSes. Multiplatform language with Windows-only (at the time) official GUI library. I think that doesnt work...
Oct 15 2006
prev sibling next sibling parent J Duncan <me nospam.com> writes:
Walter Bright wrote:
 Jari-Matti Mäkelä wrote:
 
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

What I'm mindful of is I endorsed DWT as the official D gui library, which promptly killed it.

I completely disagree. THAT did not kill DWT. If you did a survey I would guess there arent a lot of D users who liked SWT or AWT in the first place. And just looking at the DWT code makes me shudder. Actually, your endorsement probably just put it on life support....
Oct 15 2006
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Shame on you, Walter.  You should know better than to think you
have that much influence. ;D

The momentum died for strictly different reasons (most notable
being the lack of contributors).  Your choice and timing just
happened to be off on the matter. Okay, I admit that there was one
other significant issue that was a personal annoyance: you failed
to contact or discuss /anything/ with the people considering the
ports of DWT (myself, Carlos ). You just announced the ports and
that we were doing them (even though you had no idea what are
personal feelings on the matter were or how serious we were about
it).  I recall being quite shocked at your announcement. I think
Carlos was too.

Regardless, we all know that GUI Frameworks are particularly
troublesome to endorse since the area is so subjective.  It's
probably a lost cause trying to support one over the other.  Best
to encourage any GUI that people are willing to develop for D
because I don't think any one framework will be acceptable as a
standard.

As for standard libraries, I think you should be ready to endorse
an organized effort that presents itself with these traits:

1. Is well documented
2. Meets the general approval of the community
3. Continues to be developed for multiple compilers in tandem (dmd
and gdc)
4. Is actively developed for multiple platforms (linux, win32, Mac
OS X)
5. Has a strategy layed out for future direction
6. Has a dedicated core group of developers that have shown
dedication to the D language.
7. Is maintained under a version control system

Such traits by far surpass what Phobos can offer.  From my
perspective, the act of endorsing such an effort hardly constitutes
a risk.

-JJR
Oct 15 2006
next sibling parent =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
John Reimer wrote:
 As for standard libraries, I think you should be ready to endorse
 an organized effort that presents itself with these traits:
 
 1. Is well documented
 2. Meets the general approval of the community
 3. Continues to be developed for multiple compilers in tandem (dmd
 and gdc)
 4. Is actively developed for multiple platforms (linux, win32, Mac
 OS X)
 5. Has a strategy layed out for future direction
 6. Has a dedicated core group of developers that have shown
 dedication to the D language.
 7. Is maintained under a version control system
 
 Such traits by far surpass what Phobos can offer.  From my
 perspective, the act of endorsing such an effort hardly constitutes
 a risk.

Amen to that :)
Oct 15 2006
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
John Reimer wrote:
  > Regardless, we all know that GUI Frameworks are particularly
 troublesome to endorse since the area is so subjective.  It's
 probably a lost cause trying to support one over the other.  Best
 to encourage any GUI that people are willing to develop for D
 because I don't think any one framework will be acceptable as a
 standard.
 
 As for standard libraries, I think you should be ready to endorse
 an organized effort that presents itself with these traits:
 
 1. Is well documented
 2. Meets the general approval of the community
 3. Continues to be developed for multiple compilers in tandem (dmd
 and gdc)
 4. Is actively developed for multiple platforms (linux, win32, Mac
 OS X)
 5. Has a strategy layed out for future direction
 6. Has a dedicated core group of developers that have shown
 dedication to the D language.
 7. Is maintained under a version control system
 
 Such traits by far surpass what Phobos can offer.  From my
 perspective, the act of endorsing such an effort hardly constitutes
 a risk.
 
 -JJR
 

Reading the past posts about the DWT endorsement, it seems like it lacked some well defined criteria like the above and a review process. There was no consensus in the discussion. Personally I would not mind seeing DDL, Mango and Derelict endorsed (and shipped as one package by DM), these are the most mature / relevant projects at dsource? Derelict is a prime example how a well thought out standard for doing things (bindings in this case) makes life easier. It should be a boost both for D and the respective libraries if they come together. True, you can get a lot of stuff *right now* but I found myself researching a lot in the past for what is available. I have a graveyard of old half-assed wheels still somewhere in my dev folder. On a related note, is DTL vaporware or will it be revived? I know, I know, C++ sucks but STL provided some pretty cool things if you got used to it, most importantly a standard way of doing lots of stuff which makes it easier to read and even extend other STL-using code. I would love to see something like this in D.
Oct 15 2006
prev sibling next sibling parent =?ISO-8859-15?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
Content-Type: multipart/mixed;
 boundary="------------010601040108070200070003"

This is a multi-part message in MIME format.
--------------010601040108070200070003
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

John Reimer wrote:
 As for standard libraries, I think you should be ready to endorse
 an organized effort that presents itself with these traits:

 1. Is well documented
 2. Meets the general approval of the community
 3. Continues to be developed for multiple compilers in tandem (dmd
 and gdc)
 4. Is actively developed for multiple platforms (linux, win32, Mac
 OS X)
 5. Has a strategy layed out for future direction
 6. Has a dedicated core group of developers that have shown
 dedication to the D language.
 7. Is maintained under a version control system

 Such traits by far surpass what Phobos can offer.  From my
 perspective, the act of endorsing such an effort hardly constitutes
 a risk.

 -JJR

I wouldn't't limit points 1 and 7 to Phobos. Hosting a publicly readable vcs for DMD's frontent, so that everybody can see individual changes - no= t only the changes lumped together for each new release - and compile the frontend. This should result in cleaner code* and potentially more contributors. Thomas * Extract the attached dmd_stub.zip, fill the dmd directory with the current DMD sources and try to compile it... --------------010601040108070200070003 Content-Type: application/zip; name="dmd_stub.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmd_stub.zip" UEsDBAoAAAAAAJc9UDUAAAAAAAAAAAAAAAAJABUAZG1kX3N0dWIvVVQJAANOHDNFRRwzRVV4 BADoA2QAUEsDBAoAAAAAAJc9UDUAAAAAAAAAAAAAAAANABUAZG1kX3N0dWIvZG1kL1VUCQAD ThwzRU4cM0VVeAQA6ANkAFBLAwQKAAAAAADjE081AAAAAAAAAAAAAAAADgAVAGRtZF9zdHVi L21hcnMvVVQJAANKgTFFSoExRVV4BADoA2QAUEsDBAoAAgAAAOMTTzWJ767cLAAAACwAAAAU ABUAZG1kX3N0dWIvbWFycy9tYXJzLmhVVAkAA0qBMUVKgTFFVXgEAOgDZAAvL2hlYWRlciBy ZXF1aXJlZCBieSBkbWQgc291cmNlcywgbm90IHVzZWQNClBLAwQKAAAAAACqCVA1AAAAAAAA AAAAAAAADgAVAGRtZF9zdHViL3Jvb3QvVVQJAAOPwDJFSoExRVV4BADoA2QAUEsDBAoAAgAA AKoJUDWdviG8GAAAABgAAAATABUAZG1kX3N0dWIvcm9vdC9tZW0uaFVUCQADj8AyRRXAMkVV eAQA6ANkACNpbmNsdWRlICIuLi9kbWQvbWVtLmgiClBLAwQUAAIACAC5FFA1bRaz2u0GAAA/ HAAADwAVAGRtZF9zdHViL3N0dWIuY1VUCQADXdQyRRDNMkVVeAQA6ANkAN1ZX2/bNhB/nj8F kWKALQTJsEd3GJDESWssiYM4yQpsQ0BJlM1VIj2SSuwW/e47UpJNipTsdG8rVsz34/H+83hU TyM0uZlcXaIYJ58JS5FUZSwHKEIPSypRRnOCEs4UpkwitSSIFqucFAQQRTlgPDNws13wUlFG 5IkWccUFSos0I5pFEpRyxLhaUrZAcanQSlCmEEYFkRIvCJJ4o5e0uIKnZU60jCWWKCaEoRUW kqQnaA72KapKRdCGlwLxVwYMS/xCuQCDQWWlzFhSVJacDgbvKEvyMiXoF6lSyk+Wv1rYkeIK 5yfLIwuijCoXUQR8x4q4aKE2KwMNpBJlotB8U8Q8/zr49n4weOE0RTfGmfF4QRiP/9YhHY6+ Dn4w7mfDI1kmCUQgK/N8U3uJMNN/cb75AkQVDPSj/JMdHSPFL5bANByN3g++DQaVNhQ1ShSv fp1JSYQyigRRpWDo9vH6Wm/p3CEE3oQ2eF5UBlGWcc0ODKl6VigyAqYQNopz+oUILXqizqnq FnqRYyknJMmxMPVUbfl5WAmMVqk69nhQlKSV2saTkJQnFefVelB7teTs8aDhNU9QzpNj1CiS 8NMk2TEnlZtiNEDwZ4zs7Yy8omkKR4VmlIjhESTvYfYb3SIj14uASYr7LoAyJ/ETaX7smD8N 4cBKhRIoExStBMno+hjpoyYTHSgoIahYFKnuuDhSp8WKhyuph3sbMQhNz8arkiUtjx+WJftc u62N5lkmSa+tZ4uFIAs4mC1JVin2Wv8A4TgzxTseY/yBqFp7FcAMTKzCl+V4IUOCzmQxh35o 2uJ4bFO7Enrg0B8h6Pp/coTGpl52fMBTV0MDgV+OWLmBnru+4KvwGe3eRwoMBZcM5wnXaZeJ tT3EBwxGonbZFZXwglwJXtgGZDiXZMuvQ3mOJU3G47ikOVwFGpnWnaLZA0eI7HoA9MTnupvm NDZRj6pYmOX6ZnnW/XgYwBURxdA9SVJfTskz1F4wVJdrOBRSmrOrzdM9TU0ZCIKOu7U3FK5+ EW/fmggCwW32VQ14u/kY2axYLOQff1WFmNLgoTqN7A3WbtNVSW7OSCU/QtAGtN4IBY6Wvi9L JumCkVCLjrEkur3OzMkcQr6JYUJRbHv8kzFq8C6FBsQImj88ng/XI+PAOlAe6CvabkRwS2l2 vQrFuP09MSEC5F3JQKyR6Wsw5bHWTl+cl1kGp39WqupXdIw+puIDYaaqI1Baa7ILvdFY3Xj7 tEFcCxQZdZfwczi9N4IgASvLJxPZxq2zNIXrGcILKWqUAeZSwiZZCv+1AE+Cy6EjdU3YQi09 lEKp49yGzbDgAq7wc87tDRc4d0mpHFJ5AgCzqWJlU7xwqQK7NIycawdxXLWK00Grgm9BLkBf PEMBsylujrWLPGE7OZf/lE4wd+euQfQtZzF8xLkdi2pEUBsbgnpbO7RDKLIgtgU3lHluAGZT 3K8XwGyqzH2O0vbrliwc6tWmuO3RbelUx0x4kmfCIRzyjks9X7WQqRPCO2XvuCdOAu5JwV/s lJmWZ9NL31fAHEoEOGyd85wmjkwF47wdILiMoEFagH5Q2aTuZ1xN0xZmkY8yYIYGLdKtxU/c 3wBYRR3YNGfx31fmjbJtju0rYHsUqrFvW/isLAJcrRnPLmOR4YQE1rwh2w4QGN6xoi+SwBKE yEUPDMREWe+Q0b5g9Nq8vd771qXkCYWlF7KPtcuGniDslvL2rNxm6chjs6zzqfEelr7cNjx3 nGquHo65GeP2xWJv3IM101sCVdabGui8xVvPXav/B9AAVFkeWHiCEnThA8yNAjXbYbl/o/p3 ln/LtLp6q+ke0P9aw9y8GeZ2iAmIjdS585pdbzy2o6uJiNKvgEOGy6au94mvXs/1gHkHJWW+ AHWWyX63d04ervdNKs88laaBBCfrHVI3Cudugs7QEbItVp/r78/0gd15et8atWvnz+FN9dmb 5WfMDAEefsWFh/1O1dID5xuWLAVncCBTb/HeJMGDYU6FJ07pa52QDJe58jfAU8rX/EpVsuyA L4UIeOAB0yzkOcEBuRPuB2QJ84CHwkkMeFysOOTPtygY/dCr60Fs4K0QMAwWrii80PONt/TE c2jsARuvcUxyXxIk8tVDP3A4V6EE6IWujOk1Gzx0tCBxuTDnd89U0XEXv21A6jWqfo8nLzek iOGtvO2e5kOM84jd9c7/NPl1D3Fvm9Sqzz11R2w+lHZdeR3xNXjHyNRy8jvm2O0XBIvqmc96 O/R3DbenUVcNygQzaAG3RCqS3pOs+e4Ul5lVlqZx7/9+cE5Zz8eBQ17roQHEfQO7D07v+VWu nGFl3+vrkeHQI8oKnvlHo1bwAnkwc6L18c/+B4D///38L1BLAwQUAAIACACMPVA1TMlq60EC AAAFBgAAEgAVAGRtZF9zdHViL2xpbnV4Lm1ha1VUCQADOBwzRUuBMUVVeAQA6ANkAI1T22ob MRB9tr5iIA5kMY7ftw20dtzgUCclgeKHQpG12l01uiySNsT9+s5enB3RlzxJ52jmzFWP63u4 gV9sVphixYWQIVy7d+w9PxEYo1fHCQseIkGaU1/hbJGgEEunCVWImnsCJQp4HpWzlNSyQu6v JJwTBISTOTpNiNY0E5I2qniiuDUEvTUe600ilq0l8pVtCaoLX0liW0dDIquC3rvIpZKkQGUa 50m/lEUDLRMiedbKklct36gaPr4QFHAytpoIw21FtQ0X3lHoyaiMJE0xrmgTz3hqCHSNe6V5 uCYqk8ynQW0CvXOkqiAcVQuRR2mwVymlcLOC9Anb1Rf5USfevhXECKUajYIT01rFdVNzwsRy AlhJOn2ckbCvGGagQmzxxtjmcMBPUi0W3e3b9693z7C4AVju0IdtD1t8xFsp2e72bvuASBW4 KGy3/7F5+NnBXrajWHGy3Cjxuxt9GPxW86veLzuD3m1AuFT1+SIgTVEwFjluZAyQw/wK88gY u4A9f5FQS91ID413lecmQHSA4SX+Lwn4F8fCoW8ocFvAtLGBJTnlY/hu8wWbiaLDnzAetiIb jr4jGYw2sHRw9mbsvYg8KXUSul79Zyw+bDw1KyfN+UCqk92Y7iAzpjC1eMpkNEhTOXtdwK0s easjPOHnYZe4PjlcnieG5bPZmMVSJIks3fwLzD93CutW6QIMVxbwq4u2nw0b5toP+HF9n006 vePAofNGS27BHf9Av1hM9DjvzJ/22Wg4LgkeyRZm7B9QSwECFwMKAAAAAACXPVA1AAAAAAAA AAAAAAAACQANAAAAAAAAABAA7UEAAAAAZG1kX3N0dWIvVVQFAANOHDNFVXgAAFBLAQIXAwoA AAAAAJc9UDUAAAAAAAAAAAAAAAANAA0AAAAAAAAAEADtQTwAAABkbWRfc3R1Yi9kbWQvVVQF AANOHDNFVXgAAFBLAQIXAwoAAAAAAOMTTzUAAAAAAAAAAAAAAAAOAA0AAAAAAAAAEADtQXwA AABkbWRfc3R1Yi9tYXJzL1VUBQADSoExRVV4AABQSwECFwMKAAIAAADjE081ie+u3CwAAAAs AAAAFAANAAAAAAABAAAApIG9AAAAZG1kX3N0dWIvbWFycy9tYXJzLmhVVAUAA0qBMUVVeAAA UEsBAhcDCgAAAAAAqglQNQAAAAAAAAAAAAAAAA4ADQAAAAAAAAAQAO1BMAEAAGRtZF9zdHVi L3Jvb3QvVVQFAAOPwDJFVXgAAFBLAQIXAwoAAgAAAKoJUDWdviG8GAAAABgAAAATAA0AAAAA AAEAAACkgXEBAABkbWRfc3R1Yi9yb290L21lbS5oVVQFAAOPwDJFVXgAAFBLAQIXAxQAAgAI ALkUUDVtFrPa7QYAAD8cAAAPAA0AAAAAAAEAAACkgc8BAABkbWRfc3R1Yi9zdHViLmNVVAUA A13UMkVVeAAAUEsBAhcDFAACAAgAjD1QNUzJautBAgAABQYAABIADQAAAAAAAQAAAKSB/ggA AGRtZF9zdHViL2xpbnV4Lm1ha1VUBQADOBwzRVV4AABQSwUGAAAAAAgACABSAgAAhAsAAAAA --------------010601040108070200070003--
Oct 15 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:
 Shame on you, Walter.  You should know better than to think you
 have that much influence. ;D

If I'm not going to actively manage something, it's best not to get involved with it, as such tends to discourage others from taking the lead on it. They assume I will.
 The momentum died for strictly different reasons (most notable
 being the lack of contributors).

Lack of contributors is why most things wither. The more interesting question is why the lack of contributors. I had (incorrectly) thought that endorsing DWT would lead to more contributors and a more concentrated effort to get it done. The opposite seemed to happen.
 Your choice and timing just
 happened to be off on the matter. Okay, I admit that there was one
 other significant issue that was a personal annoyance: you failed
 to contact or discuss /anything/ with the people considering the
 ports of DWT (myself, Carlos ). You just announced the ports and
 that we were doing them (even though you had no idea what are
 personal feelings on the matter were or how serious we were about
 it).  I recall being quite shocked at your announcement. I think
 Carlos was too.

I'm sorry about that. I had incorrectly just assumed you'd be pleased by it. I wanted to support you guys' efforts.
 Regardless, we all know that GUI Frameworks are particularly
 troublesome to endorse since the area is so subjective.  It's
 probably a lost cause trying to support one over the other.  Best
 to encourage any GUI that people are willing to develop for D
 because I don't think any one framework will be acceptable as a
 standard.

That's where we're at now. There are several D gui's, too many for this community to really support properly.
 As for standard libraries, I think you should be ready to endorse
 an organized effort that presents itself with these traits:
 
 1. Is well documented
 2. Meets the general approval of the community
 3. Continues to be developed for multiple compilers in tandem (dmd
 and gdc)
 4. Is actively developed for multiple platforms (linux, win32, Mac
 OS X)
 5. Has a strategy layed out for future direction
 6. Has a dedicated core group of developers that have shown
 dedication to the D language.
 7. Is maintained under a version control system
 
 Such traits by far surpass what Phobos can offer.  From my
 perspective, the act of endorsing such an effort hardly constitutes
 a risk.

I encourage, and have encouraged, anyone who wants to do this. Any or all parts of Phobos can be used as a starting point. The compiler is my central focus, to enable great libraries to be written.
Oct 15 2006
next sibling parent reply "Derek Parnell" <derek nospam.org> writes:
On Mon, 16 Oct 2006 16:55:55 +1000, Walter Bright  
<newshound digitalmars.com> wrote:

 As for standard libraries, I think you should be ready to endorse
 an organized effort that presents itself with these traits:
  1. Is well documented
 2. Meets the general approval of the community
 3. Continues to be developed for multiple compilers in tandem (dmd
 and gdc)
 4. Is actively developed for multiple platforms (linux, win32, Mac
 OS X)
 5. Has a strategy layed out for future direction
 6. Has a dedicated core group of developers that have shown
 dedication to the D language.
 7. Is maintained under a version control system
  Such traits by far surpass what Phobos can offer.  From my
 perspective, the act of endorsing such an effort hardly constitutes
 a risk.

I encourage, and have encouraged, anyone who wants to do this. Any or all parts of Phobos can be used as a starting point. The compiler is my central focus, to enable great libraries to be written.

Are you saying that, for example, you would have no problems with Phobos being taken from DigitalMars and moved to DSource so that everyone who needed to could get to submit changes to the library that would actually be applied. -- Derek Parnell
Oct 16 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 On Mon, 16 Oct 2006 16:55:55 +1000, Walter Bright 
 I encourage, and have encouraged, anyone who wants to do this. Any or 
 all parts of Phobos can be used as a starting point. The compiler is 
 my central focus, to enable great libraries to be written.

Are you saying that, for example, you would have no problems with Phobos being taken from DigitalMars and moved to DSource so that everyone who needed to could get to submit changes to the library that would actually be applied.

The license for the Phobos source code certainly allows that, and that's part of the point of having the license be that way. So no, I have no problem with that.
Oct 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Brad Roberts wrote:
 Great to hear you agree.  Before going nuts, can we discuss your 
 feelings towards actually using an externally hosted phobos (or other 
 libraries for that matter) in future dmd release tarballs?  What sort of 
 coordination would you envision?  Would you take select patches and 
 merge with your internal tree?  Abandon your internal tree?  Today you 
 release at your whim.  External development of pieces changes that model.
 
 Assuming a community develops around an externally hosted (be it a fork 
 or the primary) version of phobos, a slightly more mature release 
 process probably ought to develop.  Maybe even introduce the concept of 
 beta versions (which might help with the paper-hat bugs like left in 
 debugging code :)  I'm willing to bet that people like Thomas would be 
 willing to give beta releases a spin.  In his case giving it a whirl 
 through dstress to find regressions before they hit the street.

I'm happy to merge things in, but am reluctant to do so without reviewing the diffs line by line.
Oct 16 2006
next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:eh0hgs$q8h$1 digitaldaemon.com...

 I'm happy to merge things in, but am reluctant to do so without reviewing 
 the diffs line by line.

That's what we have now. I think it's time for you to let go of Phobos. There can't be a community lead standard library from which you take patches to include into DMD's distribution. We'd end up with another Ares. Honestly, I don't think this Phobos review process can go on for much longer. Phobos should be hosted on dsource/sourceforge and its latest release should be included with each DMD/GDC release. You'll be one of the few with write rights, of course ;) L.
Oct 16 2006
parent reply Sean Kelly <sean f4.ca> writes:
Lionello Lunesu wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:eh0hgs$q8h$1 digitaldaemon.com...
 
 I'm happy to merge things in, but am reluctant to do so without reviewing 
 the diffs line by line.

That's what we have now. I think it's time for you to let go of Phobos.

It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD. This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
 There can't be a community lead standard library from which you take patches 
 to include into DMD's distribution.

Sure there can.
 We'd end up with another Ares.

I think Ares isn't used widely for two (or perhaps three) reasons: * Visibility * Features * Endorsement (maybe) When people hear about Ares, their first question is typically about Feature X or in some cases about Phobos compatibility. And in general my response is that Ares is really mostly useful for people who don't want much in the way of standard library code (it's been used for some kernel development projects, for example) or for those who want a minimal framework to build on. Mango integrates with Ares and fills essentially all the feature gaps between Ares and Phobos, but doing so requires downloading, installing, and updating a number of different libraries just to match what comes packaged with DMD--it's a large hurdle to overcome. Another related reason may be community support--Ares has pretty much always been a one-man project, I haven't had the time to maintain it recently, and the project doesn't get many contributors. It's extremely difficult to maintain interest and participation in community projects over time. Typically, once the initial "gee whiz" factor wears off, most people go back to their lives and development stagnates. However, I do think a project, if organized properly, might be able to overcome the problems that previous efforts have had--it's largely a matter of momentum. Some sort of "official" stamp may ultimately be necessary to allay the fears of general users (who are more concerned with whether a library will be supported and maintained two years from now that with its feature set) and gain broad acceptance, but I don't think this would be necessary at the outset. Community projects live and die based on community involvement, not endorsements. Just look at DWT :-P
 Honestly, I don't think this Phobos review process can go on for much 
 longer. Phobos should be hosted on dsource/sourceforge and its latest 
 release should be included with each DMD/GDC release. You'll be one of the 
 few with write rights, of course ;)

Frankly, I'm not certain of the best way to handle Walter's involvement in such a project--I think it would really depend on what appealed to him. One option would be for him to maintain only the compiler runtime code (and perhaps GC code) separately and coordinate with the community how these interact with the standard library. Another would be for him to accept patches from the community when necessary. And yet another would be direct manipulation of the public source tree. A lot really depends on how the project is structured, how the code is structured, and how Walter likes to work. Were it me however, I'd probably prefer something more along the lines of my first two suggestions than the last one. Unless I were just committing bulk updates to the public tree on each compiler release and otherwise maintaining those portions internally. Sean
Oct 16 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Sean Kelly wrote:

 It's a bit more complicated than that, since Phobos includes a bunch of 
 compiler runtime code used by DMD.  This is also why GDC has a separate 
 GPhobos where the only substantive difference is this runtime code.

There are some other lib differences too, such as the version(Unix) and std.c.unix.unix that are missing from the DMD library version ? There's also a lot of similar portability fixes spread out over the library, including some work for supporting 64-bit in the future... So in many aspects, GDC GPhobos is a portable version of DMD Phobos. --anders
Oct 16 2006
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Lionello Lunesu wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:eh0hgs$q8h$1 digitaldaemon.com...

 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

That's what we have now. I think it's time for you to let go of Phobos.

It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD. This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
 There can't be a community lead standard library from which you take 
 patches to include into DMD's distribution.

Sure there can. > We'd end up with another Ares. I think Ares isn't used widely for two (or perhaps three) reasons: * Visibility * Features * Endorsement (maybe)

Speaking of Ares, there is something I've wanted to have clarified, which is apropos to this discussion: My issue with Ares, is actually one of objective/purpose. The goal of Ares is stated to be an alternative to Phobos, but my question is how much of an alternative? Is it meant as a general, encompassing alternative to Phobos, targeted to the general (D) programmer populace, or is it a specific alternative, where it aims to deal with some issues you (and some more coders) have with Phobos, but not go further than that? Because a standard lib is a wide and ranged collection of code, and all modules and aspects of it need to be well-considered. I don't think I'm being too clear with my point here, so I'll take a look at Ares and try to give a more concrete example. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2006
parent reply Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 Sean Kelly wrote:
 Lionello Lunesu wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:eh0hgs$q8h$1 digitaldaemon.com...

 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

That's what we have now. I think it's time for you to let go of Phobos.

It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD. This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
 There can't be a community lead standard library from which you take 
 patches to include into DMD's distribution.

Sure there can. > We'd end up with another Ares. I think Ares isn't used widely for two (or perhaps three) reasons: * Visibility * Features * Endorsement (maybe)

Speaking of Ares, there is something I've wanted to have clarified, which is apropos to this discussion: My issue with Ares, is actually one of objective/purpose. The goal of Ares is stated to be an alternative to Phobos, but my question is how much of an alternative? Is it meant as a general, encompassing alternative to Phobos, targeted to the general (D) programmer populace, or is it a specific alternative, where it aims to deal with some issues you (and some more coders) have with Phobos, but not go further than that? Because a standard lib is a wide and ranged collection of code, and all modules and aspects of it need to be well-considered.

It's original aim was to be a complete replacement, but a lack of community participation changed the focus a bit. Ares is now really just a minimal framework on top of which a standard library may be built. And progress there has stalled a bit in the past few months because I've been too busy with other things. However, I do have some redesign ideas in mind that should hopefully bear fruit before too terribly long. And these are intended both to address deficiencies in the original design and to hopefully make for the beginnings of a better library. Sean
Oct 18 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Sean Kelly wrote:
 It's original aim was to be a complete replacement, but a lack of 
 community participation changed the focus a bit. 

Don't take it as lack of interest! Maybe it's just that not everyone felt comfortable submitting their code (because theirs "wasn't up to par", or whatever other personal reason). The existing Ares code does set the ante pretty high, after all. (Additionally, of course, there was the "marketing mishap" of presenting it as a one-man project, whereupon maybe some potential contributors may have felt that their code would be subsumed. (Not intentionally, but as a result of the process.)
 Ares is now really just a minimal framework on top of which a
 standard library may be built.

Now that does sound cool! It follows, that there should be a project (on dsource, for example), that aims to build the "end programmer API" on top of Ares. I can't wait to hear about it! --- Being "a minimal framework on top of which [...]" is actually an excellent position for a library: this gives the freedom for the original developer to fine tune the lib till it is not only rock solid, but diamond solid. Since this also (IMHO) implies that it is not for the regular programmer (rather it would be for the "library writers"), one could even assume additional freedom, (e.g.) using harder to understand APIs if they can bring a more coherent, efficient, or elegant structure to Ares, skip lots of the "user-land" functions (which, of course bring usability and ease, but many of which are 20% additional utility at 80% of the effort), thus giving more time to do the "right stuff, and do it right". The Ares-client libraries [meant to be used by the regular programmer] could then take care of the many-and-mundane-to-write APIs that make a library "complete" or "mature", as seen from the receiving end. --- OT: this reminds me of a joke, that I personally don't even find a joke: "When in doubt, insert a new abstraction layer!"
Oct 19 2006
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 Lionello Lunesu wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:eh0hgs$q8h$1 digitaldaemon.com...

 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

That's what we have now. I think it's time for you to let go of Phobos.

It's a bit more complicated than that, since Phobos includes a bunch of compiler runtime code used by DMD. This is also why GDC has a separate GPhobos where the only substantive difference is this runtime code.
 There can't be a community lead standard library from which you take 
 patches to include into DMD's distribution.

Sure there can. > We'd end up with another Ares. I think Ares isn't used widely for two (or perhaps three) reasons: * Visibility * Features * Endorsement (maybe)

Speaking of Ares, there is something I've wanted to have clarified, which is apropos to this discussion: My issue with Ares, is actually one of objective/purpose. The goal of Ares is stated to be an alternative to Phobos, but my question is how much of an alternative? Is it meant as a general, encompassing alternative to Phobos, targeted to the general (D) programmer populace, or is it a specific alternative, where it aims to deal with some issues you (and some more coders) have with Phobos, but not go further than that? Because a standard lib is a wide and ranged collection of code, and all modules and aspects of it need to be well-considered.

It's original aim was to be a complete replacement, but a lack of community participation changed the focus a bit. Ares is now really just a minimal framework on top of which a standard library may be built. And progress there has stalled a bit in the past few months because I've been too busy with other things. However, I do have some redesign ideas in mind that should hopefully bear fruit before too terribly long. And these are intended both to address deficiencies in the original design and to hopefully make for the beginnings of a better library. Sean

That's good to hear. For an example of what I meant in the previous post, here's two things I think should be in the standard library, and for what I see they are not in Ares (as well as Phobos): * the write/writeln unformating output functions. (news://news.digitalmars.com:119/eg2aka$1ot9$1 digitaldaemon.com) * extended path&file management functions, like Kramer's pathext: http://www.digitalmars.com/d/archives/digitalmars/D/announce/4363.html -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 23 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruno Medeiros wrote:

 That's good to hear. For an example of what I meant in the previous 
 post, here's two things I think should be in the standard library, and 
 for what I see they are not in Ares (as well as Phobos):
 * the write/writeln unformating output functions.
 (news://news.digitalmars.com:119/eg2aka$1ot9$1 digitaldaemon.com)
 * extended path&file management functions, like Kramer's pathext:
 http://www.digitalmars.com/d/archives/digitalmars/D/announce/4363.html
 
 

Is that better than phobos' std.path? At a quick glance it looks pretty similar. http://www.digitalmars.com/d/phobos/std_path.html
Oct 23 2006
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 Bruno Medeiros wrote:
 
 That's good to hear. For an example of what I meant in the previous 
 post, here's two things I think should be in the standard library, and 
 for what I see they are not in Ares (as well as Phobos):
 * the write/writeln unformating output functions.
 (news://news.digitalmars.com:119/eg2aka$1ot9$1 digitaldaemon.com)
 * extended path&file management functions, like Kramer's pathext:
 http://www.digitalmars.com/d/archives/digitalmars/D/announce/4363.html

Is that better than phobos' std.path? At a quick glance it looks pretty similar. http://www.digitalmars.com/d/phobos/std_path.html

pathext adds functions that std.path does not have. (and that are quite useful, like normalizaPath) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 26 2006
prev sibling parent reply Derek Parnell <derek psyc.ward> writes:
On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:

 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos? -- Derek Parnell Melbourne, Australia "Down with mediocrity!"
Oct 16 2006
next sibling parent "John Reimer" <terminal.node gmail.com> writes:
On Mon, 16 Oct 2006 14:04:02 -0700, Derek Parnell <derek psyc.ward> wrote:

 On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:

 I'm happy to merge things in, but am reluctant to do so without
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos?

I have to agree with this. Walter can maintain his own Phobos version as necessary to continue his own compiler development and testing, but I really think we're looking for a more "publicly" maintained standard library that is not under strict control by the compiler writer (who has frankly admitted that his emphasis is on the compiler development). The importance of relinquishing this control is more significant as more compilers are developed for the D language. I think it's useful and important that all compilers get tested on a non-vendor specific standard library, rather than one that is tightly controlled by a single compiler vendor. That, I believe, is a huge indicator to the openness of a language. Note that when I say "public", I don't mean "free for all" standard library submissions. I think we have to keep the maintenance limited to a few trusted individuals. But I still think it must be much more open than it is now. Dsource.org is a good spot for this. While all this has been discussed to some extent before, I belive that a good groundwork of principles are already set to make this work with a minimum of deliberation and conflict. Further, each compiler update, whether gdc or dmd, should be able to compile with agreed upon revision of the library before shipping. -JJR
Oct 16 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:
 
 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos?

Maybe after 1.0. I'm pretty reluctant to do so earlier. That said, it still doesn't impede anyone else from working on Phobos. An increasing number of my own contributions to it I've been making not just open source, but public domain.
Oct 16 2006
next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 16 Oct 2006 17:16:26 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:
 
 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos?

Maybe after 1.0. I'm pretty reluctant to do so earlier.

That's what I thought. I didn't really think that you meant what you said earlier ... Derek:
] Are you saying that, for example, you would have no problems with
] Phobos being taken from DigitalMars and moved to DSource so that
] everyone who needed to could get to submit changes to the library
] that would actually be applied.


] The license for the Phobos source code certainly allows that, and
] that's part of the point of having the license be that way. So no,
] I have no problem with that.

 That said, it still doesn't impede anyone else from working on Phobos.

What impedes me is you. The few times I have submitted a Phobos change to you, you have dismissed them as not worthy of the effort. Those responses just pissed me off and I can't be bothered trying too hard to work under that regimen anymore. I'm just now waiting for Phobos to be freed up so my workings can be judged against a wider body of opinion. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 17/10/2006 10:39:28 AM
Oct 16 2006
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Derek Parnell wrote:
 Walter Bright wrote:
 Derek Parnell wrote:
 Walter Bright wrote:

I'm happy to merge things in, but am reluctant to do so without 
reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion.

Maybe after 1.0. I'm pretty reluctant to do so earlier.

That's what I thought. I didn't really think that you meant what you said earlier ...
 Are you saying that, for example, you would have no problems with
 Phobos being taken from DigitalMars and moved to DSource so that
 everyone who needed to could get to submit changes to the library
 that would actually be applied.

The license for the Phobos source code certainly allows that, and that's part of the point of having the license be that way. So no, I have no problem with that.

That said, it still doesn't impede anyone else from working on Phobos.

What impedes me is you. The few times I have submitted a Phobos change to you, you have dismissed them as not worthy of the effort.

It's not like anyone has a *right* to get his code accepted. One might submit reams of code, or one might be a Distinguished Member of the community, but every line of the code still has to earn its merits by itself! The reasons of rejection may not be obvious to the submitter, but we have no reason to suspect Walter's motivation or impartiality! Or judgment. And certainly one should not get personal about it. --- As should be clear by now, it's free for anyone to set up Another Phobos right now. We might even have several different on separate servers. If any of these then turn up with worthy code, it could be copied to the others (or to the Official Phobos, if Walter so chooses). And even before 1.0, if then somebody fancies one of the Independent Phoboses better than the original, then it's free to use that instead. (Then of course one would assume all responsibility for incompatibilities with 3rd party libraries or other code that may arise from the chosen Phobos possibly being "too fancy". But that's life.)
Oct 16 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 17 Oct 2006 09:33:10 +0300, Georg Wrede wrote:

 It's not like anyone has a *right* to get his code accepted.

 One might submit reams of code, or one might be a Distinguished Member 
 of the community, but every line of the code still has to earn its 
 merits by itself!

Do I really come across as that needy or foolish? Don't bother replying. You have convinced me to have a long break from D participation. See you guys sometime after v1.0 is announced. It's time to dance to a different tune for awhile. (BTW, I'll still support Bud while that's wanted though.) -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 17/10/2006 4:42:06 PM
Oct 17 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek nomail.afraid.org> wrote in message 
news:1adzk321qmvdc.e5gos9og4ttv.dlg 40tude.net...

 Don't bother replying. You have convinced me to have a long break from D
 participation. See you guys sometime after v1.0 is announced. It's time to
 dance to a different tune for awhile.

Well that's a real mature way to handle the situation.
Oct 17 2006
parent reply John Reimer <terminal.node gmail.com> writes:
And your response is even better... like salt in a wound.

-JJR
Oct 17 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:eh3eqh$qto$1 digitaldaemon.com...
 And your response is even better... like salt in a wound.

It's also entirely true.
Oct 17 2006
parent reply John Reimer <terminal.node gmail.com> writes:
Great, Jarrett.  You're the man: that's so much better than partly
true.  And now, you've probably got a hundred people analyzing your
every word to see how mature you are from now on.

You've achieved very little in stating that other than perhaps
spreading derision and worsening irritability.  Keep it up.

-JJR
Oct 17 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:eh3jpe$109v$1 digitaldaemon.com...
 Great, Jarrett.  You're the man: that's so much better than partly
 true.  And now, you've probably got a hundred people analyzing your
 every word to see how mature you are from now on.

 You've achieved very little in stating that other than perhaps
 spreading derision and worsening irritability.  Keep it up.

I've built up a great respect for Derek over the past couple of years. And to see him just snap like that.. It irks me. Derek has always been (in my view) a voice of reason, and for him to suddenly leave D about .. what? A misinterpretation of Georg's comment? A feeling that he has "no effect" on D? Guess what -- very few people really do! And like Walter already said, Derek's on the acknowledgements page, if he's looking for some kind of validation that he's actually contributed something! As if managing one of the most popular D tools wasn't enough! I'm just really disappointed with how Derek's reacted to the situation. That's all.
Oct 17 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Tue, 17 Oct 2006 18:36:34 -0700, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 "John Reimer" <terminal.node gmail.com> wrote in message
 news:eh3jpe$109v$1 digitaldaemon.com...
 Great, Jarrett.  You're the man: that's so much better than partly
 true.  And now, you've probably got a hundred people analyzing your
 every word to see how mature you are from now on.

 You've achieved very little in stating that other than perhaps
 spreading derision and worsening irritability.  Keep it up.

I've built up a great respect for Derek over the past couple of years. And to see him just snap like that.. It irks me. Derek has always been (in my view) a voice of reason, and for him to suddenly leave D about .. what? A misinterpretation of Georg's comment? A feeling that he has "no effect" on D? Guess what -- very few people really do! And like Walter already said, Derek's on the acknowledgements page, if he's looking for some kind of validation that he's actually contributed something! As if managing one of the most popular D tools wasn't enough! I'm just really disappointed with how Derek's reacted to the situation. That's all.

That was much more eloquently expressed. That shows your real feelings on the matter and leaves little to the imagination. Thank you for posting that; I mostly agree with your take of the situation. Somehow, I still get what irks Derek, though not in the exact same way, perhaps. -JJR
Oct 17 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 What impedes me is you. The few times I have submitted a Phobos change to
 you, you have dismissed them as not worthy of the effort. Those responses
 just pissed me off and I can't be bothered trying too hard to work under
 that regimen anymore. I'm just now waiting for Phobos to be freed up so my
 workings can be judged against a wider body of opinion.

I think you've contributed a lot more to D, and have been appreciated more, than you realize. You've been listed on the D acknowledgements page for a very long time.
Oct 17 2006
prev sibling next sibling parent rm <roel.mathys gmail.com> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:

 I'm happy to merge things in, but am reluctant to do so without
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos?

Maybe after 1.0. I'm pretty reluctant to do so earlier. That said, it still doesn't impede anyone else from working on Phobos. An increasing number of my own contributions to it I've been making not just open source, but public domain.

is it because of the fact that DMD depend on some of the libraries in phobos? If so, a solution could be found for those libraries? Feature freeze for ..., frozen api, or a phobos without those libraries for starters, ... roel
Oct 16 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:

 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos?

Maybe after 1.0. I'm pretty reluctant to do so earlier. That said, it still doesn't impede anyone else from working on Phobos. An increasing number of my own contributions to it I've been making not just open source, but public domain.

I've noticed this, and it's very much appreciated. Sean
Oct 16 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Derek Parnell wrote:
 On Mon, 16 Oct 2006 11:03:14 -0700, Walter Bright wrote:
 
 I'm happy to merge things in, but am reluctant to do so without 
 reviewing the diffs line by line.

Actually, when I wrote "take Phobos", I really meant "take Phobos". You would no longer have *the* sole controlling vote on what goes in or goes out of phobos, nor would you have sole control over when new libraries were released for general consumptuion. They would in fact be released asynchonously from DMD. There would be 'beta' versions around for trying our stuff and official releases for people who just needed a standard library. Are you willing to give up control of Phobos?

Wait, now I don't get it. If you meant that Walter was not to have control of it, and in fact it(the lib) wouldn't even be bundled or synchronous with DMD, then wouldn't that make it an alternative lib, like Ares, which is something that can be made now? (When I said I would like to some more community development in Phobos, I really meant *Phobos*, the stdlib that is official, comes with D/DMD, is Walter approved,etc.) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2006
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Derek Parnell wrote:

 Are you saying that, for example, you would have no problems with 
 Phobos  being taken from DigitalMars and moved to DSource so that 
 everyone who  needed to could get to submit changes to the library that 
 would actually  be applied.

I'm confused, wasn't this what the Ares project was all about ? --anders
Oct 16 2006
parent reply "Derek Parnell" <derek nospam.org> writes:
On Mon, 16 Oct 2006 19:02:41 +1000, Anders F Björklund <afb algonet.se>  
wrote:

 Derek Parnell wrote:

 Are you saying that, for example, you would have no problems with  
 Phobos  being taken from DigitalMars and moved to DSource so that  
 everyone who  needed to could get to submit changes to the library that  
 would actually  be applied.

I'm confused, wasn't this what the Ares project was all about ?

My understanding is that Ares is a replacement for Phobos. An alternative to Phobos. Walter seems to be giving the explicit green-light to take the primary responsibility for doing all the coding to Phobos from himself. The way I read it now is that Brad could set up a new DSource project called 'phobos', open it up for read-access for everyone, and svn-commit access to 'registered developers', and a small group to be responsible for creating downloadable library releases. The documentation could also be DSource'd too if Walter doesn't mind submitting the DDOC files he currently uses. I'm sure this community can come up with a workable collabaration on the 'official' phobos library. -- Derek Parnell
Oct 16 2006
next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Derek Parnell wrote:

 I'm confused, wasn't this what the Ares project was all about ?

My understanding is that Ares is a replacement for Phobos. An alternative to Phobos.

Yeah, a community alternative to the Phobos library was what I thought. But I don't really know, and it might have changed, so I won't guess... I do know that it takes three parts to replace current phobos library: - the DMD runtime library - the DMD garbage collector - the D standard library itself I guess this would be mostly about Phobos-the-library (std), and a few parts of Deimos (etc) could probably be integrated into Phobos as well ?
 Walter seems to be giving the explicit green-light to take the primary  
 responsibility for doing all the coding to Phobos from himself. The way 
 I  read it now is that Brad could set up a new DSource project called  
 'phobos', open it up for read-access for everyone, and svn-commit 
 access  to 'registered developers', and a small group to be responsible 
 for  creating downloadable library releases. The documentation could 
 also be  DSource'd too if Walter doesn't mind submitting the DDOC files 
 he  currently uses.

If we can't even get the GPhobos additions integrated with Phobos, then I'm not so sure that Phobos will be opened up for community development. I'm hoping that I'm wrong, though. I don't know what this new plan is ? It *would* be very nice if e.g. the stderr errors and std.c.unix.unix system module could make it into DMD and Phobos, from GDC and GPhobos. --anders
Oct 16 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Derek Parnell wrote:
 On Mon, 16 Oct 2006 19:02:41 +1000, Anders F Björklund <afb algonet.se> 
 wrote:
 
 Derek Parnell wrote:

 Are you saying that, for example, you would have no problems with 
 Phobos  being taken from DigitalMars and moved to DSource so that 
 everyone who  needed to could get to submit changes to the library 
 that would actually  be applied.

I'm confused, wasn't this what the Ares project was all about ?

My understanding is that Ares is a replacement for Phobos. An alternative to Phobos. Walter seems to be giving the explicit green-light to take the primary responsibility for doing all the coding to Phobos from himself. The way I read it now is that Brad could set up a new DSource project called 'phobos', open it up for read-access for everyone, and svn-commit access to 'registered developers', and a small group to be responsible for creating downloadable library releases. The documentation could also be DSource'd too if Walter doesn't mind submitting the DDOC files he currently uses. I'm sure this community can come up with a workable collabaration on the 'official' phobos library. --Derek Parnell

If properly managed, I think it would be an excellent idea. One of the greatest problems I see with D development nowadays is the Walter-Bottleneck, and although I admire his vigorous and persistent work, I think eventually we will have to open up the D development process more. Most successful other languages and projects have teams of developers working on them (either corporate funded, or open-source communities), and as D matures I think we too will have to bring more manpower into the core tools to become competitive. The idea of a one-man army is inspirational, but I don't think it's very realistic. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 16 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Bruno Medeiros wrote:
 Walter-Bottleneck, and although I admire his vigorous and persistent 
 work, I think eventually we will have to open up the D development 
 process more. 

I'm afraid I agree. (Disclaimer: my agreement on this is not to be construed as a statement of Walter not being an inhuman coder!)
 Most successful other languages and projects have teams of 
 developers working on them (either corporate funded, or open-source 
 communities), and as D matures I think we too will have to bring more 
 manpower into the core tools to become competitive. The idea of a 
 one-man army is inspirational, but I don't think it's very realistic.

The way I see it, we do have enough capable coders. Problem is, we really have not one single example on record of getting the focus and coherence right. In other words, with this crowd, we _should_ have been able to resolve the GUI issue already, and the standard library should also have been written and finished ages ago. I'm not talking more work per programmer, I'm just stating that we're doing duplicate work, useless work, irrelevant work, and in general ill planned work -- seen from the point of view of the end-result, that is. But don't blame it on us programmers alone. Or Walter. What we really need at this point is Leaders. Guys who don't even have to be code writers themselves, just guys who can pull together a team and keep the aim crystal clear.
Oct 16 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 The documentation could also be 
 DSource'd too if Walter doesn't mind submitting the DDOC files he 
 currently uses.

The ddoc files for Phobos are already in and part of the Phobos source code.
Oct 16 2006
prev sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Sun, 15 Oct 2006 23:55:55 -0700, Walter Bright  
<newshound digitalmars.com> wrote:

 John Reimer wrote:
 Shame on you, Walter.  You should know better than to think you
 have that much influence. ;D

If I'm not going to actively manage something, it's best not to get involved with it, as such tends to discourage others from taking the lead on it. They assume I will.

Understood.
 The momentum died for strictly different reasons (most notable
 being the lack of contributors).

Lack of contributors is why most things wither. The more interesting question is why the lack of contributors. I had (incorrectly) thought that endorsing DWT would lead to more contributors and a more concentrated effort to get it done. The opposite seemed to happen.

Good question. I never quite figured that one out either. I guess, like others have said, SWT, as powerful as it is, just isn't that popular.
 Your choice and timing just
 happened to be off on the matter. Okay, I admit that there was one
 other significant issue that was a personal annoyance: you failed
 to contact or discuss /anything/ with the people considering the
 ports of DWT (myself, Carlos ). You just announced the ports and
 that we were doing them (even though you had no idea what are
 personal feelings on the matter were or how serious we were about
 it).  I recall being quite shocked at your announcement. I think
 Carlos was too.

I'm sorry about that. I had incorrectly just assumed you'd be pleased by it. I wanted to support you guys' efforts.

Ah, I forgive you. I thank you for trying to support our efforts even if it didn't work out quite right.
 Regardless, we all know that GUI Frameworks are particularly
 troublesome to endorse since the area is so subjective.  It's
 probably a lost cause trying to support one over the other.  Best
 to encourage any GUI that people are willing to develop for D
 because I don't think any one framework will be acceptable as a
 standard.

That's where we're at now. There are several D gui's, too many for this community to really support properly.

I'm not so sure there are too many GUI's to support properly. I think it doesn't matter how many or few there are. If there's a couple out of the bunch that are popular enough, they will be supported... if the community wants it enough.
 As for standard libraries, I think you should be ready to endorse
 an organized effort that presents itself with these traits:
  1. Is well documented
 2. Meets the general approval of the community
 3. Continues to be developed for multiple compilers in tandem (dmd
 and gdc)
 4. Is actively developed for multiple platforms (linux, win32, Mac
 OS X)
 5. Has a strategy layed out for future direction
 6. Has a dedicated core group of developers that have shown
 dedication to the D language.
 7. Is maintained under a version control system
  Such traits by far surpass what Phobos can offer.  From my
 perspective, the act of endorsing such an effort hardly constitutes
 a risk.

I encourage, and have encouraged, anyone who wants to do this. Any or all parts of Phobos can be used as a starting point. The compiler is my central focus, to enable great libraries to be written.

Thank you for stating that here. It's very much appreciated, as is all of your work. I know you've stated it in so many words before, but sometimes repitition seems to be the only way to get things across in a newsgroup where posts quickly get lost in the pile. -JJR
Oct 16 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
John Reimer wrote:
 On Sun, 15 Oct 2006 23:55:55 -0700, Walter Bright wrote:
 John Reimer wrote:

 Shame on you, Walter.  You should know better than to think you
 have that much influence. ;D

If I'm not going to actively manage something, it's best not to get involved with it, as such tends to discourage others from taking the lead on it. They assume I will.

Understood.
 The momentum died for strictly different reasons (most notable
 being the lack of contributors).

Lack of contributors is why most things wither. The more interesting question is why the lack of contributors. I had (incorrectly) thought that endorsing DWT would lead to more contributors and a more concentrated effort to get it done. The opposite seemed to happen.

Good question. I never quite figured that one out either. I guess, like others have said, SWT, as powerful as it is, just isn't that popular.

Dunno about others, but, IIRC, at the time it felt labourious to use, and non-portable. Thus, such an Official choice was, ehh, depressing.
 Your choice and timing just
 happened to be off on the matter. Okay, I admit that there was one
 other significant issue that was a personal annoyance: you failed
 to contact or discuss /anything/ with the people considering the
 ports of DWT (myself, Carlos ). You just announced the ports and
 that we were doing them (even though you had no idea what are
 personal feelings on the matter were or how serious we were about
 it).  I recall being quite shocked at your announcement. I think
 Carlos was too.

I'm sorry about that. I had incorrectly just assumed you'd be pleased by it. I wanted to support you guys' efforts.

Ah, I forgive you. I thank you for trying to support our efforts even if it didn't work out quite right.
 Regardless, we all know that GUI Frameworks are particularly
 troublesome to endorse since the area is so subjective.  It's
 probably a lost cause trying to support one over the other.  Best
 to encourage any GUI that people are willing to develop for D
 because I don't think any one framework will be acceptable as a
 standard.

That's where we're at now. There are several D gui's, too many for this community to really support properly.

I'm not so sure there are too many GUI's to support properly. I think it doesn't matter how many or few there are.

When I moved from VIC-20 to Kaypro-II, I had to switch from 6502 assembler to either Z-80 assembler or 8080 assembler. (Both were used "interchangeably" on the Z-80 on the Kaypro. And I didn't want to use both.) In hindsight, I spent so much time dithering between the two, that merely a toss of a coin at the start would have made the end result much happier. The same thing happened with Basic. On the VIC, I only had [a primitive version of] Microsoft Basic, whereas on the Kaypro, I had 2 versions of M$ interpreted Basic, a truly compiled basic ("C-basic"), and a (Java like) compiled but still interpreted Basic ("S-basic"). I couldn't make up my mind. (Today, I'd have used each of them for separate purposes. :-) ) The dithering didn't stop until a friend gave me a stolen copy of Turbo Pascal, v.2. (And yes, I've since repaid my debt to Borland several times beyond my legal obligations!)
 As for standard libraries, I think you should be ready to endorse
 an organized effort



...
 I encourage, and have encouraged, anyone who wants to do this. Any or  
 all parts of Phobos can be used as a starting point. The compiler is 
 my  central focus, to enable great libraries to be written.


In the last years I've heard people ask and ask about this all over again. It's almost like people wanted to be asking till they get a no for an answer.
 Thank you for stating that here.  It's very much appreciated, as is all 
 of  your work.  I know you've stated it in so many words before, but 
 sometimes  repitition seems to be the only way to get things across in a 
 newsgroup  where posts quickly get lost in the pile.

By this time somebody simply ought to just go ahead and set up the repository. Like Nike: "just do it"!
Oct 16 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Mon, 16 Oct 2006 13:08:11 -0700, Georg Wrede <georg.wrede nospam.org>  
wrote:

 Dunno about others, but, IIRC, at the time it felt labourious to use,  
 and non-portable. Thus, such an Official choice was, ehh, depressing.

SWT is portable... in a limited sort of way. :P But all SWT ports to D would be laborious since the internals are so different from each other; each would require a specially crafted automation for each platform to make it feasible (in light of future SWT versions and fixes coming out). Proof of it's portability, though, appears best demonstrated by the existance of a SWT framework for Pocket PC's. As a GUI framework, however, SWT seems comprehensive and powerful. It's just not a well-recognized or an easily learned solution.
 When I moved from VIC-20 to Kaypro-II, I had to switch from 6502  
 assembler to either Z-80 assembler or 8080 assembler. (Both were used  
 "interchangeably" on the Z-80 on the Kaypro. And I didn't want to use  
 both.) In hindsight, I spent so much time dithering between the two,  
 that merely a toss of a coin at the start would have made the end result  
 much happier. The same thing happened with Basic. On the VIC, I only had  
 [a primitive version of] Microsoft Basic, whereas on the Kaypro, I had 2  
 versions of M$ interpreted Basic, a truly compiled basic ("C-basic"),  
 and a (Java like) compiled but still interpreted Basic ("S-basic"). I  
 couldn't make up my mind. (Today, I'd have used each of them for  
 separate purposes. :-) ) The dithering didn't stop until a friend gave  
 me a stolen copy of Turbo Pascal, v.2. (And yes, I've since repaid my  
 debt to Borland several times beyond my legal obligations!)

Ah yes, those were the days. :) My initial experience with computer languages was with the C64. There, I moved form BASIC to 6510 assembler and then finally to C.
 I encourage, and have encouraged, anyone who wants to do this. Any or   
 all parts of Phobos can be used as a starting point. The compiler is  
 my  central focus, to enable great libraries to be written.


In the last years I've heard people ask and ask about this all over again. It's almost like people wanted to be asking till they get a no for an answer.

Hmmm... good point! We should have learned by now, no doubt. :)
 Thank you for stating that here.  It's very much appreciated, as is all  
 of  your work.  I know you've stated it in so many words before, but  
 sometimes  repitition seems to be the only way to get things across in  
 a newsgroup  where posts quickly get lost in the pile.

By this time somebody simply ought to just go ahead and set up the repository. Like Nike: "just do it"!

Absolutely. That's the only way to go. Ares was a start. I'm sure any such effort is not in vain. -JJR
Oct 16 2006
parent reply =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
John Reimer wrote:
 As a GUI framework,
 however, SWT seems comprehensive and powerful.  It's just not a
 well-recognized or an easily learned solution.

The only programs using SWT that I know of are Eclipse and Azureus. They're both slower than anything I've ever seen (including most of the Swing using programs). It takes a forever to start either of them, changing tabs/perspectives is just like watching a slide show and writing text has an average lag of 1-2 seconds. Maybe it's because I'm only running a 2.x GHz AMD with 1 GB of RAM and a KDE desktop, but IMHO apps on my old PC (Pentium 100, 32 of RAM, Win98/X11+Fluxbox) are way more responsive than any SWT app on the newer box.
Oct 17 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Tue, 17 Oct 2006 03:04:32 -0700, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

 John Reimer wrote:
 As a GUI framework,
 however, SWT seems comprehensive and powerful.  It's just not a
 well-recognized or an easily learned solution.

The only programs using SWT that I know of are Eclipse and Azureus. They're both slower than anything I've ever seen (including most of the Swing using programs). It takes a forever to start either of them, changing tabs/perspectives is just like watching a slide show and writing text has an average lag of 1-2 seconds. Maybe it's because I'm only running a 2.x GHz AMD with 1 GB of RAM and a KDE desktop, but IMHO apps on my old PC (Pentium 100, 32 of RAM, Win98/X11+Fluxbox) are way more responsive than any SWT app on the newer box.

Perhaps... but I don't find the Win32 DWT port that way at all. It's quite snappy. :) And my experiences with Eclipse are quite contrary to yours as well. -JJR
Oct 17 2006
parent reply =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
John Reimer wrote:
 On Tue, 17 Oct 2006 03:04:32 -0700, Jari-Matti Mäkelä
 <jmjmak utu.fi.invalid> wrote:
 
 John Reimer wrote:
 As a GUI framework,
 however, SWT seems comprehensive and powerful.  It's just not a
 well-recognized or an easily learned solution.

The only programs using SWT that I know of are Eclipse and Azureus. They're both slower than anything I've ever seen (including most of the Swing using programs). It takes a forever to start either of them, changing tabs/perspectives is just like watching a slide show and writing text has an average lag of 1-2 seconds. Maybe it's because I'm only running a 2.x GHz AMD with 1 GB of RAM and a KDE desktop, but IMHO apps on my old PC (Pentium 100, 32 of RAM, Win98/X11+Fluxbox) are way more responsive than any SWT app on the newer box.

Perhaps... but I don't find the Win32 DWT port that way at all. It's quite snappy. :) And my experiences with Eclipse are quite contrary to yours as well.

There was at least some discussion in Slashdot over two years ago: http://developers.slashdot.org/comments.pl?sid=92172&threshold=1&commentsort=0&mode=thread&cid=7929925 "First off, SWT only performes well on windows, and stack on top of that that the principal native abstractions are taylored to a win32 environment. Based off of that it is easy to see how SWT performes quite nicely on Windows. Elsewhere it sucks. MacOS, GTK, photon, Motif. Even porrly writeen swing programs outperform on those platforms." IMO it's a bit sad to see that SWT has sucked on everything else but Windows for a very long time now. I personally do not want to support anything related to GTK or SWT because they're technically very low quality. I know many companies embrace SWT because the license is quite liberal, but still it's a sign of apathetic 'Eat shit' attitude to force clients to use stuff that makes their computers vomit in order to save a few hundreds of bucks in licensing costs. Maybe in the future they'll release SWT under EPL and QT will be available under GPL 3.0 (huge maybe) - then it might become possible to use QT as a backend for SWT and DWT. IANAL, these licensing things are hard to understand. For the time being Harmonia is IMHO the best alternative as an official GUI library. I will start using it immediately after it is ported to Linux.
Oct 19 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Thu, 19 Oct 2006 13:59:08 -0700, Jari-Matti Mäkelä  
<jmjmak utu.fi.invalid> wrote:

 There was at least some discussion in Slashdot over two years ago:

 http://developers.slashdot.org/comments.pl?sid=92172&threshold=1&commentsort=0&mode=thread&cid=7929925

 "First off, SWT only performes well on windows, and stack on top of that
 that the principal native abstractions are taylored to a win32
 environment. Based off of that it is easy to see how SWT performes quite
 nicely on Windows.

 Elsewhere it sucks. MacOS, GTK, photon, Motif. Even porrly writeen swing
 programs outperform on those platforms."

Again, your quote refers to Java SWT: perhaps there might be an element of truth there, yet it looks more to me like prejudice since I've not experienced the speed deficit issue (although, I agree that it's big and slow to load, however). DWT performs quite spritely from what I've seen in a couple of projects. The size of the code is more alarming to me than anything else (the executables grow to a couple megabytes).
 IMO it's a bit sad to see that SWT has sucked on everything else but
 Windows for a very long time now. I personally do not want to support
 anything related to GTK or SWT because they're technically very low
 quality. I know many companies embrace SWT because the license is quite
 liberal, but still it's a sign of apathetic 'Eat shit' attitude to force
 clients to use stuff that makes their computers vomit in order to save a
 few hundreds of bucks in licensing costs.

The SWT running on GTK 2 seems to work quite well, so I don't really understand you here either. I don't consider GTK 2 to be a low quality library, although it is in C and horribly ugly to look at or program in. But I don't like most of the frameworks out there anyway, C++-based ones included. At least GTK is very accessible from D precisely because of its C interface. What I don't like about GTK (or SWT) is the size... I prefer lightweight and perhaps that it's my biggest grudge against many of these libraries. From a pragmatic perspective, however, GTK performs quite well, and I can see a GTK-based SWT working adequately with D, performance-wise. DUIT has been a proof of concept of this fact. After-all, GTK is moving towards Cairo and glitz (OpenGL) based surfaces: SWT is on top of all that. This certainly looks more hopeful for any D port of SWT.
 Maybe in the future they'll release SWT under EPL and QT will be
 available under GPL 3.0 (huge maybe) - then it might become possible to
 use QT as a backend for SWT and DWT. IANAL, these licensing things are
 hard to understand.

 For the time being Harmonia is IMHO the best alternative as an official
 GUI library. I will start using it immediately after it is ported to  
 Linux.

Harmonia is beautiful and small... a good example of what I like also. But it's programming interface is yet a litte unusual and unfamiliar. Furthermore, it's still hasn't been ported to other platforms, although doing so shouldn't be that difficult. Harmonia could do well with the right support and initiative from more people than jsut the maintainers (precisely, I'm sure, what they are looking for); however support has been something that's been lacking from almost every GUI project put to the forefront. -JJR
Oct 23 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Mon, 23 Oct 2006 12:49:07 -0700, John Reimer <terminal.node gmail.com>  
wrote:

 On Thu, 19 Oct 2006 13:59:08 -0700, Jari-Matti Mäkelä  
 <jmjmak utu.fi.invalid> wrote:

 There was at least some discussion in Slashdot over two years ago:

 http://developers.slashdot.org/comments.pl?sid=92172&threshold=1&commentsort=0&mode=thread&cid=7929925

 "First off, SWT only performes well on windows, and stack on top of that
 that the principal native abstractions are taylored to a win32
 environment. Based off of that it is easy to see how SWT performes quite
 nicely on Windows.

 Elsewhere it sucks. MacOS, GTK, photon, Motif. Even porrly writeen swing
 programs outperform on those platforms."

Again, your quote refers to Java SWT: perhaps there might be an element of truth there, yet it looks more to me like prejudice since I've not experienced the speed deficit issue (although, I agree that it's big and slow to load, however). DWT performs quite spritely from what I've seen in a couple of projects. The size of the code is more alarming to me than anything else (the executables grow to a couple megabytes).

Okay, it occurred to me that I missed the whole point completely: the fellow was talking about SWT on win32 performing great (which is what DWT is at the moment). So I really made no sense here since a DWT is not available yet on other platforms to prove that it also could perform well... disregard my statement. But I still hold that I think SWT isn't so bad as he makes out on other platforms. I don't fully understand what he means (note that I've only ever used SWT on linux and win32, though). -JJR
Oct 23 2006
prev sibling next sibling parent =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Walter Bright wrote:
 Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

What I'm mindful of is I endorsed DWT as the official D gui library, which promptly killed it.

LOL. It's just that I really don't believe there can be only one "official" GUI library. Even Java has AWT, Swing, SWT and now they're even porting QT to Java. There are always at least a) licensing, b) technical and c) political issues involved. Most of the D libraries have been released under very liberal licenses. I don't think closed source businesses have anything against that. Neither does the open source community. Having several competing gui libraries gives best of the both worlds to the developers. But a standard library is more tightly coupled with the core language. One of the strong points in Java has been that it's easy to use the basic stuff like collections and I/O. These have advanced a lot since Java 1.0, but still there has been less competing libraries in this area than for C++ (AFAIK). There is already a lot of basic stuff ready for D out there under a very liberal license. If only they could be an integral part of the language distribution. The "standard library" is IMO missing things like templated collections, a clone of Java I/O libraries (streams), a String-class (many people really want it), some network code and maybe more libraries for multithreaded applications.
Oct 15 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 What I'm mindful of is I endorsed DWT as the official D gui library, 
 which promptly killed it.

IMHO, more important than having an official GUI library, would be to actually have _something_ right inside dmd.zip! It doesn't have to be the world and the kitchen sink, but anybody downloading dmd.zip should be able to write a GUI hello world simply and easily.
Oct 15 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 What I'm mindful of is I endorsed DWT as the official D gui library, 
 which promptly killed it.

IMHO, more important than having an official GUI library, would be to actually have _something_ right inside dmd.zip! It doesn't have to be the world and the kitchen sink, but anybody downloading dmd.zip should be able to write a GUI hello world simply and easily.

At the very least, include the full set of Windows .lib files from the latest SDK, so that at least it's possible to do SDK programming.
Oct 15 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Don Clugston wrote:
 Georg Wrede wrote:
 Walter Bright wrote:
 What I'm mindful of is I endorsed DWT as the official D gui library, 
 which promptly killed it.

IMHO, more important than having an official GUI library, would be to actually have _something_ right inside dmd.zip! It doesn't have to be the world and the kitchen sink, but anybody downloading dmd.zip should be able to write a GUI hello world simply and easily.

At the very least, include the full set of Windows .lib files from the latest SDK, so that at least it's possible to do SDK programming.

Don't forget the implementation of WinMain that has to be copied in each win32 D project :( I wish dmd would include a higher-level entry point for win32 GUI apps. Perhaps just "int main(char[][])" but with a flag to make it a GUI app (like bud/build has, but actually including the GC init/deinit, etc). L.
Oct 16 2006
next sibling parent reply freeagle <dalibor.free gmail.com> writes:
I am using "int main(char[][])" as the entry point of my win32 GUI applications.
This makes the console window always open at the startup, but I think this can
be
avoided somehow ( I just didnt feel the need so far to find that out )
Oct 16 2006
parent "JC" <johnch_atms hotmail.com> writes:
"freeagle" <dalibor.free gmail.com> wrote in message 
news:egvstb$3t4$1 digitaldaemon.com...
I am using "int main(char[][])" as the entry point of my win32 GUI 
applications.
 This makes the console window always open at the startup, but I think this 
 can be
 avoided somehow ( I just didnt feel the need so far to find that out )

On Windows, just add this to your command line: -L/SU:WINDOWS:5.1 Replace 5.1 with your operating system version. 5.1 = Windows XP, 5.0 = Windows 2000.
Oct 16 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Lionello Lunesu wrote:
 Don Clugston wrote:
 
 Georg Wrede wrote:

 Walter Bright wrote:

 What I'm mindful of is I endorsed DWT as the official D gui library, 
 which promptly killed it.

IMHO, more important than having an official GUI library, would be to actually have _something_ right inside dmd.zip! It doesn't have to be the world and the kitchen sink, but anybody downloading dmd.zip should be able to write a GUI hello world simply and easily.

At the very least, include the full set of Windows .lib files from the latest SDK, so that at least it's possible to do SDK programming.

Don't forget the implementation of WinMain that has to be copied in each win32 D project :( I wish dmd would include a higher-level entry point for win32 GUI apps. Perhaps just "int main(char[][])" but with a flag to make it a GUI app (like bud/build has, but actually including the GC init/deinit, etc).

For a compiler + lib distributor, it shouldn't be that hard to _decide_ that the novice user _should_ be able to write his First GUI Hello World simply with something like: import std.gui; void GUImain() { gui.Window w = new gui.DefaultAppWindow(); gui.Text t = "Hello World"; t.attach(w); w.pack(); w.eventLoop(); } And this would be the same on _all_ the supported platforms. Straight outta shrink-wrap.
Oct 16 2006
prev sibling parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 IMHO, more important than having an official GUI library, would be to 
 actually have _something_ right inside dmd.zip!
 
 It doesn't have to be the world and the kitchen sink, but anybody 
 downloading dmd.zip should be able to write a GUI hello world simply and 
 easily.

I think the best bet for *inclusion* with DMD would be MinWin ? (it has a new home page at http://wiki.dprogramming.com/MinWin) Tk or wx would work too (it does for Python), but they are much bigger and I wouldn't want all of Tcl/Tk or wxWidgets included... The only problem is that it doesn't support Mac OS X, but then again neither does DMD so I don't think that would matter much ? It's not a very big issue for Mac users to use the X11* or GTK+ versions of the interface, until a native Mac port can be done. I am planning to include wxD with my GDC, but I think including MinWin with DMD would be enough to get started with GUI easily ? And, very importantly, it does play a game of Classic Empire :-) (or used to, see http://dsource.org/forums/viewtopic.php?t=660) --anders * Always included, see http://www.apple.com/macosx/features/x11/
Oct 16 2006
prev sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Sun, 15 Oct 2006 12:44:03 -0700, Walter Bright wrote:

 Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

What I'm mindful of is I endorsed DWT as the official D gui library, which promptly killed it.

What about the library contest I suggested long ago ?? Is that a useful idea? I did never get much feedback on that idea. http://all-technology.com/eigenpolls/dwishlist/index.php?it=59
Oct 15 2006
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Knud Sørensen wrote:
 On Sun, 15 Oct 2006 12:44:03 -0700, Walter Bright wrote:
 
 Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

which promptly killed it.

What about the library contest I suggested long ago ?? Is that a useful idea? I did never get much feedback on that idea. http://all-technology.com/eigenpolls/dwishlist/index.php?it=59

This is a great idea. I think Walter just needs to encourage library competition while giving good libraries recognition. How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?
Oct 15 2006
parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Sun, 15 Oct 2006 20:58:10 -0500, clayasaurus wrote:

 Knud Sørensen wrote:
 What about the library contest I suggested long ago ?? 
 Is that a useful idea?
 I did never get much feedback on that idea. 
 
 http://all-technology.com/eigenpolls/dwishlist/index.php?it=59
 

This is a great idea. I think Walter just needs to encourage library competition while giving good libraries recognition. How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?

Yes, a monthly competition like this is also a good idea. We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.
Oct 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Knud Sørensen wrote:
 On Sun, 15 Oct 2006 20:58:10 -0500, clayasaurus wrote:
 
 Knud Sørensen wrote:
 What about the library contest I suggested long ago ?? 
 Is that a useful idea?
 I did never get much feedback on that idea. 

 http://all-technology.com/eigenpolls/dwishlist/index.php?it=59

competition while giving good libraries recognition. How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?

Yes, a monthly competition like this is also a good idea. We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.

I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.
Oct 16 2006
next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Mon, 16 Oct 2006 14:09:07 -0400, Walter Bright  
<newshound digitalmars.com> wrote:

 I've thought about cash prizes and contests. I just had the nagging  
 feeling that the result would be a circus rather than serious  
 development.

I keep my clown costume nearby!
Oct 16 2006
prev sibling next sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Mon, 16 Oct 2006 11:09:07 -0700, Walter Bright wrote:


 
 We have several authors on the list maybe we can get them 
 to donate a copy of one of there books for a first prize.

I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.

Yes, part of it will be a circus, that one of the points of a contest. To attract people and show how good D is performing. Some libraries might not be serious developed, but I think that the top libraries will be. And a few good libraries might be worth all the circus. If you look at history many excellent developments have been the results of competitions: The X price: we got a private developed spaceship. Clay institute millennium problems: Several problems had had more progress since the announcement that any other period in time.
Oct 16 2006
next sibling parent Derek Parnell <derek psyc.ward> writes:
Hey Knud,
can you check your computer's clock? Your posts are arriving 6 or so hours
before you send them. :-)

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Oct 16 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Knud Sørensen wrote:
 Yes, part of it will be a circus, that one of the points of a contest.
 To attract people and show how good D is performing.
 
 Some libraries might not be serious developed, 
 but I think that the top libraries will be.
 
 And a few good libraries might be worth all the circus.
 
 If you look at history many excellent developments have been the
 results of competitions: 
 
 The X price: we got a private developed spaceship.
 Clay institute millennium problems: Several problems had had more progress
 since the announcement that any other period in time.
 

Those are good points. Another point is that whenever money gets involved, problems can come up. For example: taxes, 1099's, etc. For another, suppose I feel a submission isn't good enough, but the submitter does, and feels he's been rooked out of the cash. Bitter feelings result.
Oct 16 2006
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 Knud Sørensen wrote:
 clayasaurus wrote:
 Knud Sørensen wrote:

 What about the library contest I suggested long ago ?? Is that a 
 useful idea?

How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?

Yes, a monthly competition like this is also a good idea. We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.

I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.

A library contest would be far too much work _both_ for the administrators and for the programmers. For any non-trivial stuff it would necessarily drag out over months (if not quarters), and get psychologically diluted -- especially knowing that most (not all) of the contestants are of the breed "get quickly enthused and equally quickly disinterested". (Just look at the number of started projects at, say dsource, versus actual progress in most of them.) A bit more demanding on the "establishment", but a lot more rewarding for our end goal would be to have contests on smaller units! Such would be individual classes, maybe groups of functions, or even very-narrow-purpose libraries. There should also be a separate, on-going series for single functions!! The administration would be more work, granted. And choosing the contest items would require much more work if we wanted to stay determined on keeping in mind the end-goals and overall progress of the D effort. --- Just think about it. At the extremes, we could either have a whole-library contest every year, or we could have a singe-function contest every week. The bias here really ought to be a no-brainer, IMHO. --- About monetary compensation: if I'm not totatlly wrong, the kind of money we could have available as prize money, probably is trivial anyway. So why not just be in it for the glory? (We might instead have votings, jurys, inteviews of the winners (a la F-1), or something else that folks feel inspiring!) (I know that Euphoria (http://www.rapideuphoria.com) has "always" had this "toy money, on-going economy" with folks trying to make very nice apps, libraries, or utilities. But look at the booties: even the top grossings are hardly worth the wear on your keyboard. So, at the end of the day, it inevitably has to come down to just pride in workmanship.) --- Now, if Walter's hint about cash prizes implies outside sponsors, then the question rises, could we use those sponsors more effectively? Like donated programmer-hours, paid advertising of Digital Mars on Google, professional documentation writers... anything! (( Heck, one of my recurring daydreams is to get Google-Labs or IBM Developer Works interested in D. Against the clout and horsepower they have, I'd even be ready to negotiate some (small part) of Walter's final say in D to them! Both these guys are in an position to gross simply preposterously from using D, and for that publicity I'd be willing to offer them some tidbits of their choosing from the D say. )) //// Sorry Walter, I know I'm out of line here. But then, if I weren't this kind of person, I'd be doing something "useful" instead of beating an unborn horse here. :-)
Oct 16 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Tue, 17 Oct 2006 00:16:53 +0300, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Walter Bright wrote:
 Knud Sørensen wrote:
 clayasaurus wrote:
 Knud Sørensen wrote:

 What about the library contest I suggested long ago ?? Is that a  
 useful idea?

How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?

Yes, a monthly competition like this is also a good idea. We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.

feeling that the result would be a circus rather than serious development.

A library contest would be far too much work _both_ for the administrators and for the programmers. For any non-trivial stuff it would necessarily drag out over months (if not quarters), and get psychologically diluted -- especially knowing that most (not all) of the contestants are of the breed "get quickly enthused and equally quickly disinterested". (Just look at the number of started projects at, say dsource, versus actual progress in most of them.) A bit more demanding on the "establishment", but a lot more rewarding for our end goal would be to have contests on smaller units! Such would be individual classes, maybe groups of functions, or even very-narrow-purpose libraries. There should also be a separate, on-going series for single functions!! The administration would be more work, granted. And choosing the contest items would require much more work if we wanted to stay determined on keeping in mind the end-goals and overall progress of the D effort.

I agree. Implementing stuff usually takes a lot more time than you originally thought it would. And what if we end up with 10 good versions of a single library? If we keep just one (or two), there will be a lot of work 'wasted'. I think the most important thing conserning libraries is their API, not how they are internally implemented. Of course, the API and the implementation are usually intertwined, and you have think what may be needed in the future too. Library should be simple and easy to use, yet flexible and extendable. That's not an easy task, I think. ;) So maybe we should have contents on APIs first. When we got the base structure right, we can make competitions on parts (e.g. functions, classes) that should be efficient, or hard to implement. Bulk (trivial) stuff can be implemented outside the competitions later. Also, API implementations should include documentation.
Oct 17 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Kristian wrote:
 So maybe we should have contents on APIs first. When we got the base  
 structure right, we can make competitions on parts (e.g. functions,  
 classes) that should be efficient, or hard to implement. Bulk (trivial)  
 stuff can be implemented outside the competitions later. Also, API  
 implementations should include documentation.

I think an API competition should definitely be in two stages: - compete on the most useful and best spec - then compete on the most elegant implementations of the winning spec
Oct 19 2006
next sibling parent Nils Hensel <nils.hensel web.de> writes:
Georg Wrede schrieb:
 I think an API competition should definitely be in two stages:
 
  - compete on the most useful and best spec
  - then compete on the most elegant implementations of the winning spec

Sounds reasonable to me. Nils
Oct 19 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Georg Wrede wrote:
 Kristian wrote:
 So maybe we should have contents on APIs first. When we got the base  
 structure right, we can make competitions on parts (e.g. functions,  
 classes) that should be efficient, or hard to implement. Bulk 
 (trivial)  stuff can be implemented outside the competitions later. 
 Also, API  implementations should include documentation.

I think an API competition should definitely be in two stages: - compete on the most useful and best spec - then compete on the most elegant implementations of the winning spec

Design, then code, is the development approach that everyone advocates. It's also the approach nobody uses <g>. Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.
Oct 19 2006
next sibling parent reply Karen Lanrap <karen digitaldaemon.com> writes:
Walter Bright wrote:

 Design/code/design/code... iteratively is the real process.
 There's a good reason for that - too often when implementing a
 design we discover that the design won't work or could at least
 be improved. 

Who is 'we' in this case? Following your statement a very tiny set of coworkers might avoid desaster. But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.
Oct 19 2006
next sibling parent reply rm <roel.mathys gmail.com> writes:
Karen Lanrap wrote:
 Walter Bright wrote:
 
 Design/code/design/code... iteratively is the real process.
 There's a good reason for that - too often when implementing a
 design we discover that the design won't work or could at least
 be improved. 

Who is 'we' in this case? Following your statement a very tiny set of coworkers might avoid desaster. But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.

Iterations are always done. Even in big companies. *We* always try to start to plan ahead. But in each phase a needed "redoing" of the previous phase is a possible. It might just be that you do understand the domain better after spending a year in it. You gain new insights, your scope changes, ... Do you know *1* project where no backtracking was ever needed? True, in a truely big project the planning ahead is much more elaborated. Like is the cost for backtracking on some assumptions or chosen solution. roel
Oct 19 2006
parent reply Karen Lanrap <karen digitaldaemon.com> writes:
rm wrote:

 Do you know *1* project where no backtracking was ever needed? 

Several. They died immediately on first try to backtrack.
Oct 20 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Karen Lanrap wrote:
 rm wrote:
 
 Do you know *1* project where no backtracking was ever needed? 

Several. They died immediately on first try to backtrack.

Sounds more like they needed to backtrack, but were for whatever reason unable to do so without the project dying. Not being able to backtrack is quite different from not *needing* to backtrack. :)
Oct 20 2006
next sibling parent Karen Lanrap <karen digitaldaemon.com> writes:
Frits van Bommel wrote:

 Not being able to backtrack is quite different from not
 *needing* to backtrack. :)

In a culture, where backtracking leads to immediate death, nobody _needs_ to backtrack ;-)
Oct 20 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Frits van Bommel wrote:
 Sounds more like they needed to backtrack, but were for whatever reason 
 unable to do so without the project dying.
 Not being able to backtrack is quite different from not *needing* to 
 backtrack. :)

That's true. A sensible approach will build in the ability to backtrack. It's like when a contractor buys stone for the tile job. He always buys a few extra to account for breakage and mistakes. Nothing worse than winding up a couple broken tiles short on a big job, and it not being possible to get more matching stone of just that color!
Oct 20 2006
parent reply Karen Lanrap <karen digitaldaemon.com> writes:
Walter Bright wrote:

 A sensible approach will build in the ability to backtrack.

Uhh, I see now, that there was a misunderstanding. It is the responsibility of every project leader to reserve cost and time buffers. She/he might use them for any purpose and even call that usage backtracking. But that is not the backtracking I was talking of. I was talking about backtracking in the sense of requiring a bigger budget or more time than agreed on. If a project leader plans buffers that are too large, the project will be taken by another leader or it dies. If the buffers are too tiny the leader failed---no backtracking possible. But because the leader of the coding is not in the duty for the design there will be a vital interest to discover erroneous designs early.
Oct 20 2006
parent rm <roel.mathys gmail.com> writes:
Karen Lanrap wrote:
 
 I was talking about backtracking in the sense of requiring a bigger 
 budget or more time than agreed on.
 
 If a project leader plans buffers that are too large, the project 
 will be taken by another leader or it dies. If the buffers are too 
 tiny the leader failed---no backtracking possible.
 

like in every business, taking margins too small will lead to a loss on the job, and when persistent to failure of the business, otoh, talking margins too large will lead too no business at all. roel
Oct 20 2006
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Karen Lanrap wrote:
 Walter Bright wrote:
 
 Design/code/design/code... iteratively is the real process.
 There's a good reason for that - too often when implementing a
 design we discover that the design won't work or could at least
 be improved. 

Who is 'we' in this case? Following your statement a very tiny set of coworkers might avoid desaster. But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.

This sounds like a troll it's so far off base. I only know of one "official" software design methodology and it's called "the waterfall model". And the key point is that you have many different kinds of iterations between the different stages of software development: from requirements to design to implementation to testing to delivery to maintenance. You generally flow down the steps from top to bottom, but at *any* stage you can get loops back up higher. And in particular, you're never in just one stage. Things can be happening in every stage simultaneously. After delivery you frequently get feedback from your customer telling you that what you designed doesn't actually meet their requirements (often because their original requirements were too vague and they didn't actually know what they wanted either) --> back to requirements gathering. Or testing reveals a bug --> back to implementation (of that one part). Implementing the fix reveals a design flaw --> back to design (of that one part), etc. Or maybe we just misunderstood you? --bb
Oct 19 2006
parent reply Karen Lanrap <karen digitaldaemon.com> writes:
Bill Baxter wrote:

 You generally flow down the steps from top to bottom, but at
 *any* stage you can get loops back up higher.

Are you sure? Assume an idealized situation where you take over a team of 10 designers and 490 coders. Your team has projects A and B in the pipeline. Project A is in the beginning of the design phase, planned duration two years, and project B is in the beginning of the coding phase, planned duration also two years. your remaining budgets: for designing project A 4,000,000 $ for coding project B 147,000,000 $ This means every month delay will cost you at least 6,000,000 $ Now one of your 490 coders comes to you saying: "I am unable to implement this because of erroneous design." Are you willing to "sell" this detection to your management, your sponsor or your loan officer? And if you change positions: are you willing to "buy" such statements from yourself? "Dear Sir, I have a plan to produce software that only costs you 150,000,000$. My main production plan consists of repeated designing and coding, because every design is flawed. But although every design is flawed I am sure I do not need more money than what I said before."
Oct 20 2006
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Karen Lanrap wrote:
 Bill Baxter wrote:
 
 
You generally flow down the steps from top to bottom, but at
*any* stage you can get loops back up higher.

Are you sure? Assume an idealized situation where you take over a team of 10 designers and 490 coders. Your team has projects A and B in the pipeline. Project A is in the beginning of the design phase, planned duration two years, and project B is in the beginning of the coding phase, planned duration also two years. your remaining budgets: for designing project A 4,000,000 $ for coding project B 147,000,000 $ This means every month delay will cost you at least 6,000,000 $ Now one of your 490 coders comes to you saying: "I am unable to implement this because of erroneous design." Are you willing to "sell" this detection to your management, your sponsor or your loan officer? And if you change positions: are you willing to "buy" such statements from yourself? "Dear Sir, I have a plan to produce software that only costs you 150,000,000$. My main production plan consists of repeated designing and coding, because every design is flawed. But although every design is flawed I am sure I do not need more money than what I said before."

It sounds like we're just talking about things on a completely different scale. We're talking about *iterations* on one design. You seem to be talking about scrapping the initial design completely and starting over. Although there is a school of thought that says you should always plan to "throw the first one away" -- i.e. build a prototype, learn from it, then do the real thing -- I will agree that in the real-world that's almost always disastrous. But we're not talking about complete redesign from scratch and starting over with fresh code. We're talking about design iterations. Incremental improvements to the original design. --bb
Oct 20 2006
parent Karen Lanrap <karen digitaldaemon.com> writes:
Bill Baxter wrote:

 It sounds like we're just talking about things on a completely
 different scale.

Maybe you overread my statement on "very tiny set of coworkers".
 We're talking about design
 iterations. Incremental improvements to the original design.

But then you never started to code---and that seems to be a promising way. Have a look at the ASM design approach.
Oct 20 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Karen Lanrap wrote:
 Bill Baxter wrote:
 
 You generally flow down the steps from top to bottom, but at
 *any* stage you can get loops back up higher.

Are you sure? Assume an idealized situation where you take over a team of 10 designers and 490 coders. Your team has projects A and B in the pipeline. Project A is in the beginning of the design phase, planned duration two years, and project B is in the beginning of the coding phase, planned duration also two years. your remaining budgets: for designing project A 4,000,000 $ for coding project B 147,000,000 $ This means every month delay will cost you at least 6,000,000 $ Now one of your 490 coders comes to you saying: "I am unable to implement this because of erroneous design." Are you willing to "sell" this detection to your management, your sponsor or your loan officer?

The typical response is to the coder to figure it out, ship a product with structural issues, and let the maintenance team deal with it. And ten years down the road the product is so filled with such compromises that even theoretically trivial changes take days to fix, and often introduce additional bugs in the process. But that's the coder's fault for not being capable or efficient, so you reprimand him and hire more programmers to pick up the slack. Eventually a competing product is released by another company and you simply can't compete on a feature/cost basis. New sales drop off a bit and you lose a few existing customers to the competitor, but encourage others to stick around with fancy service contracts and promises of a redesign. And so it goes. ;-) Sean
Oct 20 2006
parent Karen Lanrap <karen digitaldaemon.com> writes:
Sean Kelly wrote:

  And so it goes.  ;-)

Quite true, but only if you had the right touch.
Oct 20 2006
prev sibling next sibling parent rm <roel.mathys gmail.com> writes:
Karen Lanrap wrote:
 Bill Baxter wrote:
 
 You generally flow down the steps from top to bottom, but at
 *any* stage you can get loops back up higher.

Are you sure? Assume an idealized situation where you take over a team of 10 designers and 490 coders. Your team has projects A and B in the pipeline. Project A is in the beginning of the design phase, planned duration two years, and project B is in the beginning of the coding phase, planned duration also two years. your remaining budgets: for designing project A 4,000,000 $ for coding project B 147,000,000 $ This means every month delay will cost you at least 6,000,000 $ Now one of your 490 coders comes to you saying: "I am unable to implement this because of erroneous design." Are you willing to "sell" this detection to your management, your sponsor or your loan officer? And if you change positions: are you willing to "buy" such statements from yourself? "Dear Sir, I have a plan to produce software that only costs you 150,000,000$. My main production plan consists of repeated designing and coding, because every design is flawed. But although every design is flawed I am sure I do not need more money than what I said before."

please tell me which firm you're acquainted with, it's certainly a criterion to take into account whenever I've dealings with them. I've seen the thing you propose as the most normal business in the world first hand. You know what happens? People do it, but leave after a year or so, the software is a mess, and non-maintainable, non-extendable. The farther you're in the cycle the more it costs to backtrack, and sometimes you do not have a choice, but with every hack you put in place, you subtract some of the lifetime of your software, and I'm not talking about D. D, C++, Python all can be used in whatever scenario you want. roel
Oct 20 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Karen Lanrap wrote:
 Now one of your 490 coders comes to you saying: "I am unable to 
 implement this because of erroneous design."
 
 Are you willing to "sell" this detection to your management, your 
 sponsor or your loan officer?

Yes, because you have two alternatives: 1) Fix the design, and take the $6,000,000 lump. 2) Ignore the problem, hope it goes away, and in the end have to write off the whole $147,000,000. As Exhibit A of approach (2), may I suggest the Denver airport baggage handling system. I've also read now an then in the paper about other government software projects, like one for the FBI, that cost in the hundreds of millions of dollars, and needed to be scrapped completely because of flawed design.
Oct 20 2006
parent Karen Lanrap <karen digitaldaemon.com> writes:
Walter Bright wrote:


 1) Fix the design, and take the $6,000,000 lump.

$6,000,000 per month for an unknown time. If the buyer is willing to take that one will be lucky. Otherwise: 3) the project dies.
 2) Ignore the problem, hope it goes away, and in the end have to
 write off the whole $147,000,000.

The is surely the worst alternative.
Oct 20 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Karen Lanrap wrote:
 Walter Bright wrote:
 
 Design/code/design/code... iteratively is the real process.
 There's a good reason for that - too often when implementing a
 design we discover that the design won't work or could at least
 be improved. 

Who is 'we' in this case?

Just about every software project outside of avionics software.
 Following your statement a very tiny set of coworkers might avoid 
 desaster.
 
 But your habits of evolving the D programming language make it hard 
 to believe that under such management principles a project of about 
 1000 man years would come to success.

The only computer language I know of that was design then build was Ada. And that was a massive failure - Ada was not accepted until the design evolved quite a bit from that first mil spec.
Oct 20 2006
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Georg Wrede wrote:
 Kristian wrote:
 So maybe we should have contents on APIs first. When we got the base  
 structure right, we can make competitions on parts (e.g. functions,  
 classes) that should be efficient, or hard to implement. Bulk 
 (trivial)  stuff can be implemented outside the competitions later. 
 Also, API  implementations should include documentation.

I think an API competition should definitely be in two stages: - compete on the most useful and best spec - then compete on the most elegant implementations of the winning spec


I see two more stages preceding your two: -- gather proposals for cool and useful libraries & pick one -- gathering requirements for selected proposals (nothing formal, just discussion on the list to see what people who might use it want out of it, like "I want to be able to connect gui fields to a database backend")
 Design, then code, is the development approach that everyone advocates. 
 It's also the approach nobody uses <g>. Design/code/design/code... 
 iteratively is the real process. There's a good reason for that - too 
 often when implementing a design we discover that the design won't work 
 or could at least be improved.

So in that case, just don't require that people stick to the spec in stage 2. The spec competition gets the ideas out there, and gives the community a chance to give feedback on them. If the process is any good then the writer of the implementation will need pretty darn good justification for diverging from the spec. Otherwise people will just say "the spec's way was better". Sounds cool. But it seems like a huge waste of coding talent to have everyone concentrate on one particular library and then throw away N-1 out of N of the implementations resulting. Why not get the list of proposals then say the competition is just to come up with an implementation of the best and most useful thing on that list, period. Regardless of who wins, the range and variety of code that gets written that way will likely exceed that from a race-to-write-lib-x competition. --bb
Oct 19 2006
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 Georg Wrede wrote:
 
 Kristian wrote:

 So maybe we should have contents on APIs first. When we got the base  
 structure right, we can make competitions on parts (e.g. functions,  
 classes) that should be efficient, or hard to implement. Bulk 
 (trivial)  stuff can be implemented outside the competitions later. 
 Also, API  implementations should include documentation.

I think an API competition should definitely be in two stages: - compete on the most useful and best spec - then compete on the most elegant implementations of the winning spec

Design, then code, is the development approach that everyone advocates. It's also the approach nobody uses <g>. Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.

True! However, If we had a separate contest on the API spec, then people really would "restrict" their thought to the API itself. Such restriction is never possible in an environment where the Task is to spec-and-execute some API. As an example of the diametrically opposite situation, we might have a code shop where the boss tells Niles-the-Programmer to create an API and implement it. Now, knowing from the outset that he's the one who has to actually implement whatever API he comes up with, will feed-back and personal beliefs on the relative required effort, hamper his judgement on the what-to-dos and what-to-not-dos? In other words, hard-to-code things get reduced priority, hard-to-conceptualize things get lowered priority, and labourious APIs get less attention and respect. An environment where the decision on APIs is disentangled from the decision on how to implement such, is much more fruitful for the end result than the former. A contest where these two stages are separate, may eicourage quality due to the fact that participants in the API part may not have an intention of actually coding the API parts in then next competition.
Oct 20 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 Knud Sørensen wrote:
 On Sun, 15 Oct 2006 20:58:10 -0500, clayasaurus wrote:

 Knud Sørensen wrote:
 What about the library contest I suggested long ago ?? Is that a 
 useful idea?
 I did never get much feedback on that idea.
 http://all-technology.com/eigenpolls/dwishlist/index.php?it=59

competition while giving good libraries recognition. How about a "Top 10 D libraries" page on digitalmars D where the D community votes for the top 10 libraries each month on the newsgroups and then they get a very special recognition on the digitalmars site?

Yes, a monthly competition like this is also a good idea. We have several authors on the list maybe we can get them to donate a copy of one of there books for a first prize.

I've thought about cash prizes and contests. I just had the nagging feeling that the result would be a circus rather than serious development.

I was thinking more towards the grand prize being a spot on the digitalmars top 10 D libraries for the month, I wasn't thinking huge cash prizes or such. This will be no cost to anyone, promote awareness of the best of the D libraries, and promote some friendly competitions and bragging rights. ~ Clay
Oct 16 2006
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Walter Bright wrote:
 
 I've thought about cash prizes and contests. I just had the nagging 
 feeling that the result would be a circus rather than serious development.

What about bounties? We come up with a list of libraries we need/want and assign a $$ value to each item. They don't have to be big numbers. Anyone is free to submit an implementation of any item for your approval. If you accept the submission, you pay out the submitter and strike the item off of the list. If you aren't comfortable handing out cash, perhaps you can reward them with a DMDScript license, a free Digital Mars CD, or whatever you feel comfortable with. At any rate, a bounty system focuses the concept more on seriousness and less on clowning around.
Oct 17 2006
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
[depressing subject line -- let's change it]

Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging 
 feeling that the result would be a circus rather than serious 
 development.

What about bounties?

Ooh. I like that. wxWidgets has a bounties page. http://www.wxwidgets.org/wiki/index.php/WxWidgets_Bounties I don't know how successful it is. It looks active though. Personally I'm more likely to put up a $100 for a bounty than I am to contribute $100 to a project in hopes they will make progress in the direction I want. --bb
Oct 17 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging 
 feeling that the result would be a circus rather than serious 
 development.

What about bounties? We come up with a list of libraries we need/want and assign a $$ value to each item. They don't have to be big numbers. Anyone is free to submit an implementation of any item for your approval. If you accept the submission, you pay out the submitter and strike the item off of the list.

Personally, I don't see the point of cash rewards for contributions. People contribute because they want to, not because they desperately need twenty dollars. And frankly, I'm not sure that the code quality of a submission purely for the money would be particularly high anyway. Sean
Oct 17 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Sean Kelly wrote:
 Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging 
 feeling that the result would be a circus rather than serious 
 development.

What about bounties? We come up with a list of libraries we need/want and assign a $$ value to each item. They don't have to be big numbers. Anyone is free to submit an implementation of any item for your approval. If you accept the submission, you pay out the submitter and strike the item off of the list.

Personally, I don't see the point of cash rewards for contributions. People contribute because they want to, not because they desperately need twenty dollars. And frankly, I'm not sure that the code quality of a submission purely for the money would be particularly high anyway.

I've seen a bounty system used successfully elsewhere. GarageGames used such a system to enhance the second generation of their Torque Game Engine. Community members were always willing to contribute code, and a very few did and do post small code snippets from time to time, but small cash rewards gave some of them the extra kick to really put together some complex systems rather than just think about it. It's not about desperately needing twenty dollars, but just a motivational factor. GG got several quality submissions, including the most impressive implementation of a real-time lightning effect I've ever seen. So based on witnessing that, I think it can be an effective system. It's a bit like subcontracting without the risk. If a submission doesn't pass muster, it doesn't get accepted and the bounty isn't paid. People who might not otherwise have contributed something may very well come out of the woodwork with some useful, well-written code.
Oct 17 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Mike Parker wrote:
 Sean Kelly wrote:
 Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging 
 feeling that the result would be a circus rather than serious 
 development.

What about bounties?



Getting some Google summer-of-coders might be good too. Where there any proposals for D this last time around? --bb
Oct 17 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

 Mike Parker wrote:
 Sean Kelly wrote:
 Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging
 feeling that the result would be a circus rather than serious
 development.

What about bounties?



Getting some Google summer-of-coders might be good too. Where there any proposals for D this last time around? --bb

afaik, only formally organized projects may apply, although it is somewhat unclear to me what constitutes formal in this respect. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Oct 18 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Lars Ivar Igesund wrote:
 Bill Baxter wrote:
 
 Mike Parker wrote:
 Sean Kelly wrote:
 Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging
 feeling that the result would be a circus rather than serious
 development.




Where there any proposals for D this last time around? --bb

afaik, only formally organized projects may apply, although it is somewhat unclear to me what constitutes formal in this respect.

I'm pretty sure D is formally organized enough to count. There may be some application process to qualify as a mentor, though. --bb
Oct 18 2006
parent reply Chad J <""gamerChad\" spamIsBad gmail.com"> writes:
Bill Baxter wrote:
 Lars Ivar Igesund wrote:
 
 Bill Baxter wrote:

 Mike Parker wrote:

 Sean Kelly wrote:

 Mike Parker wrote:

 Walter Bright wrote:

 I've thought about cash prizes and contests. I just had the nagging
 feeling that the result would be a circus rather than serious
 development.

What about bounties?



Getting some Google summer-of-coders might be good too. Where there any proposals for D this last time around? --bb

afaik, only formally organized projects may apply, although it is somewhat unclear to me what constitutes formal in this respect.

I'm pretty sure D is formally organized enough to count. There may be some application process to qualify as a mentor, though. --bb

It'd be nice if someone would apply for mentorship for summer of code '07. You don't have much to lose. I was looking at the summer of code in 2006 as a student and didn't see any D projects on there, but I was probably too late anyways. If someone were to be a mentor for 2007 with a D project, I would seriously look at doing that. That $4500 stipend is mighty appealing at my current pay level of nothing with the studentacious employment potential of a mcjob. So... who wants an extra developer next summer? :)
Oct 18 2006
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Chad J > wrote:
 Bill Baxter wrote:
 Lars Ivar Igesund wrote:

 Bill Baxter wrote:

 Mike Parker wrote:

 Sean Kelly wrote:

 Mike Parker wrote:

 Walter Bright wrote:

 I've thought about cash prizes and contests. I just had the nagging
 feeling that the result would be a circus rather than serious
 development.

What about bounties?



Getting some Google summer-of-coders might be good too. Where there any proposals for D this last time around? --bb

afaik, only formally organized projects may apply, although it is somewhat unclear to me what constitutes formal in this respect.

I'm pretty sure D is formally organized enough to count. There may be some application process to qualify as a mentor, though. --bb

It'd be nice if someone would apply for mentorship for summer of code '07. You don't have much to lose. I was looking at the summer of code in 2006 as a student and didn't see any D projects on there, but I was probably too late anyways. If someone were to be a mentor for 2007 with a D project, I would seriously look at doing that. That $4500 stipend is mighty appealing at my current pay level of nothing with the studentacious employment potential of a mcjob. So... who wants an extra developer next summer? :)

Hehe, I tried to apply last summer but got rejected. I will try harder next summer though, I bet my application just wasn't detailed and exciting enough to stand out.
Oct 18 2006
prev sibling parent =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
hi Chad 

I plan to start an open source D project very soon, 
so maybe next summer there will be a opportunity.
 

 
 --bb

It'd be nice if someone would apply for mentorship for summer of code '07. You don't have much to lose. I was looking at the summer of code in 2006 as a student and didn't see any D projects on there, but I was probably too late anyways. If someone were to be a mentor for 2007 with a D project, I would seriously look at doing that. That $4500 stipend is mighty appealing at my current pay level of nothing with the studentacious employment potential of a mcjob. So... who wants an extra developer next summer? :)

Oct 18 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bill Baxter wrote:
 Mike Parker wrote:
 Sean Kelly wrote:
 Mike Parker wrote:
 Walter Bright wrote:
 I've thought about cash prizes and contests. I just had the nagging 
 feeling that the result would be a circus rather than serious 
 development.

What about bounties?



Getting some Google summer-of-coders might be good too. Where there any proposals for D this last time around? --bb

Actually there where (one mine), but it was ineligible to participate. The reason was: proposals must be submitted under the respective mentor organizations, and if there is no mentor organization for the proposal, it can be submitted to Google. However this year's SoC (unlike the previous one) such applications without mentor organization must have a high "academic research focus", and when I found that out it was too late for new mentor organizations to sign up (one representing D was needed). :( I think it's an opportunity that should not be missed next year. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 19 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Knud Sørensen wrote:
 On Sun, 15 Oct 2006 12:44:03 -0700, Walter Bright wrote:
 
 Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than enough
 work in extending the language and maintaining the compiler.

which promptly killed it.

What about the library contest I suggested long ago ?? Is that a useful idea? I did never get much feedback on that idea. http://all-technology.com/eigenpolls/dwishlist/index.php?it=59

I worked at a small software company once where the marketing folks decided to have a big contest. They advertised it software development magazines and everything. Top prize was supposed to be like $10,000 cash I think. In the end, when the deadline came, we counted up all the submissions. One... two. That's it. We got *two* submissions. Granted, they were pretty good, but I think in the end the marketing department decided to cancel the contest and gave the two entrants free copies of our software instead. I was pretty embarrassed for the whole company. Anyway, this is just to say, my experience with big prize programming contests for niche software has not been good. And no matter how cool it is, you have to admit D is still pretty niche. --bb
Oct 16 2006
parent reply "John Reimer" <terminal.node gmail.com> writes:
On Mon, 16 Oct 2006 16:40:32 -0700, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:

 Knud Sørensen wrote:
 On Sun, 15 Oct 2006 12:44:03 -0700, Walter Bright wrote:

 Jari-Matti Mäkelä wrote:
 Walter is a true compiler expert, but I think he wants to leave the
 development of libraries to those who are more experienced with
 different kinds of frameworks. Besides, he already has more than  
 enough
 work in extending the language and maintaining the compiler.

which promptly killed it.

useful idea? I did never get much feedback on that idea. http://all-technology.com/eigenpolls/dwishlist/index.php?it=59

I worked at a small software company once where the marketing folks decided to have a big contest. They advertised it software development magazines and everything. Top prize was supposed to be like $10,000 cash I think. In the end, when the deadline came, we counted up all the submissions. One... two. That's it. We got *two* submissions. Granted, they were pretty good, but I think in the end the marketing department decided to cancel the contest and gave the two entrants free copies of our software instead. I was pretty embarrassed for the whole company. Anyway, this is just to say, my experience with big prize programming contests for niche software has not been good. And no matter how cool it is, you have to admit D is still pretty niche. --bb

I think it's simple. While I don't see much purpose in prizes and contests in specific area of D development (not at this point, at least), I do think it would be handy to setup donation accounts for developers similar to what sourceforge.net does. I can say I wouldn't mind contributing some dollars to projects like bud (aka build) as a motivator. And if there were a standard library development happening, I'd have no inhibitions there either. Not everybody likes donating, but there are definitely D projects out there that are proving there worth many times over. -JJR
Oct 16 2006
parent Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:
 I think it's simple. While I don't see much purpose in prizes and 
 contests in specific area of D development (not at this point, at 
 least),  I do think it would be handy to setup donation accounts for 
 developers similar to what sourceforge.net does.  I can say I wouldn't 
 mind contributing some dollars to projects like bud (aka build) as a 
 motivator.  And if there were a standard library development happening, 
 I'd have no inhibitions there either.  Not everybody likes donating, but 
 there are definitely D projects out there that are proving there worth 
 many times over.

Does anyone know how effective the sourceforge donations are?
Oct 16 2006
prev sibling parent reply =?ISO-8859-15?Q?Peter_=A6i=A8ka?= <sisken kmit.sk> writes:
Jari-Matti Mäkelä wrote:

 I've been here since 2003. What bugs me the most is that D (the
 language) still does not have an up-to-date roadmap anywhere. Ok, many
 of us know what features are postponed to 2.0, but for a newcomer things
 look pretty confusing.

ad) many of us know what features are postponed to 2.0... please be so kind and tell me i don't know :) personaly what I miss from higher level languages is only reflection. But i am interested in what is cooking for next release. generally I agree with fact that better roadmap should be available, maybe it would be suficient to sit and write down changes that happend (but these are already mapped with changelog) or are going to happen.
Oct 16 2006
parent reply =?ISO-8859-15?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Peter ¦i¨ka wrote:
 Jari-Matti Mäkelä wrote:
 
 I've been here since 2003. What bugs me the most is that D (the
 language) still does not have an up-to-date roadmap anywhere. Ok, many
 of us know what features are postponed to 2.0, but for a newcomer things
 look pretty confusing.

ad) many of us know what features are postponed to 2.0... please be so kind and tell me i don't know :)

Well, it's a bit early to talk about 2.0 now. There is a truckload of stuff scattered around. Some ideas can be found from the D poll, some other things are on the D wiki, and a lot of things have been discussed or ignored in these newsgroups. Walter has promised to implement some things in 2.0, but suddenly they are fully implemented (sans possible bugs) in the next release. It's a bit hard to keep track of things unless one regularly reads the NG. The worst thing is that whenever something "big" happens, something like 5-10 threads with 1000+ messages pops out of nowhere. It takes a week to realize what's going on :-I
Oct 16 2006
next sibling parent Justin Calvarese <technocrat7 gmail.com> writes:
== Quote from Jari-Matti_Mäkelä (jmjmak utu.fi.invalid)'s article
 Well, it's a bit early to talk about 2.0 now. There is a truckload of
 stuff scattered around. Some ideas can be found from the D poll, some
 other things are on the D wiki, ...

Right. For example, some information about future plans is on the official comment page for "Future Directions": http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Future
Oct 16 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Jari-Matti Mäkelä wrote:
 Walter has promised to implement some things in 2.0, but suddenly they
 are fully implemented (sans possible bugs) in the next release.

Well, I think it is understandable. Since D is a one-man effort, it would feel downright disgusting to pin down the next two years. From experience one knows that some of the "unbelievably hard" things to implement may become just simple after a good night's sleep, or after a nice morning shower some other problem might just "come to you" in a flash. Equally, some of the things slated for immediate release might prove intractable at closer look. If, OTOH, a language (or any major SW project in general) is developed by a large group of developers, then it simply becomes imperative to have roadmaps, timelines, and all that stuff. That simply is the price to pay for coherence of effort and cohesion of the group. (From the above two paragraphs it is clear that large projects simply have to be less productive per capita _unless_ the management is exceptionally adept and experienced.) OT:
 It's a
 bit hard to keep track of things unless one regularly reads the NG. The
 worst thing is that whenever something "big" happens, something like
 5-10 threads with 1000+ messages pops out of nowhere. It takes a week to
 realize what's going on :-I

My feelings exactly. Stay here 18 hours per day and nothing happens. Get out of town for 2 days, and all of a sudden you find 500 unread messages. But what bugs me even more is that I continually keep finding "already old" things that have surreptitiously been fixed or implemented in D, and by still asking for them here I just make a fool of myself. No help rereading the entire HTML documentation tree and all the posts here between every release. Seems like the only way to do this is to implement a diff system that goes through the whole dmd tree between each and every release. At times it really is frustrating.
Oct 16 2006
next sibling parent =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 Seems like the only way to do this is to 
 implement a diff system that goes through the whole dmd tree between 
 each and every release. At times it really is frustrating.

Like this one ? http://gdcmac.sourceforge.net/diffs/ (as usual with auto-generated docs, there's a bunch of false positives on the "generated on" timestamps) --anders
Oct 16 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Georg Wrede wrote:
  From experience one knows that some of the "unbelievably hard" things 
 to implement may become just simple after a good night's sleep, or after 
 a nice morning shower some other problem might just "come to you" in a 
 flash. Equally, some of the things slated for immediate release might 
 prove intractable at closer look.

That is so very true. For me, my best ideas and solutions come from jogging, not sitting at the computer. Jogging is my most mentally productive time, by far. I don't know why <g>. If it wasn't, I probably would have given it up out of boredom years ago.
Oct 16 2006
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 Georg Wrede wrote:
  From experience one knows that some of the "unbelievably hard" things 
 to implement may become just simple after a good night's sleep, or 
 after a nice morning shower some other problem might just "come to 
 you" in a flash. Equally, some of the things slated for immediate 
 release might prove intractable at closer look.

That is so very true. For me, my best ideas and solutions come from jogging, not sitting at the computer. Jogging is my most mentally productive time, by far. I don't know why <g>. If it wasn't, I probably would have given it up out of boredom years ago.

more blood flow to the head :-P
Oct 16 2006
prev sibling parent "John Reimer" <terminal.node gmail.com> writes:
On Mon, 16 Oct 2006 18:08:57 -0700, Walter Bright  
<newshound digitalmars.com> wrote:

 Georg Wrede wrote:
  From experience one knows that some of the "unbelievably hard" things  
 to implement may become just simple after a good night's sleep, or  
 after a nice morning shower some other problem might just "come to you"  
 in a flash. Equally, some of the things slated for immediate release  
 might prove intractable at closer look.

That is so very true. For me, my best ideas and solutions come from jogging, not sitting at the computer. Jogging is my most mentally productive time, by far. I don't know why <g>. If it wasn't, I probably would have given it up out of boredom years ago.

Well just be careful that you don't run into a car while you're deep in thought. :( ...Or hopefully you've managed to find a running route away from traffic. -JJR
Oct 16 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Georg Wrede wrote:
 It's a
 bit hard to keep track of things unless one regularly reads the NG. The
 worst thing is that whenever something "big" happens, something like
 5-10 threads with 1000+ messages pops out of nowhere. It takes a week to
 realize what's going on :-I

My feelings exactly. Stay here 18 hours per day and nothing happens. Get out of town for 2 days, and all of a sudden you find 500 unread messages. But what bugs me even more is that I continually keep finding "already old" things that have surreptitiously been fixed or implemented in D, and by still asking for them here I just make a fool of myself. No help rereading the entire HTML documentation tree and all the posts here between every release. Seems like the only way to do this is to implement a diff system that goes through the whole dmd tree between each and every release. At times it really is frustrating.

Yes, and that's simple actually, I've been doing that since the latest 10 revisions or so. Just put the spec under SVN, and on a new release unpack dmd and do: svn diff > dmdXXX.txt svn commit -m dmdXXX plus run 1 or 2 regexps on dmdXXX.txt to eliminate some trivial stuff, like the last updated stamps. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 18 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
rm wrote:

 If other reasonings can/need be give, please do so ..
 
 So back to libraries for D in D :-)
 What could be the reasons the Senior Darch is *ignoring* this?
 - he doesn't see a need for it (right now)
    => so it's low on his priority list
 - he doesn't have the resources to coordinate such an effort
 - he's planning to release D 1.0 before starting to think on libraries
    => are we talking about specifications for libraries
    => are we talking about a specific implementation (license?)
 - building libraries when important features are still being added
    => that might be regrettable in the not to distant future
    => when do you start with "standard" libraries, when do you stop
 evolving the language
 - are we talking about minimal batteries, or full blown batteries?

I think a batteries-included distribution would be a great help. The current situation makes it more difficult than it needs to be to get going with D. There's good stuff out there but you have to get this bit from here, then download dbuild from there, and mango from there etc etc. A batteries-included version should include * the best of the best from Dsource, * all the bindings and wrappers that are out there (SDL, GL, system headers, wxD etc) * editor integration scripts & tools from the wiki * and numerous sample programs that demonstrate good D coding practices * and samples showing how to accomplish various tasks in D > text processing > shell-script type things > a little game demo > GUI programming > template metaprogramming > good use of modules > numerical computing > etc...). * And it should have an installer for platforms where that makes sense. This seems like it would be a very good thing to have ready for the official 1.0 release. The 1.0 announcement will at the very least get attention from Slashdot I'm sure, and probably from other quarters of the net as well. It would be good if the folks who come poking to see what 1.0 looks like were greeted with a user-friendly package that gives them everything they need to be productive with D, and see instantly how useful D is for a wide variety of things. I think most of this stuff exists already, except maybe sample programs, but it's more a matter of putting it all together and getting permission from everyone to bundle it all up into one package. I don't have the time (or knowledge) to make such a beast, but I'd surely be willing to do testing of it (the Windows version, anyway). --bb
Oct 15 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Bill Baxter wrote:
 I think a batteries-included distribution would be a great help.
 The current situation makes it more difficult than it needs to be to get 
 going with D.
 
 A batteries-included version should include

<lots of good stuff deleted> True. Currently, the DMD zip seems to be geared towards people who already have been with us for a long time. It looks as if it's taken for granted that any essential libraries are already downloaded on your machine if you want to do any other stuff than just CLI-essentials. The batteries-included version should be the default. (And only then, maybe, a bare-bones version also available, a la the current zip.) --- Probably we all here are either too used to D as-is, or simply too savvy or professional to ever notice how actually *huge* the difference between bare-bones and batteries-included is for the expansion velocity of D. --- Times change. Most of even ourselves don't anymore go to the computer store to find the box, to the next to buy the hard drive, the internet for the monitor, and to a surplus store for the floppy drive. No, we buy the whole thing ready-made. The $100 we could save with an inordinate amount of work and running, simply isn't worth it anymore. Today, those shopping for a new programming language don't want to do that kind of legwork either! -- Especially when the D community (as a whole, inlcuding DM) makes it exceptionally hard for the newcomer to ever get a grasp of what is available and what is outdated and where to start looking in the first place.
Oct 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Georg Wrede wrote:
 -- Especially when the D community (as a whole, inlcuding DM) makes it 
 exceptionally hard for the newcomer to ever get a grasp of what is 
 available and what is outdated and where to start looking in the first 
 place.

If you (or anyone else) would like to come up with a "getting started" text, including links for the best libraries, tools, etc., I'd be more than happy to host it on the Digital Mars D site.
Oct 16 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 Georg Wrede wrote:
 
 -- Especially when the D community (as a whole, inlcuding DM) makes it 
 exceptionally hard for the newcomer to ever get a grasp of what is 
 available and what is outdated and where to start looking in the first 
 place.

If you (or anyone else) would like to come up with a "getting started" text, including links for the best libraries, tools, etc., I'd be more than happy to host it on the Digital Mars D site.

It's not that simple. To really alleviate the "batteries not included problem", the list should be short and sweet. This inevitably means recommending one GUI lib, one this and one that, and then showing from where, and how to get it up and running in no time. The whole point of the text being Simplicity. But then every competing GUI and other lib would come crying about why they are not chosen or included. Even worse, if such a text were on the DM site itself, this would obviously give some semi-official status to the chosen, and the rivals would feel bad. =========== There is a solution, but I don't know what folks think about it. Suppose we let people create competing distros of D? "Download Georg's distro, it's cool, or get Derek's distro, it's useful. Or get the plain DM distro and build your own system around it." That's essentially how Linux does it. Batteries included.
Oct 16 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Georg Wrede wrote:
 Walter Bright wrote:
 Georg Wrede wrote:

problem", the list should be short and sweet. This inevitably means recommending one GUI lib, one this and one that, and then showing from where, and how to get it up and running in no time. The whole point of the text being Simplicity. But then every competing GUI and other lib would come crying about why they are not chosen or included. Even worse, if such a text were on the DM site itself, this would obviously give some semi-official status to the chosen, and the rivals would feel bad.

Is there really so much D code that they couldn't just all be in there? I'd love to have them all in one place so I could take em all for a spin and see what works for me. How big would it be? Python's up to a 10MB download now, but I'm certainly not complaining about it. It could be 50MB for all I care. The other option is to have something net-connected like the python easy_install stuff or the cygwin installer, or I suppose things like fink (though I've never used it), and apt-get. Of those I think the Cygwin model makes most sense. You get a front-end configurator to run that lets you pick which modules you want in addition to the core. Of course that's a lot more work / infrastructure to set up. --bb
Oct 17 2006
next sibling parent mike <vertex gmx.at> writes:
Am 17.10.2006, 10:56 Uhr, schrieb Bill Baxter <dnewsgroup billbaxter.com=
:

 The other option is to have something net-connected like the python  =

 easy_install stuff or the cygwin installer, or I suppose things like  =

 fink (though I've never used it), and apt-get.   Of those I think the =

 Cygwin model makes most sense.  You get a front-end configurator to ru=

 that lets you pick which modules you want in addition to the core.  Of=

 course that's a lot more work / infrastructure to set up.

 --bb

http://www.bloodshed.net/ I worked a long time with Dev-C++ and the Devpack system was really nice= - = with an installer which could be started directly from the IDE, afair ev= en = the help files of all packages where accessible from the ide. -mike -- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Oct 17 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 
 The other option is to have something net-connected like the python 
 easy_install stuff or the cygwin installer, or I suppose things like 
 fink (though I've never used it), and apt-get.   Of those I think the 
 Cygwin model makes most sense.  You get a front-end configurator to run 
 that lets you pick which modules you want in addition to the core.  Of 
 course that's a lot more work / infrastructure to set up.

Personally, I would love for D libraries to be distributed this way. Ruby Gems does this too, and implementation issues aside, the basic concept is just fantastic. Sean
Oct 17 2006
next sibling parent Brad Anderson <brad dsource.org> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 The other option is to have something net-connected like the python
 easy_install stuff or the cygwin installer, or I suppose things like
 fink (though I've never used it), and apt-get.   Of those I think the
 Cygwin model makes most sense.  You get a front-end configurator to
 run that lets you pick which modules you want in addition to the
 core.  Of course that's a lot more work / infrastructure to set up.

Personally, I would love for D libraries to be distributed this way. Ruby Gems does this too, and implementation issues aside, the basic concept is just fantastic.

The example I am familiar with is Gentoo's Portage, with the 'emerge' utility. I have wanted dsource,org to serve this role for a while now. Maybe Gregor's DSSS will do the trick? BA
Oct 17 2006
prev sibling parent reply J Duncan <jtd514 nospam.ameritech.net> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 The other option is to have something net-connected like the python 
 easy_install stuff or the cygwin installer, or I suppose things like 
 fink (though I've never used it), and apt-get.   Of those I think the 
 Cygwin model makes most sense.  You get a front-end configurator to 
 run that lets you pick which modules you want in addition to the 
 core.  Of course that's a lot more work / infrastructure to set up.

Personally, I would love for D libraries to be distributed this way. Ruby Gems does this too, and implementation issues aside, the basic concept is just fantastic. Sean

I have been discussing this idea pretty much since I came to D. Gregor is working on the DSSS project and he had discussed putting in some sort of 'netinstall' option. At any rate this is something we eventually have to do, without a doubt!
Oct 17 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
J Duncan wrote:
 Sean Kelly wrote:
 Bill Baxter wrote:
 The other option is to have something net-connected like the python 
 easy_install stuff or the cygwin installer, or I suppose things like 
 fink (though I've never used it), and apt-get.   Of those I think the 
 Cygwin model makes most sense.  You get a front-end configurator to 
 run that lets you pick which modules you want in addition to the 
 core.  Of course that's a lot more work / infrastructure to set up.

Personally, I would love for D libraries to be distributed this way. Ruby Gems does this too, and implementation issues aside, the basic concept is just fantastic. Sean

I have been discussing this idea pretty much since I came to D. Gregor is working on the DSSS project and he had discussed putting in some sort of 'netinstall' option. At any rate this is something we eventually have to do, without a doubt!

I think it'd be cool, too.
Oct 17 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 J Duncan wrote:
 Sean Kelly wrote:
 Bill Baxter wrote:
 The other option is to have something net-connected like the python 
 easy_install stuff or the cygwin installer, or I suppose things like 
 fink (though I've never used it), and apt-get.   Of those I think 
 the Cygwin model makes most sense.  You get a front-end configurator 
 to run that lets you pick which modules you want in addition to the 
 core.  Of course that's a lot more work / infrastructure to set up.

Personally, I would love for D libraries to be distributed this way. Ruby Gems does this too, and implementation issues aside, the basic concept is just fantastic. Sean

I have been discussing this idea pretty much since I came to D. Gregor is working on the DSSS project and he had discussed putting in some sort of 'netinstall' option. At any rate this is something we eventually have to do, without a doubt!

I think it'd be cool, too.

Oh no! You may have just killed it! ;-) --bb
Oct 17 2006
parent John Reimer <terminal.node gmail.com> writes:
LOL! Good one, Bill.

Not likely, though.  I think Gregor has a great idea, and I hope he
carries it to fruition. :)

-JJR
Oct 17 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 On Mon, 16 Oct 2006 16:55:55 +1000, Walter Bright
 I encourage, and have encouraged, anyone who wants to do this. Any or 
 all parts of Phobos can be used as a starting point. The compiler is 
 my central focus, to enable great libraries to be written.

Are you saying that, for example, you would have no problems with Phobos being taken from DigitalMars and moved to DSource so that everyone who needed to could get to submit changes to the library that would actually be applied.

The license for the Phobos source code certainly allows that, and that's part of the point of having the license be that way. So no, I have no problem with that.

Great to hear you agree. Before going nuts, can we discuss your feelings towards actually using an externally hosted phobos (or other libraries for that matter) in future dmd release tarballs? What sort of coordination would you envision? Would you take select patches and merge with your internal tree? Abandon your internal tree? Today you release at your whim. External development of pieces changes that model. Assuming a community develops around an externally hosted (be it a fork or the primary) version of phobos, a slightly more mature release process probably ought to develop. Maybe even introduce the concept of beta versions (which might help with the paper-hat bugs like left in debugging code :) I'm willing to bet that people like Thomas would be willing to give beta releases a spin. In his case giving it a whirl through dstress to find regressions before they hit the street. Later, Brad
Oct 16 2006