From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <87hf2v1wgj.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:

> 
>   It still amazes me that anyone, and I do mean anyone, can be so stuck in
>   a particluar "solution" instead of trying to solve the _problem_.  Such
>   behavior is _not_ a good sign for someone who wants to be a
>programmer.

The problem is -- as I stated before -- to find a LOC measurement for the
excercises in that book. So while finding a decent LOC (or whatever)
metrics I'll solve the problem. I think that is quite a good sign for
someone who wants to be a programmer.

Friedrich

From: ········@hex.net
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <b0Y96.240871$IP1.8252228@news1.giganews.com>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Erik Naggum <····@naggum.net> writes:
>>   It still amazes me that anyone, and I do mean anyone, can be so
>>   stuck in a particluar "solution" instead of trying to solve the
>>   _problem_.  Such behavior is _not_ a good sign for someone who
>>   wants to be a programmer.

> The problem is -- as I stated before -- to find a LOC measurement
> for the excercises in that book. So while finding a decent LOC (or
> whatever) metrics I'll solve the problem. I think that is quite a
> good sign for someone who wants to be a programmer.

If you truly wanted to be a _programmer_, then you should instead be
investigating things that are actually useful as techniques for
_programming_, such as studying algorithms and the sorts of
programming techniques actually used to produce working code.

A _programmer_ should look at things like:
 -> Common algorithms, as presented by Knuth, TAOCP volumes 1-3
 -> AI algorithms, perhaps as presented by Norvig, PAIP
 -> Lisp macro techniques, as per Graham, On Lisp

In contrast LOC measurements outright _distract_ you from programming,
because they do nothing _constructive_.

You cannot use LOC rules to _create_ a good program; such rules can
only give some _vague_ measure that takes a program and _throws most
of it away_.  LOC is not constructive; it tells you nothing of what
code to put in; all it tells you is some after-the-fact: "well, that
program seemed complex."
-- 
(reverse (concatenate 'string ····················@" "454aa"))
http://www.ntlug.org/~cbbrowne/wp.html
"As far as Saddam Hussein being a great military strategist, he is
neither a strategist, nor is he schooled in the operational arts, nor
is he a tactician, nor is he a general, nor is he as a soldier.  Other
than that, he's a great military man, I want you to know that."
-- General Norman Schwarzkopf, 2/27/91
From: Raymond Wiker
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <867l3r1u7m.fsf@raw.grenland.fast.no>
········@hex.net writes:

> Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > Erik Naggum <····@naggum.net> writes:
> >>   It still amazes me that anyone, and I do mean anyone, can be so
> >>   stuck in a particluar "solution" instead of trying to solve the
> >>   _problem_.  Such behavior is _not_ a good sign for someone who
> >>   wants to be a programmer.
> 
> > The problem is -- as I stated before -- to find a LOC measurement
> > for the excercises in that book. So while finding a decent LOC (or
> > whatever) metrics I'll solve the problem. I think that is quite a
> > good sign for someone who wants to be a programmer.
> 
> If you truly wanted to be a _programmer_, then you should instead be
> investigating things that are actually useful as techniques for
> _programming_, such as studying algorithms and the sorts of
> programming techniques actually used to produce working code.

        Also: consider things like parser generators. Do you count the
volume of generated code, or the input code? If the latter, how do you
compare something that uses a parser generator with something that is
produced manually?

        The input to the parser generator is (obviously!) going to be
much smaller than hand-written parsers, and is also going to be much
easier to maintain.

-- 
Raymond Wiker
·············@fast.no
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <87puhjzbpo.fsf@frown.here>
Raymond Wiker <·············@fast.no> writes:

> 
>         Also: consider things like parser generators. Do you count the
> volume of generated code, or the input code? If the latter, how do you
> compare something that uses a parser generator with something that is
> produced manually?

See this SEI document:
http://www.sei.cmu.edu/publications/documents/92.reports/92.tr.020.html

It's more than 150 pages on the problematic to find a loc counter. If
one looks into Watts book one can see that he follows tightly. I guess
that i not suprise because he had worked or is working there.

Regards
Friedrich
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <87lms7zbar.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:

> 
>   But somebody needs to put such obvious things in a book that sells a lot
>   so Friedrich Dominicus can buy it in a prestigous bookstore _and_ it has
>   to contain the above as an "exercise" before he'll listen to it.
>*sigh*

It seems that you did not have looked into that book. I do not know
how high you grade Watts, but IMHO he knows quite much about software
development and/or software quality.

And I do think he spend a lot of time on putting together
that book and if you look for the name you'll see that he spends 
a lot of time on research about Software development of high quality. 

So I'm quite happy that some people spend their time on writing such
books. He's not the only one but IMHO among the best.


> 
>   My cat spent 11 minutes, 50 seconds sleeping in my arms right now, fully
>   40 seconds longer than yesterday.  That makes me a 5.6% better person
>   than yesteday.  I cannot find any books that says this is a useless
>   measure of personal improvement, so it must clearly be a valid
>metric.
Feel free to take it as a valid metric.

Friedrich
From: Rob Warnock
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <94iq4l$1raqd$1@fido.engr.sgi.com>
Erik Naggum  <····@naggum.net> wrote:
+---------------
|   Then we can always employ the easy route to improvement: Do a bad job on
|   purpose first, evaluate it thoroughly with all possible metrics with a
|   great deal of status and official approval, then do it half as well as
|   you could have done it to begin with, and reevaluate it thoroughly, etc.
|   You win!  Now you can keep doing a better and better job by cutting the
|   distance to how well you could have done it in half each time.  It'll
|   take years before you get fired for this, and who could possibly prove
|   that you did a bad job when you can document your improvement so well?
| 
|   But somebody needs to put such obvious things in a book that sells a lot
|   so Friedrich Dominicus can buy it in a prestigous bookstore _and_ it has
|   to contain the above as an "exercise" before he'll listen to it.  *sigh*
+---------------

Will an expensive, prestigous book containing a "cautionary tale" do
as well as an exercise? If so, Dijkstra's EWD678 "A Story that Starts
with a Very Good Computer"[*] might do the trick. It tells the story of
a comp center that bought a Very Good Computer that had a high-powered
"SORT" instruction... that (oops!) used quite a lot of electricity.
Chagrined by the expense, the boss ordered the programmer of the main
application to do something, and he replaced the SORT instructions by
calls to a routine that partitioned the arrays to be sorted into two
portions such that "the largest element in the left-hand section did
not exceed the smallest element in the right-hand section; thereafter
he gave two SORT-instructions, one for each section."  Which cut the
power used by almost a factor of 2!

All was fine for a time, until the boss came back wanting more savings.
[Most readers of this group can guess the subsequent steps and the final
punchline...]


-Rob

[*] pp.360-362 in Edsger W. Dijkstra, "Selected Writing on
    Computing: A Personal Perspective, Springer Verlag, 1982, or
    scanned at <URL:http://www.cs.utexas.edu/users/EWD/ewd06xx/EWD678.PDF>.

-----
Rob Warnock, 31-2-510		····@sgi.com
SGI Network Engineering		http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <87u26vzbv1.fsf@frown.here>
········@hex.net writes:

> 
> A _programmer_ should look at things like:
>  -> Common algorithms, as presented by Knuth, TAOCP volumes 1-3
>  -> AI algorithms, perhaps as presented by Norvig, PAIP
>  -> Lisp macro techniques, as per Graham, On Lisp

I have done this beside the "useless search for counting LOC in
Lisp". Again all the excercises which follow are based on this LOC
count. So besiedes looking into that stuff I had to find a counting
scheme.

> 
> In contrast LOC measurements outright _distract_ you from programming,
> because they do nothing _constructive_.
Why then does Watts asked anyone to use the suggested size estimate?


> 
> You cannot use LOC rules to _create_ a good program; such rules can
> only give some _vague_ measure that takes a program and _throws most
> of it away_. 
It is not for good or bad it's for how many time you will spend on
it. I cited the Watts reasons in another message.

Regards
Friedrich
From: ········@hex.net
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <4a6a6.38299$lV5.500314@news2.giganews.com>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> ········@hex.net writes:
>> In contrast LOC measurements outright _distract_ you from
>> programming, because they do nothing _constructive_.

> Why then does Watts asked anyone to use the suggested size estimate?

Because he _had_ to ask people to do this sort of thing in order to
produce a book that people would buy.

Given a book that counsels people to do LOC analysis, he can then do
consulting engagements counselling companies to do LOC analysis, as
well as to hold lectures counselling more of the same.

Whether we're talking about techniques for:
 a) Not programming,
 b) Buying real estate with no money down, or
 c) Channelling your "inner child,"
there are ample opportunities to find people willing to pay $400 to go
to a "seminar," regardless of the merits of the activity.
-- 
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hex.net/~cbbrowne/sgml.html
"Besides, I  think [Slackware]  sounds better than  'Microsoft,' don't
you?"  -- Patrick Volkerding
From: Michael Schuerig
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <1enibng.brio1ifwdw8wN%schuerig@acm.org>
<········@hex.net> wrote:

> Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > Erik Naggum <····@naggum.net> writes:
> >>   It still amazes me that anyone, and I do mean anyone, can be so
> >>   stuck in a particluar "solution" instead of trying to solve the
> >>   _problem_.  Such behavior is _not_ a good sign for someone who
> >>   wants to be a programmer.
> 
> > The problem is -- as I stated before -- to find a LOC measurement
> > for the excercises in that book. So while finding a decent LOC (or
> > whatever) metrics I'll solve the problem. I think that is quite a
> > good sign for someone who wants to be a programmer.
> 
> If you truly wanted to be a _programmer_, then you should instead be
> investigating things that are actually useful as techniques for
> _programming_, such as studying algorithms and the sorts of
> programming techniques actually used to produce working code.

Maybe he wants to become a better "software engineer". (Scare quotes
intended to avoid longish discussions about the applicability of the
term.)

> A _programmer_ should look at things like:
>  -> Common algorithms, as presented by Knuth, TAOCP volumes 1-3
>  -> AI algorithms, perhaps as presented by Norvig, PAIP
>  -> Lisp macro techniques, as per Graham, On Lisp

And then there are people who read stuff such as

- F.P. Brooks: The Mythical Man-Month
- Steve McConnell: After the Gold Rush
- Watts Humphresys: A Discipline of Software Engineering
- Kent Beck: Extreme Programming
- DeMarco/Lister: Peopleware

These two short lists provide very different perspectives on software
development. I do think it is possible and useful to bring these
perspectives together, but I'm surprised how often people take one or
the other for granted and exclude the other. Needless to say, this is
bound to cause communication problems: Hackers vs. Process Weenies. 

Michael

-- 
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: ········@hex.net
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <ba6a6.38301$lV5.500314@news2.giganews.com>
········@acm.org (Michael Schuerig) writes:
> <········@hex.net> wrote:
> 
> > Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > > Erik Naggum <····@naggum.net> writes:
> > >>   It still amazes me that anyone, and I do mean anyone, can be so
> > >>   stuck in a particluar "solution" instead of trying to solve the
> > >>   _problem_.  Such behavior is _not_ a good sign for someone who
> > >>   wants to be a programmer.
> > 
> > > The problem is -- as I stated before -- to find a LOC measurement
> > > for the excercises in that book. So while finding a decent LOC (or
> > > whatever) metrics I'll solve the problem. I think that is quite a
> > > good sign for someone who wants to be a programmer.
> > 
> > If you truly wanted to be a _programmer_, then you should instead be
> > investigating things that are actually useful as techniques for
> > _programming_, such as studying algorithms and the sorts of
> > programming techniques actually used to produce working code.
> 
> Maybe he wants to become a better "software engineer". (Scare quotes
> intended to avoid longish discussions about the applicability of the
> term.)
> 
> > A _programmer_ should look at things like:
> >  -> Common algorithms, as presented by Knuth, TAOCP volumes 1-3
> >  -> AI algorithms, perhaps as presented by Norvig, PAIP
> >  -> Lisp macro techniques, as per Graham, On Lisp
> 
> And then there are people who read stuff such as
> 
> - F.P. Brooks: The Mythical Man-Month
> - Steve McConnell: After the Gold Rush
> - Watts Humphresys: A Discipline of Software Engineering
> - Kent Beck: Extreme Programming
> - DeMarco/Lister: Peopleware
> 
> These two short lists provide very different perspectives on software
> development. I do think it is possible and useful to bring these
> perspectives together, but I'm surprised how often people take one or
> the other for granted and exclude the other. Needless to say, this is
> bound to cause communication problems: Hackers vs. Process Weenies. 

Different perspectives, indeed.

The one set of literature actually addresses the construction of
programs; the other set of literature is likely useful for those that
want to _manage_ programmers.

When the line was "someone who wants to be a programmer", it would
seem more likely to be the former set of literature that helps
accomplish the task than the latter...
-- 
(reverse (concatenate 'string ····················@" "454aa"))
http://vip.hyperusa.com/~cbbrowne/unix.html
"Ahhh. A man with a sharp wit.  Someone ought to take it away from him
before he cuts himself." -- Peter da Silva
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <878zo6390i.fsf@frown.here>
········@hex.net writes:

> 
> When the line was "someone who wants to be a programmer", it would
> seem more likely to be the former set of literature that helps
> accomplish the task than the latter...

Do you really think it's useless for a programmer to know the "larger
picture"? What makes the difference of a programmer and a manager?
Are this bounds strict? 

I disagree fully. Just studying one kind of books dealing with the
"programming" details is as bad as just reading the books about
software managment and denying the importance of knowing the tools.

Regards
Friedrich
From: Kent M Pitman
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <sfwn1cm6t31.fsf@world.std.com>
········@hex.net writes:

> The one set of literature actually addresses the construction of
> programs; the other set of literature is likely useful for those that
> want to _manage_ programmers.
> 
> When the line was "someone who wants to be a programmer", it would
> seem more likely to be the former set of literature that helps
> accomplish the task than the latter...

They say that if you want to manage a production shop, the best preparation
is to have once worked on the floor.  That is, that people manage best who
understand what those who are managing ACTUALLY do.  I'd say the same of
programmers.  If you want to manage a programmer, you should learn what's
IN programming, and avoid quantitative measures, which will never tell you
when to excuse a legitimate delay and when to yell at someone for taking
too long.
From: Friedrich Dominicus
Subject: Re: loc measurement for Common Lisp?
Date: 
Message-ID: <87d7di3951.fsf@frown.here>
········@acm.org (Michael Schuerig) writes:

> Maybe he wants to become a better "software engineer". (Scare quotes
> intended to avoid longish discussions about the applicability of the
> term.)

I do not like the word all too much (software enineer), it has a note
of "higher grades" and I've unfortunatly come along the way with
people which do not care about the implementation. It's up to you
imagination what the code looks like...
> 
> > A _programmer_ should look at things like:
> >  -> Common algorithms, as presented by Knuth, TAOCP volumes 1-3
> >  -> AI algorithms, perhaps as presented by Norvig, PAIP
> >  -> Lisp macro techniques, as per Graham, On Lisp
> 
> And then there are people who read stuff such as
> 
> - F.P. Brooks: The Mythical Man-Month
> - Steve McConnell: After the Gold Rush
> - Watts Humphresys: A Discipline of Software Engineering
> - Kent Beck: Extreme Programming
> - DeMarco/Lister: Peopleware

And there are people trying to read both ;-) I allow to add myself to
those groups. All suggested books but Extreme Progamming are on my
book shelf and I'm extremly happy that this people spend their time on
writing a book which is usually as time consuming and "frusttrating"
as programming can be.

> 
> These two short lists provide very different perspectives on software
> development. I do think it is possible and useful to bring these
> perspectives together, but I'm surprised how often people take one or
> the other for granted and exclude the other. 
I would not say it is useful, I would say this things must seen
together.

Regards
Friedrich