I wish to express my gratitude towards Walter for his reluctance for change. While there are many times that he does finally make changes he was hardily against, "Shown the light" you might say. I believe that he should not only be applauded for putting up with some of the attacks toward him, but that this stone wall helps to clearly define the problem.

With such strong views coming from both ends, ideas build on each other to provide what could be a much better solution. We still have yet to really see what has come out from the Const stuff, however without such great opposition to it some serious problems my not have been resolved. Many are still unsure of this new direction and there is go reason to be.

I do not wish to say that Walter is alway correct in his standings, only that it provides a very good buffer to stupid changes that would result in later removal and rabid feature growth that does not need to be there. And I believe even those that become frustrated trying to get a change across no matter how trivial it seems do agree on the benefits from having such a barrier.

Jesse Phillips wrote:
> I wish to express my gratitude towards Walter for his reluctance for change. While there are many times that he does finally make changes he was hardily against, "Shown the light" you might say. I believe that he should not only be applauded for putting up with some of the attacks toward him, but that this stone wall helps to clearly define the problem.
> 
> With such strong views coming from both ends, ideas build on each other to provide what could be a much better solution. We still have yet to really see what has come out from the Const stuff, however without such great opposition to it some serious problems my not have been resolved. Many are still unsure of this new direction and there is go reason to be.
> 
> I do not wish to say that Walter is alway correct in his standings, only that it provides a very good buffer to stupid changes that would result in later removal and rabid feature growth that does not need to be there. And I believe even those that become frustrated trying to get a change across no matter how trivial it seems do agree on the benefits from having such a barrier.

while I completely agree with the goal of:
<qoute>
 provide a very good buffer to stupid changes that would result
 in later removal and rabid feature growth that does not need to be
 there.
</qoute>
I'm not sure the current way is the best for D. Instead of arguing for
ever for each tiny change until the community can persuade Walter to
change something in D - like the recent change to the opEqueals return
type to bool (that only took what, two years?) there are other much more
efficient ways to provide a buffer to protect the language from unneeded
changes.
Python for example has pypy, a python compiler written in python. every
new feature or idea proposed by the community has a pep (that's how they
call that, right?) and if needed they can easily develop an extension to
the that compiler (easy to do since pypy is written in python and not C)
that can be tested in a separate version outside of the "real" python
language. just create a prototype and test new ideas. if it works than
it would be integrated in a future version of python. if it doesn't work
just discard that code and move on.
same thing goes even for C++: there's an experimental branch of gcc to
test the design of features that will be added to c++0x. I recall
stumbling online on a gcc-concepts version to test the new concepts
feature, for example.
D doesn't have anything like this. the thread about a compiler-kit
showed that. people offer to pay 100$ to get the DMD backend as a lib. I
know that the money is not the main issue here and that Walter has
copyright concerns and such, but nevertheless this hurts D since there
is no way to test new ideas, and Walter puts this wall to protect the
released version of D.

All I want to say is basically: wouldn't it be better for D and much
faster if people could just create a modified test version of dmd to
test new ideas instead of trying to convince Walter to test those same
ideas himself? that way const would have been solved by now, and the 3
versions of it could have been developed simultaneously and require much
less effort to change.
D needs something akin to debian's three branches, IMO.

"Yigal Chripun" <yigal100@gmail.com> wrote in message news:g55vng$2b6q$1@digitalmars.com...

> change something in D - like the recent change to the opEqueals return type to bool (that only took what, two years?)

Oh, longer than that!  Arcane Jill was arguing for it in 2004, and probably earlier.

Reply to Yigal,

> Python for example has pypy, a python compiler written in python.
> every new feature or idea proposed by the community has a pep (that's
> how they call that, right?) and if needed they can easily develop an
> extension to the that compiler (easy to do since pypy is written in
> python and not C)
> 

without actually reading the whole post...

and as a shameless plug...

I'm kind of working on a D compiler in D that has some of that in mind. I want adding "optional language features" to be easy. I think I have even found a way (on the fly regeneration of vtbls and other evil hacks) to do it.

OTOH I'm not making progress very fast to that puts a bit of salt on the issue.

Yigal Chripun wrote:
> All I want to say is basically: wouldn't it be better for D and much
> faster if people could just create a modified test version of dmd to
> test new ideas instead of trying to convince Walter to test those same
> ideas himself? that way const would have been solved by now, and the 3
> versions of it could have been developed simultaneously and require much
> less effort to change.

There's a 100% open source implementation of D - gdc. If someone wants to create an experimental branch, like gcc-concepts, it only takes motivation.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:g563h5$2kvl$1@digitalmars.com...
> Yigal Chripun wrote:
>> All I want to say is basically: wouldn't it be better for D and much faster if people could just create a modified test version of dmd to test new ideas instead of trying to convince Walter to test those same ideas himself? that way const would have been solved by now, and the 3 versions of it could have been developed simultaneously and require much less effort to change.
>
> There's a 100% open source implementation of D - gdc. If someone wants to create an experimental branch, like gcc-concepts, it only takes motivation.

It takes that...and the patience and masochism to actually dive into the gcc source.

Seriously, I tried twice to merge GDC with DevKitARM (another unofficial GCC
branch that adds support for modern Nintendo targets) and gave up both times
because every little step of the way was such an unbelievable
pain-in-the-ass. There's at least one other person that attempted it too,
and the last time I heard anything about it (many months ago) he hadn't
gotten much farther than I had.

On Thu, 10 Jul 2008 17:58:36 -0400, Jarrett Billingsley wrote:

> "Yigal Chripun" <yigal100@gmail.com> wrote in message news:g55vng$2b6q$1@digitalmars.com...
> 
>> change something in D - like the recent change to the opEqueals return type to bool (that only took what, two years?)
> 
> Oh, longer than that!  Arcane Jill was arguing for it in 2004, and probably earlier.

We didn't have a bool type at that time, though maybe it was for bit? Anyway, implementation time vs convincing it should be changed.

Yigal, I like your idea, but as Walter has said there are open-source compilers and if GCC is to much off a headache finish LVDCSGORO whatever.

On Thu, 10 Jul 2008 15:47:02 -0700, Walter Bright wrote:

> Yigal Chripun wrote:
>> All I want to say is basically: wouldn't it be better for D and much faster if people could just create a modified test version of dmd to test new ideas instead of trying to convince Walter to test those same ideas himself? that way const would have been solved by now, and the 3 versions of it could have been developed simultaneously and require much less effort to change.
> 
> There's a 100% open source implementation of D - gdc. If someone wants to create an experimental branch, like gcc-concepts, it only takes motivation.

Well, if the things would be so simple...

It is not about creating a branch. It is about having a D compiler. All things that strive the people to different directions weak the community.

Personally, I like D. Otherwise I would not be posting here. Professionally, I can only suggest D for freetime activities. It is not about the superiority of the language spec; it is about having a stable environment to build things.

Anyway, I'm a bit fed up with all these things. If we do not want to co- operate, next time I change to my "T" programming language (T stands for ToyHLL, and it has several fancy command line arguments, like being a serious smart-ass).

Markus Koskimies wrote:
> Personally, I like D. Otherwise I would not be posting here. Professionally, I can only suggest D for freetime activities. It is not about the superiority of the language spec; it is about having a stable environment to build things.

I don't know really what you're asking for. Is it to have a D compiler that anyone can modify and try new things out, or is it a stable compiler that only gets bug fixes?

Jesse Phillips wrote:
> On Thu, 10 Jul 2008 17:58:36 -0400, Jarrett Billingsley wrote:
> 
>> "Yigal Chripun" <yigal100@gmail.com> wrote in message news:g55vng$2b6q$1@digitalmars.com...
>>
>>> change something in D - like the recent change to the opEqueals return type to bool (that only took what, two years?)
>> Oh, longer than that!  Arcane Jill was arguing for it in 2004, and probably earlier.
> 
> We didn't have a bool type at that time, though maybe it was for bit? Anyway, implementation time vs convincing it should be changed.
> 
> Yigal, I like your idea, but as Walter has said there are open-source compilers and if GCC is to much off a headache finish LVDCSGORO whatever.

Two problems:
A) as already noted by others, messing with gcc source code is not easy
and that is a major point in my post. there's a reason python uses pypy
to test new features instead of their C based implementation: what would
take a month with c is done in a day or two with python. You don't care
for performance for this since it's just for testing purposes. when the
python devs are convinced that the feature should be added to the
official version than they'll port it to C, optimize it, etc..
using gcc to test new features is the complete reverse of that.

B) this point is even more important - pypy is officially used by the
python devs. sure I can use gcd to test new ideas. I also can use other
compilers like dil, dang, etc. since those are not the official
reference implementation than if the new idea does pan out to be a good
thing, it still doesn't mean Walter will even look at it and consider
adding it to dmd. than we go back to trying to convince him that we have
a good idea. the whole process I described needs to be part of the
development process of the official reference implementation in order to
be effective, otherwise, we get a fork of D.
the gcc-concepts branch for example is the version used by the c++
committee itself for testing purposes, not a third-party fork of gcc.
it'll be merged to the gcc main trunk when the feature is finalized.
same goes for all the approved pypy extensions for python.
thus, Walter needs to be part of such a development process and be the
final decision maker on what new ideas will be incorporated into D.