"Andy Walker" <Andy_member@pathlink.com> wrote in message news:ae4cp2$1u39$1@digitaldaemon.com...
> PERL has done will by Larry Wahl, as well.
>
> As for me, I am not much impressed with the products of committees.

I like Larry's approach with Perl.

Agreed, we keep all the overhead and responsibility with Walter, and then just get him to do things via a potent combination of guilt and pride. Love it!

"Andy Walker" <Andy_member@pathlink.com> wrote in message news:ae4cp2$1u39$1@digitaldaemon.com...
> In article <ae30b2$h63$1@digitaldaemon.com>, Philippe Elie says...
> >
> >apologize for my poor english ...
>
> As far as I am concerned, you do not need to aplogize.  I am from the
U.S.,
> and I have not yet learned "proper" English.
>
> >
> >An attempt to clarify things about gcc:
> >
> >GCC compiler is a core compiler + a certain number of
> >front end, the C compiler is for historical reason in the
> >core compiler directory. There is not point in gcc which
> >forbid to use a front-end to build another front-end. g++
> >use this trick and is always compiled from the newly created
> >gcc C compiler so on, from recent gcc distribution, the C++
> >front-end is written in ISO C rather in K&R C. Actually there is
> >no attempt to use a front-end other than the C compiler itself
> >but you can write a front-end in C++, and compile it through
> >the newly compiled c++ compiler. That's "just" need trickery in
> >configure/makefile (and indeed you can't get only the Core+C
> >minimal distribution). Actualy this is used in many part of gcc,
> >mainly for library, (a part of the java runtime is written in C++ ;).
> >It allows to create portable compiler which, at start of build
> >process, only assume it exist a vaguely K&R or ISO compliant
> >compiler installed
> >
> >About the tree RTL generation: The Run Time Language is the
> >portable data struct which must describe the program being
> >to be compiled. Because the RTL is already used in C/C++/ada
> >/java/PASCAL there is probably no point to create new RTL
> >expressions for D. I mean than I hope that D does not contains
> >any things that can't be expressed in the other language given
> >above ? That's one of the first point which needs to be checked.
>
> I am so sure of this that I did not bother to think about it.  There is nothing really fancy or sophisticated about Bright D.  Instead, it is a simple and solid approach, doing the things that should have been done twenty years ago.
>
> >
> >You need also a shell script/unix basic tools/Makefile wizard, configuration/Makefile models of gcc are not easy to understand.
>
> I can usually figure out this kind of thing.  My code is usually not very elegant, but it works.
>
> >
> >What about the gcc compiler version you want to use to start this work ? 3.1 compiler has been released a few time ago, 2.95.3 is probably the most used actually, 3.0 compiler will probably become the most used in one year.
>
> Yes, I know 3.1 is brand new.  I prefer to try to hook up to it.  Time is a very scarce resource, and I do not have time to try to hook Bright D to the 2.95.3 version.
>
> >
> >If you want also the front-end acceptable in future for inclusion in
> >a gcc distributions you need to comply with the GNU standards
> >coding, to prove than the language is usefull (used but a sufficiently
> >number of people, apologize for the lack of precision about "sufficiently
> >number of") and indeed the front end must be GPL'ed.
>
> I think "sufficiently number of people" is exactly precise.
>
> >
> >The licence terms of the D specifications is perhaps a problem
> >
> >"Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved"
> >
> >Is this means than the document which describe D is copyrighted or the specifications themself are copyrighted ? (I'm newbie on copyright things ...)
>
> I have some idea about how they work.  It will require us persuading Walter to sign an assignment for the front end that he has already released.  I think he knows that.  That is why he released the front end without the back end.  Perfectly reasonable as far as I am concerned.
>
> >
> >Note than at the point of your current work I think it's better than D
> >specifications can be modified only by one person but, in futur,
> >many people can get a bad feeling to work if specifications
> >are closed.
>
> Linux seems to be working very well, having gone for years with the specifications in the hands of just one person.
>
> PERL has done will by Larry Wahl, as well.
>
> As for me, I am not much impressed with the products of committees.
>
> >
> >regards,
> >Philippe Elie
> >
> >
>
> Andy Walker

Andy Walker wrote:
> ...
> 
> Linux seems to be working very well, having gone for years with the specifications in the hands of just one person.  
> 
> PERL has done will by Larry Wahl, as well.  

Python and Ruby have also done well with one person in charge.  Eiffel has been less spectacularlly successful, though it has a nice theoretical excellence.

OTOH, we have C, C++, Cobol, Ada, Fortran, ...

Both sides have successes and failures.  The languages with a single chief designer seem to maintain a more central and simple vision, but the products of committees tend to be more encompassing. (Theoretically, this is silly, as they are all complete languages.  In practice, however...)

> 
> As for me, I am not much impressed with the products of committees.
> 
> 
>>regards,
>>Philippe Elie
>>
>>
> Andy Walker