View mode: basic / threaded / horizontal-split · Log in · Help
April 22, 2005
Re: Quality of D
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".
April 22, 2005
Re: Quality of D
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.
April 22, 2005
Peer reviewing (was: Quality of D)
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
April 22, 2005
Re: Peer reviewing (was: Quality of D)
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
April 22, 2005
Re: Peer reviewing
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
April 22, 2005
Re: Peer reviewing
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.
April 22, 2005
Re: Quality of D
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. ;)
>
>
>
April 22, 2005
Re: Peer reviewing
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]
>
April 22, 2005
Re: Quality of D
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
April 22, 2005
Re: Peer reviewing
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
1 2 3
Top | Discussion index | About this forum | D home