John Reimer wrote:
> 2) It was never suggested (to my knowledge) that the language should
> be open-sourced.  This was not the object of the "F-word"
> discussions.

Ouch, something hit my ankle!

I have to elaborate on my Micro Forks talk.

The Micro Forks were actually not demands to open source DMD. Instead, I was thinking of GDC packaged so that any beginner could start tinkering "out of the box".

Agreed on both counts.  In my opinion, it's going to happen.  I see where D is going, and even if Walter doesn't want to lose any control at all, it's still going to have to happen.

It would take an external force to stop D, I think, and if it doesn't stop it's going to be too much for Walter.  Eventually, he will see that it has to change for D to grow, and I am pretty sure he won't hold it back.

It just means it might take a bit longer, is all.

As for peer review: good point.  I had applied it to things other than code before, but I'd never thought of it in quite that general a scope.

-[Unknown]


> I too wish that Walter would accept some help. He still needs to have
> ultimate say about what goes into D, but there is no need for him to do all
> the leg-work. 

On Thu, 21 Apr 2005 21:23:13 -0700, Unknown W. Brackets wrote:

> As for peer review: good point.  I had applied it to things other than code before, but I'd never thought of it in quite that general a scope.

We have used it on documentation, test cases, training materials, specifications, tenders, in-house work processes, project planning, management summaries, etc ... in fact everything that has a human-readable output produced by human effort. And I suspect that if we were in the building construction business, we'd apply it to blueprints, drawings, and actual buildings too.

The results have been always positive. When I first introduced it to the company, I trained a small development team (6 people) in how to do it well, and their bug rate went down from 95% to 1% in three months. That's right, nearly every program they released to a client for user acceptance testing failed. And *just* by doing peer reviews, we got that down to one program in 100 which failed. After some more experience and training, the team began to teach other teams in the company. That built up a solid collection of reviewing checklists, better coding and development standards, and a *lot* of pride in their work. The overall company customer-fail rate went down to around 0.1% (1 in a 1000) inside of six months.

Naturally enough, I didn't get a nice bonus for it either ;-)

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v2.03 released 20/Apr/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
22/04/2005 2:48:49 PM

Peer review is an amazingly powerful tool.

A nice effect is seen when one is explaining one's code to a peer. Just the very act of explaining something can lead one to seeing it from a different and/or fresh perspective, and consequently discover bugs.

"Derek Parnell" <derek@psych.ward> wrote in message news:1ok0kbl844k03.nrcpe9oqyjqe.dlg@40tude.net...
> On Thu, 21 Apr 2005 21:23:13 -0700, Unknown W. Brackets wrote:
>
>> As for peer review: good point.  I had applied it to things other
>> than
>> code before, but I'd never thought of it in quite that general a
>> scope.
>
> We have used it on documentation, test cases, training materials,
> specifications, tenders, in-house work processes, project
> planning,
> management summaries, etc ... in fact everything that has a
> human-readable
> output produced by human effort. And I suspect that if we were in
> the
> building construction business, we'd apply it to blueprints,
> drawings, and
> actual buildings too.
>
> The results have been always positive. When I first introduced it
> to the
> company, I trained a small development team (6 people) in how to
> do it
> well, and their bug rate went down from 95% to 1% in three months.
> That's
> right, nearly every program they released to a client for user
> acceptance
> testing failed. And *just* by doing peer reviews, we got that down
> to one
> program in 100 which failed. After some more experience and
> training, the
> team began to teach other teams in the company. That built up a
> solid
> collection of reviewing checklists, better coding and development
> standards, and a *lot* of pride in their work. The overall company
> customer-fail rate went down to around 0.1% (1 in a 1000) inside
> of six
> months.
>
> Naturally enough, I didn't get a nice bonus for it either ;-)
>
> -- 
> Derek Parnell
> Melbourne, Australia
> http://www.dsource.org/projects/build/ v2.03 released 20/Apr/2005
> http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
> 22/04/2005 2:48:49 PM

On Fri, 22 Apr 2005 15:49:01 +1000, Matthew wrote:

> Peer review is an amazingly powerful tool.
> 
> A nice effect is seen when one is explaining one's code to a peer. Just the very act of explaining something can lead one to seeing it from a different and/or fresh perspective, and consequently discover bugs.
> 
Exactly, and it works at all levels and is so simple.

My 10-year-old daughter was writing a story for her homework. There was one paragraph that was just not coming out right. So I got her to explain to me what the paragraph was trying to say, as opposed to what it was actually saying. The act of her explaining it to me enabled her to discover the precise words that the paragraph needed. It only took a few minutes.

-- 
Derek
Melbourne, Australia
22/04/2005 4:32:33 PM

I find this works remarkably well with comments as well, so long as you do them after the fact, but too many programmers have that three step "always out of date, always wrong, or always missing" opinion of them.

Really, any review (even self review) tends to find bugs, mistakes, or bottlenecks.  Explaining it - whether in speech, comments, or coding documentation - tends to help you reapply the concepts in a very enlightening manner.

This works, as Derek Parnell mentioned, on other things as well - even math, history, speech skills, and the like.  It all goes back to the well-accepted idea that you never really know something until you both can and have taught it to someone else.

-[Unknown]


> A nice effect is seen when one is explaining one's code to a peer. Just the very act of explaining something can lead one to seeing it from a different and/or fresh perspective, and consequently discover bugs.

Yes, it is so nice when more than one way of thinking is supported... as I was just stating in another thread should be much more common than it is.  :)

TZ

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d49f4t$14ab$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d49ed9$13kn$1@digitaldaemon.com...
> >
> > "Andreas Schmid" <monkey@gmx.info> wrote in message news:d4997k$v07$1@digitaldaemon.com...
> >> I know that many programmers dislike garbage collection. I suspect that
> > only
> >> true experts like Walter really know how expensive a garbage collector is
> > in
> >> various situations, can correctly evaluate its usefulness and
> >> devise an
> >> efficient implementation - and am afraid that if D had been a
> >> community-project from the ground up, this wonderful feature
> >> would have
> > been
> >> one of the first to be dropped due to popular demand.
> >
> > I, for a very long time, was convinced that garbage collectors
> > were crutches
> > for poor programmers, and that there's no way a gc app could beat
> > a
> > carefully written explicitly memory managed app. It's so obvious
> > by
> > inspection. It's the conventional wisdom (see the thread entitled
> > "Why do
> > you program in C++?" 4/18/2005 on comp.lang.c++.moderated).
> >
> > Then, when writing a Java compiler, I was forced into dealing with
> > one.
> > Imagine my disbelief when I discovered that gc programs are often
> > *faster*,
> > in addition to being quicker to write and less buggy. This effect
> > is often
> > why D outperforms C++, to the point where the proponents of the
> > Conventional
> > Wisdom have literally accused me of "sabotaging" C++.
> >
> > (Of course, gc isn't a panacea for all memory management problems,
> > which is
> > why D allows one to use explicit memory management where that
> > makes sense.)
> >
> > An interesting discovery I made was that much of the numbing
> > complexity in
> > C++ comes from attempts to deal with managing memory.
>
> Yes, and, alas, this gets tied up in other GC-languages with other resources, which is so wrong-headed it makes your cheeks laugh. Thankfully we have auto in D, and therefore adroitly sidestep the debate completely. ;)
>
>
>

Yep.  I've always felt that a person generally learns more by teaching than by studying.  :)

TZ

"Unknown W. Brackets" <unknown@simplemachines.org> wrote in message news:d4a92l$1tqc$1@digitaldaemon.com... *snip*
> This works, as Derek Parnell mentioned, on other things as well - even math, history, speech skills, and the like.  It all goes back to the well-accepted idea that you never really know something until you both can and have taught it to someone else.
>
> -[Unknown]
>

Georg Wrede wrote:

>> 2) It was never suggested (to my knowledge) that the language should
>> be open-sourced.  This was not the object of the "F-word"
>> discussions.
> 
> Ouch, something hit my ankle!
> I have to elaborate on my Micro Forks talk.
> 
> The Micro Forks were actually not demands to open source DMD. Instead, I was thinking of GDC packaged so that any beginner could start tinkering "out of the box".

I don't understand this, Walter has "open-sourced" D long ago ?
(at least the parsing/lexing/front-end and the standard library)

That the back-end of DMD is not open source is understandable,
and as far as I know most of it is being shared with DMD anyway
(just as the GDC backend is being shared with GCC, I suppose ?)
And since both DMC and DMD are free of charge, most don't care.


The only thing that is missing now is the D specification itself,
but as I understood it - that was mostly due to fear-of-forking
before it had been finalized as "D (the programming language) 1.0" ?
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/20694

Hopefully this means that it will eventually be an open standard...
(no idea what's involved in getting something like ISO or EMCA)


Meanwhile, my company is sponsoring work on the Mac version of GDC
both based on "hope" and since it has already proven useful enough.

It's all GPL. (will be on http://sourceforge.net/projects/gdcmac/)
But currently the only documentation is on Digital Mars home page.

--anders

TechnoZeus wrote:

>> This works, as Derek Parnell mentioned, on other things as well -
>> even math, history, speech skills, and the like.  It all goes back
>> to the well-accepted idea that you never really know something
>> until you both can and have taught it to someone else.
> 
> Yep.  I've always felt that a person generally learns more by
> teaching than by studying.  :)

Funny, I read that as *earns* more - and agreed to that too ;-)

--anders