May 12, 2009
Walter Bright wrote:
> Georg Wrede wrote:
>>  From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) perspective, _the_ newsgroup should be called D and it should contain D1 discussions. And then there should be a less conspicuous NG called "future releases discussions", which would be D2.
> 
> Sounds like a good idea.

I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.


Andrei
May 12, 2009
grauzone wrote:
>  Everyone, you just wasted your time reading this posting.

Bestimmt.

Andrei
May 12, 2009
Andrei Alexandrescu wrote:
> grauzone wrote:
>>  Everyone, you just wasted your time reading this posting.
> 
> Bestimmt.

Reading and posting on the group is a great waste of time in general, so I hope it doesn't bother you too much.

> Andrei
May 12, 2009
On Mon, 11 May 2009 16:25:24 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> D1 is not complete. That has nothing to do with the bugs it still contains. It is not complete because there is documented functionality for which no implementation has yet been attempted. This assumes that the documentation is complete and accurate.
>> 
>> The D-Team should be dedicating resources to ensuring that the D1 implementation and D1 documentation are in alignment with each other. By dedicating, I mean that is all that this D1-subteam of the D-Team work on - no D2 work at all. Any D1 fixes that need to be propagated to D2 should be done by the D2-subteam. Priority should be given to getting D1 completed.
> 
> Please help me understand - why is contract inheritance preventing you from using D1? Exported templates haven't stopped anyone from using C++ compilers from Microsoft/Sun/Intel/etc. I don't think anyone has made a feature complete C99 compiler, either.

Contract inheritance is NOT preventing me use D1. I have never, not once, said that it has.

Is Contract Inheritance documented as being a part of D1's functionality? If yes, then is it implemented? If yes, then well done. If no, then is the documentation wrong or is DMD v1 incomplete?

If Contract Inheritance is not documented as being a part of D1's functionality then why are we talking about it?

I do NOT automatically associate completeness with worthiness. D1 is stable enough to use for production applications. I have never, not once, said otherwise.

My thinking re completeness is just this ...

  Docs say X is a function point of D1.
  DMD v1 does not implement X.
  Therefore, DMD v1 is not a complete implementation of D1.

That has NOTHING WHATSOEVER to do with deciding to use DMD v1 for important applications. It is an observation, not a criticism or a complaint.

If was to complain, and I'm not, I might mention that sometimes the impression I get is that the D-team feels that DMD v1 is as complete as its ever going to be but won't admit it.

If DMD v1 is intending to ever be a complete implementation of D1, then IMO there needs to be a concerted effort to reach a completed stage in DMD v1, independently of any work happening in the D2 arena.

If this is not the intention, IMO, it ought to be stated clearly in the DMD v1 documentation that DMD v1 is not the definitive D1 implementation. That would slow down the rate of people complaining about it being incomplete.

>> Unless of course, D1 is just a prototype for D2 and will thus be discarded the instant that D2 is released.
>> 
>> What are the support plans for D1 after D2 is released? (I consider current D2 releases as beta editions at best).
> 
> D1 will continue to be supported as long as there is a significant userbase for it. I've said this many times.

Times change. People change. Policies change. Readers of this newsgroup change. I just wanted confirmation of what the current policy was.

Is this policy recorded in the DMD v1 documentation? I couldn't find it.

> I also fail to understand this perception that D1 is abandoned. Every month an update is released for it that fixes a load of problems. D1 has led the way in ports to other platforms.

I have never said, not once, that D1 *is* abandoned. Stability and completeness are not the same thing, as you well know. In fact, I'm amazed at the amount of repairs that you are able to achieve, given the small resource pool that is available. All kudos to your good selves.

What I have said was that D1 /might/ be abandoned in the future, if and only if, D1 is to be considered as merely a prototype for D2. However, from your recent comments I'm now convinced that you do not see D1 as merely a prototype.

D2 is evolving from D1. D2 will be so significantly different from D1 as to almost class it as a different language. I'm sure that a lot of D1 code will not compile under D2, or if it does will have changed semantics.

But that is not an issue for me either; just an observation and not a complaint.

> What isn't being done with D1 is adding a boatload of new features - because that would destroy any pretense of it being a stable release.

Of course. Totally justifiable too. I am not asking for anything 'new' to be added to D1. But I do see that D1 and DMD v1 are not the same thing (yet).


Ok, so what is stopping me using D1? Below are some off-the-cuff ideas and it may be that I'm mistaken in my beliefs, so take that into consideration.

* I like what D2 has to offer, so I'll wait for that. I'm not in a hurry to use D as there is no current or approaching project that requires it.

* Phobos has missing functionality, which means I have needed to write that code myself. (Adding the functionality to D1 Phobos is not an option because D1 is 'closed' for additions.)

* Tango is too 'weird' for me to use. I'm not keen about the Everything-Is-An-Object style of coding. A personal preference, to be sure.

* Tango means I need to do a special installation of DMD plus it assumes an older version of DMD.

* I'm too busy to invest in something that I will need to rework for D2.

I really like D. I want to use it. But ... oh well, maybe I should just 'bite the bullet' and begin my next D project using D1 anyway. I can only learn from the experience, right?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 12, 2009
Derek Parnell wrote:
> Ok, so what is stopping me using D1? Below are some off-the-cuff ideas and
> it may be that I'm mistaken in my beliefs, so take that into consideration.
> 
> * I like what D2 has to offer, so I'll wait for that. I'm not in a hurry to
> use D as there is no current or approaching project that requires it.

There's always going to be "Coming Soon To A Compiler Near You!" with D. It's been undergoing improvement for 7 years now.


> * Phobos has missing functionality, which means I have needed to write that
> code myself. (Adding the functionality to D1 Phobos is not an option
> because D1 is 'closed' for additions.)

There are a lot of add-on libraries. There's no reason anyone cannot write one to fit various needs.


> * Tango is too 'weird' for me to use. I'm not keen about the
> Everything-Is-An-Object style of coding. A personal preference, to be sure.
> 
> * Tango means I need to do a special installation of DMD plus it assumes an
> older version of DMD.
> 
> * I'm too busy to invest in something that I will need to rework for D2.

While (without using a text preprocessor) you can't make the source code work for both D1 and D2, the amount of rework necessary is quite minor.


> I really like D. I want to use it. But ... oh well, maybe I should just
> 'bite the bullet' and begin my next D project using D1 anyway. I can only
> learn from the experience, right?

Reading about and using a language are entirely different things <g>.
May 12, 2009
On Mon, 11 May 2009 18:28:22 -0500, Andrei Alexandrescu wrote:

> Derek Parnell wrote:
>> The D-Team should be dedicating resources to ensuring that the D1
>> implementation and D1 documentation are in alignment with each other.
>>  By dedicating, I mean that is all that this D1-subteam of the D-Team
>>  work on - no D2 work at all. Any D1 fixes that need to be propagated
>> to D2 should be done by the D2-subteam. Priority should be given to
>> getting D1 completed.
> 
> Well thank you General :o).

In spite of the smiley, I'm still feel that your "General" comment is out-of-line and not fair.

If one cannot give opinions here then why do we bother.

> Derek, I have all respect for you and your contributions to D. The response below does not have the slightest intent to pick on you but to rein in an unhelpful pattern in this group.

Thank you and I understand.

> I invite you to see the paragraph quoted above through a different pair of eyes - the eyes of someone with a different vision of what should be done for D, and also (most importantly) who believes in it strongly enough to invest their own non-existing free time  in effecting that vision.

(btw, what exactly is that vision, and why do you think that it is
different from mine?)

> I confess that this couch quarterbacking is mightily frustrating for both Walter and myself. All the pieces are there for anyone with a vision to make it happen. I understand you wanted to share your opinion on what would be best for the future of D, and that's laudable in and by itself, but such opinions have lately become a choir of whines fulfilling a "if I want something from D, and I expect Walter to do it" pattern. We need the exact opposite - if you care, what can *you* do to make D better? D needs action and leadership.

I can only speak for myself here but I am not expecting Walter to do it all. In fact, I expect Walter to delegate tasks to others, but I get the feeling that is not the norm.

I cannot influence in any practical manner what happens to D1. I cannot code in C++ (effectively) so I'm unable to contribute to fixing bugs. I cannot add to Phobos as 'additions' are closed. I could improve the unit tests and documentation, but ... well, I might be a little behind the times, for the mechanisms for contributing code changes to Phobos and the documentation have been, for me, counter-productive. It is not a simple process and there is no feeling that my efforts will even make a difference. Your phrase "All the pieces are there" needs to be fleshed out, I think. Are you referring to the process that enables one to submit work for consideration into D? If so, what exactly is that process - Bugzilla is fine for issues and bugs, but is that also the method that we need to use for documentation updates and unit tests?

> And why is D1 not finished? Most "finished" languages have implementation insufficiencies. I've read a couple of days ago that D1 is unfinished (and unusable by implication) because contracts aren't inherited. If I were Walter, that would be the exact kind of claim that causes high blood pressure. This is ridiculous! Is *that* the feature that the building of a system hinges on? Is that really what's stopping you? Then go back and use contracts in C++, Java, or C#. My guess is, if anyone is whining that D1 is unusable because it doesn't have contract inheritance, tomorrow (should contract inheritance be fixed) they'll whine that it doesn't have named arguments, template virtuals, or a gorram cherry on top. Sheesh.

I realize your remarks above were not specifically directed towards myself, however I feel the need to respond.

I am not saying that D1 is not finished, but I am saying that DMD-v1 is not finished.

   D1 documentation says X is a function of D1.
   DMD-v1 does not implement X.
   Therefore DMD-v1 is not a complete implementation of D1.

Even though D1 is finished, DMD-v1 might not be finished.

Either the documentation is wrong or DMD-v1 is not complete yet.

I do not automatically associate incompleteness with unusable. They are not the same thing. There exists complete things that are unusable and incomplete things that are usable.

I believe that D1 is very suitable for production applications today. DMD-v1 has a level of stability and completeness that enables it to be used for important works right now.

I choose not to use D1 for totally different reasons that have nothing to do with functionality or defect rates.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 12, 2009
Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Georg Wrede wrote:
>>>  From a (go ahead, call it "shrewd" and "marketing liar", I won't mind) perspective, _the_ newsgroup should be called D and it should contain D1 discussions. And then there should be a less conspicuous NG called "future releases discussions", which would be D2.
>>
>> Sounds like a good idea.
> 
> I'm all for it. My guess, however, is that this is another case of couch quarterbacking that's unlikely to effect a touchdown. Today, the majority of discussions on digitalmars.d is about D2 because - surprise! - the stuff that people are interested in debating has mostly to do with D2. You can't tell people what they should be talking about. People vote with their pens. If a separate newsgroup is created for digitalmars.d.next, then that won't automatically increase the quantity and quality of D1-related traffic on digitalmars.d. Then the archetypal noob tunes to digitalmars.d, sees a tumbleweed rolling by, and moves on.

We could rename D.learn to D and D to D.future-issues.

Then the two newsgroups would be /appropriately seeded/.
May 12, 2009
Derek Parnell wrote:
> I am not saying that D1 is not finished, but I am saying that DMD-v1 is not
> finished.
> 
>    D1 documentation says X is a function of D1.
>    DMD-v1 does not implement X.
>    Therefore DMD-v1 is not a complete implementation of D1.
> 
> Even though D1 is finished, DMD-v1 might not be finished.
> 
> Either the documentation is wrong or DMD-v1 is not complete yet. 


So, make a list of the things mentioned in the docs that aren't in DMD, and I bet Walter and Andrei will take a hard look at your list, and probably remove most of those things from the docs.

That's definitely a contribution that everyone would value and welcome.
May 12, 2009
Stewart Gordon wrote:
> (a) having a spec that the public agrees to be complete and consistent

I think this is probably the most important of your points. Without a complete and consistent spec, there's no possible way to make a correct compiler. All features need to be in there, explaining how they should work in detail. This is a blocker for anyone who wants to write a D compiler currently, they have to go by dmd in some cases rather than the spec.

> (b) all language features implemented

I think this is probably least important currently. Most (if not all) major features have been implemented in D1, and D2 is still in alpha so has no requirement for this.

> (c) all of the most serious known bugs and most of the others fixed

This comes right after a complete spec on what I'd rate as important. While some of these bug fixes might be seen as "breaking changes" that shouldn't be in D1, I think we'll live. I know I'd rather have to update a load of code to comply with the spec than have a load of invalid code that works forever, even if it is a pain to update. I think frontend bugs should take priority here, as they effect all compilers that use it, not just dmd.

> But generally, it's about time D1 got a move on....

Agreed. I've had trouble getting people to use D due to (mainly) those 3 rough edges. Having 3 year old unfixed bugs in the bug tracker doesn't help with persuasion.

> ...when we reach this practical milestone, maybe we could call it D 1.1?

I guess this is up to Walter. Would D 1.1 just be a milestone for D, or would it need a new spec? Maybe D 1.1 could be a fork of D1 which introduces the breaking changes and finalizes the spec? That way we don't have the issue of breaking D1.0. When it is complete D1.0 could be marked deprecated and D1.1 could take its place. Or of course the changes could take place in D1.0 and gradually introduce the breaking changes, making D1.1 the final result (or maybe just D1.098, however many revisions of the compiler it takes :P).

Robert

May 12, 2009
Georg Wrede wrote:
> Derek Parnell wrote:
>> I am not saying that D1 is not finished, but I am saying that DMD-v1 is not
>> finished.
>>
>>    D1 documentation says X is a function of D1.
>>    DMD-v1 does not implement X.
>>    Therefore DMD-v1 is not a complete implementation of D1.
>>
>> Even though D1 is finished, DMD-v1 might not be finished.
>>
>> Either the documentation is wrong or DMD-v1 is not complete yet. 
> 
> 
> So, make a list of the things mentioned in the docs that aren't in DMD, and I bet Walter and Andrei will take a hard look at your list, and probably remove most of those things from the docs.
> 
> That's definitely a contribution that everyone would value and welcome.

Or start pushing patches.