Long names are doom ?

Long names are doom ?

[00001111]

 Hi All,

  Anybody use variables/names longer than 31 character
and finds it really useful ?

Then please respond  why, where, when.
I have folks here in comp.lang.fortran who will die claiming that they

- "never seen a well written, legible program
  that uses any identifiers longer than 18-20 characters..".
- "long variables names are *hard* to read.  And, you have to
  read though all the characters of every instance of them...".
- "it degrades the legibility of a program to use identifiers that
  can't be easily remembered...."

As a result, despite 90% of computer languages have long, very
long or 'infinite' identifiers, fortran folks seems plan to stay
with their 6...aargh ...sorry this was just not far ago... 31 character
limit intil year 3000.

cheers

Re: Long names are doom ?

[Chris Smith]

"00001111" <00001111@my-deja.net> wrote ...
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?

Yes, I do occasionally use very long identifiers.  Normally, I do so when I
am using a lot of identifiers according to a set naming convention.  For
example, I might, in a Swing GUI application, declare an Action subclass
called:

    viewPreferencesGeneralOptionsAction

That's 35 characters.  If that's really my menu structure (that is, view |
prefs | general | options) then I really want to use that variable name.
This is not to say that I very frequently use such names, but when I need to
for consistency, I'd really hate for the language to stand in my way.

> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".

Mostly true, but I disagree with the absolute statement.

> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".

Definitely true.

> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."

Definitely true.

For those reasons, I don't agree with regularly using long variable names
unless, like in the example above, they make intuitive sense and there's
some systematic reason for that name choice.

Chris Smith

Re: Long names are doom ?

[Jan Schaumann]

* Chris Smith wrote:
>  "00001111" <00001111@my-deja.net> wrote ...
> >   Anybody use variables/names longer than 31 character
> > and finds it really useful ?
>  
>  Yes, I do occasionally use very long identifiers.  Normally, I do so when I
>  am using a lot of identifiers according to a set naming convention.  For
>  example, I might, in a Swing GUI application, declare an Action subclass
>  called:
>  
>      viewPreferencesGeneralOptionsAction
>  
>  That's 35 characters.  If that's really my menu structure (that is, view |
>  prefs | general | options) then I really want to use that variable name.

viewPrefsGenOptAction - that's 21, and just as readable.

-Jan

-- 
Jan Schaumann 
http://www.netmeister.org

Re: Long names are doom ?

[(null)]

In article <slrn9grkuk.10u.jschauma@www.netmeister.org>,
Jan Schaumann <jschauma@netmeister.org> wrote:
>* Chris Smith wrote:
>>  Yes, I do occasionally use very long identifiers.  Normally, I do so when I
>>  am using a lot of identifiers according to a set naming convention.  
>>  For example, I might, in a Swing GUI application, declare an Action subclass
>>  called:
>>  
>>      viewPreferencesGeneralOptionsAction
>>  
>>  That's 35 characters.  If that's really my menu structure (that is, view |
>>  prefs | general | options) then I really want to use that variable name.
>
>viewPrefsGenOptAction - that's 21, and just as readable.


viewPrefsGenOptAction?  Do you mean soething like a procedure 
to VIEW PREFerences implemented as a GENeric unit and the procedure 
has an OPTional ACTION.

The moral of the story, all names are "readable" to the author.
The real test is what other people might think.  Abbreviations are
good, but only if they aren't ambiguous. 


-- 
=======================================================================
 Life is short.                  | Craig Spannring 
      Bike hard, ski fast.       | cts@internetcds.com
 --------------------------------+------------------------------------

Re: Long names are doom ?

[Patricia Shanahan]

"(null)" wrote:
> 
> In article <slrn9grkuk.10u.jschauma@www.netmeister.org>,
> Jan Schaumann <jschauma@netmeister.org> wrote:
> >* Chris Smith wrote:
> >>  Yes, I do occasionally use very long identifiers.  Normally, I do so when I
> >>  am using a lot of identifiers according to a set naming convention.
> >>  For example, I might, in a Swing GUI application, declare an Action subclass
> >>  called:
> >>
> >>      viewPreferencesGeneralOptionsAction
> >>
> >>  That's 35 characters.  If that's really my menu structure (that is, view |
> >>  prefs | general | options) then I really want to use that variable name.
> >
> >viewPrefsGenOptAction - that's 21, and just as readable.
> 
> viewPrefsGenOptAction?  Do you mean soething like a procedure
> to VIEW PREFerences implemented as a GENeric unit and the procedure
> has an OPTional ACTION.

Perhaps it will VIEW the PREFerenceS and GENerate the OPTimal ACTION?

Why did "Preferences" get to keep the final "s", being abbreviated to
"Prefs", but "Options" went to "Opt"? Faced with that identifier, in its
original meaning, I would keep putting the "s" on both, or dropping it
from both, or getting it the wrong way round.

> 
> The moral of the story, all names are "readable" to the author.
> The real test is what other people might think.  Abbreviations are
> good, but only if they aren't ambiguous.
> 
> --
> =======================================================================
>  Life is short.                  | Craig Spannring
>       Bike hard, ski fast.       | cts@internetcds.com
>  --------------------------------+------------------------------------

Re: Long names are doom ?

[Charles Demas]

In article <slrn9grkuk.10u.jschauma@www.netmeister.org>,
Jan Schaumann <jschauma@netmeister.org> wrote:
>* Chris Smith wrote:
>>  "00001111" <00001111@my-deja.net> wrote ...
>> >   Anybody use variables/names longer than 31 character
>> > and finds it really useful ?
>>  
>>  Yes, I do occasionally use very long identifiers.  Normally, I do so when I
>>  am using a lot of identifiers according to a set naming convention.  For
>>  example, I might, in a Swing GUI application, declare an Action subclass
>>  called:
>>  
>>      viewPreferencesGeneralOptionsAction
>>  
>>  That's 35 characters.  If that's really my menu structure (that is, view |
>>  prefs | general | options) then I really want to use that variable name.
>
>viewPrefsGenOptAction - that's 21, and just as readable.

No, it isn't.  e.g. the "Gen" could have meant "Generate",
and viewPrefsGenOptAction and viewPrefGenOptAction  could
easily get typed for the same variable.  Using the full words
prevents differing abreviations being used by different authors.


Chuck Demas

-- 
  Eat Healthy    |   _ _   | Nothing would be done at all,
  Stay Fit       |   @ @   | If a man waited to do it so well,
  Die Anyway     |    v    | That no one could find fault with it.
  demas@tiac.net |  \___/  | http://www.tiac.net/users/demas

Re: Long names are doom ?

[Larry Elmore]

00001111 wrote:
> 
>  Hi All,
> 
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
> 
> Then please respond  why, where, when.
> I have folks here in comp.lang.fortran who will die claiming that they
> 
> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."
> 
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.

I regularly use names longer than 31 characters, but it's in large part
due to naming conventions in force at work (every function name must
start with the name of the protocol being implemented, for example,
"etsiBssmapLe3...") which eats up characters. Those rules stem from the
limitations of the language, which is a proprietary extension of C.
Also, I use the names provided by the specs without any attempts at
abbreviations because short, abbreviated names are a false economy since
whatever time is saved in typing will be be paid back tenfold later on
when doing maintenance. Being completely unambiguous and avoiding any
possible confusions makes future modifications _so_ much easier than
trying to figure out some of the damnably cryptic abbreviations other
programmers have used at work -- it's not easier reading if you have to
read _5_ different source files to figure out which _1_ corresponds to a
given parameter in a spec!

I must say that _most_ names I use are <= 31 characters, though.

Larry

Re: Long names are doom ?

[Patricia Shanahan]

00001111 wrote:
...
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."
...

That is the most important single point, and the reason why long
identifiers are a good thing to have available.

Abbreviations in identifiers make them less memorable. For a given
concept, there is the full name and possibly several ways of
abbreviating it, and anyone using it has to remember which to use. I try
to avoid them in public names, including class names.

Also, a consistent naming system makes names more memorable.

Sometimes, very rarely, a consistent naming scheme can lead to a
situation in which limiting the name to e.g. 31 characters would require
it to either break its naming convention or have some components
abbreviated.

For example, take a look at the constant names in
javax.accessibility.AccessibleContext. Names such as
"ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
either abbreviating or not using a consistent scheme, but doing so would
make them harder to remember. In Fortran I suppose it would be called
something like ACCTABCOLDESCCHNGE.

Patricia

Re: Long names are doom ?

[Roedy Green]

On 25 May 2001 03:21:04 GMT, Patricia Shanahan <pats@acm.org> wrote or
quoted :

>> - "it degrades the legibility of a program to use identifiers that
>>   can't be easily remembered...."
>...
>
>That is the most important single point, and the reason why long
>identifiers are a good thing to have available.

 The other place long names can be useful is in mechanically generated
code.

-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/gloss.html or http://209.153.246.39/gloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963.
Almost ready to take on new work.

Re: Long names are doom ?

[Jim Monty]

Patricia Shanahan <pats@acm.org> wrote:
> 00001111 wrote:
> ...
> > - "it degrades the legibility of a program to use identifiers that
> >   can't be easily remembered...."
> ...
>
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
>
> Abbreviations in identifiers make them less memorable. For a given
> concept, there is the full name and possibly several ways of
> abbreviating it, and anyone using it has to remember which to use. I try
> to avoid them in public names, including class names.

Would you be "less memorable" if you were

    Patricia_Shanahan@Association_of_Computing_Machinery.Organization

instead of simply

    pats@acm.org?

Easily ninety percent of all Web users have no idea what any of
the abbreviations http, www, com, org, etc. stand for. But does
that make it harder for them to remember the URL www.mtv.com?
Imagine a typical URL spelled out in its entirety. It would be
absurdly long and unwieldy!

We use abbreviations for various reasons, not the least of which
is as a mnemonic aid. This is certainly true of identifiers in
computer programming languages.

> Also, a consistent naming system makes names more memorable.

I don't think anyone would disagree with that. But given two
consistent naming systems (or two inconsistent naming (non-)systems),
which one is to be preferred: the one that allows long names or
the one that does not?

There's no One Answer for every language, culture, compiler, company,
and circumstance. This topic is mostly fodder for religious wars.

> Sometimes, very rarely, a consistent naming scheme can lead to a
> situation in which limiting the name to e.g. 31 characters would require
> it to either break its naming convention or have some components
> abbreviated.

So abbreviate consistently. And don't forget to use acronyms, too
("EOF", "NaN", etc.).

> For example, take a look at the constant names in
> javax.accessibility.AccessibleContext. Names such as
> "ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
> either abbreviating or not using a consistent scheme, but doing so would
> make them harder to remember. In Fortran I suppose it would be called
> something like ACCTABCOLDESCCHNGE.

Or ACCESS_TBL_COL_DESC_CHGD (24 characters). This is no more
difficult to remember than your 43-character, spelled-out version.
Indeed, I have seen each of these same four abbreviations used many
times before. They're pretty standard.

-- 
Jim Monty
monty@primenet.com
Tempe, Arizona USA

Re: Long names are doom ?

[Jon Skeet]

Jim Monty <monty@primenet.com> wrote:
> Easily ninety percent of all Web users have no idea what any of
> the abbreviations http, www, com, org, etc. stand for. But does
> that make it harder for them to remember the URL www.mtv.com?
> Imagine a typical URL spelled out in its entirety. It would be
> absurdly long and unwieldy!
> 
> We use abbreviations for various reasons, not the least of which
> is as a mnemonic aid. This is certainly true of identifiers in
> computer programming languages.

Yes, we use abbreviations and acronyms for *common* things - but given a 
general long variable name, in many cases there won't be a "standard" 
abbreviation, so the author has to check each time or until they 
remember - and each poor maintenance programmer has to learn the same 
set of abbreviations!

Abbreviations are fine when they're unambiguous and easily remembered, 
but not when there could be a dozen ways of abbreviating a long name.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Larry Kilgallen]

In article <9ekth1$49o$1@nnrp1.phx.gblx.net>, Jim Monty <monty@primenet.com> writes:

> Would you be "less memorable" if you were
> 
>     Patricia_Shanahan@Association_of_Computing_Machinery.Organization
> 
> instead of simply
> 
>     pats@acm.org?

"Shanahan" is not particularly meaningful to me, so whether "pats"
is a "Shanahan" or a "Shannon" or a "Smith" does not particularly
help me understand the meaning of a message.  Identifiers in programs
are (should be) different, and which of many possible original words
was reduced to make a particular abbreviation is important.

I can see how people might feel abbreviations are important in tiny
programs, but when you get up beyond 200,000 source lines of code
(where one begins to choose Ada) understanding the name of a particular
subprogram can be a bit tougher.

> Easily ninety percent of all Web users have no idea what any of
> the abbreviations http, www, com, org, etc. stand for. But does
> that make it harder for them to remember the URL www.mtv.com?
> Imagine a typical URL spelled out in its entirety. It would be
> absurdly long and unwieldy!

A guiding principle of Ada is that programs are written for the
convenience of the reader rather than the author.  Thus typing
effort is not important compared to clarity.

Re: Long names are doom ?

[John]

> 
> Would you be "less memorable" if you were
> 
>     Patricia_Shanahan@Association_of_Computing_Machinery.Organization
> 
> instead of simply
> 
>     pats@acm.org?

Actually, both are not that easy. 

> 
 But does
> that make it harder for them to remember the URL www.mtv.com?

I doubt that my code is going to become as popular as mtv or www or
.com.

If there were standard abbreviations or popular abbreviations or
common ones, I think people would understand those. One way to get a
happy medium is to use
Descriptive class names or somewhere in the code where you can figure
out what
the object is. 

AbbreviationConfabulator ac = new AbbreviationConfabulator(); //is not
bad style.
OR
public static String LCD = "Least Common Denominator"; 
sheesh or at least comments. (that's what they're there for)
The javadoc is a neat invention. someday, someone might decide to use
it.
;>
Long or short neither bother me unless it is intentionally obnoxious
or undocumented at least somewhere in the file.

Re: Long names are doom ?

[Larry Elmore]

John wrote:
> 
> If there were standard abbreviations or popular abbreviations or
> common ones, I think people would understand those. One way to get a
> happy medium is to use
> Descriptive class names or somewhere in the code where you can figure
> out what
> the object is.

Documentation strings are a nice feature of Lisp (_if_ they are used).
 
Larry

Re: Long names are doom ?

[Everett M. Greene]

Patricia Shanahan <pats@acm.org> writes:
> 
> 00001111 wrote:
> ....
> > - "it degrades the legibility of a program to use identifiers that
> >   can't be easily remembered...."
> ....
> 
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
> 
> Abbreviations in identifiers make them less memorable. For a given
> concept, there is the full name and possibly several ways of
> abbreviating it, and anyone using it has to remember which to use. I try
> to avoid them in public names, including class names.
> 
> Also, a consistent naming system makes names more memorable.
> 
> Sometimes, very rarely, a consistent naming scheme can lead to a
> situation in which limiting the name to e.g. 31 characters would require
> it to either break its naming convention or have some components
> abbreviated.
> 
> For example, take a look at the constant names in
> javax.accessibility.AccessibleContext. Names such as
> "ACCESSIBLE_TABLE_COLUMN_DESCRIPTION_CHANGED" could be made shorter by
> either abbreviating or not using a consistent scheme, but doing so would
> make them harder to remember. In Fortran I suppose it would be called
> something like ACCTABCOLDESCCHNGE.

Not at least in earlier versions of ANSI Fortran (6 chars).

I was once involved with a (Government) project which was
going to use coded identifiers for all the programming
components and do it in ANSI Fortran (77?)!  I was still
contemplating how that was going to be done when the
project was cancelled for lack of need.

Re: Long names are doom ?

[AG]

"Patricia Shanahan" <pats@acm.org> wrote in message
news:3B0DD011.88FCD00E@acm.org...
>
>
> 00001111 wrote:
> ...
> > - "it degrades the legibility of a program to use identifiers that
> >   can't be easily remembered...."
> ...
>
> That is the most important single point, and the reason why long
> identifiers are a good thing to have available.
>
> Abbreviations in identifiers make them less memorable.

One could argue though, that longer identifiers create more chances
for mistakes in themselves (just by virtue of been longer) than short
ones. Some other poster mentioned maintaining code written by
people who can't spell but there is also the matter of different spellings.
I once saw some code which used (in the same namespace) identifiers
PassThruID  and PassThroughIDs. They were apparently introduced
by separate programmers over time and worked fine until someone
confused them. Took ages to sort it out. So, while those two aren't
even at 31 char limit, one could argue that 6 char limit would have
precluded that sort of error :)

Re: Long names are doom ?

[Shankar Unni]

AG wrote:

> I once saw some code which used (in the same namespace) identifiers
> PassThruID  and PassThroughIDs. They were apparently introduced
> by separate programmers over time and worked fine until someone
> confused them. Took ages to sort it out. So, while those two aren't
> even at 31 char limit, one could argue that 6 char limit would have
> precluded that sort of error :)

Really?  Would it have been somehow been a lot clearer, and harder to
confuse the two, if they had been, say, "PTID" and "PTIDS"? I'd think
the opposite, actually..

You're right in that infinitely long names don't help beyond a certain
point, but 6 chars is ridiculous. Forcing ultra-short names has the
effect of people using an acronym soup for variable names, and "ABCXQZ"
is pretty easy to confuse with "ABCQXZ".

Here's an *actual* example of code I saw posted in another newsgroup
(names erased to protect the guilty - or in this case, the innocent!).
And these are 12-char names - think how much more readable this would
have been with 6-char names:

>                 double sicjpcisj=*scratchptr;
>                 double sicjncisj=*(scratchptr+1);
>                 double cicjpsisj=*(scratchptr+2);
>                 double cicjnsisj=*(scratchptr+3);
>                 double qcksicjpcisj,qcksicjncisj;
>                 double qsksicjpcisj,qsksicjncisj;
>                 double qckcicjpsisj,qckcicjnsisj;
>                 double qskcicjpsisj,qskcicjnsisj;

--
Shankar.

Re: Long names are doom ?

[Gary Scott]

Hi,

It is possible to write highly mnemonic names with 6 characters.  I
agree it's too short, but consistency of design helps tremendously and a
quick study of the documentation for the library itself coupled with a
general knowledge of the subject matter makes it reasonably evident:

GSLT = graphics subroutine line <set> type
GSQLT = graphics subroutine query <get> line type
GSLW = graphics subroutine line width
GSQLW = graphics subroutine query line width

I have probably 500-1000 routines of this type virtually memorized
(between GDDM and GINO) with many of the parameter types and value
ranges memorized as well.  Once you've been programming this way for 20
years, it isn't difficult at all to read the code.  Obviously not easy
for a novice or someone unfamiliar with the libraries to do so.  There
are few if any users of Fortran that ever thought 6 characters was
enough and nearly all compilers allowed more.  Some compilers had the
abhorent habit of ignoring characters beyond 6, however.  

31 is a reasonable minimum in my opinion, but it was put into effect
about a decade ago.  If someone wants to change it, formally approach
the standard committee with a proposal.



Shankar Unni wrote:
> 
> AG wrote:
> 
> > I once saw some code which used (in the same namespace) identifiers
> > PassThruID  and PassThroughIDs. They were apparently introduced
> > by separate programmers over time and worked fine until someone
> > confused them. Took ages to sort it out. So, while those two aren't
> > even at 31 char limit, one could argue that 6 char limit would have
> > precluded that sort of error :)
> 
> Really?  Would it have been somehow been a lot clearer, and harder to
> confuse the two, if they had been, say, "PTID" and "PTIDS"? I'd think
> the opposite, actually..
> 
> You're right in that infinitely long names don't help beyond a certain
> point, but 6 chars is ridiculous. Forcing ultra-short names has the
> effect of people using an acronym soup for variable names, and "ABCXQZ"
> is pretty easy to confuse with "ABCQXZ".
> 
> Here's an *actual* example of code I saw posted in another newsgroup
> (names erased to protect the guilty - or in this case, the innocent!).
> And these are 12-char names - think how much more readable this would
> have been with 6-char names:
> 
> >                 double sicjpcisj=*scratchptr;
> >                 double sicjncisj=*(scratchptr+1);
> >                 double cicjpsisj=*(scratchptr+2);
> >                 double cicjnsisj=*(scratchptr+3);
> >                 double qcksicjpcisj,qcksicjncisj;
> >                 double qsksicjpcisj,qsksicjncisj;
> >                 double qckcicjpsisj,qckcicjnsisj;
> >                 double qskcicjpsisj,qskcicjnsisj;
> 
> --
> Shankar.


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Long names are doom ?

[Jon Skeet]

Gary Scott <scottg@flash.net> wrote:

> I have probably 500-1000 routines of this type virtually memorized
> (between GDDM and GINO) with many of the parameter types and value
> ranges memorized as well.  Once you've been programming this way for 20
> years, it isn't difficult at all to read the code.  Obviously not easy
> for a novice or someone unfamiliar with the libraries to do so.

And that last point is the killer one. How much of the time spent 
looking at a program is done when it's in development, compared with 
when it's in maintenance? How likely is it that you'll be the one doing 
the maintenance? (In some cases, the answer *may* be "very likely", but 
in far from all.)

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Gary Scott]

Jon Skeet wrote:
> 
> Gary Scott <scottg@flash.net> wrote:
> 
> > I have probably 500-1000 routines of this type virtually memorized
> > (between GDDM and GINO) with many of the parameter types and value
> > ranges memorized as well.  Once you've been programming this way for 20
> > years, it isn't difficult at all to read the code.  Obviously not easy
> > for a novice or someone unfamiliar with the libraries to do so.
> 
> And that last point is the killer one. How much of the time spent
> looking at a program is done when it's in development, compared with
> when it's in maintenance? How likely is it that you'll be the one doing
> the maintenance? (In some cases, the answer *may* be "very likely", but
> in far from all.)

Very likely.  When I die, the code goes with me.  Virtually everything I
write is an "engineering convenience" tool designed to improve
efficiency of some analysis process.  If I don't write them, engineers
will likely just "do it the hard way".

However, I still believe that it is quite easy to study a well designed,
consistently designed API and pick it up very quickly, even with 6
character names.  I did this in a very short time when switching from
GDDM (about 500 API routines) to GINO (about 650 API routines).  I just
don't personally find this programming methodology that difficult or
error prone (others may have different experiences obviously). 

I've never in 23+/- years had an error induced myself because of short
name length restrictions.  I've also never witnessed such an error in 20
years as a software/system test engineer with responsibility for
root-cause-analysis, resolution coordination, and metrics generation of
anomalies in 50+ multi-tens to hundreds of million $ projects (well
maybe there was one that I don't remember, but it certainly wasn't a
widespread occurrence).

The Fortran standard committee is overworked as it is, let them focus on
getting "OO" right for now and save this one (internal/external name
lengths) for some future update.  If it truly is such a big deal, then
it will be addressed soon enough (relative to its importance).

The end of off-topic stuff (I hope).

> 
> --
> Jon Skeet - skeet@pobox.com
> http://www.pobox.com/~skeet
> If replying to the group, please don't mail me at the same time


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Long names are doom ?

[Roedy Green]

On Sun, 27 May 2001 14:02:17 -0500, Gary Scott <scottg@flash.net>
wrote or quoted :

>1 is a reasonable minimum in my opinion, but it was put into effect
>about a decade ago. 
 
Assume there is such a thing as the objectively best possible name for
a given variable that could be found my sufficient experiment.

I would think it highly unlikely that in all possible computer
programs that all such names are less than 20 characters.  It is thus
arrogant of the designers of languages to enforce very short names.
There was an excuse a long time ago -- compiling long ones could not
be done in typical available RAM.

Today it makes more sense to let the people most familiar with the app
decide on what the optimum name is and how long it should be, subject
only to the practicalities of writing a compiler, e.g. using a single
length byte.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Wes Groleau]

> I once saw some code which used (in the same namespace) identifiers
> PassThruID  and PassThroughIDs. They were apparently introduced

And I once had to use a 200-page set of program documentation,
upper-case only, poor quality, line-printer output, in which
it was very important not to confuse the two modes of the software:

EXECUTIVE  and
EXECUTION

The issue is not short or long, it's readability and likelihood
of error.  From that viewpoint, I find it hard to understand why,
in the name of "consistency" some folks _vociferously_ castigate
those of us who prefer

   View_Preferences_General_Options_Action

over 

   viewPreferencesGeneralOptionsAction

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Chris Smith]

"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote ...
> The issue is not short or long, it's readability and likelihood
> of error.

Definitely.  You are exactly right.

> From that viewpoint, I find it hard to understand why,
> in the name of "consistency" some folks _vociferously_ castigate
> those of us who prefer
>
>    View_Preferences_General_Options_Action
>
> over
>
>    viewPreferencesGeneralOptionsAction

Well, this thread is being posted to multiple newsgroups, and I have no idea
where you are posting from.  When I wrote the original example, I was
posting from comp.lang.java.programmer, and didn't notice that the thread
was being cross-posted.  For that reason, I used standard Java naming
conventions.  In other languages, of course, the conventions are
different... some languages leave conventions to be defined on a per-project
(or, more pessimistically, per-developer) basis.

If you're arguing for the View_... form in the Java language, then I'll have
to disagree.  I disagree for two reasons: first, under standard conventions,
each type of name in Java has a specific meaning to those reading the code.
It helps people to understand the code *without* prior familiarity with the
vocabulary itself; at least I know whether an instance method is being
invoked on an object, or a class method is being invoked on a class.
Second, these standard conventions allow developers to make reasonable
guesses, and to more easily remember, the names of the methods and fields
they do commonly use.  I'd hate to (as I have in C++ on occasion) use
several third party libraries in a project and have to remember that library
A capitalizes method names and uses underscores, but library B starts them
with lower case and no underscores and library C in turn adds a 'C' before
all class names.

That's why consistency is a valid goal.  Java *does* have a nearly universal
convention on naming of identifiers, and that makes things much easier, as
long as people follow it.

Chris Smith

Re: Long names are doom ?

[Alvaro Segura]

Chris Smith wrote:
 
> If you're arguing for the View_... form in the Java language, then I'll have
> to disagree.  I disagree for two reasons: first, under standard conventions,
> each type of name in Java has a specific meaning to those reading the code.
> It helps people to understand the code *without* prior familiarity with the
> vocabulary itself; at least I know whether an instance method is being
> invoked on an object, or a class method is being invoked on a class.
> Second, these standard conventions allow developers to make reasonable
> guesses, and to more easily remember, the names of the methods and fields
> they do commonly use.  I'd hate to (as I have in C++ on occasion) use
> several third party libraries in a project and have to remember that library
> A capitalizes method names and uses underscores, but library B starts them
> with lower case and no underscores and library C in turn adds a 'C' before
> all class names.
> 
> That's why consistency is a valid goal.  Java *does* have a nearly universal
> convention on naming of identifiers, and that makes things much easier, as
> long as people follow it.
> 
> Chris Smith

Anyone likes the MS convention of using "lpstrzLastName" instead of just
"LastName"?
They say it helps you see the type of the variable. But what is a last
name going to be? A floating-point number maybe? :-)

Anyway I do like some consistency like capitalized class names and
lowercase variable names, but not adding letters (my pet is a Dog, not a
CDog or a TDog or a Dog_t).

Re: Long names are doom ?

[Rev. Bob 'Bob' Crispen]

The kindly Rev. overheard Alvaro Segura <asegura@facilnet.es> saying
on 01 Jun 2001: 

>Anyway I do like some consistency like capitalized class names and
>lowercase variable names, but not adding letters (my pet is a Dog,
>not a CDog or a TDog or a Dog_t).

Ages and ages ago, I suggested to the editors of Ada Quality and 
Style (as part of the public comment process) that they use the 
following convention:

    	type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
    	Dog : Dogs;

That is, plural for type names, singular for object names.  You'd be 
surprised how often that works out.  The editors even adopted it as 
their recommendation in an early edition of AQ&S.

Evidently some CS professor types were aghast at the simplicity of this 
proposal, and a later version of AQ&S changed it to something like 
"abstract words for type names, specific words for object names" -- 
advice that's impossible to understand, much less follow.

I found this culture clash perfectly understandable: I'd come from an 
engineering background, so type names like Amperes and Foot_Pounds came 
naturally.  And too, I had the requirement to produce large volumes of 
maintainable code.  CS professors are, in my experience, strangers to 
both those things.  I'm sure there are some dazzling exceptions to this 
observation, but all the ones I've met couldn't even get their arms 
around the notion that at the end of the day, the sumbitch had to WORK.

Nowadays, I'd probably use My_Dog as the object identifier, but the 
good old plural as a type name is still a perfectly good convention, 
imho.

Alas, in C and C++ all the really interesting stuff is in the type or 
class definitions, and the name you give x in x->foo[i].bar doesn't 
make much difference.
-- 
Rev. Bob "Bob" Crispen
crispen at hiwaay dot net

"We can fix this, but you're gonna need a butter knife, a roll of
duct tape, and a car battery."

Re: Long names are doom ?

[Marco Schmidt]

On Fri, 01 Jun 2001 13:50:22 -0000, revbob@the.rectory (Rev. Bob 'Bob'
Crispen) wrote:

>    	type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
>    	Dog : Dogs;
>
>That is, plural for type names, singular for object names.  You'd be 
>surprised how often that works out.  The editors even adopted it as 
>their recommendation in an early edition of AQ&S.

I think that's a good idea when dealing with enumeration types.
However, there are cases where I would find it confusing. Example: a
class (type) for a GUI component, a window. If that type's name would
be plural, I'd presume that a variable of that type stores a
collection of those components (buttons, windows, scrollbars). The
other way round, if you make it the convention to always use plural,
there is no more easy way of naming a type that includes a set of
objects.

If the language is case-sensitive, I think it's a good idea to use
dog: Dog; unless there is an obvious way of naming the variable
differently, giving more meaning to what it's supposed to do / be.

Regards,
Marco
-- 
Java programming tips (last modified 2001-05-17):
http://jiu.sf.net/javatips.html

Choosing proper object names (was: Long names are doom ?)

[Ted Dennison]

In article <Xns90B35A5F54A70revbob@207.126.101.100>, Rev. Bob 'Bob' Crispen
says...
>    	type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
>    	Dog : Dogs;
>
>That is, plural for type names, singular for object names.  You'd be 
>surprised how often that works out.  The editors even adopted it as 
>their recommendation in an early edition of AQ&S.

That doesn't work too well for quantity nouns (try the same trick with "Sheep"),
or for linked structures or arrays. Personally I prefer to name arrays in the
singular so they look better when individual elements are accesed (their typical
use), but many develpers do not.

I know the "general and specific" rule seems vague, but it is in fact the rule I
settled on for my Ada code. Funny that I independantly settled on the same rule
as all those ivory tower acedemics after a couple of years of experience. :-) I
do think it reads better. If you come across the declaration:

Thread_List : Singly_Linked_List;

..it tells you a lot more relevent information than:

Thread_List : Thread_Lists;

Of course there's nothing stopping you from using both rules:
Thread_List : Singly_Linked_Lists;

But then what's plural here? The type is a singly linked list type, not a group
of them (unless you are into recursive logic). The thing that is plural here is
the *contents* of the list, so I think you'd really have to name it something
more like "Singly_Linked_Nodes", if you want it plural. But we have a name for a
bunch of singly linked nodes; its a "singly linked list". Might as well use that
name.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Choosing proper object names (was: Long names are doom ?)

[Ray Blaak]

Ted Dennison<dennison@telepath.com> writes:
> If you come across the declaration:
> 
> Thread_List : Singly_Linked_List;
> 
> ..it tells you a lot more relevent information than:
> 
> Thread_List : Thread_Lists;

More information yes, but to me this is information that the client should
*not* be aware of when using it, ideally speaking.

What the client should be aware of is that Thread_Lists (or Thread_List --
that is not my point here) is a container of threads such that one can get the
first one, maybe the last, and the next. Whether that is single or doubly
linked or even linked at all should be irrelevant to the client.

That is, plural or not, the name should indicate what the object is,
abstractly speaking, not how it is implemented.

With regards to plurality, what guides me is if the name indicates accurately
how can something be used. Do you have a list of threads or a list of thread
lists? If the former than my preference is for:

  Pending_Threads : Threads;

That is, I try to avoid the use of things like "List" in a type name, so as to
free myself from dependencies on a particular implementation. (e.g. what it is
changed to a hash table or array or something? "List" would be confusing to
maintainers). But I do have a collection of threads, accessible somehow, and
that is the important point.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Long names are doom ?

[Marin David Condic]

Using plurals for type names and singulars for object names can work - but
not always. When I've got a variable that counts up how many of something
I've got, the name naturally wants to reflect that. (Something like
Ripe_Oranges : Integer;) Seeing the plural name under your suggested
convention would lead one to think it is a type name - at least on cursory
inspection or without context. (Ripe_Oranges := Ripe_Oranges + 1; is not
likely to get confused as a type name...)

I tend to use "_Type" at the end of type names - but that is a bit long and
itself subject to confusion or ludicrous afectations. (Sometimes you want an
object called "Message_Type" & then have to go invent some name like
"Message_Category" or violate your convention. And of course
"Message_Type_Type" for the type name looks awfully silly!)

I've never seen a convention that I *really* liked and didn't have problems.
Probably like source code formatting (the great "Capital versus Lower Case
Debate", anyone?) it is probably best to write one down and then stick to
it. Consistency being more important than the exact details of the naming
convention.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Rev. Bob 'Bob' Crispen" <revbob@the.rectory> wrote in message
news:Xns90B35A5F54A70revbob@207.126.101.100...
>
> Ages and ages ago, I suggested to the editors of Ada Quality and
> Style (as part of the public comment process) that they use the
> following convention:
>
>     type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
>     Dog : Dogs;
>
> That is, plural for type names, singular for object names.  You'd be
> surprised how often that works out.  The editors even adopted it as
> their recommendation in an early edition of AQ&S.
>
> Evidently some CS professor types were aghast at the simplicity of this
> proposal, and a later version of AQ&S changed it to something like
> "abstract words for type names, specific words for object names" --
> advice that's impossible to understand, much less follow.
>
> I found this culture clash perfectly understandable: I'd come from an
> engineering background, so type names like Amperes and Foot_Pounds came
> naturally.  And too, I had the requirement to produce large volumes of
> maintainable code.  CS professors are, in my experience, strangers to
> both those things.  I'm sure there are some dazzling exceptions to this
> observation, but all the ones I've met couldn't even get their arms
> around the notion that at the end of the day, the sumbitch had to WORK.
>
> Nowadays, I'd probably use My_Dog as the object identifier, but the
> good old plural as a type name is still a perfectly good convention,
> imho.
>
> Alas, in C and C++ all the really interesting stuff is in the type or
> class definitions, and the name you give x in x->foo[i].bar doesn't
> make much difference.
> --
> Rev. Bob "Bob" Crispen
> crispen at hiwaay dot net
>
> "We can fix this, but you're gonna need a butter knife, a roll of
> duct tape, and a car battery."

Re: Long names are doom ?

[Roedy Green]

On Fri, 1 Jun 2001 11:09:30 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

>I tend to use "_Type" at the end of type names

I trust you are not a Java programmer from the long list of cross
posts.  Here in Java land we have a convention: lower case =
variable/method.  upper case = class, all upper case = named constant.

Nice and compact.  The only problem is the compiler does not enforce
it.  Every once in a while you run into some Bozo who refuses to
follow the convention and it is hell understanding the code because
you can't HELP but unconsciously presume he IS following it even when
you know he is not.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Marin David Condic]

Nope. Not a Java programmer. I'm at present a C/C++ Programmer-Under-Duress.
By inclination, I'm an Ada programmer. I've fooled with C++ enough to be
familiar with Hungarian notation & basically hated it - except that I'd
agree with you. When you get used to looking at it in a given context, *not*
seeing it tends to throw you. That's why I favor consistency within a
project moreso than some particular naming convention.

Ada identifier style from the Ada Reference Manual is typically words
separated by underscores with capitalization of the first character of each
word. Identifiers_Like_This. Reserved words are always lower case. There is
no widely used or publicized naming convention for Ada beyond the Ada style
guide referenced elsewhere in this thread. AFAIK, there is no detailed
naming convention laid out there - only general guidelines that are like
Mom, Apple Pie & Chevrolet. (all sorts of "goodness" you can't argue with,
but not always real specific.) I've invented naming conventions within
projects and found they can be helpful or a major nuisance - sometimes both
at the same time. My inclination is to stay simple & not impose too much
burden or it won't get followed.

The only real gripe I've got with the C/C++/Java crowd about naming
conventions is that whole business of slurring everything together as if
space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
hyphens or tic-marks or whatever the language uses...) are some kind of
blasphemy in the various sects of C-ism? That, and I never liked any
language or OS that was case-sensitive. (Note: This is personal taste and I
won't even begin to try to justify it with science or logic. I hate it.
That's enough. Its settled. Don't get caught doing it when I'm in charge.)
(Nice little bit of flame-bait there, eh? We can resurrect one of those old
debates that keeps cropping up periodically, right? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:ttofhtk7j7ufbtot7l2o0svn71qq0j7420@4ax.com...
>
> I trust you are not a Java programmer from the long list of cross
> posts.  Here in Java land we have a convention: lower case =
> variable/method.  upper case = class, all upper case = named constant.
>
> Nice and compact.  The only problem is the compiler does not enforce
> it.  Every once in a while you run into some Bozo who refuses to
> follow the convention and it is hell understanding the code because
> you can't HELP but unconsciously presume he IS following it even when
> you know he is not.
>
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Pete Thompson]

On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

I hate to cross-post, but...

<snip>

>The only real gripe I've got with the C/C++/Java crowd about naming
>conventions is that whole business of slurring everything together as if
>space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
>hyphens or tic-marks or whatever the language uses...) are some kind of
>blasphemy in the various sects of C-ism? That, and I never liked any
>language or OS that was case-sensitive. (Note: This is personal taste and I
>won't even begin to try to justify it with science or logic. I hate it.
>That's enough. Its settled. Don't get caught doing it when I'm in charge.)
>(Nice little bit of flame-bait there, eh? We can resurrect one of those old
>debates that keeps cropping up periodically, right? :-)

Methinks it would be far more productive to simply let the team members get
their job done rather than worrying about whether they're adhering to your
personal tastes instead of theirs...

Anyways, regarding the underscore.  I'm a C/C++ programmer (now learning Java)
and I don't like the underscore because of its location on my keyboard, and it
affects my typing speed.  C/C++ are terse languages.  Being terse allows you to
do more in a shorter period of time.  I like using the i++ statement instead of
i = i + 1.   I like being able to code as fast as my train of thought allows
me, and having to pause to type out the underscores can throw me off.  Typing
This_Is_A_Variable takes me far longer than typing ThisIsAVariable.  Reading
the code isn't much of an issue as long as you capitalize each word in the
variable name.  Yes, 'Thisisavariable' would be quite horrible.

Another issue about the underscore's location on the keyboard:   I avoid it as
much as possible to cut down on the risks of carpal tunnel.  The side of my
right hand is already getting sore from having to reach over for +, =, {, }, \,
backspace, and enter.  Throwing the underscore in there would just make it
worse and more painful.

You know, now that I look more closely at my keyboard, it does seem like
there's an awful lot of keys for my right pinky finger to press.  Maybe Dvorak
was onto something after all... 

Re: Long names are doom ?

[AG]

"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com...
> On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote:
>
> I hate to cross-post, but...
>
> <snip>
>
> >The only real gripe I've got with the C/C++/Java crowd about naming
> >conventions is that whole business of slurring everything together as if
> >space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
> >hyphens or tic-marks or whatever the language uses...) are some kind of
> >blasphemy in the various sects of C-ism? That, and I never liked any
> >language or OS that was case-sensitive. (Note: This is personal taste and
I
> >won't even begin to try to justify it with science or logic. I hate it.
> >That's enough. Its settled. Don't get caught doing it when I'm in
charge.)
> >(Nice little bit of flame-bait there, eh? We can resurrect one of those
old
> >debates that keeps cropping up periodically, right? :-)

I guess you just did:)

>
> Methinks it would be far more productive to simply let the team members
get
> their job done rather than worrying about whether they're adhering to your
> personal tastes instead of theirs...

Well, they do need to talk to each other don't they? And how about the
project
manager just letting "the team members get their job done" ? I guess that
*would*
qualify as the perfect world:)

>
> Anyways, regarding the underscore.  I'm a C/C++ programmer (now learning
Java)
> and I don't like the underscore because of its location on my keyboard,
and it
> affects my typing speed.  C/C++ are terse languages.  Being terse allows
you to
> do more in a shorter period of time.

Like more erorrs? Do you really really claim that your productivity speed is
only
limited by your typing speed? You must be a very exceptional programmer if
your
productive speed is only limited by that ...

>  I like using the i++ statement instead of
> i = i + 1.   I like being able to code as fast as my train of thought
allows
> me, and having to pause to type out the underscores can throw me off.

Ummm, you are confusing things now - if you speak touch-typing, then
underscores
are no problem - any half-way competenet secretary can do that of course, no
problem.
However, that has nothing to do with the programming.

Besides, your example compares 3 characters to 5 characters (plus perhaps
two spaces
which shouldn't be needed as far as your theory is concerned) So, anyone
really cares
about the [fraction of a second] difference in typing speed as oposed to
hours of design
time?

>  Typing
> This_Is_A_Variable takes me far longer than typing ThisIsAVariable.

You must be a very bad typer then:) I note that the whole of your sentence
above contains just 3 underscores but 7 blank spaces. So, how come the
3 underscores took you longer then 7 spaces? Sure, technically speaking
hitting the space bar IS faster then the underscore. *** But *** is it
really
your contention that this is what limits the speed of software development?

>  Reading
> the code isn't much of an issue as long as you capitalize each word in the
> variable name.  Yes, 'Thisisavariable' would be quite horrible.

If only reading the code was as simple as that... You only need caps to read
the code? Cool...

Re: Long names are doom ?

[Pete Thompson]

On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:

Youch.  I lost the thread a couple of days ago, and only managed to find it
just now.  I didn't realize that my post had sparked a bit of a sub-thread
there  :)  In any case, I'll try to address most responses in this single
post...

>> Methinks it would be far more productive to simply let the team members
>get
>> their job done rather than worrying about whether they're adhering to your
>> personal tastes instead of theirs...
>
>Well, they do need to talk to each other don't they? And how about the
>project
>manager just letting "the team members get their job done" ? I guess that
>*would*
>qualify as the perfect world:)

Yes, of course having a code convention is important in a team.  What I was
trying to get at was that if your standards are different from the
"conventional" standard for the language you're using, then perhaps it's your
own standards that needs to be looked at.  Of course, I'm no Ada programmer, so
I don't know what the standards are like in Ada.

But suffice to say that it would seem that the standards for Ada and C/C++ seem
to be different.  :/

>Like more erorrs? Do you really really claim that your productivity speed is
>only
>limited by your typing speed? You must be a very exceptional programmer if
>your
>productive speed is only limited by that ...

No, that's not what I was saying at all.  I'll try to explain better:

In most C/C++ code, I very rarely ever see anyone using an underscore in a
variable name.  When they do, they usually come from a Pascal background.

It's fairly standard for C/C++ (and Java it would seem) to simply capitalize
each word in a variable name (with the exception of the first word).  When
you're writing C/C++ code, your target audience is generally other C/C++
programmers who already follows the same (or similar) conventions.  Underscores
then become less needed. 

>Ummm, you are confusing things now - if you speak touch-typing, then
>underscores
>are no problem - any half-way competenet secretary can do that of course, no
>problem.
>However, that has nothing to do with the programming.

I'm a touch-typist.  I've been a touch-typist for longer than I'd care to think
about <G>, and therein lies the problem, actually.  My right hand's beginning
to feel the strain.  

You're right, medical issues have nothing to do with programming, but it *IS*
an issue, and it's growing bigger in the marketplace every day.  And it just so
happens that it's an issue that affects typing. 


>Besides, your example compares 3 characters to 5 characters (plus perhaps
>two spaces
>which shouldn't be needed as far as your theory is concerned) So, anyone
>really cares
>about the [fraction of a second] difference in typing speed as oposed to
>hours of design
>time?

re:  This_Is_A_Variable.

Those "3 characters" can quickly expand when you actually use that variable
name in a block of code (or more if it's a major variable name in an entire
program).  Plus you'd be using it in all the other variable names and function
names.  So we're not talking about only 3 characters.

>You must be a very bad typer then:) I note that the whole of your sentence
>above contains just 3 underscores but 7 blank spaces. So, how come the
>3 underscores took you longer then 7 spaces? Sure, technically speaking
>hitting the space bar IS faster then the underscore. *** But *** is it
>really
>your contention that this is what limits the speed of software development?

No, that is not my contention at all.  See above.

It's a bit unfair to compare the underscore to the spacebar.  The spacebar is
essential to separate keywords.  The underscore is not.  It's purely used for
readability issues.

>>  Reading
>> the code isn't much of an issue as long as you capitalize each word in the
>> variable name.  Yes, 'Thisisavariable' would be quite horrible.
>
>If only reading the code was as simple as that... You only need caps to read
>the code? Cool...

Yep.  Want a better example?  Try hungarian notation.

char* pszString;

It looks weird.  It looks clumsy.  And it stops typecasting errors cold once
you get the hang of it, and learn how to read it naturally.

The bottom line is that when you've been using a language for a long time, then
its conventions become second-nature to you.  It's a bit like a culture shock
when talking to programmers of other languages.

Just curious... but do you use perl?

Re: Long names are doom ?

[Chris Uzdavinis]

Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:

> On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:

> In most C/C++ code, I very rarely ever see anyone using an
> underscore in a variable name.  When they do, they usually come from
> a Pascal background.

Sorry, I must disagree with your generalization.  Using underscores
has strong C++ roots -- their use is common in the C++ standard
itself. 

Most names in the C++ Standard library uses underscores as separators
when one is needed (random_shuffle, const_iterator, next_permutation,
type_name, etc.)  Even keywords in C++ use underscores: dynamic_cast,
const_cast, static_cast, reinterpret_cast, wchar_t.

The GNU coding standard uses underscores in identifiers.  (For that
matter, The Linux kernel itself is coded using underscore notation.)
Plus, every platform-specific extension by any C++ compiler vendor is
required to have leading underscores (__declspec, __finally, __int64,
etc), and all implementations of the standard library internally use
leading underscores, since the standard explicitly reserves such names
(in global scope) for their use.

It's common among Unix programmers to use trailing underscores on
variable names to indicate class membership.  In windows, it's common
to prefix member variables with m_ to indicate class membership.

-- 
Chris

Re: Long names are doom ?

[Pete Thompson]

On 05 Jun 2001 18:22:30 -0400, Chris Uzdavinis <chris@atdesk.com> wrote:

>Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
>
>> On Sat, 2 Jun 2001 17:29:04 +1200, "AG" <ang@xtra.co.nz> wrote:
>
>> In most C/C++ code, I very rarely ever see anyone using an
>> underscore in a variable name.  When they do, they usually come from
>> a Pascal background.
>
>Sorry, I must disagree with your generalization.  Using underscores
>has strong C++ roots -- their use is common in the C++ standard
>itself. 
>
>Most names in the C++ Standard library uses underscores as separators
>when one is needed (random_shuffle, const_iterator, next_permutation,
>type_name, etc.)  Even keywords in C++ use underscores: dynamic_cast,
>const_cast, static_cast, reinterpret_cast, wchar_t.
>
>The GNU coding standard uses underscores in identifiers.  (For that
>matter, The Linux kernel itself is coded using underscore notation.)
>Plus, every platform-specific extension by any C++ compiler vendor is
>required to have leading underscores (__declspec, __finally, __int64,
>etc), and all implementations of the standard library internally use
>leading underscores, since the standard explicitly reserves such names
>(in global scope) for their use.
>
>It's common among Unix programmers to use trailing underscores on
>variable names to indicate class membership.  In windows, it's common
>to prefix member variables with m_ to indicate class membership.

Sure, underscores are used quite heavily in header files, macros, and in
argument parameters.  However, I'm referring to general variable names and
function names, where the underscore is used as a separator between words
within a variable/function name.

Underscores were used heavily in the past, I'll give you that, but I suspect it
was mostly because programmers had migrated to C/C++ from other languages where
the underscore was quite prominent.

In today's times, I rarely see people using it in their variable and function
names, and even then, only to indicate a prefix/suffix like your class member
example.  Not as a separator of words within a variable name.

I suspect if the C/C++ language was to be re-created from scratch today, the
underscore would be more omitted.  As it is now, we have quite an inconsistency
within the language:  typedef, sizeof, dynamic_cast, size_t, memset, iostream
classes and methods, etc.

Re: Long names are doom ?

[John English]

Pete Thompson wrote:
> Underscores were used heavily in the past, I'll give you that, but I suspect it
> was mostly because programmers had migrated to C/C++ from other languages where
> the underscore was quite prominent.

I think you'll find that C code of 20 or 30 years ago (K&R C, long before
ANSI C let alone C++) traditionally used lower_case_with_underlines for
identifiers, and the fashion for namesWithCapitalLetters is a more recent
one... Certainly there are no capital letters used in the standard libraries
other than in #defines, and then they're ALL_CAPS_WITH_UNDERLINES.

IIRC the first language where I found namesLikeThis in common usage
was Smalltalk.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Larry Elmore]

John English wrote:
> 
> Pete Thompson wrote:
> > Underscores were used heavily in the past, I'll give you that, but I suspect it
> > was mostly because programmers had migrated to C/C++ from other languages where
> > the underscore was quite prominent.
> 
> I think you'll find that C code of 20 or 30 years ago (K&R C, long before
> ANSI C let alone C++) traditionally used lower_case_with_underlines for
> identifiers, and the fashion for namesWithCapitalLetters is a more recent
> one... Certainly there are no capital letters used in the standard libraries
> other than in #defines, and then they're ALL_CAPS_WITH_UNDERLINES.
> 
> IIRC the first language where I found namesLikeThis in common usage
> was Smalltalk.

I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
if Pascal adopted it from something earlier.

Larry

Re: Long names are doom ?

[Wes Groleau]

> > IIRC the first language where I found namesLikeThis in common usage
> > was Smalltalk.
> 
> I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> if Pascal adopted it from something earlier.

I wrote thousands of lines of Pascal without ever doing that
or even seeing it.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Larry Elmore]

Wes Groleau wrote:
> 
> > > IIRC the first language where I found namesLikeThis in common usage
> > > was Smalltalk.
> >
> > I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> > if Pascal adopted it from something earlier.
> 
> I wrote thousands of lines of Pascal without ever doing that
> or even seeing it.

Curious. I learned Pascal in 1984 (Montana State used it then, now they
use Ada for 2 years and C++ thereafter (ick)). I've only rarely seen
Pascal written any other way. The three books on my shelf that have
Pascal code in them have namesLikeThis, and I know Delphi's Object
Pascal has always been written in that style.

Larry

Re: Long names are doom ?

[Patricia Shanahan]

Larry Elmore wrote:
> 
> Wes Groleau wrote:
> >
> > > > IIRC the first language where I found namesLikeThis in common usage
> > > > was Smalltalk.
> > >
> > > I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> > > if Pascal adopted it from something earlier.
> >
> > I wrote thousands of lines of Pascal without ever doing that
> > or even seeing it.
> 
> Curious. I learned Pascal in 1984 (Montana State used it then, now they
> use Ada for 2 years and C++ thereafter (ick)). I've only rarely seen
> Pascal written any other way. The three books on my shelf that have
> Pascal code in them have namesLikeThis, and I know Delphi's Object
> Pascal has always been written in that style.
> 
> Larry

Since I rarely throw away books, I still have the copy of the "Pascal
User Manual and Report" (2nd. Edition, Kathleen Jensen and Niklaus
Wirth, 1974) from which I learned Pascal. It uses all lower case
identifiers, with no punctuation to separate words, or more commonly
their abbreviations.

Flipping through it, I just came across "egrepeat" which had me
wondering for a moment why a sample program would do anything with peat,
and what does "egre" mean anyway?

Patricia

Re: Long names are doom ?

[Adam Beneschan]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote in message news:<3B210FF5.C53AC949@ftw.rsc.raytheon.com>...
> > > IIRC the first language where I found namesLikeThis in common usage
> > > was Smalltalk.
> > 
> > I first saw it Pascal. I suspect it outdates Smalltalk, but don't know
> > if Pascal adopted it from something earlier.
> 
> I wrote thousands of lines of Pascal without ever doing that
> or even seeing it.

Actually, when I worked with Pascal in college (late 70's-early 80's), we
were encouraged to use the "pseudo-germanic" style, and our lab director gave
some examples of why.  Before that, the tendency was to use all capitals with
no underscores (which aren't or weren't part of Pascal).  So if you had a 
variable named "Go On", it would look funny in all capitals with no separators.
But the worst example . . .

We were using UCSD Pascal, which had a simple graphics package called
TURTLEGRAPHICS.  The concept was simple.  The package had a "pen" that you could
move around.  The pen could be either up or down.  While it was down, a line
would get drawn on the screen when you moved the pen from one location to
another.  While it was up, you could move the pen without drawing anything.

Anyway, the all-capitals-with-no-separators practice caused some problems 
when programmers were using Turtlegraphics and they wanted a Boolean variable
to hold the current state of the pen, naturally called "Pen Is Down" . . .

Just reminiscing . . .
				-- Adam

Re: Long names are doom ?

[James Kanze]

John English wrote:

> Pete Thompson wrote:
> > Underscores were used heavily in the past, I'll give you that, but
> > I suspect it was mostly because programmers had migrated to C/C++
> > from other languages where the underscore was quite prominent.

> I think you'll find that C code of 20 or 30 years ago (K&R C, long
> before ANSI C let alone C++) traditionally used
> lower_case_with_underlines for identifiers, 

C code of 20 or 30 years ago didn't use either. Identifiers would be
something like lwrcswuline.  Modern C++ makes extensive use of the _
as a separator, at least in the standard libraries.  Ten years ago,
however, it was still more or less following the C tradition.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[John English]

James Kanze wrote:
> 
> John English wrote:
> > I think you'll find that C code of 20 or 30 years ago (K&R C, long
> > before ANSI C let alone C++) traditionally used
> > lower_case_with_underlines for identifiers,
> 
> C code of 20 or 30 years ago didn't use either. Identifiers would be
> something like lwrcswuline.  Modern C++ makes extensive use of the _
> as a separator, at least in the standard libraries.  Ten years ago,
> however, it was still more or less following the C tradition.

Well, *I* used to use underlines in *my* C code in the 70s/80s... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Chris Uzdavinis]

John English <je@brighton.ac.uk> writes:

> James Kanze wrote:
> > 
> > C code of 20 or 30 years ago didn't use either. Identifiers would be
> > something like lwrcswuline.  Modern C++ makes extensive use of the _
> > as a separator, at least in the standard libraries.  Ten years ago,
> > however, it was still more or less following the C tradition.
> 
> Well, *I* used to use underlines in *my* C code in the 70s/80s... :-)

You were ahead of your time.  :)

-- 
Chris

Re: Long names are doom ?

[James Kanze]

Pete Thompson wrote:

> In most C/C++ code, I very rarely ever see anyone using an
> underscore in a variable name.  When they do, they usually come from
> a Pascal background.

I don't think that the people who thought up size_t necessarily come
from a Pascal background.

> It's fairly standard for C/C++ (and Java it would seem) to simply
> capitalize each word in a variable name (with the exception of the
> first word).  When you're writing C/C++ code, your target audience
> is generally other C/C++ programmers who already follows the same
> (or similar) conventions.  Underscores then become less needed.

I've only rarely seen this convention in C/C++ outside of the telecoms
domain (where the convention corresponds to the naming convention in
the telecoms standards).

The most frequent convention in C/C++ seems to be to not signal the
start of a new word at all, and to abbreviate to a point that no one
can recognize words anyway:-).  (getenv, chmod, etc.)  When the start
of words is marked, it is with a _; just look at the C++ standard
library.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Simon Wright]

Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:

> On Fri, 1 Jun 2001 15:38:58 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote:

> >The only real gripe I've got with the C/C++/Java crowd about naming
> >conventions is that whole business of slurring everything together as if
> >space isn't useful. TheNamesLikeThis just annoy me! What? Underscores (or
> >hyphens or tic-marks or whatever the language uses...) are some kind of
> >blasphemy in the various sects of C-ism? That, and I never liked any
> >language or OS that was case-sensitive. (Note: This is personal taste and I
> >won't even begin to try to justify it with science or logic. I hate it.
> >That's enough. Its settled. Don't get caught doing it when I'm in charge.)
> >(Nice little bit of flame-bait there, eh? We can resurrect one of those old
> >debates that keeps cropping up periodically, right? :-)
>
> Methinks it would be far more productive to simply let the team
> members get their job done rather than worrying about whether
> they're adhering to your personal tastes instead of theirs...

The point Marin made (in a bit you snipped, I think) was that we're
talking about a programming *team*. A team will be much more effective
if all the members are cooperating. Your idea seems to just accept
that running a programming team is like herding cats.

The job of the team is not to produce lots of modules that someone
else has to fit together. The job is to produce an integrated working
program. You will have to come to a common understanding of the
software architecture, and this isn't just about whose job it is to
manage deallocation or how we deal with threads or what design
patterns we use, it also includes common stylistic conventions.

> Anyways, regarding the underscore.  I'm a C/C++ programmer (now
> learning Java) and I don't like the underscore because of its
> location on my keyboard, and it affects my typing speed.  C/C++ are
> terse languages.  Being terse allows you to do more in a shorter
> period of time.  I like using the i++ statement instead of i = i +
> 1.  I like being able to code as fast as my train of thought allows
> me, and having to pause to type out the underscores can throw me
> off.  Typing This_Is_A_Variable takes me far longer than typing
> ThisIsAVariable.

Tough, because ..

>                   Reading the code isn't much of an issue as long as
> you capitalize each word in the variable name.  Yes,
> 'Thisisavariable' would be quite horrible.

.. most code is read far more often than it's written. Your job isn't
just to work in a way that makes _you_ most comfortable, it's to
support what your employer needs in the future.

If you want your work to be thrown away next time maintenance is
needed, go ahead .. think of your successors, looking for a picture of
you so they can stick black pins in it.

Of course, if you're in a throwaway environment, all these engineering
considerations are out of the window.

Re: Long names are doom ?

[Ted Dennison]

In article <aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com>, Pete Thompson says...
>
>...  C/C++ are terse languages.  Being terse allows you to
>do more in a shorter period of time.  I like using the i++ statement instead of

Yowch. You lost me right there. Typing in the program is nowhere *near* the most
time-consuming part of developing software. That distinction belongs to the
"getting it to work" phase, along with maintanence in general. The focus needs
to be on doing things that will make those phases go quicker.

This statement is a perfect illustration of how the ancient design of C
encourages developers to worry about optimizing the wrong things. Back in '72
when C was designed, the size of a source file was a real issue, and programs
were generally much smaller (and thus simpler to get running). But none of this
is true today.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

Its important to note that the actual act of *typing* the code is so trivial
in comparison to other phases that it falls below the noise level and is
nearly undetectable. You may spend a fair amount of time *staring* at the
code you are writing and *reasoning* about the code and so forth, but if one
thinks the *typing* of the code is a significant part of the productivity
equation, I'd want to challenge that and ask for some actual test data.
Attempting to optimize typing time just isn't going to pay off in any
business case.

Except for one-shot, throw-away programs or extremely small, near-trivial
programs, I think almost any study would show that the time spent reading
the code far exceeds the time spent writing it - including the
staring/reasoning part. (I'd exclude requirements and design time since
these are basically language-independent activities. Test and debug time
probably are significantly impacted by language choice - at least I had data
to indicate this was true in one problem domain.) Hence the reason Ada was
designed with readability in mind rather than attempting to save keystrokes.
That realization and experience has impacted the way I write C code & I
think most of my associates appreciate the fact that I eschew obfuscation
when writing in C. It may not be as "terse" as their code, but it is a heck
of a lot easier for them to figure out what my code is up to than the other
way around. (And when did "terse" become of value in and of itself, anyway?
Why should it be a goal to be strived for?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:IsNS6.3800$v4.180713@www.newsranger.com...
> In article <aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com>, Pete Thompson
says...
> >
> >...  C/C++ are terse languages.  Being terse allows you to
> >do more in a shorter period of time.  I like using the i++ statement
instead of
>
> Yowch. You lost me right there. Typing in the program is nowhere *near*
the most
> time-consuming part of developing software. That distinction belongs to
the
> "getting it to work" phase, along with maintanence in general. The focus
needs
> to be on doing things that will make those phases go quicker.
>
> This statement is a perfect illustration of how the ancient design of C
> encourages developers to worry about optimizing the wrong things. Back in
'72
> when C was designed, the size of a source file was a real issue, and
programs
> were generally much smaller (and thus simpler to get running). But none of
this
> is true today.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Roedy Green]

On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> Hence the reason Ada was
>designed with readability in mind rather than attempting to save keystrokes.

There is a general rule though, that a terser program makes it easier
to see the big picture.  You can get more of it on screen at once.
Use of smaller methods so can easily see the whole flow of a method in
a single screen full, without getting bogged in too much detail,
really helps.

Rapid navigation tools similarly help.  See
http://mindprod.com/scid.html.

What I find so strange is something as simple as variable
sized/coloured {} and () to make visual balancing easier still has not
caught on.  

Perhaps if we had more females in the tool design process they would
not be so macho about insisting on making programming uncomfortable
and difficult.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> There is a general rule though, that a terser program makes it easier
> to see the big picture.  You can get more of it on screen at once.
> Use of smaller methods so can easily see the whole flow of a method in
> a single screen full, without getting bogged in too much detail,
> really helps.

I agree that you should be able to see a whole unit (method, function,
whatever) on a single screen/page, but making the code "terser" just
means you can get twice as much stuff in the same space, so there's
twice as much complexity to absorb and it's twice as cryptic too.
The answer isn't terseness, it's abstraction. It's about breaking
things into bite-sized modules, not trying to cram as much stuff
as possible into an arbitrarily-chosen amount of space. Otherwise,
you could achieve a similar effect by removing unnecessary white
space (i.e. indentation and line breaks), which otherwise "wastes" 
about 50% of the available screen area in most programs...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <pb2ohtgs64jhssmmohpq5qr7nmcsq6119c@4ax.com>, Roedy Green says...
>
>On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
><marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
>
>> Hence the reason Ada was
>>designed with readability in mind rather than attempting to save keystrokes.
>
>There is a general rule though, that a terser program makes it easier
>to see the big picture.  You can get more of it on screen at once.

So by this rule, APL produces the most readable code?

Clearly there's a bit more to it than just physical size. I'd agree that the
most readable code might be split up into small routines. But it doesn't follow
that you can therefore make your code more readable just like those other small
routines by compressing your large routine into a small-lookng one without
restructuring anything. Being able to suck your gut in and hold your breath for
a while doesn't mean you're not overweight.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 13:25:58 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>>There is a general rule though, that a terser program makes it easier
>>to see the big picture.  You can get more of it on screen at once.
>
>So by this rule, APL produces the most readable code?

Not at all.  By terse I mean bubblegum-free, not abbreviated. 

However, APL does have ways of avoiding the bubblegum of dealing with
subscripts and manually tracking just how many elements are in the
array.  It takes those details out of your concern and lets you focus
on the problem.

People are stupid and have great difficulty with information overload.
Anything the computer can do for itself, should be taken out of
applications.

It very difficult to appreciate the value of this if you have never
programmed any other way other than buried in bubblegum.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 13:25:58 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :


>So by this rule, APL produces the most readable code?

APL has a bit of a bum rap for several reasons:

1. the glyphs were unreadable on the screens and golf ball typewriters
of the time. Iverson designed the glyphs only to be typeset. They are
not nearly distinct enough for low res.

2. people judged the language on its IMMEDIATE readability, not after
some practice so that the operators were familiar.

3. APL programmers, like Forth programmers, liked to show off with
tricky opaque but terse code.

But in general, if a solution is shorter, there is less to digest.
There is less to go wrong. There is less to keep in sync.

Creating terseness with meaningless short identifiers is not what I
meant.  Terseness by needing the fewest number of syntatic elements
with the greatest simplicity in their connections, is valid.

Redundancy, just as in English, can help reduce errors. I 
exaggerate slightly, but, in PostScript for example, almost any string
of characters you get from a monkey on a typewriter can be fed
successfully to a PS parser.  Achieving your terseness at that expense
is not wise.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Ted Dennison]

In article <7ciqhtk6595rgr8qsc92d793ubl1l47saj@4ax.com>, Roedy Green says...
>
>On Tue, 05 Jun 2001 13:25:58 GMT, Ted Dennison<dennison@telepath.com>
>wrote or quoted :
>Creating terseness with meaningless short identifiers is not what I

There are some circumstances where non-identifier based terseness hurts. For
example, its quite possible in C to make many short "if" statements much more
terse using the "?" operator. Its also quite possible to "tersify" many loops by
putting *all* their code inside the parentheses of a "for" loop (the comma
operator helps here). This may be physically shorter, but most C programmers I
know would not consider it easier to understand. Both of these techniques are
outlawed in many C programming standards.

>meant.  Terseness by needing the fewest number of syntatic elements
>with the greatest simplicity in their connections, is valid.

OK. I can agree with that. But I think you are talking about *complexity*, not
tersenes. They may often go hand-in-hand, but there's a *big* difference.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Wes Groleau]

> exaggerate slightly, but, in PostScript for example, almost any string
> of characters you get from a monkey on a typewriter can be fed
> successfully to a PS parser.  Achieving your terseness at that expense
> is not wise.

Change Postscript to C and it's less of an exaggeration.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Marin David Condic]

Mostly because with C, the compiler takes the attitude of "I don't care if
it wrong - I'll close my eyes, ignore it, generate code anyway and you can
go find the problem with the debugger!" :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B1E33AF.CB1AB79D@ftw.rsc.raytheon.com...
>
> > exaggerate slightly, but, in PostScript for example, almost any string
> > of characters you get from a monkey on a typewriter can be fed
> > successfully to a PS parser.  Achieving your terseness at that expense
> > is not wise.
>
> Change Postscript to C and it's less of an exaggeration.
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Roedy Green]

On Wed, 06 Jun 2001 08:44:15 -0500, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote or quoted :

>Change Postscript to C and it's less of an exaggeration.

C at least makes you declare your identifiers which catches many typos
at compile time.

Fortran's habit of gleefully creating a new variable when you
misspelled an existing one lead to all kinds of problems, especially
in the days when keypunch operators would literally type 0 for O or O
for 0 if you left off the / in your hand written document.

There was one keypunchist, Loreli, beloved of all the Fortran
programmers, who would hand you your deck back with, set of extra
cards attached with what she thought you REALLY meant. In the days
when you got one compile a day, that made a big difference.

I am a very big fan of languages where you must define everything you
use, and put as much information about how to handle that thing, in
one place, in the definition. 

Java, with its casts, want you to specify the type information all
over the procedural code. It also wants you handle the formatting for
display procedurally.  It also wants you to handle data validation
procedurally. This leads to inevitable inconsistency.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Gary Scott]

It's true that Fortran still allows implicit declarations.  But it also
allows you to turn it off, which 99% do.  It is unfortunate that that
behavior is not the default for free-form source.  It was fully
unnecessary for free-form source applications to maintain backward
compatibility with that particular feature.

Roedy Green wrote:
> 
> On Wed, 06 Jun 2001 08:44:15 -0500, Wes Groleau
> <wwgrol@ftw.rsc.raytheon.com> wrote or quoted :
> 
> >Change Postscript to C and it's less of an exaggeration.
> 
> C at least makes you declare your identifiers which catches many typos
> at compile time.
> 
> Fortran's habit of gleefully creating a new variable when you
> misspelled an existing one lead to all kinds of problems, especially
> in the days when keypunch operators would literally type 0 for O or O
> for 0 if you left off the / in your hand written document.
> 
> There was one keypunchist, Loreli, beloved of all the Fortran
> programmers, who would hand you your deck back with, set of extra
> cards attached with what she thought you REALLY meant. In the days
> when you got one compile a day, that made a big difference.
> 
> I am a very big fan of languages where you must define everything you
> use, and put as much information about how to handle that thing, in
> one place, in the definition.
> 
> Java, with its casts, want you to specify the type information all
> over the procedural code. It also wants you handle the formatting for
> display procedurally.  It also wants you to handle data validation
> procedurally. This leads to inevitable inconsistency.
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <7ciqhtk6595rgr8qsc92d793ubl1l47saj@4ax.com>, on 06/05/2001
   at 09:15 PM, Roedy Green <roedy@mindprod.com> said:

>APL has a bit of a bum rap for several reasons:

And for some good reasons:

No operator precedence

Fixed[1] array lower bounds

Poor character handling. But C suffers from the same disease

Little attention to program structure

Reliance on "magic numbers"

[1] FSVO fixed. They can be 0 or 1, on an all-or-nothing basis.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[James Kanze]

"Shmuel (Seymour J.) Metz" wrote:

>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I

Do you drive an Edsel, too?

(Sorry, I couldn't resist:-).  But PL/I and OS/2 both...)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Gary Scott]

Hey!...we still have hundreds of jobs using Jovial (openings too)...

James Kanze wrote:
> 
> "Shmuel (Seymour J.) Metz" wrote:
> 
> >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> >      Atid/2
> >      Team OS/2
> >      Team PL/I
> 
> Do you drive an Edsel, too?
> 
> (Sorry, I couldn't resist:-).  But PL/I and OS/2 both...)
> 
> --
> James Kanze                               mailto:kanze@gabi-soft.de
> Conseils en informatique orient�e objet/
>                    Beratung in objektorientierter Datenverarbeitung
> Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B20D2D8.4AD88183@dresdner-bank.com>, on 06/08/2001
   at 03:27 PM, James Kanze <James.Kanze@dresdner-bank.com> said:

>Do you drive an Edsel, too?

Well, if at the time[1] the Edsel was being marketed the alternative
was a Renault, then I would have driven an Edsel. Is there some reason
that I should run a popular broken system instead of an unpopular
working system that suits my needs?

[1] Ignoring issues like legal driving age.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Dirk Bosmans]

I'm responding to following parts of Roedy Green <roedy@mindprod.com>'s article
in comp.lang.java.programmer on Mon, 04 Jun 2001 22:26:20 GMT6

>On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
><marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
>
>> Hence the reason Ada was
>>designed with readability in mind rather than attempting to save keystrokes.
>
>There is a general rule though, that a terser program makes it easier
>to see the big picture.  You can get more of it on screen at once.
>Use of smaller methods so can easily see the whole flow of a method in
>a single screen full, without getting bogged in too much detail,
>really helps.
>
>Rapid navigation tools similarly help.  See
>http://mindprod.com/scid.html.
>
>What I find so strange is something as simple as variable
>sized/coloured {} and () to make visual balancing easier still has not
>caught on.  

Do you mean the way they are highlighted in Excell formules? Wonderfull, isn't
it. On each IDE review I write I mention this in the TODO list.

>
>Perhaps if we had more females in the tool design process they would
>not be so macho about insisting on making programming uncomfortable
>and difficult.
>
>
>
>For more detail, please look up the key words mentioned in this post in
>the Java Glossary at: http://mindprod.com/gloss.html 
>If you don't see what you were looking for, complain!
>or send your contribution for the glossary.


Greetings,
Dirk Bosmans


Java tools at http://users.belgacombusiness.net/arci/
- Cramfull Resource Compiler library (NEW)
- Applicet Framework: turns Applets into Applications
- ArciMath BigDecimal: now with BigDecimalFormat

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 21:44:31 +0200, Dirk Bosmans
<Dirk.Bosmans@tijd.com> wrote or quoted :

>Do you mean the way they are highlighted in Excell formules? Wonderfull, isn't
>it. On each IDE review I write I mention this in the TODO list

It is exciting when Microsoft adopts radical new ideas like this, I
mean as in Sir Isaac Newton's mathematical notation or Knuth's TeX for
something a little more recent.

I wonder when the 2D graphic nature of the screen will dawn on the
authors of Java IDEs.  I think they fear future shock if they
attempted it. We Java programmers are such old fogies glued to our
glass TTY metaphor.

see http://mindprod.com/scid.html



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[James Kanze]

Roedy Green wrote:

> I wonder when the 2D graphic nature of the screen will dawn on the
> authors of Java IDEs.  I think they fear future shock if they
> attempted it. We Java programmers are such old fogies glued to our
> glass TTY metaphor.

It's the C heritage.  (And the TTY isn't glass.  It makes a real bang
each time a character is output.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B20D334.309E06DD@dresdner-bank.com>, on 06/08/2001
   at 03:29 PM, James Kanze <James.Kanze@dresdner-bank.com> said:

>It's the C heritage.  (And the TTY isn't glass.  It makes a real bang
>each time a character is output.)

TTY is an abbreviation for Teletype. It refers to more than just,
e.g., an ASR33. Some Teletype products used a CRT. Q.E.D.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Roedy Green]

On Wed, 13 Jun 2001 08:33:53 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote or quoted :

>TTY isn't glass
 
"glass TTY" is Canadian for a dumb terminal, most notably the VU-Com
then the more flexible DEC VT-100.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Jerry Petrey]

Roedy Green wrote:
> 
> On Wed, 13 Jun 2001 08:33:53 -0400, "Shmuel (Seymour J.) Metz"
> <spamtrap@library.lspace.org.invalid> wrote or quoted :
> 
> >TTY isn't glass
> 
> "glass TTY" is Canadian for a dumb terminal, most notably the VU-Com
> then the more flexible DEC VT-100.
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Not just Canadian -
'Glass TTY' has been in common use in the US for many years for the
same thing (a dumb terminal).


Jerry
-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to
reply                  
-----------------------------------------------------------------------------

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <hljfitke5uvgn1nj3vadlt5hjrghruholn@4ax.com>, on 06/13/2001
   at 08:38 PM, Roedy Green <roedy@mindprod.com> said:

>On Wed, 13 Jun 2001 08:33:53 -0400, "Shmuel (Seymour J.) Metz"
><spamtrap@library.lspace.org.invalid> wrote or quoted :

>>TTY isn't glass
> 
>"glass TTY" is Canadian for a dumb terminal, most notably the VU-Com
>then the more flexible DEC VT-100.

TTY is an abbreviation for Teletype and, as I noted, some Teletype
products were CRT terminals. The usage "glass TTY" is by no means
limited to Canada.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Conrad Schneiker]

IMHO, this has strayed pretty far off topic insofar as Ruby is concerned.

Please omit comp.lang.ruby from future replies to this thread.

Perhaps mercy and/or a little more netiquitte for other newsgroups is called
for as well. :-)

Thanks.

Conrad

Re: Long names are doom ?

[Larry Kilgallen]

In article <pb2ohtgs64jhssmmohpq5qr7nmcsq6119c@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
> 
>> Hence the reason Ada was
>>designed with readability in mind rather than attempting to save keystrokes.
> 
> There is a general rule though, that a terser program makes it easier

And where is this rule written ?  Most programs I have seen can be made
more clear by tripling their length with well-written comments (once
good identifier names have been chosen).

> to see the big picture.  You can get more of it on screen at once.
> Use of smaller methods so can easily see the whole flow of a method in
> a single screen full, without getting bogged in too much detail,
> really helps.

Subprograms are important to separate logical functions, but using
them just in pursuit of getting the whole thing to show on a screen
of some arbitrary size is much less valuable.

> What I find so strange is something as simple as variable
> sized/coloured {} and () to make visual balancing easier still has not
> caught on.  

What makes you say it has not caught on ?

Several editors do syntax coloring for Ada, and the Alpha editor also
does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
Postscript, Scheme, SQL, Tcl, TeX, LaTeX and LaTeX2e.

BBEdit does it for HTML JavaScript, Perl, PHP3, XHTML and XML.

Of those two, BBEdit is more popular, but someone else would have to
speak to the capabilities of various Emacs implementations.

Re: Long names are doom ?

[Roedy Green]

On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
Kilgallen) wrote or quoted :

>> There is a general rule though, that a terser program makes it easier
>
>And where is this rule written ?  

Two places.  See Byte Magazine 1986 October, my article on Abundance.

See also http://mindprod.com/unmain.html an essay on how to write
unmaintainable code.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Roedy Green]

On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
Kilgallen) wrote or quoted :

>> What I find so strange is something as simple as variable
>> sized/coloured {} and () to make visual balancing easier still has not
>> caught on.  
>
>What makes you say it has not caught on ?
>
>Several editors do syntax coloring for Ada, and the Alpha editor also
>does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
>Postscript, Scheme, SQL, Tcl, TeX, LaTeX and LaTeX

I did not explain clearly.  I don't just mean making all {} some
colour different from the rest of text, but to make them match
pairwise in increasing size with nesting depth, possibly also using
different shade with matching pairs the same shade.

See http://mindprod.com/bali.html where you can see some examples of
what it might look like.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Blaikie]

> I did not explain clearly.  I don't just mean making all {} some
> colour different from the rest of text, but to make them match
> pairwise in increasing size with nesting depth, possibly also using
> different shade with matching pairs the same shade.

only a finite number of possible shades, yet an infinite number of possibly
nested brakets, a quite usefull solution is used in Forte4Java, whenever the
text cursor passes over a braket, both the begin and matching end brackets
go bold for a short time.
db

Re: Long names are doom ?

[Gary Scott]

Kedit matches left/right by color.  No def file for Ada, but you could
easily write one.

Roedy Green wrote:
> 
> On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :
> 
> >> What I find so strange is something as simple as variable
> >> sized/coloured {} and () to make visual balancing easier still has not
> >> caught on.
> >
> >What makes you say it has not caught on ?
> >
> >Several editors do syntax coloring for Ada, and the Alpha editor also
> >does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
> >Postscript, Scheme, SQL, Tcl, TeX, LaTeX and LaTeX
> 
> I did not explain clearly.  I don't just mean making all {} some
> colour different from the rest of text, but to make them match
> pairwise in increasing size with nesting depth, possibly also using
> different shade with matching pairs the same shade.
> 
> See http://mindprod.com/bali.html where you can see some examples of
> what it might look like.
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Larry Kilgallen]

In article <bqeoht05rusrp4v72bf2aq4r0ib4s5c5fs@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :
> 
>>> There is a general rule though, that a terser program makes it easier
>>
>>And where is this rule written ?  
> 
> Two places.  See Byte Magazine 1986 October, my article on Abundance.
> 
> See also http://mindprod.com/unmain.html an essay on how to write
> unmaintainable code.

Since these are both your work, I think a more open statement than
"There is a general rule" would have been "I have a general rule".

Re: Long names are doom ?

[Roedy Green]

On 4 Jun 2001 22:27:23 -0500, Kilgallen@eisner.decus.org.nospam (Larry
Kilgallen) wrote or quoted :

>Since these are both your work, I think a more open statement than
>"There is a general rule" would have been "I have a general rule".

Being dreadfully modest, I doubt there are few other people in the
world who, when they can't fall asleep at night worry about why the
world's computer programs are not maintainable.  It has been a bit of
an obsession of mine for a long time, going back before some of you
were born.  I have done quite a bit of experimenting trying to find
out what makes programs maintainable and unmaintainable.  Few others
in the known universe have come near the number of posts I have done
preaching the gospel of maintainability and the path to true
salvation.

Even the esteemed Bruce Eckel said I should write a book on the topic.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Blaikie]

rather than making every method less than a screen long (again a rather
arbitrary measure of code length, especially seeing as different ppls
resolutions effect what a 'screen' of code is), u only need to seperate
resused code into seperate methods, if u have one method that is 10 pages
long, but there is no reptition and the code is used nowhere else, why make
it into seperate methods? yes a few comments, and alot of thought about the
elegance of the algorithm should be used, but splitting a method just for
the sake of length seems a bit pointless (sometimes, other times if a
certain part of the code serves an independant function to the rest of the
code, yet is still only used once, it may still be nice to seperate it)
db

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> rather than making every method less than a screen long (again a rather
> arbitrary measure of code length, especially seeing as different ppls
> resolutions effect what a 'screen' of code is), u only need to seperate
> resused code into seperate methods, if u have one method that is 10 pages
> long, but there is no reptition and the code is used nowhere else, why make
> it into seperate methods? yes a few comments, and alot of thought about the
> elegance of the algorithm should be used, but splitting a method just for
> the sake of length seems a bit pointless (sometimes, other times if a
> certain part of the code serves an independant function to the rest of the
> code, yet is still only used once, it may still be nice to seperate it)

There *is* a reason to do it - it makes the overall structure easier to 
read. For instance, in many cases those 10 pages of code can be isolated 
into easily described blocks that are independent of the other bits. Say 
you get one of those per page - then the main method can become just 10 
lines long, giving a very easy overview. It then becomes very easy to 
pinpoint which piece of the code performs any particular function.

It doesn't always work like that, but it can. Code repetition isn't the 
only reason for refactoring.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> > the sake of length seems a bit pointless (sometimes, other times if a
> > certain part of the code serves an independant function to the rest of
the
> > code, yet is still only used once, it may still be nice to seperate it)
> It doesn't always work like that, but it can. Code repetition isn't the
> only reason for refactoring.

i agree, thats why i put the exception in the brakets at the end, but there
are times when the code just simple isn't divisible, which is the point i
was making, yes if u have a routine that reads in and creates a simple
object., but one of its fields is an int, yes, have a seperate method that
reads and parses an int, but such a case is not always possible
db

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> 
> > > the sake of length seems a bit pointless (sometimes, other times if a
> > > certain part of the code serves an independant function to the rest of
> the
> > > code, yet is still only used once, it may still be nice to seperate it)
> > It doesn't always work like that, but it can. Code repetition isn't the
> > only reason for refactoring.
> 
> i agree, thats why i put the exception in the brakets at the end, but there
> are times when the code just simple isn't divisible, which is the point i
> was making, yes if u have a routine that reads in and creates a simple
> object., but one of its fields is an int, yes, have a seperate method that
> reads and parses an int, but such a case is not always possible

Not *always* possible - but your inclusion of it just in brackets makes 
it appear that you believe it's normally the case.

I'd suggest that *very* few methods which are ten pages of code which 
*can't* be broken down further are well-designed.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> Not *always* possible - but your inclusion of it just in brackets makes
> it appear that you believe it's normally the case.
> I'd suggest that *very* few methods which are ten pages of code which
> *can't* be broken down further are well-designed.

quite probably, neways the point is, we agree, its just a matter of degrees
and probability of atomic code
db

Re: Long names are doom ?

[Ted Dennison]

In article <9fi87m$9du$1@bugstomper.ihug.com.au>, Blaikie says...
>
>rather than making every method less than a screen long (again a rather
>arbitrary measure of code length, especially seeing as different ppls
>resolutions effect what a 'screen' of code is), u only need to seperate
>resused code into seperate methods, if u have one method that is 10 pages
>long, but there is no reptition and the code is used nowhere else, why make
>it into seperate methods? yes a few comments, and alot of thought about the

Any routine that is 10 pages long is doing a *lot* of stuff. Perhaps in
high-level terms you can express what it is doing succinctly, but at the level
that the routine actually operates, you can't. If you can't express what the
routine is doing succinctly, at the level it operates, then a maintainer is
going to have to read through 10 screens of code to figure it out themselves.
The author might even get confused on the subject from time to time. Bugs are
going to be tougher to spot and track down because you'll have to rethink the
subject of exactly what the routine is supposed to be doing every time you
revisit it.

Additionally, I find that I often end up with *less* code when I split a big
routine up into smaller ones. The data flow is also easier to follow because
what were routine-wide globals that could be modified anywhere within 10 screens
of code often turn into parameters that only go into one or two of the new
smaller routines. Its also much better commented, becuase I always have a header
comment for every routine describing its purpose and what it does.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> Being dreadfully modest, I doubt there are few other people in the
> world who, when they can't fall asleep at night worry about why the
> world's computer programs are not maintainable...

I beg to differ.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

If you like maintainability - you probably want to look seriously at Ada.
That was one of the design goals of the language. There are lots of examples
on the net of well structured Ada code that I believe illustrate how it can
be used to develop more easily maintained systems. (I like to think the code
on my web page is very readable & maintainable. Take a look at some of it
at: http://www.mcondic.com/ There are plenty of other examples & a good
place to start is at http://www.adapower.org/)

I'd have to disagree on the notion that "terseness" in and of itself is
somehow going to contribute to clarity & maintainability. In my experience,
what counts much more is clarity of thought in the original design, a
logical breakdown of the problem into pieces, meaningful expression of the
design in the language of implementation (good names, comments, obvious
flow, etc.) and support from the environment for error detection and
correction. If expressing something in as few keystrokes as possible were
somehow going to lead to maintainability, then the answer would have been
things like APL - or even machine code. (Not many characters needed to
represent hex digits, right?)

If "terseness" is really another word for "abstraction" then I might be
inclined to agree. Saying in your code something like: Quick_Sort
(Some_Array) ; is obviously easier to understand than spelling out in great
detail the entire Quick Sort algorithm. Here the "terseness" is a way of
saying "There is this highly complex operation of sorting an array that you
don't need to bother trying to understand. Trust me. When I get back from
the call, your whole array will be sorted." That sort of "terseness" I'd
concede helps with maintenance - but I think it is more aptly named
"Abstraction" or "Functional Independence".

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:q81pht43ib89sjop0i245bvs502416t1tp@4ax.com...
> On 4 Jun 2001 22:27:23 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :
>
> >Since these are both your work, I think a more open statement than
> >"There is a general rule" would have been "I have a general rule".
>
> Being dreadfully modest, I doubt there are few other people in the
> world who, when they can't fall asleep at night worry about why the
> world's computer programs are not maintainable.  It has been a bit of
> an obsession of mine for a long time, going back before some of you
> were born.  I have done quite a bit of experimenting trying to find
> out what makes programs maintainable and unmaintainable.  Few others
> in the known universe have come near the number of posts I have done
> preaching the gospel of maintainability and the path to true
> salvation.
>
> Even the esteemed Bruce Eckel said I should write a book on the topic.
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Larry Kilgallen]

In article <MPG.1586b84f5bc22ee798a6c8@mrmog.peramon.com>, Jon Skeet <skeet@pobox.com> writes:
> Blaikie <david_blaikie@hotmail.com> wrote:
>> rather than making every method less than a screen long (again a rather
>> arbitrary measure of code length, especially seeing as different ppls
>> resolutions effect what a 'screen' of code is), u only need to seperate
>> resused code into seperate methods, if u have one method that is 10 pages
>> long, but there is no reptition and the code is used nowhere else, why make
>> it into seperate methods? yes a few comments, and alot of thought about the
>> elegance of the algorithm should be used, but splitting a method just for
>> the sake of length seems a bit pointless (sometimes, other times if a
>> certain part of the code serves an independant function to the rest of the
>> code, yet is still only used once, it may still be nice to seperate it)
> 
> There *is* a reason to do it - it makes the overall structure easier to 
> read. For instance, in many cases those 10 pages of code can be isolated 
> into easily described blocks that are independent of the other bits. Say 
> you get one of those per page - then the main method can become just 10 
> lines long, giving a very easy overview. It then becomes very easy to 
> pinpoint which piece of the code performs any particular function.

For me, block comments do that just as well as subprograms.

Re: Long names are doom ?

[Larry Kilgallen]

In article <MPG.1586bd4148c0f02198a6ca@mrmog.peramon.com>, Jon Skeet <skeet@pobox.com> writes:
> Blaikie <david_blaikie@hotmail.com> wrote:
>> 
>> > > the sake of length seems a bit pointless (sometimes, other times if a
>> > > certain part of the code serves an independant function to the rest of
>> the
>> > > code, yet is still only used once, it may still be nice to seperate it)
>> > It doesn't always work like that, but it can. Code repetition isn't the
>> > only reason for refactoring.
>> 
>> i agree, thats why i put the exception in the brakets at the end, but there
>> are times when the code just simple isn't divisible, which is the point i
>> was making, yes if u have a routine that reads in and creates a simple
>> object., but one of its fields is an int, yes, have a seperate method that
>> reads and parses an int, but such a case is not always possible
> 
> Not *always* possible - but your inclusion of it just in brackets makes 
> it appear that you believe it's normally the case.
> 
> I'd suggest that *very* few methods which are ten pages of code which 
> *can't* be broken down further are well-designed.

How about a case statement for 137 possible cases ?

Even if it only calls a separate subprogram for each, that is longer
than most people's screenful.

Re: Long names are doom ?

[Jon Skeet]

Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:

> > I'd suggest that *very* few methods which are ten pages of code which 
> > *can't* be broken down further are well-designed.
> 
> How about a case statement for 137 possible cases ?
> 
> Even if it only calls a separate subprogram for each, that is longer
> than most people's screenful.

Yup - and how often does that happen (in a way which isn't better coped 
with by more object-oriented design)?

Very occasionally - hence my allowance that it's possible. I suspect 
there are far more programs with methods of 10 "normal" screenfuls that 
are just badly written than there are programs with a genuine 
justification for it.

(Note - I'm discounting auto-generated code in the above; that will 
often naturally create huge methods.)

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Steve Bellenot]

In article <+FWVg+noA0yk@eisner.encompasserve.org>,
Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
>In article <MPG.1586bd4148c0f02198a6ca@mrmog.peramon.com>, Jon Skeet <skeet@pobox.com> writes:
>> Blaikie <david_blaikie@hotmail.com> wrote:
>>> 
>>> > > the sake of length seems a bit pointless (sometimes, other times if a
>>> > > certain part of the code serves an independant function to the rest of
>>> the
>>> > > code, yet is still only used once, it may still be nice to seperate it)
>>> > It doesn't always work like that, but it can. Code repetition isn't the
>>> > only reason for refactoring.
>>> 
>>> i agree, thats why i put the exception in the brakets at the end, but there
>>> are times when the code just simple isn't divisible, which is the point i
>>> was making, yes if u have a routine that reads in and creates a simple
>>> object., but one of its fields is an int, yes, have a seperate method that
>>> reads and parses an int, but such a case is not always possible
>> 
>> Not *always* possible - but your inclusion of it just in brackets makes 
>> it appear that you believe it's normally the case.
>> 
>> I'd suggest that *very* few methods which are ten pages of code which 
>> *can't* be broken down further are well-designed.
>
>How about a case statement for 137 possible cases ?

Depends on the language of course, but I think it is likely that this
is the wrong solution. At some point, it would make sense to replace
the case statement with a config file and some program that automatically
generated the case code from the config file. 

If the language supported it, a jump table might make more sense than
a case statement. Again the jump table could be loaded from a config
file.

>Even if it only calls a separate subprogram for each, that is longer
>than most people's screenful.

-- 
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu 
+1.850.644.7189 (4053fax)

Re: Long names are doom ?

[Blaikie]

> Depends on the language of course, but I think it is likely that this
> is the wrong solution. At some point, it would make sense to replace
> the case statement with a config file and some program that automatically
> generated the case code from the config file.
>
> If the language supported it, a jump table might make more sense than
> a case statement. Again the jump table could be loaded from a config
> file.

well i am not sure what a jump table is, but if it were in Java and there
were corresponding methods to each of the cases in the swtich, i would use a
general piece of java.lang.reflection code to load the method based directly
on the string (or turn the variable into the string nescessary using maybe a
hashmap)
db

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> > Depends on the language of course, but I think it is likely that this
> > is the wrong solution. At some point, it would make sense to replace
> > the case statement with a config file and some program that automatically
> > generated the case code from the config file.
> >
> > If the language supported it, a jump table might make more sense than
> > a case statement. Again the jump table could be loaded from a config
> > file.
> 
> well i am not sure what a jump table is, but if it were in Java and there
> were corresponding methods to each of the cases in the swtich, i would use a
> general piece of java.lang.reflection code to load the method based directly
> on the string (or turn the variable into the string nescessary using maybe a
> hashmap)

Reflection would be an *incredibly* slow way of doing that. Better would 
be to create (at startup) one object for handling each case, each 
implementing the same interface. Put *those* into a map of some 
description, then get out the "right" object and call one of the methods 
of the common interface.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> Reflection would be an *incredibly* slow way of doing that. Better would
> be to create (at startup) one object for handling each case, each
> implementing the same interface. Put *those* into a map of some
> description, then get out the "right" object and call one of the methods
> of the common interface.

what makes u say reflection is so slow? seems alot of applications use it
alot (main one i can think of is jsp)
db

Re: Long names are doom ?

[Jon Skeet]

Blaikie <david_blaikie@hotmail.com> wrote:
> > Reflection would be an *incredibly* slow way of doing that. Better would
> > be to create (at startup) one object for handling each case, each
> > implementing the same interface. Put *those* into a map of some
> > description, then get out the "right" object and call one of the methods
> > of the common interface.
> 
> what makes u say reflection is so slow? seems alot of applications use it
> alot (main one i can think of is jsp)

Reflection is *far* slower than straight method calls, partly because 
there's an awful lot more to do.

Yes, it's very useful *in its place*, but there's no need to do it in 
this case, and could easily turn it into a bottleneck if this code is 
run frequently.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Blaikie]

> Reflection is *far* slower than straight method calls, partly because
> there's an awful lot more to do.

i'm not saying it isn't, but what evidence do u have to suggest it is? if
there is documentation somewhere, i would just like to see it thats all
db

Re: Long names are doom ?

[Roedy Green]

On Wed, 6 Jun 2001 18:18:29 +1000, "Blaikie"
<david_blaikie@hotmail.com> wrote or quoted :

>what makes u say reflection is so slow?
 
Ask Jonathan Revusky about that, then watch the steam shoot from his
ears.  He unsuccessfully tried to convince our boss from using
reflection in a project we both once worked on.  Reflection is a fun
toy, suitable for bean boxes and the like where, but there are much
faster ways of handling the usual production cases.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Jonathan Revusky]

Roedy Green <roedy@mindprod.com> wrote in message news:<nh6thtgkds4dlubj0s1ss0n7b43jjir39h@4ax.com>...

> On Wed, 6 Jun 2001 18:18:29 +1000, "Blaikie"

> <david_blaikie@hotmail.com> wrote or quoted :

> 

> >what makes u say reflection is so slow?

>  

> Ask Jonathan Revusky about that, then watch the steam shoot from his

> ears.  He unsuccessfully tried to convince our boss from using

> reflection in a project we both once worked on.  Reflection is a fun

> toy, suitable for bean boxes and the like where, but there are much

> faster ways of handling the usual production cases.


I didn't actually care so much about calls via reflection being slower
(though I guess they must be and it is also something to worry
about... a bit) but my concern was the tendency for the code to be
very difficult to read or maintain.

I think there is a tendency for the C hackers moving to Java to
overuse reflection (once they discover it) because things like
java.lang.reflect.Method can map perfectly in their minds to a C
function pointer. Also, the C hackers aren't usually familiar enough
with OO patterns to realize that you don't really need function
pointers like that in Java. (Or at least hardly ever.) In C, the use
of the function pointers also leads to very obfuscated,
hard-to-maintain code, but that's really unavoidable. AFAICS it's the
only way you get polymorphism in C.

Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper
classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://www.revusky.com/hacks/

Re: Long names are doom ?

[James Kanze]

Jonathan Revusky wrote:

> I didn't actually care so much about calls via reflection being
> slower (though I guess they must be and it is also something to
> worry about... a bit) but my concern was the tendency for the code
> to be very difficult to read or maintain.

Not to mention that it means that all of the compiler type checking is
moved off to runtime.

> I think there is a tendency for the C hackers moving to Java to
> overuse reflection (once they discover it) because things like
> java.lang.reflect.Method can map perfectly in their minds to a C
> function pointer.

Except that most real C hackers don't use function pointers, either.
Most often, I've seen monster switches or a chain of if's.

> Also, the C hackers aren't usually familiar enough with OO patterns
> to realize that you don't really need function pointers like that in
> Java. (Or at least hardly ever.) In C, the use of the function
> pointers also leads to very obfuscated, hard-to-maintain code, but
> that's really unavoidable. AFAICS it's the only way you get
> polymorphism in C.

As with many things, used correctly, function pointers can actually
improve readability.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[James Kanze]

Jon Skeet wrote:

> Blaikie <david_blaikie@hotmail.com> wrote:
> > > Depends on the language of course, but I think it is likely that
> > > this is the wrong solution. At some point, it would make sense
> > > to replace the case statement with a config file and some
> > > program that automatically generated the case code from the
> > > config file.

> > > If the language supported it, a jump table might make more sense
> > > than a case statement. Again the jump table could be loaded from
> > > a config file.

> > well i am not sure what a jump table is, but if it were in Java
> > and there were corresponding methods to each of the cases in the
> > swtich, i would use a general piece of java.lang.reflection code
> > to load the method based directly on the string (or turn the
> > variable into the string nescessary using maybe a hashmap)

> Reflection would be an *incredibly* slow way of doing that. Better
> would be to create (at startup) one object for handling each case,
> each implementing the same interface. Put *those* into a map of some
> description, then get out the "right" object and call one of the
> methods of the common interface.

That's the way I generally do it, but there are exceptions.  The
classical example is in lexical analysis, where you use a switch with
one entry per starting character.  Speed is often an issue here, of
course.  (And in most modern systems, you'll arrange for the switch to
be generated automatically, so it isn't hand written code.)

Of course, the fact that there is ONE exception doesn't invalidate the
general premice.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Larry Kilgallen]

In article <eseohtcf468ea4v1klabbm47k01uohdnt3@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On 4 Jun 2001 19:40:29 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :
> 
>>> What I find so strange is something as simple as variable
>>> sized/coloured {} and () to make visual balancing easier still has not
>>> caught on.  
>>
>>What makes you say it has not caught on ?
>>
>>Several editors do syntax coloring for Ada, and the Alpha editor also
>>does it for C, C++, Fortran, HTML, Java, Pascal, Modula-2, Perl,
>>Postscript, Scheme, SQL, Tcl, TeX, LaTeX and LaTeX
> 
> I did not explain clearly.  I don't just mean making all {} some
> colour different from the rest of text, but to make them match
> pairwise in increasing size with nesting depth, possibly also using
> different shade with matching pairs the same shade.

Increasing depths are taken care of automatically by prettyprinters
(a misnomer, but that is what a lot of people call formatting programs).
In Ada those that are standalone are actually begin/end pairs, and I
always find the indentation to be sufficient.  If it is not I view it
as a danger signal for excessive complexity.

I presume you are not worried about matching in something short like
an array reference or function call:

	Answer := Correct_Answer ( Answer_Number ( Index ) );

Re: Long names are doom ?

[Larry Kilgallen]

In article <bqeoht05rusrp4v72bf2aq4r0ib4s5c5fs@4ax.com>, Roedy Green <roedy@mindprod.com> writes:

> See also http://mindprod.com/unmain.html an essay on how to write
> unmaintainable code.

That is a good essay, though.

Re: Long names are doom ?

[Pete Thompson]

On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

>way around. (And when did "terse" become of value in and of itself, anyway?
>Why should it be a goal to be strived for?)
>
>MDC

Terse for the sake of readability is good.  It gets right to the point.

Terse for the sake of being cryptic is bad.  

Re: Long names are doom ?

[Marin David Condic]

My comment is WRT "terse" for the sake of "terse". If the goal is
"readability" then it is yet to be demonstrated to my satisfaction that
"terse" serves this goal. As has been noted elsewhere, APL and assembly
language could both be described as "terse" and neither is typically held up
as an example of how to produce "readability". If one would contend that
"terse" serves "readability" I would ask to see some kind of study backing
up that claim - complete with a definition of what counts as "terse" and
what is simply "cryptic".

Granted, there are some shorthand notations within any given language that
the cognosenti immediately recognize. This might lead them to believe that
their shorthand is thus more "readable". What they are really seeing is the
fact that it is their familiarity with the idiom that makes it readable - in
the same way that a program I spend weeks building & massaging is more
"readable" than the one someone just now dumped in my lap.

In my estimation, the issue of "readability" is far more important for
someone *new* to a project and/or *new* to the language. Can they walk in
the door and get up to speed more quickly (thus making more money for the
stockholders) if we rely on "terse" languages/notations or will they become
productive faster if the language/notations are more verbose, rely less on
non-obvious semantics, have better comments, etc.?

As for "terse for the sake of being cryptic" - that's obviously A Bad Thing.
My contention is that some programmers are terse for the sake of being
cryptic without really realizing that this is what they are doing. As
cognosenti they derive satisfaction from having what seems cryptic to the
outsider seem intuitively obvious to them. They may remark "....Well any
*competent* XXX programmer would understand this code at a glance!..." It
makes them feel good that they (and the rest of the in-crowd) must be
"better" than the unwashed masses.

Me? I'd rather write unbelievably uncomplicated, uncryptic, un-terse code
(especially when using C) so that when I have someone less experienced, less
familiar or less gifted coming on to a project, they can pick it up as
absolutely quickly as is possible and have the minimum problems making
changes to the code. Why? A) it makes money for the stockholders. B) It
keeps them from asking me hundreds of questions and using up my day - thus
making more money for the stockholders. C) Its less likely they'll make a
mistake that ends up costing the company lots of money - again maximizing
shareholder value, D) Did I mention that it makes money for the
stockholders? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:rdeqht0fhtvgbpima8jbuolfvrl88n3cc3@4ax.com...
> On Mon, 4 Jun 2001 11:46:36 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote:
>
> >way around. (And when did "terse" become of value in and of itself,
anyway?
> >Why should it be a goal to be strived for?)
> >
> >MDC
>
> Terse for the sake of readability is good.  It gets right to the point.
>
> Terse for the sake of being cryptic is bad.
>
>

Re: Long names are doom ?

[Pete Thompson]

On Tue, 5 Jun 2001 16:47:36 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

>My comment is WRT "terse" for the sake of "terse". If the goal is
>"readability" then it is yet to be demonstrated to my satisfaction that
>"terse" serves this goal. As has been noted elsewhere, APL and assembly

Hmm in that case, I should give you my sister's phone number.  She can talk for
well over two hours on the phone before finally getting to the point  :)  

I feel the same way about code:  being verbose is all well and good, but
pointless verbosity can do more harm than good.  It tends to hide the overall
picture as to what the function/application is *really* doing.  It makes the
function look more complicated than it really is.  It leaves you wondering if
you're somehow missing something because there's more to read than is really
necessary.  

As Roedy mentioned in some other message, it's a hard one to pin down since
it's such a subjective matter.  Maybe it's futile to even try.

>language could both be described as "terse" and neither is typically held up
>as an example of how to produce "readability". If one would contend that
>"terse" serves "readability" I would ask to see some kind of study backing
>up that claim - complete with a definition of what counts as "terse" and
>what is simply "cryptic".

Perhaps it'd help by using a thesaurus?  

Good terse:  clear summary, concise, succinct.
Bad terse:  hidden, cryptic, magical.

Good verbosity: descriptive, explanatory.
Bad verbosity:  tedious, rambling, long-winded.

Which one of the following do you prefer:

i = i + 1;

or

i equals i plus one.  

Imagine a whole program written using the latter method.  Would that really be
much fun to read?  Compound statements would be nearly unreadable.

>Granted, there are some shorthand notations within any given language that
>the cognosenti immediately recognize. This might lead them to believe that
>their shorthand is thus more "readable". What they are really seeing is the
>fact that it is their familiarity with the idiom that makes it readable - in
>the same way that a program I spend weeks building & massaging is more
>"readable" than the one someone just now dumped in my lap.

True.  After all, a mathematical formula may seem cryptic to the average
layperson, but it's immediately readable by other mathematicans.  

>In my estimation, the issue of "readability" is far more important for
>someone *new* to a project and/or *new* to the language. Can they walk in
>the door and get up to speed more quickly (thus making more money for the
>stockholders) if we rely on "terse" languages/notations or will they become
>productive faster if the language/notations are more verbose, rely less on
>non-obvious semantics, have better comments, etc.?

Hmm.. I'd have to say that I agree and disagree.  It really depends on what
industry you're in.  If you're in the kind of industry where you're hiring
newbie programmers all the time, then yes, it's important to be as explicit as
possible.  However, there are industries where programmers MUST be experienced
before they're hired.  Does it really make sense to make your code as
newbie-ish as possible for them?  (Again, without being cryptic).  

There has to be a cut-off point where a certain number of knowledge and
experience is required from new programmers, though.  If they don't meet that
requirement, then they shouldn't have been hired in the first place.  After
all, it's not *my* problem if someone doesn't know what a modulus operator is.

>As for "terse for the sake of being cryptic" - that's obviously A Bad Thing.
>My contention is that some programmers are terse for the sake of being
>cryptic without really realizing that this is what they are doing. As
>cognosenti they derive satisfaction from having what seems cryptic to the
>outsider seem intuitively obvious to them. They may remark "....Well any
>*competent* XXX programmer would understand this code at a glance!..." It
>makes them feel good that they (and the rest of the in-crowd) must be
>"better" than the unwashed masses.

Well, that's sort of going to the extreme.  If the syntax is a part of the
language itself, then it should be readable by anyone well versed with the
language.  "i++" is not cryptic since that's a part of the language.  

If it's a "clever" (ab)use of the language, then you may need to reevaluate
what you're doing.   I hate it when people try to cram 4 or 5 or more different
things into the same line.  I just love reading stuff like c = a+++++b.  (not)

My general convention is one or two instructions per line, if possible, and use
generous amounts of whitespaces and brackets.

>Me? I'd rather write unbelievably uncomplicated, uncryptic, un-terse code
>(especially when using C) so that when I have someone less experienced, less
>familiar or less gifted coming on to a project, they can pick it up as
>absolutely quickly as is possible and have the minimum problems making
>changes to the code. Why? A) it makes money for the stockholders. B) It
>keeps them from asking me hundreds of questions and using up my day - thus
>making more money for the stockholders. C) Its less likely they'll make a
>mistake that ends up costing the company lots of money - again maximizing
>shareholder value, D) Did I mention that it makes money for the
>stockholders? :-)
>
>MDC

I guess we're pretty much arguing the same thing at this point.  My own
contention is that there are programmers who are needlessly verbose that the
code looks more complex than it really is.

Of course, coming from a DirectX background, it's possible that I may be a
little biased  :) 

Re: Long names are doom ?

[John English]

Pete Thompson wrote:
> Good terse:  clear summary, concise, succinct.
> Bad terse:  hidden, cryptic, magical.
> 
> Good verbosity: descriptive, explanatory.
> Bad verbosity:  tedious, rambling, long-winded.

There are also many instances of "bad verbose" code where "bad verbose"
translates to "hidden, cryptic, magical", or even just plain stupid.
As an extreme example of this, I cite a past student of mine who
couldn't remember how to determine the length of a string, and resorted
to writing it to a temporary file because he knew how to find the size
of a file... :-(

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Creative? (was: Long names ....)

[Wes Groleau]

> couldn't remember how to determine the length of a string, and resorted
> to writing it to a temporary file because he knew how to find the size
> of a file... :-(

Add five points for creativity and resourcefulness.
Subtract twenty for being too lazy to open the reference manual.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 10:14:31 +0100, John English <je@brighton.ac.uk> wrote:

>Pete Thompson wrote:
>> Good terse:  clear summary, concise, succinct.
>> Bad terse:  hidden, cryptic, magical.
>> 
>> Good verbosity: descriptive, explanatory.
>> Bad verbosity:  tedious, rambling, long-winded.
>
>There are also many instances of "bad verbose" code where "bad verbose"
>translates to "hidden, cryptic, magical", or even just plain stupid.
>As an extreme example of this, I cite a past student of mine who
>couldn't remember how to determine the length of a string, and resorted
>to writing it to a temporary file because he knew how to find the size
>of a file... :-(
>


Ouch.  That's pretty sick.

Still, I'd have to give him a couple of points for creativity  :) 

Re: Long names are doom ?

[David Gillon]

Pete Thompson wrote:

> >In my estimation, the issue of "readability" is far more important for
> >someone *new* to a project and/or *new* to the language. Can they walk in
> >the door and get up to speed more quickly (thus making more money for the
> >stockholders) if we rely on "terse" languages/notations or will they become
> >productive faster if the language/notations are more verbose, rely less on
> >non-obvious semantics, have better comments, etc.?
> 
> Hmm.. I'd have to say that I agree and disagree.  It really depends on what
> industry you're in.  If you're in the kind of industry where you're hiring
> newbie programmers all the time, then yes, it's important to be as explicit as
> possible.  However, there are industries where programmers MUST be experienced
> before they're hired.  Does it really make sense to make your code as
> newbie-ish as possible for them?  (Again, without being cryptic).

Explicit, readable coding has value even when being read by the most
experienced of software engineers. Consider the case of a safety
critical system under review by an external auditor prior to
certification. It's vital he be able to review the system in as thorough
a manner as possible in the time available, yet he may be completely new
to your coding standards and practices. The logic of a decision needs to
be clearly laid our for him, not something he needs to delve into the
musty depths of obscure documents for or to seek information on from the
original coder (especially if the original coder is in a substantially
different timezone). Equally, someone may have to fix your code twenty
years down the tracks, when the original coding team and the rationale
behind their decisions may have long since vanished (or walked in front
of a bus...). 

Explicit pays, maybe not now, maybe not directly, but in the end its a
worthwhile investment.


-- 


David Gillon

Re: Long names are doom ?

[Gary Scott]

Hi,

"Readability" can be far better achieved through the proper use of
comments.  While variable names should be "understandable" (you decide
what that means), the implication that
variables/procedure/class/member/etc names must be full english words is
a red herring.  The CODE does not necessarily need to be so obsessively
verbose, the commentary needs to be verbose (or "sufficiently" so).

David Gillon wrote:
> 
> Pete Thompson wrote:
> 
> > >In my estimation, the issue of "readability" is far more important for
> > >someone *new* to a project and/or *new* to the language. Can they walk in
> > >the door and get up to speed more quickly (thus making more money for the
> > >stockholders) if we rely on "terse" languages/notations or will they become
> > >productive faster if the language/notations are more verbose, rely less on
> > >non-obvious semantics, have better comments, etc.?
> >
> > Hmm.. I'd have to say that I agree and disagree.  It really depends on what
> > industry you're in.  If you're in the kind of industry where you're hiring
> > newbie programmers all the time, then yes, it's important to be as explicit as
> > possible.  However, there are industries where programmers MUST be experienced
> > before they're hired.  Does it really make sense to make your code as
> > newbie-ish as possible for them?  (Again, without being cryptic).
> 
> Explicit, readable coding has value even when being read by the most
> experienced of software engineers. Consider the case of a safety
> critical system under review by an external auditor prior to
> certification. It's vital he be able to review the system in as thorough
> a manner as possible in the time available, yet he may be completely new
> to your coding standards and practices. The logic of a decision needs to
> be clearly laid our for him, not something he needs to delve into the
> musty depths of obscure documents for or to seek information on from the
> original coder (especially if the original coder is in a substantially
> different timezone). Equally, someone may have to fix your code twenty
> years down the tracks, when the original coding team and the rationale
> behind their decisions may have long since vanished (or walked in front
> of a bus...).
> 
> Explicit pays, maybe not now, maybe not directly, but in the end its a
> worthwhile investment.
> 
> --
> 
> David Gillon

Re: Long names are doom ?

[Roedy Green]

On Wed, 06 Jun 2001 10:26:11 -0500, Gary Scott
<Gary.L.Scott@lmtas.lmco.com> wrote or quoted :

>While variable names should be "understandable" (you decide
>what that means), the implication that
>variables/procedure/class/member/etc names must be full english words is
>a red herring.  
 
The really important thing is not having two similar variables/methods
whose purposes could be easily confused.  

The problem usually comes from writing a method with a generic name,
then later adding one with a minor variant.  You probably need to
globally rename the first method to make the distinction clear.

Up until recently, most people considered global renaming infeasible.

If we ever gets SCIDS, http://mindprod.com/scid.html,  I think global
renaming will tend to take over from scoping as the preferred way of
avoiding ambiguity, since human brains don't have scoped memory banks.
"i" will still remain the universal loop counter. This is not a human
ambiguity problem.





For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[John English]

Gary Scott wrote:
> "Readability" can be far better achieved through the proper use of
> comments.  While variable names should be "understandable" (you decide
> what that means), the implication that
> variables/procedure/class/member/etc names must be full english words is
> a red herring.  The CODE does not necessarily need to be so obsessively
> verbose, the commentary needs to be verbose (or "sufficiently" so).

The trouble is with comments is that they aren't checked by the compiler,
are often not maintained properly when the code is, and can therefore be
misleading. I'd much prefer the code to provide the information that
would otherwise go in the comments, and the use of meaningful names
(not necessarily verbose, just meaningful) goes a long way towards
achieving that. That way my "commentary" is checkable by the compiler.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Commenting code

[Roedy Green]

On Thu, 07 Jun 2001 09:10:44 +0100, John English <je@brighton.ac.uk>
wrote or quoted :

>That way my "commentary" is checkable by the compiler.

This is one of the big arguments for design by contract rather than
using comments to describe the rules for what methods will eat and
produce.

There a philosophical problem that Jonathan Revusky and I have tussled
over.  When writing JavaDoc, should it be complete, or should it
contain only unexpected information?

We both agree that JavaDoc of this form:

"getSize gets the Size"

Is a waste of effort. You have to think "What would a reasonable human
not know about this parameter or method, that he would reasonably want
to know?"

So you might create a comment of the form:


"getSize gets the number of elements currently in the collection, not
counting free slots."

however, sometimes there is nothing really useful you could add:
e.g. 

"getZipPlusFive  get the US Zip+5 postal code."

If you add this sort of comment, you just needlessly create typing.
You pad the source, diluting the true information.

However, if you leave it out entirely, someone just perusing the
JavaDoc instead of the method signatures themselves, is missing vital
information.

Perhaps then, you could document just the parameter, with no comment.
The problem with this is, how do you tell a "boring" void entry from
one yet to be done? That too could lead to invalid assumptions.

My long term solution is to use SCIDS, where code and the equivalent
of JavaDoc are much more rigidly intertwined.  There would be not need
to type or see any unwanted bubblegum filler, and there would be a
distinction between a entry that does not need a comment and one that
does not yet have a comment.

You could also encode your comments by their surprise value.  That way
for most of the time, you would see only the most important comments,
and gradually fill in picky detail only when you were having a
problem.

Assembler commenting requires that you be able to follow the logic
without looking at ANY of the code. Without a complete picture of what
is going on in the comments, it is very difficult to find the code you
are looking for.  With well-named methods you don't need to do this
for high level languages.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Commenting code

[Jane Williams]

On Thu, 07 Jun 2001 21:58:10 GMT, Roedy Green <roedy@mindprod.com>
wrote:

>however, sometimes there is nothing really useful you could add:
>e.g. 
>
>"getZipPlusFive  get the US Zip+5 postal code."

I'd say that was useful comment, myself. Never having heard of
anything called "zip+5", I would not have guessed that it was a postal
code. Two words of added information: great! If all you'd said was
"gets the zip plus five code" then I'd agree that the comment would be
useless.

Re: Commenting code

[Larry Elmore]

Jane Williams wrote:
> 
> On Thu, 07 Jun 2001 21:58:10 GMT, Roedy Green <roedy@mindprod.com>
> wrote:
> 
> >however, sometimes there is nothing really useful you could add:
> >e.g.
> >
> >"getZipPlusFive  get the US Zip+5 postal code."
> 
> I'd say that was useful comment, myself. Never having heard of
> anything called "zip+5", I would not have guessed that it was a postal
> code.

Even being an American, I would be confused -- I've heard of Zip+4, but
would think this _must_ mean something other than postal code without
the comment. 

> Two words of added information: great! If all you'd said was
> "gets the zip plus five code" then I'd agree that the comment would be
> useless.

As it is, I'd still be bemused and trying to find out if a new standard
had been enacted, or if the programmer (and their program) had seriously
bad assumptions!

Larry

Re: Commenting code

[Marin David Condic]

Good point. Had it been called something like:

procedure Get_Postal_Code (
    Zip_Plus_5_Code    :    out US_Postal_Code_Type) ;

even more information would be communicated in the source code. A comment at
that point saying "Get the US postal code..." would tell you nothing new or
useful.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jane Williams" <jane@williams.nildram.co.uk> wrote in message
news:3b1ffa9a.10556848@pubnews.netcom.net.uk...
> On Thu, 07 Jun 2001 21:58:10 GMT, Roedy Green <roedy@mindprod.com>
> wrote:
>
> >however, sometimes there is nothing really useful you could add:
> >e.g.
> >
> >"getZipPlusFive  get the US Zip+5 postal code."
>
> I'd say that was useful comment, myself. Never having heard of
> anything called "zip+5", I would not have guessed that it was a postal
> code. Two words of added information: great! If all you'd said was
> "gets the zip plus five code" then I'd agree that the comment would be
> useless.
>
>
>

Re: Commenting code

[Larry Kilgallen]

In article <n1tvht8gg83qd4l5jfegp9t2q5gpcfjoeb@4ax.com>, Roedy Green <roedy@mindprod.com> writes:

> however, sometimes there is nothing really useful you could add:
> e.g. 
> 
> "getZipPlusFive  get the US Zip+5 postal code."
> 
> If you add this sort of comment, you just needlessly create typing.
> You pad the source, diluting the true information.

The comment I would like to see is what it returns if only the Zip
code is known and not the additional digits.

Re: Commenting code

[Roedy Green]

On 7 Jun 2001 18:25:27 -0500, Kilgallen@eisner.decus.org.nospam (Larry
Kilgallen) wrote or quoted :

>The comment I would like to see is what it returns if only the Zip
>code is known and not the additional digits.

In my style of documenting you would NOT document that.  That
information belongs in a central project glossary/data directory of
just what a Zip+5 is, and how it is displayed.

The problem with putting that information on every method is it gets
out of sync too easily, and it would be ponderous to document the
format fully everywhere it is used. If ZipPlus5 were a class, with a
display or toString method, the logical place to document that would
be in the ZipPlus5 class.

The problem comes that so many things are for expediency are
considered as primitives in Java that really are logically types, e.g.
treating ZipPlus5 as just a String. There then is not a natural
central place to define and document them.

Again, in future I would hope SCIDS http://mindprod.com/scid.html
would come to the rescue so that the definition would be only a click
or two away when you wanted it.  It could not get out of sync, because
there is logically only one copy of it.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Commenting code

[James Kanze]

Roedy Green wrote:

> On 7 Jun 2001 18:25:27 -0500, Kilgallen@eisner.decus.org.nospam (Larry
> Kilgallen) wrote or quoted :

> >The comment I would like to see is what it returns if only the Zip
> >code is known and not the additional digits.

> In my style of documenting you would NOT document that.  That
> information belongs in a central project glossary/data directory of
> just what a Zip+5 is, and how it is displayed.

One meta-comment: just what is zip+5?  When Roedy first posted the
example, I figured it was just an imaginary example; that the function
actually returned the zip code + 5 (e.g.: for ZipCode 30318, it would
return 30323).  This function obviously has no use (or has no obvious
use), but then, silly examples often don't.

From later comments, I get the feeling that my first impression was
wrong.

> The problem with putting that information on every method is it gets
> out of sync too easily, and it would be ponderous to document the
> format fully everywhere it is used. If ZipPlus5 were a class, with a
> display or toString method, the logical place to document that would
> be in the ZipPlus5 class.

The question is where the information is treated.  If the function
goes to some central data base, and returns whatever it finds there,
then the fact that it returns a standard format should be documented,
but not the format itself.  If the function returns a type
ZipPlusFive, then any documentation concerning the invariants of that
class belong in that class.  If the function actually does something
itself to generate the results, however, then it should document what
it does.  Or rather, what it guarantees.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Commenting code

[John English]

Roedy Green wrote:
> 
> On Thu, 07 Jun 2001 09:10:44 +0100, John English <je@brighton.ac.uk>
> wrote or quoted :
> 
> >That way my "commentary" is checkable by the compiler.
> 
> This is one of the big arguments for design by contract rather than
> using comments to describe the rules for what methods will eat and
> produce.
> 
> There a philosophical problem that Jonathan Revusky and I have tussled
> over.  When writing JavaDoc, should it be complete, or should it
> contain only unexpected information?
> 
> We both agree that JavaDoc of this form:
> 
> "getSize gets the Size"
> 
> Is a waste of effort. You have to think "What would a reasonable human
> not know about this parameter or method, that he would reasonably want
> to know?"

Indeed. Saying "the size" tells you nothing you don't already know...

> So you might create a comment of the form:
> 
> "getSize gets the number of elements currently in the collection, not
> counting free slots."

... but this tells you what "the size" really means, and so is useful.
An assertion could provide the same information, but in current forms
of assertions would be less readable that the natural language
equivalent.

> however, sometimes there is nothing really useful you could add:
> e.g.
> 
> "getZipPlusFive  get the US Zip+5 postal code."

Hmm, I disagree. I'm not an American, so "zip plus 5" means absolutely
nothing to me (just like other American terms like GPA and K-12 and
CS101
that American educators toss around). I also had to have "soccer mom"
translated -- it appeared in an article in CACM, and a letter to the
editor produced a null response since it was presumably too obvious
to answer.

(Off topic: OTOH, Americans talk about "soccer" instead of "football",
but the game they call "football" is played mainly by picking the ball
up and running like hell instead of using the feet. Another example
of misleading documentation provided by an ill-chosen identifier? :-)

Yours very Englishly...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Commenting code

[John English]

John English wrote:
> 
> ... I also had to have "soccer mom"
> translated -- it appeared in an article in CACM, and a letter to the
> editor produced a null response since it was presumably too obvious
> to answer.

Off topic: I just dug the article out for another look, and apparently
in the USA "technology is chasing the soccer mom", which conjures up
images of a mobile phone running around a "soccer" pitch after some
hapless woman dressed in football kit... It could equally well have
read "pizzas are chasing the tweety bird", for all the semantic import
it had for me... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Commenting code

[Roedy Green]

On Fri, 08 Jun 2001 02:44:55 +0100, John English <je@brighton.ac.uk>
wrote or quoted :

>Hmm, I disagree. I'm not an American, so "zip plus 5" means absolutely
>nothing to me (just like other American terms like GPA and K-12 and

Bad example for an international audience.  ZipPlus5 would be
instantly familiar to any American bean counting programming team. For
the purposes of discussion, (what to do in JavaDoc with methods and
variables that don't desperately need a comment), you might come up
with example methods that need no further elaboration, either because
the vocabulary has a central project glossary definition or because
there in nothing additional you have to say that is not obvious from
the type information or the method/variable name.

e.g. 
getSecondInitial
getFaxAreaCode
getSubscriptionExpiryDate
setEstimatedArrivalTime



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Commenting code

[Roedy Green]

On Fri, 08 Jun 2001 03:10:53 GMT, Roedy Green <roedy@mindprod.com>
wrote or quoted :

>ZipPlus5 would be
>instantly familiar to any American bean counting programming team. 

oops. Egg on face here. ZipPlus4.  An American Zip is two zero padded
ints 5+4 separated by a dash unless the second part is missing.  eg.
90210-1234.

I'm surprised there are not yet standard class libraries for display,
keyin and validation of Zips and other business objects with some sort
of mechanism to automatically refresh the lookup tables from the net.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Commenting code

[Larry Kilgallen]

In article <4up0itohqg0clnug35c9oqped1jra5hn4d@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On Fri, 08 Jun 2001 03:10:53 GMT, Roedy Green <roedy@mindprod.com>
> wrote or quoted :
> 
>>ZipPlus5 would be
>>instantly familiar to any American bean counting programming team. 
> 
> oops. Egg on face here. ZipPlus4.  An American Zip is two zero padded
> ints 5+4 separated by a dash unless the second part is missing.  eg.
> 90210-1234.
> 
> I'm surprised there are not yet standard class libraries for display,
> keyin and validation of Zips and other business objects with some sort
> of mechanism to automatically refresh the lookup tables from the net.

This vendor offers to sell source and database, since you wanted
someone else to do the implementation:

	http://www.speedkeys.com/index.htm

If you are morally opposed to paying money for people's work product,
you could ask the Post Office what their business arrangements are for
providing the information directly to you.

Re: Commenting code

[Shmuel (Seymour J.) Metz]

In <5sf0itoauh0fi1nvq4ll5ljmh3u4fjope1@4ax.com>, on 06/08/2001
   at 03:10 AM, Roedy Green <roedy@mindprod.com> said:

>Bad example for an international audience.  ZipPlus5 would be
>instantly familiar to any American bean counting programming team.

I doubt it. They might recognize ZIP plus 4.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Commenting code

[James Kanze]

Roedy Green wrote:

> On Fri, 08 Jun 2001 02:44:55 +0100, John English <je@brighton.ac.uk>
> wrote or quoted :

> >Hmm, I disagree. I'm not an American, so "zip plus 5" means
> >absolutely nothing to me (just like other American terms like GPA
> >and K-12 and

> Bad example for an international audience.  ZipPlus5 would be
> instantly familiar to any American bean counting programming
> team. For the purposes of discussion, (what to do in JavaDoc with
> methods and variables that don't desperately need a comment), you
> might come up with example methods that need no further elaboration,
> either because the vocabulary has a central project glossary
> definition or because there in nothing additional you have to say
> that is not obvious from the type information or the method/variable
> name.

Note that all of these still need some comment concerning border
conditions:

> e.g.
> getSecondInitial

What does the function return for people who don't have a second
initial?  (FWIW: this is also an Americanism.  In Europe, we don't use
anything but the first name and the family name.)

> getFaxAreaCode

> getSubscriptionExpiryDate

What about lifetime subscriptions?

> setEstimatedArrivalTime

Any preconditions?  (What happens, for example, if the estimated
arrival time is before the departure time?)

In sum, there is almost never a case where you can encode all of the
necessary information in the function name.  Calling the function
"getSecondInitialOrEmptyStringIfNone" is probably carrying things too
far, so a short comment would be in order.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Commenting code

[Wes Groleau]

> > e.g.
> > getSecondInitial
> 
> What does the function return for people who don't have a second
> initial?  (FWIW: this is also an Americanism.  In Europe, we don't use
> anything but the first name and the family name.)

What does it do for the numerous people who go by something
like W. Wesley Groleau?  I find it incredible the number of
people who are convinced I don't know my own name.  

Or who think I am "uncooperative" because I won't have
it legally changed to support THEIR half-baked idea of
a database.

Sure, it's unusual, but I am too civilized to criticize my
parents for choosing it.

Then there are the people who think I don't know how to
SPELL my own name and the people who design forms with
two square centimeters for your name and fifteen for your
postal code .....    oh, well, let's stay on topic.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commenting code

[James Kanze]

Wes Groleau wrote:

> > > e.g.
> > > getSecondInitial

> > What does the function return for people who don't have a second
> > initial? (FWIW: this is also an Americanism. In Europe, we don't
> > use anything but the first name and the family name.)

> What does it do for the numerous people who go by something like
> W. Wesley Groleau?  I find it incredible the number of people who
> are convinced I don't know my own name.

Generally speaking, people don't go by such names in Europe.  You have
a family name, which would be preceded by a Mr. (or Herr, or M.), and
used to address you by people who don't know you very well.  And you
have a name which people who know you well call you -- do your friends
call you W. Wesley, or something else.  Thus, in America, I am
generally "James A. Kanze", and people (including people who've just
met me) try and call me Jim, whereas in Europe, I'm just "James
Kanze" ; people who know me well call me "James", but for most people,
I'm "Kanze", or "Mr. Kanze".

> Or who think I am "uncooperative" because I won't have it legally
> changed to support THEIR half-baked idea of a database.

> Sure, it's unusual, but I am too civilized to criticize my parents
> for choosing it.

I'm not sure, but I would expect that most systems would allow a space
and punctuation in the first name, if what you really want to be
called is "W. Wesley".

Note that most Europeans do have two first names.  It's just rare for
documents (or data bases) to use them.  Once or twice, people have
entered my name into the data base from my (American) passport; the
result is that my first name appears as "James Albert" (often with a
hyphen), as if it were a compound name (a frequent occurance in
France).

> Then there are the people who think I don't know how to SPELL my own
> name and the people who design forms with two square centimeters for
> your name and fifteen for your postal code .....  oh, well, let's
> stay on topic.

What about the web page designers who insist that the postal code
comes after the city and state, and won't let you enter an address
without a state?  Or the ones that insist that a telephone number with
an area code is exactly 10 digits?

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Commenting code

[Roedy Green]

On Mon, 11 Jun 2001 12:38:06 +0200, James Kanze
<James.Kanze@dresdner-bank.com> wrote or quoted :

>What about the web page designers who insist that the postal code
>comes after the city and state, and won't let you enter an address
>without a state?  

I did an application for a group called IFIAS many years ago in
Abundance. They wanted the postal codes, and city codes verified and
placed in the correct order for each different country.

I figured eventually someone could do smoothing like that for Java.
You have an ADDRESS class that just deals with all that verification,
formatting, squeezing to fit in the given real estate by hook or by
crook, shrinking, abbreviating, squeezing out white space, or on
screen by having scrollable fields.

You also do the sorting in the various magical orders the post office
wants mail physically sorted.

To do this properly requires huge tables that need to be frequently
updated.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Commenting code

[Alvaro Segura]

James Kanze wrote:
> 
> Generally speaking, people don't go by such names in Europe.  You have
> a family name, which would be preceded by a Mr. (or Herr, or M.), and
> used to address you by people who don't know you very well.  And you
> have a name which people who know you well call you -- do your friends
> call you W. Wesley, or something else.  Thus, in America, I am
> generally "James A. Kanze", and people (including people who've just
> met me) try and call me Jim, whereas in Europe, I'm just "James
> Kanze" ; people who know me well call me "James", but for most people,
> I'm "Kanze", or "Mr. Kanze".
...
> Note that most Europeans do have two first names.  It's just rare for
> documents (or data bases) to use them.  Once or twice, people have
> entered my name into the data base from my (American) passport; the
> result is that my first name appears as "James Albert" (often with a
> hyphen), as if it were a compound name (a frequent occurance in
> France).

[a bit OT]

Officially in Spain we have one first name (simple or compound) and TWO
family names, one from the father and one from the mother (in that order
by default, but can be changed). And women don't change their name when
they marry. Often the first (paternal) family name is enough, but a
proper identification needs the second (maternal) one too.

And again this is hard to fit in american style forms that require a
(proper) first name, a middle name and a (family) last name.

  Alvaro Segura Lasa
  (Segura is not my middle name, it's my paternal family name :-)

Re: Commenting code

[Ted Dennison]

In article <3B27604B.4D156A75@facilnet.es>, Alvaro Segura says...
>Officially in Spain we have one first name (simple or compound) and TWO
>family names, one from the father and one from the mother (in that order
>by default, but can be changed). And women don't change their name when

I'm sorry for the stupid question, but if your parents both have two last names,
and you get both of their last names, wouldn't that give you 4? Obviously,
you're keeping one of their family names rather than both, but which one?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Commenting code

[Bill]

Ted Dennison wrote:

> In article <3B27604B.4D156A75@facilnet.es>, Alvaro Segura says...
> >Officially in Spain we have one first name (simple or compound) and TWO
> >family names, one from the father and one from the mother (in that order
> >by default, but can be changed). And women don't change their name when
>
> I'm sorry for the stupid question, but if your parents both have two last names,
> and you get both of their last names, wouldn't that give you 4? Obviously,
> you're keeping one of their family names rather than both, but which one?
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

In Spain the names you retain are your paternal names.

So if Jose Alvarez Garcia marries Maria Martin Dominguez their children might be
named
Juan Alvarez Martin or Isabel Alvarez Martin

Re: Commenting code

[Ted Dennison]

In article <3B2784CC.4EB620B2@lanl.gov>, Bill says...
>In Spain the names you retain are your paternal names.
>
>So if Jose Alvarez Garcia marries Maria Martin Dominguez their children might be
>named
>Juan Alvarez Martin or Isabel Alvarez Martin

So the mother's family gets 1 genration of recognition, but no more. I guess
that beats the 0 generations here.

Interestingly, in urban America lately thev'e been doing this by *blending* the
first names of samed-sex grandparents on either parent's side. For instance, a
girl who has grandmothers named Wanda and Latisha might be named "Latwanda".
After a few generations of this you get some pretty odd-looking names. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Commenting code

[John English]

Ted Dennison wrote:
> Interestingly, in urban America lately thev'e been doing this by *blending* the
> first names of samed-sex grandparents on either parent's side. For instance, a
> girl who has grandmothers named Wanda and Latisha might be named "Latwanda".
> After a few generations of this you get some pretty odd-looking names. :-)

What my wife and I decided to do was give boys my surname and give girls
hers (which has made my father quite cross since we stopped at one
daughter, but hey dad, it's the genes that count...)

The reason my wife kept her maiden name is partly to do with her job
(head of the English dept. in a local school, so she didn't want to
be "Mrs. English") and partly to do with her surname (Lord) which we
couldn't even double-barrel (English-Lord? Lord-English?)

I wonder how much further off-topic this thread can go? :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Commenting code

[Karl Schmidt]

John English schrieb:

> The reason my wife kept her maiden name is partly to do with her job
> (head of the English dept. in a local school, so she didn't want to
> be "Mrs. English") and partly to do with her surname (Lord) which we
> couldn't even double-barrel (English-Lord? Lord-English?)

Reminds me of an old computer game - no that was Lord British...


> I wonder how much further off-topic this thread can go? :-)

Far, far, far off...


--

MfG


Karl Schmidt
ICQ #15923569

Re: Commenting code

[tt]

Alvaro Segura <asegura@facilnet.es> writes:

> Officially in Spain we have one first name (simple or compound) and TWO
> family names, one from the father and one from the mother (in that order
> by default, but can be changed). And women don't change their name when
> they marry. Often the first (paternal) family name is enough, but a
> proper identification needs the second (maternal) one too.
> 
> And again this is hard to fit in american style forms that require a
> (proper) first name, a middle name and a (family) last name.

Well you still have it easy compared to (most) Indonesians, who don't 
have family names at all, only one or sometimes more given names.
(Some of them do have family names, notably the Chinese minority,
but the majority doesn't.)
Some Indonesian students have had problems enrolling in US universities
because of that...

-- 
Tapani Tarvainen

Re: Commenting code

[Ted Dennison]

In article <3B202E17.7C728B66@brighton.ac.uk>, John English says...
>(Off topic: OTOH, Americans talk about "soccer" instead of "football",
>but the game they call "football" is played mainly by picking the ball
>up and running like hell instead of using the feet. Another example

Not to mention that in our football, big burly guys "sock" the bezejsus out of
each other. But we had our football before yours, so the name was already in use
(and I don't think even Emacs is powerful enough to find and change all
occurances in American minds :-)  )



---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Commenting code

[James Kanze]

Ted Dennison wrote:

> In article <3B202E17.7C728B66@brighton.ac.uk>, John English says...
> >(Off topic: OTOH, Americans talk about "soccer" instead of
> >"football", but the game they call "football" is played mainly by
> >picking the ball up and running like hell instead of using the
> >feet. Another example

> Not to mention that in our football, big burly guys "sock" the
> bezejsus out of each other. But we had our football before yours, so
> the name was already in use (and I don't think even Emacs is
> powerful enough to find and change all occurances in American minds
> :-) )

Are you sure you had your football first?  The Encyclopedia Brittanica
doesn't agree with you.

BTW: we also have a version of "football" where they carry the ball
and sock the bezejsus out of each other.  Started at a school called
Rugby, in England, but is now quite popular in southern France.  But
of course, we don't call it football.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Commenting code

[Ted Dennison]

In article <3B24A059.4A2B081A@dresdner-bank.com>, James Kanze says...
>
>Ted Dennison wrote:
>
>> Not to mention that in our football, big burly guys "sock" the
>> bezejsus out of each other. But we had our football before yours, so
>> the name was already in use (and I don't think even Emacs is
>> powerful enough to find and change all occurances in American minds
>> :-) )
>
>Are you sure you had your football first?  The Encyclopedia Brittanica
>doesn't agree with you.

I'm quite sure that we had our football before *we* had yours. I would have
hoped it was quite clear from the context that I meant that. Claiming the other
would just be plain stupid. (I knew I'd get roasted for leaving out that
pronoun. Damn.)


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Commenting code

[James Kanze]

Ted Dennison wrote:

> In article <3B24A059.4A2B081A@dresdner-bank.com>, James Kanze says...

> >Ted Dennison wrote:

> >> Not to mention that in our football, big burly guys "sock" the
> >> bezejsus out of each other. But we had our football before yours,
> >> so the name was already in use (and I don't think even Emacs is
> >> powerful enough to find and change all occurances in American
> >> minds :-) )

> >Are you sure you had your football first?  The Encyclopedia
> >Brittanica doesn't agree with you.

> I'm quite sure that we had our football before *we* had yours. I
> would have hoped it was quite clear from the context that I meant
> that. Claiming the other would just be plain stupid. (I knew I'd get
> roasted for leaving out that pronoun. Damn.)

Sorry, my misreading.  Although if I remember the Brittanica article
correctly, your American football started because someone playing
European football took to carrying the ball.  After which, it was
unanimously decided that carrying the ball was OK, and our football
became yours.  (When the same thing happened in England, there was no
agreement, and they ended up with two sports: football and rugby.
Rugby is a lot like American football without the forward passes,
without the commercial timeouts, and without any of the protective
clothing -- in south France, they say you can always recognize a Rugby
player by the missing front teeth.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Off-Topic "football"

[Wes Groleau]

> (Off topic: OTOH, Americans talk about "soccer" instead of "football",
> but the game they call "football" is played mainly by picking the ball
> up and running like hell instead of using the feet. Another example
> of misleading documentation provided by an ill-chosen identifier? :-)

But it does use feet to start the game and occasionally during.
The fact that the name football was already taken somewhere else
in the world was irrelevant to US.

   Joke.... or perhaps not?

   From: "Angelico" in another newsgroup

   (translated from Spanish):

   A few years ago, I took a world-wide survey.  The question
   was, "What is your opinion on food scarcities in the rest
   of the world?"

   The survey was a failure because:

    > > > - in Africa, they didn't know what "food" meant
    > > > - in Eastern Europe, they didn't know what "opinion" meant
    > > > - in Western Europe they didn't know what "scarcities" meant
    > > > - in the USA they didn't know what "the rest of the world" meant

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commenting code

[Shmuel (Seymour J.) Metz]

In <n1tvht8gg83qd4l5jfegp9t2q5gpcfjoeb@4ax.com>, on 06/07/2001
   at 09:58 PM, Roedy Green <roedy@mindprod.com> said:

>Assembler commenting requires that you be able to follow the logic
>without looking at ANY of the code.

No way! That just obscurs the code and makes it less likely that
errors will be spotted.

>Without a complete picture of what
>is going on in the comments, it is very difficult to find the code
>you are looking for.

Au contraire; with a complete picture you can't see the forrest for
the trees. Comments should explain the code, not echo it. Some authors
have gone so far as to insist on covering the comments while reviewing
the code to ensure that the reviewer is not mislead by the comments.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Commenting code

[Donald L. Dobbs]

"Shmuel (Seymour J.) Metz" wrote:
> 
> In <n1tvht8gg83qd4l5jfegp9t2q5gpcfjoeb@4ax.com>, on 06/07/2001
>    at 09:58 PM, Roedy Green <roedy@mindprod.com> said:
> 
> >Assembler commenting requires that you be able to follow the logic
> >without looking at ANY of the code.
> 
> No way! That just obscurs the code and makes it less likely that
> errors will be spotted.

As one who spends about half and half between assembler language
(firmware situations) and higher level languages (PL/I, VB, etc.) I must
chime in. The comments are absolutely necessary in Assembler, to wit:

label:	ADC	A,$01

This is a perfectly good instruction to do an add with carry to the
accumulator A.
So what?  But if you add the comment "Increment the shaft encoder
counter until limit reached" then I have some idea of what the code is
SUPPOSED to be doing and how that snippet of code relates to the overall
problem to be solved.

> 
> >Without a complete picture of what
> >is going on in the comments, it is very difficult to find the code
> >you are looking for.
> 
> Au contraire; with a complete picture you can't see the forrest for
> the trees. 

At the beginning of each section of code (or function or subroutine) the
"forest" is described.  The comments on each line of code describe the
individual trees. It's sort of a drill down approach but highly
effective.  Somewhere comments must always include purpose,
circumstance, rationale, requirements, constraints, algorithms, etc.  If
I have that then I have a baseline and a point of departure if debugging
is required.

>Comments should explain the code, not echo it. Some authors
> have gone so far as to insist on covering the comments while reviewing
> the code to ensure that the reviewer is not mislead by the comments.
> 
> --
> -----------------------------------------------------------
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I
> 
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
> 
> I mangled my E-mail address to foil automated spammers; reply to
> domain acm dot org user shmuel to contact me.  Do not reply to
> spamtrap@library.lspace.org
> -----------------------------------------------------------

Re: Commenting code

[Wes Groleau]

> label:  ADC     A,$01
> 
> This is a perfectly good instruction to do an add with carry to the
> accumulator A.

How many people are still using assemblers with no symbolic features?

(Still, even with those, assembly needs comments.)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Commenting code (a plea)

[Dave Thomas]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> > label:  ADC     A,$01
> > 
> > This is a perfectly good instruction to do an add with carry to the
> > accumulator A.
> 
> How many people are still using assemblers with no symbolic features?


Folks: does this thread really need to be cross posted so much?

Thanks


Dave

Re: Commenting code

[Shmuel (Seymour J.) Metz]

In <3B20EDAC.5A4F7BD4@home.com>, on 06/08/2001
   at 03:22 PM, "Donald L. Dobbs" <donaldldobbs@home.com> said:

>label:	ADC	A,$01

>This is a perfectly good instruction to do an add with carry to the
>accumulator A.
>So what?  But if you add the comment "Increment the shaft encoder
>counter until limit reached" then I have some idea of what the code
>is SUPPOSED to be doing and how that snippet of code relates to the
>overall problem to be solved.

Nu? In what way does that echo the code? If, instead, you add the
comment "increment the accumulator with carry", would you defend the
comment as necessary?


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Commenting code

[Donald L. Dobbs]

"Shmuel (Seymour J.) Metz" wrote:
> 
> In <3B20EDAC.5A4F7BD4@home.com>, on 06/08/2001
>    at 03:22 PM, "Donald L. Dobbs" <donaldldobbs@home.com> said:
> 
> >label: ADC     A,$01
> 
> >This is a perfectly good instruction to do an add with carry to the
> >accumulator A.
> >So what?  But if you add the comment "Increment the shaft encoder
> >counter until limit reached" then I have some idea of what the code
> >is SUPPOSED to be doing and how that snippet of code relates to the
> >overall problem to be solved.
> 
> Nu? In what way does that echo the code? If, instead, you add the
> comment "increment the accumulator with carry", would you defend the
> comment as necessary?
> 
Of course "increment the accumulator with carry" as a comment doesn't
tell me anything more than I can already discern by looking at the code.
The point I'm trying to make is that I am handed some assembly language
code written by someone else in a different country in a different time
zone who is a junior programmer and didn't do a decent job of
documenting his program. He's generally unavailable and uncooperative. 
[This is an actual case.] His code has a bug in it. I have to fix it on
my own. Unless there is some documentation somewhere (preferably near
the code) that tells what the program is SUPPOSED to do and the
rationale of his code as how he implemented a solution, my job really
becomes tough because I have no baseline.  I can look at the code and
see what bit fiddling it actually does. But is that what it is supposed
to be doing?  Properly documented code allows me to get to the heart of
the problem rapidly; otherwise it becomes a big job of reverse
engineering.

> --
> -----------------------------------------------------------
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I
> 
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
> 
> I mangled my E-mail address to foil automated spammers; reply to
> domain acm dot org user shmuel to contact me.  Do not reply to
> spamtrap@library.lspace.org
> -----------------------------------------------------------

Re: Commenting code

[Shmuel (Seymour J.) Metz]

In <3B27AD17.DF50BDED@home.com>, on 06/13/2001
   at 06:13 PM, "Donald L. Dobbs" <donaldldobbs@home.com> said:

>Of course "increment the accumulator with carry" as a comment doesn't
>tell me anything more than I can already discern by looking at the
>code. The point I'm trying to make is that I am handed some assembly
>language code written by someone else in a different country in a
>different time zone who is a junior programmer and didn't do a decent
>job of documenting his program. He's generally unavailable and
>uncooperative.  [This is an actual case.] His code has a bug in it. I
>have to fix it on my own. Unless there is some documentation
>somewhere (preferably near the code) that tells what the program is
>SUPPOSED to do and the rationale of his code as how he implemented a
>solution, my job really becomes tough because I have no baseline.  I
>can look at the code and see what bit fiddling it actually does. But
>is that what it is supposed to be doing?  Properly documented code
>allows me to get to the heart of the problem rapidly; otherwise it
>becomes a big job of reverse engineering.

None of which has anything to do with assembler language per se; the
same consideerations apply to Ada, BASIC, COBOL, FORTRAN, ICON, LISP,
PERL, SETL or whatever. 


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Commenting code

[Donald L. Dobbs]

"Shmuel (Seymour J.) Metz" wrote:
> 
> In <3B27AD17.DF50BDED@home.com>, on 06/13/2001
>    at 06:13 PM, "Donald L. Dobbs" <donaldldobbs@home.com> said:
> 
> >Of course "increment the accumulator with carry" as a comment doesn't
> >tell me anything more than I can already discern by looking at the
> >code. The point I'm trying to make is that I am handed some assembly
> >language code written by someone else in a different country in a
> >different time zone who is a junior programmer and didn't do a decent
> >job of documenting his program. He's generally unavailable and
> >uncooperative.  [This is an actual case.] His code has a bug in it. I
> >have to fix it on my own. Unless there is some documentation
> >somewhere (preferably near the code) that tells what the program is
> >SUPPOSED to do and the rationale of his code as how he implemented a
> >solution, my job really becomes tough because I have no baseline.  I
> >can look at the code and see what bit fiddling it actually does. But
> >is that what it is supposed to be doing?  Properly documented code
> >allows me to get to the heart of the problem rapidly; otherwise it
> >becomes a big job of reverse engineering.
> 
> None of which has anything to do with assembler language per se; the
> same consideerations apply to Ada, BASIC, COBOL, FORTRAN, ICON, LISP,
> PERL, SETL or whatever.
> 
But, of course!

And I practice what I preach regardless of the language to make life a
little easier on the person who may end up having to support my code
somewhere down the road.


> --
> -----------------------------------------------------------
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I
> 
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
> 
> I mangled my E-mail address to foil automated spammers; reply to
> domain acm dot org user shmuel to contact me.  Do not reply to
> spamtrap@library.lspace.org
> -----------------------------------------------------------

Re: Commenting code

[Conrad Schneiker]

IMHO, this has strayed pretty far off topic insofar as Ruby is concerned.

Please omit comp.lang.ruby from future replies to this thread.

Perhaps mercy and/or a little more netiquitte for other newsgroups is called
for as well. :-)

Thanks.

Conrad

Re: Commenting code

[Roedy Green]

On Thu, 14 Jun 2001 14:20:50 -0500, "Conrad Schneiker"
<schneiker@jump.net> wrote or quoted :

>IMHO, this has strayed pretty far off topic insofar as Ruby is concerned

I don't know what Ruby even is, but if it is some sort of computer
language, why would it be unique in all computer languages?  All other
languages seem to require very much the same sort of commenting
etiquette.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Commenting code

[Michael Mauch]

Roedy Green <roedy@mindprod.com> wrote:
> On Thu, 14 Jun 2001 14:20:50 -0500, "Conrad Schneiker"
> <schneiker@jump.net> wrote or quoted :
> 
>>IMHO, this has strayed pretty far off topic insofar as Ruby is concerned
> 
> I don't know what Ruby even is, but if it is some sort of computer
> language, why would it be unique in all computer languages?  All other
> languages seem to require very much the same sort of commenting
> etiquette.

Cute. Then would you please stop cross-posting without F'up2? This
thread is off-topic, probably in all of these groups.

F'up2 poster

Re: Commenting code

[Charles Hixson]

Roedy Green wrote:

> On Thu, 14 Jun 2001 14:20:50 -0500, "Conrad Schneiker"
> <schneiker@jump.net> wrote or quoted :
> 
> 
>>IMHO, this has strayed pretty far off topic insofar as Ruby is concerned
>>
> 
> I don't know what Ruby even is, but if it is some sort of computer
> language, why would it be unique in all computer languages?  All other
> languages seem to require very much the same sort of commenting
> etiquette.
> 
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html 
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.
> 

Actually, different languages have differing needs depending on their 
features.  Javadoc says certain things about how Java should be 
commented.  Python's documentation strings imply something a bit 
different.  Eiffel is vastly different because they use the short tool 
as a primary means of documentation.  Ada considers that most of the 
user documentation should be in the *.ads file, where details of the 
program operation should be in the *.adb file.  C/C++ is generally 
free-form and totally anarchic, unless you are using one of the 
documentation tools.  Smalltalk believes that you should be able to 
obtain most of the information via direct inspection of the code ... but 
there is a line or two at the beginning of each method that is 
traditionally for comments about things that aren't obvious.  Etc. 
That's most of the languages that I know well enough to comment on, and 
no two of them are really closely related to each other in what a 
comment should be or how it should be done.  About all that they all 
agree on it that you shouldn't document totally obvious things, and you 
should document obscure things somewhere.  But they sure don't agree on 
who should see that latter documentation.


-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Commenting code

[Shmuel (Seymour J.) Metz]

In <9gb2ti$p2q$1@news.jump.net>, on 06/14/2001
   at 02:20 PM, "Conrad Schneiker" <schneiker@jump.net> said:

>IMHO, this has strayed pretty far off topic insofar as Ruby is
>concerned.

>Please omit comp.lang.ruby from future replies to this thread.

>Perhaps mercy and/or a little more netiquitte for other newsgroups is
>called for as well. :-)

You mean like setting an appropriate followup when you complain about
the news groups listed?


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Commenting code

[Ray Blaak]

Roedy Green <roedy@mindprod.com> writes:
> There a philosophical problem that Jonathan Revusky and I have tussled
> over.  When writing JavaDoc, should it be complete, or should it
> contain only unexpected information?

It should only contain the unexpected information. Let the code describe
itself as much as possible, as you pointed out.

> 
> "getZipPlusFive  get the US Zip+5 postal code."
> 
> If you add this sort of comment, you just needlessly create typing.
> You pad the source, diluting the true information.
> 
> However, if you leave it out entirely, someone just perusing the
> JavaDoc instead of the method signatures themselves, is missing vital
> information.

This works for me:

  public PostalCode getZipPlusFive(PostalCode zipCode);

When perusing java code or its documentation, missing the method signatures
themselves seems completely nonsensical to me. 

Are not the signatures always present even in JavaDoc generated pages?

One cannot reliably understand an interface otherwise.

> Perhaps then, you could document just the parameter, with no comment.

Only if the parameter name and type do not adequately describe themselves.

> The problem with this is, how do you tell a "boring" void entry from
> one yet to be done? That too could lead to invalid assumptions.

My rule is: don't repeat what the code says. This is my canonical bad example:

  /**
   * Does a particular thing.
   *
   * @parm someInput - some input
   * @exception InvalidInput raised when the input is invalid
   * @return the result
   */
  public Result doParticularThing(Input someInput) throws InvalidInput

this is ok:

  public Result doParticularThing(Input someInput) throws InvalidInput

this is too:

  /**
   * @exception InvalidInput when someInput is null or not blah blah
   * @return a valid result or null when blah blah
   */
  public Result doParticularThing(Input someInput) throws InvalidInput

That is, comments describe things not intuitively available from the code.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Commenting code

[Jon Skeet]

Ray Blaak <blaak@infomatch.com> wrote:
> Roedy Green <roedy@mindprod.com> writes:
> > There a philosophical problem that Jonathan Revusky and I have tussled
> > over.  When writing JavaDoc, should it be complete, or should it
> > contain only unexpected information?
> 
> It should only contain the unexpected information. Let the code describe
> itself as much as possible, as you pointed out.

By "the code", do you actually mean "the signature"? I'd rather not have 
to go to the code itself in order to find out what a method does, even 
if the code itself makes it crystal clear.

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Re: Commenting code

[Ray Blaak]

Jon Skeet <skeet@pobox.com> writes:
> By "the code", do you actually mean "the signature"? I'd rather not have 
> to go to the code itself in order to find out what a method does, even 
> if the code itself makes it crystal clear.

Yes, I mean the signature.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: Commenting code

[Roedy Green]

On 08 Jun 2001 09:18:25 -0700, Ray Blaak <blaak@infomatch.com> wrote
or quoted :

>Are not the signatures always present even in JavaDoc generated pages

I don't know.  I used a program called iDOc for proofreading first
when preparing such Javadoc.

However, if you use simple minded stuff like Slick Edit, just show me
the Javadoc embedded in the source, they won't be there, unless you
used the JavaDoc skeleton feature to place them there.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 12:30:26 +0100, David Gillon <david.gillon@baesystems.com>
wrote:

>Explicit, readable coding has value even when being read by the most
>experienced of software engineers. Consider the case of a safety
>critical system under review by an external auditor prior to
>certification. It's vital he be able to review the system in as thorough
>a manner as possible in the time available, yet he may be completely new
>to your coding standards and practices. The logic of a decision needs to
>be clearly laid our for him, not something he needs to delve into the
>musty depths of obscure documents for or to seek information on from the
>original coder (especially if the original coder is in a substantially
>different timezone). Equally, someone may have to fix your code twenty
>years down the tracks, when the original coding team and the rationale
>behind their decisions may have long since vanished (or walked in front
>of a bus...). 
>
>Explicit pays, maybe not now, maybe not directly, but in the end its a
>worthwhile investment.

Yes, I quite agree.  The point I was trying to make is that there are varying
levels of "explicitness" allowed in different industries.  In your example, a
critical system designed to last years, you'd be crazy to be non-explicit.  

However, if you're working in an industry where speed and optimization is king,
then you sometimes simply don't have a choice and you're forced to write
optimizations that may look cryptic.  However, in such cases you should be sure
to COMMENT it, and explain what it is and how it works.

I think that people misunderstand me on one thing:  I am not at all arguing
against the use of comments.  The code itself doesn't have to read like an
essay if it's well commented. 

However, if I'm using a fairly standard API, then it's not up to me to write
code that also teaches a newbie programmer how the API works.  That's not my
job.  My job is to do my job, and to explain why and how I'm doing my job, not
teach others how to code.  If a newbie programmer has to read my code, then
there are two requirements expected from him/her:  know the language, and
understand the API.  I don't think this is too much to ask from any new
programmers.

Re: Long names are doom ?

[David Gillon]

Pete Thompson wrote:
> it's not up to me to write
> code that also teaches a newbie programmer how the API works.  That's not my
> job.  My job is to do my job, and to explain why and how I'm doing my job, not
> teach others how to code.  If a newbie programmer has to read my code, then
> there are two requirements expected from him/her:  know the language, and
> understand the API.  I don't think this is too much to ask from any new
> programmers.

Got to disagree with this point. I've always thought that training less
experienced engineers what is good practise and what isn't was a
fundamental part of my job. If you do any kind of code review then this
is something you're doing implicitly, whether you're reviewer or
reviewee.

-- 

David Gillon

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B1E1452.BAFAAB7F@baesystems.com>, on 06/06/2001
   at 12:30 PM, David Gillon <david.gillon@baesystems.com> said:

>Explicit pays, maybe not now, maybe not directly, but in the end its
>a worthwhile investment.

"clear" pays; "explicit" may be a booby trap. Your first priority
should be to make the code clear, maintainable and robust. In most
cases that requires getting rid of explicit values in the code and
relegating them to named constants, #define, EQU or whatever the
equivalents are in the language that you are using. NO MAGIC NUMBERS!


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

"Pete Thompson" <blackpete@nowhere.somewhere.anywhere.com> wrote in message
news:35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com...
> Hmm in that case, I should give you my sister's phone number.  She can
talk for
> well over two hours on the phone before finally getting to the point  :)
>
Verbosity for the sake of being verbose is as dumb as terseness for the sake
of being terse. Whatever you put on paper needs to say something *useful* to
the reader and do so in a *clear* manner. Verbosity or terseness must be
used to serve some higher goal - not become goals in and of themselves.

> I feel the same way about code:  being verbose is all well and good, but
> pointless verbosity can do more harm than good.  It tends to hide the
overall
> picture as to what the function/application is *really* doing.  It makes
the
> function look more complicated than it really is.  It leaves you wondering
if
> you're somehow missing something because there's more to read than is
really
> necessary.
>
We agree here. I think that again I'd emphasize that it is neither verbosity
nor terseness that makes something clear to the reader. Clarity of thought
and expression are not going to come from either terse or verbose notation.
First the thought has to be clear. Then you have to find a way of expressing
that thought in a manner that will be understood by the audience.


> As Roedy mentioned in some other message, it's a hard one to pin down
since
> it's such a subjective matter.  Maybe it's futile to even try.
>
There is some subjectivity to it, but I would say "not entirely" I think
that the notation in C is entirely too terse and subject to way too much
abuse. Likewise, I think the syntax of Cobol is way too verbose and
needlessly obfuscates with TMI. (Who thinks that "Add Gin To Vermouth Giving
Martini." is somehow a better idea than "Gin := Vermouth + Martini;" ?)

> Which one of the following do you prefer:
>
> i = i + 1;
>
> or
>
> i equals i plus one.
>
I like the first better. But I dislike things like I++ - not so much that
particular one, but all the subtle variations that can take place. It
changes meaning if it is in front or behind - but that only makes a
difference sometimes. It can be mixed with other interesting variations and
things like +=, etc. In the end, the "terseness" possible with this kind of
operator is just plain not worth it. Way too subject to abuse. Way too easy
to misconstrue meaning in complicated cases. Often ambiguous in definition
leading to "implementation dependent", reliant on side effects, Etc. So to
save the few keystrokes needed for "I := I + 1 ;" I give you "I++" and open
the floodgates for the "Betcha can't guess what *this* line does!!!" kind of
coding. Better to be rid of it and insist on the few extra keystrokes needed
for Fortran-ish expressions and avoid all the trouble that will inevitably
come from that programmer who will insist that "It should be intuitively
obvious to any *COMPETENT* C programmer..."

> Imagine a whole program written using the latter method.  Would that
really be
> much fun to read?  Compound statements would be nearly unreadable.
>
Imagine? Don't need to. Been there. Done that. Its called "Cobol
Programming"


>
> Hmm.. I'd have to say that I agree and disagree.  It really depends on
what
> industry you're in.  If you're in the kind of industry where you're hiring
> newbie programmers all the time, then yes, it's important to be as
explicit as
> possible.  However, there are industries where programmers MUST be
experienced
> before they're hired.  Does it really make sense to make your code as
> newbie-ish as possible for them?  (Again, without being cryptic).
>
Here's the issue: (And there's no way of getting around the question.) How
is it that this MAKES MONEY FOR THE STOCKHOLDERS? (Sorry for shouting.)

All industries hire newbies. Even experienced programmers are newbies to
your code - otherwise they aren't new-hires. If I write simple, direct,
straightforward code with good comments, good structure, good documentation,
etc., then I've got code that a newbie to Language XXX can readily read and
grasp (hopefully). Does it *HURT* the experienced programmer that you didn't
write something in as few keystrokes as possible within Language XXX? I
don't think so. (Like I said, whenever someone else picks up your program
for the first time, they are a "newbie") Anything I do to help the newbie
understand what is going on is at worst, not going to hurt the experienced
programmer and at best will probably help him along as well.

Now there are some things which are inherently complicated. If I need
multitasking - that's going to be tough to express simply because it isn't a
simple thing to do. Can't help you there by picking some kind of notational
syntax perceived to be "better". I think it was Einstein who said "Things
should be made as simple as possible - but no simpler." I guess what I'd
prefer to avoid in a language syntax are the obvious pitfalls that
repeatedly create errors and inevitably cause confusion and
miscommunication. Doing that much accomplishes something. It will never make
E := M * C**2 ; be as simple to understand as Y := M * X + B ;


>
> Well, that's sort of going to the extreme.  If the syntax is a part of the
> language itself, then it should be readable by anyone well versed with the
> language.  "i++" is not cryptic since that's a part of the language.
>
Read before what I said about opening up the floodgates. Some features of a
language are *inherently* unsafe or encourage obfuscation or make it easy to
introduce errors. In C (and in a number of other languages) you have well
known "syntax traps" that make it easy to create compile time errors that
are hard to locate. Similarly, there are "semantic traps" that make it easy
to introduce run-time errors. (BTW, this is true of verbose languages like
Cobol as well). I'm in favor of structuring the notation of a language such
that it minimizes the risk of errors and maximizes the communication to the
reader. IMHO, C's terse notation works against these goals. C's semantics
work against these goals as well, but that's another debate.


> If it's a "clever" (ab)use of the language, then you may need to
reevaluate
> what you're doing.   I hate it when people try to cram 4 or 5 or more
different
> things into the same line.  I just love reading stuff like c = a+++++b.
(not)
>
I hear you. I agree with this. I'd prefer a language design that does not
ALLOW something like what you just described, no matter how much "expressive
power" can be gained for the attainment of Good And Noble goals. (Sort of an
"ends justifies the means" argument?) Just because someone might rarely (and
arguably) use this sort of notation to express something in a clear and
concise manner, does not mean I want to frequently (and not so arguably) see
these kinds of attrocities committed either because someone a) thought it
was "clever" or b) thought it was "Intuitively Obvious To Any *Competent*
Programmer" or c) both.

One of the reasons I like Ada so much is because the syntax and semantics
tends to avoid such obfuscations. Its not that you *can't* write bad code in
Ada. (nor is it hard to write "concise" code - as long as we aren't simply
counting keystrokes as the measure of "conciseness") Its just that it tends
to steer you towards more straightforward and direct expression of what you
intended to do. It also does an enormous amount of error checking and
disallows certain things that cause errors commonly. The syntax also avoids
common "syntax traps" found in other languages & makes it easier for the
compiler to pinpoint exactly where you mistyped something. If you can't
write good code in C, you aren't magically going to start writing good code
in Ada. However, I think Ada provides a lot more help to the programmer who
is capable of writing good code.


> I guess we're pretty much arguing the same thing at this point.  My own
> contention is that there are programmers who are needlessly verbose that
the
> code looks more complex than it really is.
>
Anything can be taken to extremes. I've seen Ada code where the
proliferation of types & subtypes got so bad that you couldn't tell the
players without a scorecard. I've seen Ada code where the programmers
thought tasks were so cool, they ended up using them like they were
procedrues - to no advantage and with subsequent synchronization problems.
Obviously, someone sent these dudes off to a class that taught Ada & OOD/OOP
and they came back with half an understanding and lots of enthusiasm. The
first attempt at using just about any language may result in drastically bad
code because the newbie doesn't have the experience needed to make judgement
calls about the things that are rather subjective. (How many subtypes should
a program have? How many tasks should a program be broken down into? There
are no iron-clad rules. Like pornography, I can't write you a uniform legal
description, but I know it when I see it.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Long names are doom ?

[Pete Thompson]

On Wed, 6 Jun 2001 11:25:28 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote:

<snipping of mostly agreements>


>I like the first better. But I dislike things like I++ - not so much that
>particular one, but all the subtle variations that can take place. It
>changes meaning if it is in front or behind - but that only makes a
>difference sometimes. It can be mixed with other interesting variations and
>things like +=, etc. In the end, the "terseness" possible with this kind of
>operator is just plain not worth it. Way too subject to abuse. Way too easy
>to misconstrue meaning in complicated cases. Often ambiguous in definition

Well, sure it's subject to abuse.  However, that's the fault of the programmer,
not the language itself.  I too froth at the mouth whenever someone makes a
stupid use of operator overloading in C++, or write unnecessary compound
statements.

>leading to "implementation dependent", reliant on side effects, Etc. So to
>save the few keystrokes needed for "I := I + 1 ;" I give you "I++" and open
>the floodgates for the "Betcha can't guess what *this* line does!!!" kind of
>coding. Better to be rid of it and insist on the few extra keystrokes needed
>for Fortran-ish expressions and avoid all the trouble that will inevitably
>come from that programmer who will insist that "It should be intuitively
>obvious to any *COMPETENT* C programmer..."

Maybe I've just been lucky enough to have never worked in a workplace with
programmers like that who insists on trying to look clever in their code, and
thus I have no problems like that.  Should I be forced to move on to a more
verbose language because other people had bad experiences? 

>> Hmm.. I'd have to say that I agree and disagree.  It really depends on
>what
>> industry you're in.  If you're in the kind of industry where you're hiring
>> newbie programmers all the time, then yes, it's important to be as
>explicit as
>> possible.  However, there are industries where programmers MUST be
>experienced
>> before they're hired.  Does it really make sense to make your code as
>> newbie-ish as possible for them?  (Again, without being cryptic).
>>
>Here's the issue: (And there's no way of getting around the question.) How
>is it that this MAKES MONEY FOR THE STOCKHOLDERS? (Sorry for shouting.)

You have deadlines.  Miss the deadlines and you're going to piss the
stockholders off.  More experienced people are generally faster than newbie
coders, and new hires with experience tend to hit the ground running faster.
No need to wait for them to learn the ins and out of the API that your company
happens to be using, if they already know it.  I'll explain more below.

>All industries hire newbies. Even experienced programmers are newbies to
>your code - otherwise they aren't new-hires. If I write simple, direct,
>straightforward code with good comments, good structure, good documentation,
>etc., then I've got code that a newbie to Language XXX can readily read and
>grasp (hopefully). Does it *HURT* the experienced programmer that you didn't
>write something in as few keystrokes as possible within Language XXX? I
>don't think so. (Like I said, whenever someone else picks up your program

If you're asking for my personal experiences, then yes it would hurt everyone
(including the shareholders and customers) if I needlessly broke the code up
into multiple statements that used up more clock cycles, especially if it's a
piece of code that needs to be called often.  I work in the gaming industry.
Speed is king.  Just make damn sure that you comment your algorithms.
Unfortunately, people do tend to try to be needlessly terse and cram many
instructions into a single line because they think that's a good way to
optimize when it in fact accomplishes nothing.

When hiring new people, we expect them to know at least the basics of the API
we're using  (DirectX, OpenGL, whatever), some 3D math, and some of the bells
and whistles.  We've got deadlines.  We can't afford to hire pure newbies.  A
certain level of experience is a must.  And yes, we do look for people with
good coding practices -- no sloppy stuff, please!  That'd just slow down the
other team members.  We once had a vacuum salesman with no programming
experience applying for a job... want him?  :)   Of course there are the odd
times when we do hire programmers from another industry, but we generally stick
them with the task of creating tools and utilities until they learn the gaming
fundamentals. Sometimes they're quite happy with creating tools, and never want
to work on games directly.

If I was working for, say, a bank, then yes I would write slow and reliable
code that would last for years and be easily readable by people 10 years down
the road.  If I was writing software for a weapons research facility, then I'd
be sweating over every line and be agonizingly descriptive (/* here is the
auto-destruct function.  I say again, here is the auto-destruct function.
WARNING! Danger Will Robinson Danger! */). 

However, working in the gaming industry is a bit unforgiving in the sense that
your code generally becomes obsolete fairly quickly.  Just about the only thing
we can keep from project to project are the libraries, interfaces, and
platform-independent functions, and even they may need changing as new
platforms ship.  Spend too long programming, and your game becomes obsolete
before it even ships, like a certain over-hyped game...
*cough*Daikatana*cough*.  As such, writing long-term code is a bit of a wasted
effort (unless if it's REALLY useful and generic such as a quicksort function),
and that time would be better invested in tweaking the eye-candy to attract
more customers.


>Read before what I said about opening up the floodgates. Some features of a
>language are *inherently* unsafe or encourage obfuscation or make it easy to
>introduce errors. In C (and in a number of other languages) you have well
>known "syntax traps" that make it easy to create compile time errors that
>are hard to locate. Similarly, there are "semantic traps" that make it easy
>to introduce run-time errors. (BTW, this is true of verbose languages like
>Cobol as well). I'm in favor of structuring the notation of a language such
>that it minimizes the risk of errors and maximizes the communication to the
>reader. IMHO, C's terse notation works against these goals. C's semantics
>work against these goals as well, but that's another debate.

Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and encourages
obfuscation.  However, it also promotes flexibility.  That's always been an
acknowledged trade-off in C/C++ - with flexibility comes responsibility.  I
don't see how you can clean up the notations to reduce bugs, though, short of
getting rid of pointers altogether (which I definitely DON'T want to see happen
in C/C++).  


>I hear you. I agree with this. I'd prefer a language design that does not
>ALLOW something like what you just described, no matter how much "expressive
>power" can be gained for the attainment of Good And Noble goals. (Sort of an

Well.. it's always hard to predict how creative the programmer can be.  Java
was supposed to be "clean"... of course it didn't take too long for people to
prove otherwise  :)    On the flip side, be too restrictive, and you could end
up with a dead language.  People complained about Pascal because it was so
"structured".

It really depends on the programmer - like you said, anything can be taken to
the extremes, and even the greatest language in the world can end up looking
horrible in the hands of a talented (ahem) programmer, and there's not much we
can do to "fix" this.  I've accepted this about C/C++:  I know it's not
perfect, and I do bitch about it off and on, but it works well for me for what
I need to do. 

A hammer's just so damn useful, but I still sometimes hit my thumb.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, on 06/06/2001
   at 03:53 PM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>More experienced people are generally faster than newbie coders,

FSVO faster. The newbies are less likely to take the time to do it
right. They may deliver the code faster, but with significant
downstream costs as bugs materialize.

"There's never time to do it right but there's always time to do it
over."

>If you're asking for my personal experiences, then yes it would hurt
>everyone (including the shareholders and customers) if I needlessly
>broke the code up into multiple statements that used up more clock
>cycles, especially if it's a piece of code that needs to be called
>often.

"You have to carve the bird at the joints. It is sound practice to
write code in pieces that naturally divide. It is wasteful and
unmaintainable to break the code up arbitrarily. In your environment,
the performance impact is part of the "joints" metric.

>People complained about Pascal because it was so "structured".

Some people. Other people complained about Pascal because it was too
unstructured and ineptly structured. Shileds up, Scotty.




-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Roedy Green]

On Thu, 07 Jun 2001 07:36:52 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote or quoted :

>FSVO faster. 
FSVO?




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Jon Skeet]

Roedy Green <roedy@mindprod.com> wrote:
> On Thu, 07 Jun 2001 07:36:52 -0400, "Shmuel (Seymour J.) Metz"
> <spamtrap@library.lspace.org.invalid> wrote or quoted :
> 
> >FSVO faster. 
> FSVO?

"For suitable values of", I believe.

One of the more bizarre abbreviations I used to see on ucam.chat was 
TMBSNMOTW <foo> OWIWNPA, which stood for:

"This must be some new meaning of the word <foo> of which I was not 
previously aware."

(The source for this, of course, is The Hitch-hikers' Guide To The 
Galaxy, where there is an exchange that runs something like:

Arthur: Where are we?
Ford:   We're safe.
Arthur: Where, exactly?
Ford:   We're on a ship in the Vogon constructor fleet.
Arthur: Ah, I see. This must be some new meaning of the word "safe" of
        which I was not previously aware.

In fact, I believe the book has a slightly different way of putting it 
from the above, but the misquote has become reasonably widely known :)

-- 
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <acuvht0gtl5mkrc6s637vfeshb0b0tsl48@4ax.com>, on 06/07/2001
   at 10:01 PM, Roedy Green <roedy@mindprod.com> said:

>FSVO?

For some value of.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, Pete Thompson says...
>
>Well, sure it's subject to abuse.  However, that's the fault of the programmer,
>not the language itself.  I too froth at the mouth whenever someone makes a
>stupid use of operator overloading in C++, or write unnecessary compound
>statements.
..
>A hammer's just so damn useful, but I still sometimes hit my thumb.

Real-world tools are actually a damn good analogy here. For example, whenever
someone takes their fingers off with a table-saw, its the fault of the user.
However, that doesn't stop table-saw makers from putting guards and other safety
features on them, does it? Languages, like any other tool, can be designed with
user safety in mind, or they can be built in a way that practicly invites users
to maim themselves. Sure, its the user's own stupid fault when they do so. But
their first mistake was using the unsafely designed tool in the first place.

(I know, I know. Lawsuits are actually an issue here, and they aren't typically
in the software world. Please lets ignore that issue for a minute. No analogy is
perfect. )

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

My table saw has a guard over the blade that shields the user from
accidentally bumping into the blade, reduces the flying sawdust and helps
prevent the workpiece from kicking back if the blade hangs on something. It
is a very nice safety feature that protects me on a lot of occasions.
However, I *can* and *do* from time to time remove it when I've got to cut
some workpiece that makes the guard awkward or impossible to live with.

I think Ada is similar. It has lots of checking to help insure you don't
shoot yourself in the foot. However, when the need arises, you can
circumvent the safety features. C is more like a saw that never came
equipped with such safety features. You can't add them on after the fact
very easily and are unlikely to do so. Better to have them there and
occasionally take them off than never have them there and mostly operate
without a net.

Hey! Maybe we can get OSHA to mandate the use of Ada???

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Ted Dennison" <dennison@telepath.com> wrote in message
news:VLLT6.2273$bA3.110613@www.newsranger.com...
> Real-world tools are actually a damn good analogy here. For example,
whenever
> someone takes their fingers off with a table-saw, its the fault of the
user.
> However, that doesn't stop table-saw makers from putting guards and other
safety
> features on them, does it? Languages, like any other tool, can be designed
with
> user safety in mind, or they can be built in a way that practicly invites
users
> to maim themselves. Sure, its the user's own stupid fault when they do so.
But
> their first mistake was using the unsafely designed tool in the first
place.
>
> (I know, I know. Lawsuits are actually an issue here, and they aren't
typically
> in the software world. Please lets ignore that issue for a minute. No
analogy is
> perfect. )
>

Re: Long names are doom ?

[Pete Thompson]

On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:

Lawsuits over bugs?!  Say it ain't so!

In all seriousness, yes you could try to use safeguards, but there are cases
where you simply cannot defend someone from themselves.  How would you put
safeguards on a hammer?  A hammer's already pretty basic.  The only thing I
could think of is to tell someone to use an electric hammer instead, but that's
an entirely different tool to accomplish the same task.  Similarly, if
someone's so worried about pointers and memory, then I'd just tell him to use
Java instead.

But there are times where you just can't anticipate ahead of time what the
programmers may do... who woulda thunk that NASA would allow a simple
imperial/metric mistake to screw up a mission?  :) 





>In article <vj7tht0jkrkoivki4lsadlivgghdr0b6pe@4ax.com>, Pete Thompson says...
>>
>>Well, sure it's subject to abuse.  However, that's the fault of the programmer,
>>not the language itself.  I too froth at the mouth whenever someone makes a
>>stupid use of operator overloading in C++, or write unnecessary compound
>>statements.
>..
>>A hammer's just so damn useful, but I still sometimes hit my thumb.
>
>Real-world tools are actually a damn good analogy here. For example, whenever
>someone takes their fingers off with a table-saw, its the fault of the user.
>However, that doesn't stop table-saw makers from putting guards and other safety
>features on them, does it? Languages, like any other tool, can be designed with
>user safety in mind, or they can be built in a way that practicly invites users
>to maim themselves. Sure, its the user's own stupid fault when they do so. But
>their first mistake was using the unsafely designed tool in the first place.
>
>(I know, I know. Lawsuits are actually an issue here, and they aren't typically
>in the software world. Please lets ignore that issue for a minute. No analogy is
>perfect. )
>
>---
>T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Ted Dennison]

In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson says...
>
>On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:
>
>Lawsuits over bugs?!  Say it ain't so!

Yeah, if that were allowed, then Bell would have been killed over C long before 
the Justice Department had a change to break it up. :-)

>In all seriousness, yes you could try to use safeguards, but there are cases
>where you simply cannot defend someone from themselves.  How would you put
>safeguards on a hammer?  A hammer's already pretty basic.  The only thing I

Right, you can't. But where you can put in safety features to prevent common
accidents, like with a table-saw, most people would consider it practicly
irresponsible not to.


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Larry Kilgallen]

In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com> wrote:
> 
> Lawsuits over bugs?!  Say it ain't so!
> 
> In all seriousness, yes you could try to use safeguards, but there are cases
> where you simply cannot defend someone from themselves.  How would you put
> safeguards on a hammer?

Remember that in the good old US of A manufacturers of aluminum
ladders are obliged to attach labels telling the user not to lean
the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Marin David Condic]

Ladders are supposed to be so overly expensive here specifically because of
all the product liability insurance the manufacturers have to carry. What
I'd like to know is how come a woman can spill hot coffee in her lap, sue
McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
unsafe technology. (Comes The Revolution, the lawyers will be the second
ones up against the wall, right after the entire marketing department of
Cirrus Cybernetics Corporation! :-)

As for the hammer? I'd suggest OSHA require they all be wrapped in
styrofoam. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:FzmIx3$T4lbd@eisner.encompasserve.org...
> In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> writes:
> > On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com>
wrote:
> >
> > Lawsuits over bugs?!  Say it ain't so!
> >
> > In all seriousness, yes you could try to use safeguards, but there are
cases
> > where you simply cannot defend someone from themselves.  How would you
put
> > safeguards on a hammer?
>
> Remember that in the good old US of A manufacturers of aluminum
> ladders are obliged to attach labels telling the user not to lean
> the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Benjamin.Altman]

Cause you don't expect coffee do give you 3rd degree burns, but everyone knows
that the software is unsafe or buggy when they buy it (not excuse, but...)

Marin David Condic wrote:

> Ladders are supposed to be so overly expensive here specifically because of
> all the product liability insurance the manufacturers have to carry. What
> I'd like to know is how come a woman can spill hot coffee in her lap, sue
> McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
> sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
> unsafe technology. (Comes The Revolution, the lawyers will be the second
> ones up against the wall, right after the entire marketing department of
> Cirrus Cybernetics Corporation! :-)
>
> As for the hammer? I'd suggest OSHA require they all be wrapped in
> styrofoam. :-)
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> news:FzmIx3$T4lbd@eisner.encompasserve.org...
> > In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
> <blackpete@nowhere.somewhere.anywhere.com> writes:
> > > On Thu, 07 Jun 2001 13:58:13 GMT, Ted Dennison<dennison@telepath.com>
> wrote:
> > >
> > > Lawsuits over bugs?!  Say it ain't so!
> > >
> > > In all seriousness, yes you could try to use safeguards, but there are
> cases
> > > where you simply cannot defend someone from themselves.  How would you
> put
> > > safeguards on a hammer?
> >
> > Remember that in the good old US of A manufacturers of aluminum
> > ladders are obliged to attach labels telling the user not to lean
> > the aluminum ladder against an overhead power wire.

Re: Long names are doom ?

[Blaikie]

> Cause you don't expect coffee do give you 3rd degree burns, but everyone
knows
> that the software is unsafe or buggy when they buy it (not excuse, but...)

coffee is hot, quite often boiling when it passes through the filter, ne1
with 1/2 a brain could expect that.
and ppl are able to and have sued M$, but the result depends on who has the
money, obviously stacking the case in Micrososfts favour.
db

Re: Long names are doom ?

[Roedy Green]

On Fri, 8 Jun 2001 07:52:08 +1000, "Blaikie"
<david_blaikie@hotmail.com> wrote or quoted :

>coffee is hot, quite often boiling when it passes through the filter, ne1
>with 1/2 a brain could expect that.
>and ppl are able to and have sued M$, but the result depends on who has the
>money, obviously stacking the case in Micrososfts favour.

I will be very happy when someone wins the first software suit.  We
will finally see some major attention paid to writing bug-free
programs for the ordinary marketplace.

It will be like the move from building by eye to building with finite
element stress analysis.

We don't even attempt to treat software construction as a science.  




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Marin David Condic]

When I was in kindergarden, the teacher gave us these sage words of advice:
"Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
the point. If it was cold, you would complain. Through your own
carelessness, a thing expected to be what it is is actually what it is and
it does you harm. That is the fault of McDonalds? OTOH, One *expects*
software to work just like one expects their car to work or their TV to
work. (O.K. We all know better, but why do we stand for it?) When it doesn't
do what it is expected to do, we let the manufacturer off the hook - even
when there are proven methods for making software more reliable and they are
not followed?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Benjamin.Altman" <benjamin.altman@noaa.gov> wrote in message
news:3B1FE1FE.B49AE27F@noaa.gov...
> Cause you don't expect coffee do give you 3rd degree burns, but everyone
knows
> that the software is unsafe or buggy when they buy it (not excuse, but...)
>
> Marin David Condic wrote:
>
> > Ladders are supposed to be so overly expensive here specifically because
of
> > all the product liability insurance the manufacturers have to carry.
What
> > I'd like to know is how come a woman can spill hot coffee in her lap,
sue
> > McDonalds for making the coffee hot & *win*, yet nobody seems to be able
to
> > sue Bell Labs or Micro$oft for manufacturing operating systems with
*known*
> > unsafe technology. (Comes The Revolution, the lawyers will be the second
> > ones up against the wall, right after the entire marketing department of
> > Cirrus Cybernetics Corporation! :-)
> >
> > As for the hammer? I'd suggest OSHA require they all be wrapped in
> > styrofoam. :-)
> >
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas    www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> > "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> > news:FzmIx3$T4lbd@eisner.encompasserve.org...
> > > In article <hpgvht8u8j7nr2gtel8f90g9motg7ga7aq@4ax.com>, Pete Thompson
> > <blackpete@nowhere.somewhere.anywhere.com> writes:
> > > > On Thu, 07 Jun 2001 13:58:13 GMT, Ted
Dennison<dennison@telepath.com>
> > wrote:
> > > >
> > > > Lawsuits over bugs?!  Say it ain't so!
> > > >
> > > > In all seriousness, yes you could try to use safeguards, but there
are
> > cases
> > > > where you simply cannot defend someone from themselves.  How would
you
> > put
> > > > safeguards on a hammer?
> > >
> > > Remember that in the good old US of A manufacturers of aluminum
> > > ladders are obliged to attach labels telling the user not to lean
> > > the aluminum ladder against an overhead power wire.
>

Re: Long names are doom ?

[Eric The Read]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> When I was in kindergarden, the teacher gave us these sage words of advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm. That is the fault of McDonalds?

I don't know why I expect computer professionals to be more informed
about this sort of thing than the average person (more web-literacy,
maybe?  I don't know...) but you might wish to educate yourself a bit
more on the actual facts of the case.

* McDonald's had paid more than 700 claims of exactly that type at the
  point Ms. Leibeck sued them.  They knew the nature and severity of the
  injuries their coffee had caused.

* Ms Leibeck suffered full-thickness (or third-degree) burns over 6
  percent of her body, and was hospitalized for 8 days, undergoing
  (rather painful, I might editorialize here) skin grafts and debridement 
  treatments.

* McDonald's served their coffee 40 to 50 degrees Fahrenheit hotter than
  the industry norm.  The consultant who advocated this to them admitted
  he'd never done any safety analysis of that temperature.

* McDonald's QA manager admitted that company policy required coffee to
  be served at 185 degrees, +/- 5 degrees, and that burning hazards
  existed at temperatures above 140.  He further testified that
  McDonald's knew there was a risk of burns, but wasn't going to do
  anything about it.

* At the temperatures the coffee was served, a full thickness burn of
  human skin will only take about 2 to 7 seconds.  If it had been served
  even at 155 degrees, likely Ms. Liebeck would not have been seriously
  injured.  (A survey of Alberquerque McDonalds' afterward found coffee
  served at an average of 158 degrees.)

* The car Liebeck was in was stopped when she spilled the coffee, and she 
  was not in the driver's seat.

* Leibeck originally sued for only $20,000, roughly her hospital costs.
  The jury awarded her $160k, plus $2.7M for punitive damages, which
  latter award the judge later reduced to a mere $480k (three times
  compensatory damages).

Source: <URL:http://www.lectlaw.com/files/cur78.htm>

> OTOH, One *expects*
> software to work just like one expects their car to work or their TV to
> work. (O.K. We all know better, but why do we stand for it?) When it doesn't
> do what it is expected to do, we let the manufacturer off the hook - even
> when there are proven methods for making software more reliable and they are
> not followed?

That's the real problem, and the main obstacle, I think, is that nobody
has seriously tried to sue a software manufacturer for providing useless, 
buggy, crap.  At least, not that I'm aware of (corrections welcome).
Until we see consumers start caring about quality, feature creep will win 
the day, I fear.

Followups set to 'poster' for OT content; if you want to reply to the
last para, feel free.

-=Eric
-- 
The hardest thing in the world to understand is the income tax.
		-- Albert Einstein

Off Topic: Hot Coffee (was Re: Long names are doom ?)

[Marin David Condic]

None of those facts of the case in any way negates what I believe is the
most important fact of the case: You are a grown-up now and you are
responsible for your own actions. Hot things burn. You don't put hot things
between your legs or otherwise balance them precariously unless you want to
invite an accident. You handle dangerous, hot things with appropriate care
and caution. When you do something stupid and injure yourself with someone
else's product, it gets *real easy* to start looking for someone else to
blame. All too often we don't look where we should: in the mirror.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Eric The Read" <emschwar@rmi.net> wrote in message
news:xkfzobjj3ed.fsf@valdemar.cos.agilent.com...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> > When I was in kindergarden, the teacher gave us these sage words of
advice:
> > "Hot things burn. Sharp things cut." You *expect* coffee to be hot -
that's
> > the point. If it was cold, you would complain. Through your own
> > carelessness, a thing expected to be what it is is actually what it is
and
> > it does you harm. That is the fault of McDonalds?
>
> I don't know why I expect computer professionals to be more informed
> about this sort of thing than the average person (more web-literacy,
> maybe?  I don't know...) but you might wish to educate yourself a bit
> more on the actual facts of the case.
>
> * McDonald's had paid more than 700 claims of exactly that type at the
>   point Ms. Leibeck sued them.  They knew the nature and severity of the
>   injuries their coffee had caused.
>
> * Ms Leibeck suffered full-thickness (or third-degree) burns over 6
>   percent of her body, and was hospitalized for 8 days, undergoing
>   (rather painful, I might editorialize here) skin grafts and debridement
>   treatments.
>
> * McDonald's served their coffee 40 to 50 degrees Fahrenheit hotter than
>   the industry norm.  The consultant who advocated this to them admitted
>   he'd never done any safety analysis of that temperature.
>
> * McDonald's QA manager admitted that company policy required coffee to
>   be served at 185 degrees, +/- 5 degrees, and that burning hazards
>   existed at temperatures above 140.  He further testified that
>   McDonald's knew there was a risk of burns, but wasn't going to do
>   anything about it.
>
> * At the temperatures the coffee was served, a full thickness burn of
>   human skin will only take about 2 to 7 seconds.  If it had been served
>   even at 155 degrees, likely Ms. Liebeck would not have been seriously
>   injured.  (A survey of Alberquerque McDonalds' afterward found coffee
>   served at an average of 158 degrees.)
>
> * The car Liebeck was in was stopped when she spilled the coffee, and she
>   was not in the driver's seat.
>
> * Leibeck originally sued for only $20,000, roughly her hospital costs.
>   The jury awarded her $160k, plus $2.7M for punitive damages, which
>   latter award the judge later reduced to a mere $480k (three times
>   compensatory damages).
>
> Source: <URL:http://www.lectlaw.com/files/cur78.htm>
>
> > OTOH, One *expects*
> > software to work just like one expects their car to work or their TV to
> > work. (O.K. We all know better, but why do we stand for it?) When it
doesn't
> > do what it is expected to do, we let the manufacturer off the hook -
even
> > when there are proven methods for making software more reliable and they
are
> > not followed?
>
> That's the real problem, and the main obstacle, I think, is that nobody
> has seriously tried to sue a software manufacturer for providing useless,
> buggy, crap.  At least, not that I'm aware of (corrections welcome).
> Until we see consumers start caring about quality, feature creep will win
> the day, I fear.
>
> Followups set to 'poster' for OT content; if you want to reply to the
> last para, feel free.
>
> -=Eric
> --
> The hardest thing in the world to understand is the income tax.
> -- Albert Einstein

Re(ally): Off Topic: Hot Coffee (was Re: Long names are doom ?)

[Paul Graham]

Marin David Condic wrote:
> 
> None of those facts of the case in any way negates what I believe is the
> most important fact of the case: You are a grown-up now and you are
> responsible for your own actions. Hot things burn. You don't put hot things
> between your legs or otherwise balance them precariously unless you want to
> invite an accident. You handle dangerous, hot things with appropriate care
> and caution. When you do something stupid and injure yourself with someone
> else's product, it gets *real easy* to start looking for someone else to
> blame. All too often we don't look where we should: in the mirror.
> 
> MDC

This may be a totally ridiculous analogy, but suppose I gave you a
keyboard to work on and told you "whatever you do, don't hit ctrl-c." 
Well, one day you accidentally hit ctrl-c, and boiling water squirted
out at you and burned you.  Would you blame me, or look in the mirror?

Paul

Re: Re(ally): Off Topic: Hot Coffee (was Re: Long names are doom ?)

[Marin David Condic]

I'm afraid I'd consider that totally ridiculous. Daffy Duck was always
trying to bump off Bugs Bunny and "make it look like an accident" by wiring
TNT up to a piano keyboard. Would you believe that Bugs was the victim of a
random accident? Do pianos often explode while being played? Would you like
to buy some land here in Florida? :-)

Try to get around this: Coffe is hot. Hot things burn. By the age of five,
you probably had that part all figured out. When mishandling hot things in a
dangerous and risky manner, and then getting burned, are you going to blame
the coffee pot for making it hot? Or are you going to look in the mirror and
say "Boy was I stupid for trying to juggle a hot cup of coffee!!!"

But we live in a world where people smoke cigarettes and then blame the
manufacturer for their health problems, or people get s**t-faced drunk &
wreck their cars and then blame the bartender & the breweries, or shoot
their neighbor in the head in an argument over a garden hose and then blame
the gun manufacturer for making a product that functions perfectly as
described in the owner's manual. Its always easy to blame some nameless,
faceless, wealthy company rather than accept personal responsibility. Its
also very handy when one has a political agenda that can't be won in the
legislature so it gets taken to court where you don't have to persuade 51%
of the population that it is important enough to side with you. But that's
ANOTHER really off topic harangue! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Paul Graham" <pgraham@cadence.com> wrote in message
news:3B252F51.CDD3BB1E@cadence.com...
> This may be a totally ridiculous analogy, but suppose I gave you a
> keyboard to work on and told you "whatever you do, don't hit ctrl-c."
> Well, one day you accidentally hit ctrl-c, and boiling water squirted
> out at you and burned you.  Would you blame me, or look in the mirror?
>

Re: Long names are doom ?

[Dan Mercer]

In article <9fotpi$4k6$1@nh.pace.co.uk>,
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> When I was in kindergarden, the teacher gave us these sage words of advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot - that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm.

DELETIA

Much as I loathe taking this topic farther off-topic

The burden is on the producer to provide the product safely.
McDonalds sold the coffee at the drive through window.  It was
easily foreseeable that the coffee would sometimes spill.  Thus,
they needed to provide it in a safe container (a larger container
partially filled rather than a small container filled to the
brim), provide it with lids less likely to come off,  provide a
carrier, or at very minimum make sure the coffee would not burn. 
McD's failed in all these regards.  Coffee hot enough to cause
3rd degree burns is too hot to drink.  It's deliberately
overheated so it will still be hot when people get it home.
McD's biggest fault was overreaching and taking the lawsuit to
a conclusion.  They could and should have settled out of court for 1/10
the judgement (and no precedent).

-- 
Dan Mercer
damercer@mmm.com


> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
MORE DELETIA

Re: Long names are doom ?

[Roedy Green]

On Thu, 7 Jun 2001 18:04:32 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> You *expect* coffee to be hot - that's
>the point. If it was cold, you would complain.

Well put.  Further coffee is advertised to be "piping hot" and
software is advertised to be "a snap to use".

There whole classes of misleading advertising that we consider
acceptable. We don't demand they substantiate their claims. Lying is
so out of hand we just throw up our hands and blame the consumer if he
is stupid enough to take the claims at face value.

Here is my top ten list:

1. gross exaggeration, so the claim could not possibly be considered
true. I'm ok with this, e.g. if you buy x brand dish soap your family
will fight over who gets the privilege of doing the dishes.

2. psychics

3. religions and faith healers.

4. fast food that looks so different in reality from that displayed in
the commercial or posters in the restaurant.

5. Pills that cause you to lose weight.

6. That buying a product will noticeably enhance your sex appeal or
enhance your mood.  E.g. buying a Swiffer will cause you to start
incontrollably dancing with joy, even when confronted by a boot camp
sargent. see (1).

7. aphrodisiacs.

8. how 900 personnel really look and dress.

9. age defying creams and devices.  If there is such a thing, only
Barbra Streisand has enough money to afford it.

10. That software will actually help you get your work done.

Engineering and aviation were hit and miss affairs to start, but they
gradually got their act together, and for the most part, buildings,
bridges and planes don't fall down. We programmers are still in the
biplane era, unwilling to give up the romance of seat of the pants
flying.  Some day we will have rude awakening that our customers don't
quite see it that way.  It may come with the advent of software
rental.  See http://mindprod.com/projects.html#SOFTWARERENTAL It may
come with the first successful software malpractice suit.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9fotpi$4k6$1@nh.pace.co.uk...
> When I was in kindergarden, the teacher gave us these sage words of
advice:
> "Hot things burn. Sharp things cut." You *expect* coffee to be hot -
that's
> the point. If it was cold, you would complain. Through your own
> carelessness, a thing expected to be what it is is actually what it is and
> it does you harm. That is the fault of McDonalds? OTOH, One *expects*
> software to work just like one expects their car to work or their TV to
> work. (O.K. We all know better, but why do we stand for it?) When it
doesn't
> do what it is expected to do, we let the manufacturer off the hook - even
> when there are proven methods for making software more reliable and they
are
> not followed?


Unfortunately, a software lawsuit would have little ground to stand on.
Imagine if McDonald's required all customers who order hot coffee to sign an
agreement before they are given the coffee where they acknowledge that the
coffee is hot and can cause burns and that the customer assumes all
responsibility for the proper handling of the coffee. If you got burnt from
the coffee would you be able to win a suit agains McDonald's? Not likely,
since you agreed to accept the responsibility.

Read most software license agreements and you'll find that most are like my
hypothetical coffee agreement. Here is a sample from an IBM license
agreement: "IBM does not warrant uninterrupted or error-free operation of
the Program or that we will correct all Program defects. You are responsible
for the results obtained from the use of the Program." And since "IBM WILL
LICENSE THE PROGRAM TO YOU ONLY IF YOU FIRST ACCEPT THE TERMS OF THIS
AGREEMENT. " then you don't really have a legal leg to stand on. They even
have clauses limiting their liability.
--
 Dale King

software suits, was Re: Long names are doom ?

[tmoran]

>Unfortunately, a software lawsuit would have little ground to stand on.
>Imagine if McDonald's required all customers who order hot coffee to sign an
>agreement before they are given the coffee where they acknowledge that the
>...
>agreement: "IBM does not warrant uninterrupted or error-free operation of
  If my doctor used that IBM software and harmed me, I would sue the
doctor *and* IBM.  If IBM then wants to sue the doctor for improperly
using their clearly labeled dangerous software, that's between them and
the doctor.  If my car crashed because of a software glitch I'd sue the
car company, whether they created the buggy software themselves or
bought it from IBM.  And if my doctor or auto dealer said I'd have to
sign a "hold harmless" agreement, I'd go elsewhere.

Re: software suits, was Re: Long names are doom ?

[Larry Kilgallen]

In article <Kk6V6.82266$%i7.62035400@news1.rdc1.sfba.home.com>, tmoran@acm.org writes:
>>Unfortunately, a software lawsuit would have little ground to stand on.
>>Imagine if McDonald's required all customers who order hot coffee to sign an
>>agreement before they are given the coffee where they acknowledge that the
>>...
>>agreement: "IBM does not warrant uninterrupted or error-free operation of
>   If my doctor used that IBM software and harmed me, I would sue the
> doctor *and* IBM.  If IBM then wants to sue the doctor for improperly
> using their clearly labeled dangerous software, that's between them and
> the doctor.  If my car crashed because of a software glitch I'd sue the
> car company, whether they created the buggy software themselves or
> bought it from IBM.  And if my doctor or auto dealer said I'd have to
> sign a "hold harmless" agreement, I'd go elsewhere.

Agreements not to sue are often held invalid if the defendent is judged
to be more "sophisticated" than the plaintiff in US courts.

Re: software suits, was Re: Long names are doom ?

[Marin David Condic]

There is a whole bunch of contract law that can come into play that can
pretty much make everything written on paper completely meaningless. Courts
are concerned with "Did a contract take place?" not so much with "What did
the piece of paper say?" You are right. Courts can and have concluded that
inequality of the parties in terms of sophistication and level of power can
make the written contract null. Ever seen one of those things when accepting
employment from a company that outlines all the benefits and so on where it
says clearly at the top "This is not a contract..."? Guess what? Courts have
thrown that sort of thing out saying "You lead the employee to believe that
these were promises and committments - you formed a contract. Tough noogies
that you wrote 'This is not a contract...'"

I think that a good trial lawyer would probably be able to find case law and
arguments that would nullify the usual disclaimers made for software in
extreme cases of software failure. Not being a lawyer nor do I play one in
newsgroups, I could not say for sure, but it seems that a lot of those
standard disclaimers written in small type and easily blipped over when
installing software seem to be a bit unilaterally imposed and with a bit of
a disparity of power. How am I supposed to make an informed judgement about
accepting your software "as is" until I install it and test-drive it? I
can't adequately inspect the goods without installing it on my machine. And
by then I've walked past the screen saying 'I Accept' without being able to
find out that your software turns disk drives into a smouldering heap of
slag.

I think the only reason more software companies have not been handed their
asses in court is that for the most part end-users have just come to accept
as gospel that most software is buggy crap and there isn't anything they can
do about it. If you can sue cigarette companies for billions for having sold
a legal product with well known risks and blame them for the fact that you
used their product and suffered from the well known risks, why can't you sue
Microsoft? (Aside: Alcohol is also a legal product with well known risks -
notice how they're going after that too? I'm waiting for someone to discover
that a) McDonalds hamburgers are loaded with saturated fat. b) Saturated fat
is addictive and kills more people than cigarettes. c) McDonalds uses clowns
and toys to market this known health hazzard to kids. d) McDonalds, et alia,
probably have *even*more* money than the cigarette companies. e) Trial
lawyers ought to smell those profits too. Pretty soon we all should be able
to retire from productive work and just sue each other in order to make a
living.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:y5Ym0m8y82Qu@eisner.encompasserve.org...
>
> Agreements not to sue are often held invalid if the defendent is judged
> to be more "sophisticated" than the plaintiff in US courts.

RE: software suits, was Re: Long names are doom ?

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Martin Condic et al.

If you really want to create a commercial market for Ada, educate some
lawyers. There are enough expert witnesses in the Comp.Lang.Ada and Team-Ada
groups to create mayhem. I have often said that Ada will not solve all of a
medical device company's problems. However together with a reasonable
software process, the use of Ada should help to minimize damages due to
negligence. C++ is a wonderful language for the plaintiffs' attorneys.

I suspect that the present lack of software sophistication amongst
malpractice lawyers has resulted in the evidence literally being buried.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Monday, June 11, 2001 11:48 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: software suits, was Re: Long names are doom ?


There is a whole bunch of contract law that can come into play that can
pretty much make everything written on paper completely meaningless. Courts
are concerned with "Did a contract take place?" not so much with "What did
the piece of paper say?" You are right. Courts can and have concluded that
inequality of the parties in terms of sophistication and level of power can
make the written contract null. Ever seen one of those things when accepting
employment from a company that outlines all the benefits and so on where it
says clearly at the top "This is not a contract..."? Guess what? Courts have
thrown that sort of thing out saying "You lead the employee to believe that
these were promises and committments - you formed a contract. Tough noogies
that you wrote 'This is not a contract...'"

I think that a good trial lawyer would probably be able to find case law and
arguments that would nullify the usual disclaimers made for software in
extreme cases of software failure. Not being a lawyer nor do I play one in
newsgroups, I could not say for sure, but it seems that a lot of those
standard disclaimers written in small type and easily blipped over when
installing software seem to be a bit unilaterally imposed and with a bit of
a disparity of power. How am I supposed to make an informed judgement about
accepting your software "as is" until I install it and test-drive it? I
can't adequately inspect the goods without installing it on my machine. And
by then I've walked past the screen saying 'I Accept' without being able to
find out that your software turns disk drives into a smouldering heap of
slag.

I think the only reason more software companies have not been handed their
asses in court is that for the most part end-users have just come to accept
as gospel that most software is buggy crap and there isn't anything they can
do about it. If you can sue cigarette companies for billions for having sold
a legal product with well known risks and blame them for the fact that you
used their product and suffered from the well known risks, why can't you sue
Microsoft? (Aside: Alcohol is also a legal product with well known risks -
notice how they're going after that too? I'm waiting for someone to discover
that a) McDonalds hamburgers are loaded with saturated fat. b) Saturated fat
is addictive and kills more people than cigarettes. c) McDonalds uses clowns
and toys to market this known health hazzard to kids. d) McDonalds, et alia,
probably have *even*more* money than the cigarette companies. e) Trial
lawyers ought to smell those profits too. Pretty soon we all should be able
to retire from productive work and just sue each other in order to make a
living.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:y5Ym0m8y82Qu@eisner.encompasserve.org...
>
> Agreements not to sue are often held invalid if the defendent is judged
> to be more "sophisticated" than the plaintiff in US courts.

Re: software suits, was Re: Long names are doom ?

[Marin David Condic]

I suspect a case could be made on the basis that known technology would
avoid a large number of errors. If you build software with weak technology
when better technology is proven to work, there's a certain amount of
malfeasance there. The other side would argue "Yes, but technology A was in
place and the cost of switching to technology B was so high as to be
prohibitive." It's worked for the auto industry in the past. It would be
interesting to hear the case though...

(BTW: Its "Marin" - but don't feel bad - everyone gets it wrong...)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.992328167.17608.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Martin Condic et al.
>
> If you really want to create a commercial market for Ada, educate some
> lawyers. There are enough expert witnesses in the Comp.Lang.Ada and
Team-Ada
> groups to create mayhem. I have often said that Ada will not solve all of
a
> medical device company's problems. However together with a reasonable
> software process, the use of Ada should help to minimize damages due to
> negligence. C++ is a wonderful language for the plaintiffs' attorneys.
>
> I suspect that the present lack of software sophistication amongst
> malpractice lawyers has resulted in the evidence literally being buried.
>

Re: software suits, was Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9g33oo$rp$1@nh.pace.co.uk...
<completely unrelated example snipped>
>
> I think that a good trial lawyer would probably be able to find case law
and
> arguments that would nullify the usual disclaimers made for software in
> extreme cases of software failure. Not being a lawyer nor do I play one in
> newsgroups, I could not say for sure, but it seems that a lot of those
> standard disclaimers written in small type and easily blipped over when
> installing software seem to be a bit unilaterally imposed and with a bit
of
> a disparity of power. How am I supposed to make an informed judgement
about
> accepting your software "as is" until I install it and test-drive it? I
> can't adequately inspect the goods without installing it on my machine.
And
> by then I've walked past the screen saying 'I Accept' without being able
to
> find out that your software turns disk drives into a smouldering heap of
> slag.

I certainly do not put anything past a trial lawyer to attempt. But the odds
are stacked against them. And I have never seen a license agreement that you
could skip by without actually making a conscious effort to say that you
accept the agreement. I even had one recently that would not let me just hit
accept if I didn't at least scroll down a little through the text of the
agreement. It is very difficult to claim ignorance when you have to hit a
button that  says "I accept the terms of this agreement". If you don't
bother to read what you are agreeing to, that pretty much qualifies as your
problem.

And they are not unilaterally imposed. You have all the power. Most
agreements say if you do not agree to these terms, then return the software.
They can't make you agree, install, and use it.

> I think the only reason more software companies have not been handed their
> asses in court is that for the most part end-users have just come to
accept
> as gospel that most software is buggy crap and there isn't anything they
can
> do about it.

And the problem is that they have accepted an agreement with the software
company that says this software may be a buggy piece of crap, so it is
rather difficult to sue a company for living up to its agreement.

--
 Dale King

Re: software suits, was Re: Long names are doom ?

[Wes Groleau]

> And they are not unilaterally imposed. You have all the power. Most
> agreements say if you do not agree to these terms, then return the software.
> They can't make you agree, install, and use it.

Well, I am not saying this would hold up in court in ANY country,
but I HAVE SEEN packages which actually said, "If you do not agree
to the terms of the license inside this package, then do not open
the package."

!!!!

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: software suits, was Re: Long names are doom ?

[Marin David Condic]

Exactly! When you go to buy a house or a used car labeled "as is", a court
would likely rule that you had reasonable opportunity to inspect the house
or car and look for flaws & hence could have and should have known what you
were buying. (BTW: This also doesn't hold up across the board - there are
exceptions - talk to a relator about "disclosure" and how that still may not
get you out of all troubles!)

When you buy a piece of software at CompUSA, all you can do there is read
the stuff on the outside of the box - and maybe the user's manuals if you
bust open the box (and doing so does not constitute acceptance.) You cannot
inspect the actual product until you put it on your machine and go past the
"I Accept" button. That "contract" doesn't even promise that the software
inside will even start up and execute *at*all*. It could be an .EXE full of
random zeros and ones and you have no way of knowing that until after you go
past the "I Accept". Hence, you can't really know what you are agreeing to
and no contract takes place.

Naturally, no reputable firm would try to get money out of you for a file
full of random zeros and ones - most would make a good faith effort to
insure their product at least started up and got past the splash screan.
Naturally, they're trying to avoid having someone hold them accountable for
every conceivable little bug or glitch and insist that they fix it at
potentially huge expense. They are also trying to avoid piracy. All of that
is fair, but I still don't think that this should excuse a manufacturer of
software from putting out really buggy crap when it is possible to make
substantially more reliable software. I'd be satisfied if the warranty would
list a set of functions and promise that those functions will work without
flaws with the sole remedy being a refund of my money when I return the
product. (This naturally gets difficult when the flaws may lie beneath your
software in the OS or network or elsewhere... but still, it would be some
sort of progress! Stipulating that the software can pass some set of tests
without failure would be progress. Almost anything would be better than the
"We promise you absolutely nothing!" claim of most licenses.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B267A3D.1B2F2750@ftw.rsc.raytheon.com...
> Well, I am not saying this would hold up in court in ANY country,
> but I HAVE SEEN packages which actually said, "If you do not agree
> to the terms of the license inside this package, then do not open
> the package."
>
> !!!!
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: software suits, was Re: Long names are doom ?

[James Kanze]

Marin David Condic wrote:

> Exactly! When you go to buy a house or a used car labeled "as is", a
> court would likely rule that you had reasonable opportunity to
> inspect the house or car and look for flaws & hence could have and
> should have known what you were buying.

Even then, you are protected against hidden flaws.  In particular, at
least in Germany, if the car has been in a major wreck, the seller is
required to inform you about it, and is liable if he doesn't.

That isn't really relevant here, though.  In the case of most
software, the seller *has* told you that they practice absolutly no
quality control measures, and that what they are selling is really
just a pile of shit.  The relevant law here is more related to the
fact that you didn't sign anything, and you probably didn't read
anything even if you could have, and you certainly didn't intend to
sign away all of your rights.

In the end, regardless of contract, a consumer has a certain number of
rights.  Today, many of these are explictly spelled out, but there are
also implicit rights concerning hidden defects, etc.  And I cannot
give these rights away, regardless of what I sign.  If I buy a new
car, and the brakes fail after driving the car 100 meters, then the
vendor is responsible for the accident.  Not just because the car
manufacturer offers a guarantee (none of the guarantees I've seen
include civil responsibility for accidents), but because I have a
legal right to expect the brakes to work.  The legal right is based on
the principle that any reasonable person would expect the brakes to
work on a new car, and not necessarily take any precautions against
the possibility of their not working.

In the case of software, the problem is complicated.  What should a
reasonable person expect?  If the software is seriously deficient,
compared to other, similar products, then I suspect that you would
have a case.  Given the typical quality of shrink wrapped software,
however, it's hard to imagine anything significantly worse.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: software suits, was Re: Long names are doom ?

[Ted Dennison]

In article <3B2721D9.83CF4E07@dresdner-bank.com>, James Kanze says...
>In the end, regardless of contract, a consumer has a certain number of
>rights.  Today, many of these are explictly spelled out, but there are

Perhaps, but if the "Hague Treaty" ( http://www.gnu.org/philosophy/hague.html )
passes, then you could be sued under US law where you don't have those
protections, and your German courts would be required to enforce any award. :-)

Welcome to the 21'st century...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: software suits, was Re: Long names are doom ?

[Wes Groleau]

Marin David Condic wrote:
> "I Accept" button. That "contract" doesn't even promise that the software

> "Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
> news:3B267A3D.1B2F2750@ftw.rsc.raytheon.com...
> > but I HAVE SEEN packages which actually said, "If you do not agree
> > to the terms of the license inside this package, then do not open
> > the package."

You are criticizing words that imply acceptance of a product that
one has not seen (and I agree with you) but I am criticizing the
even stupider idea that one can accept a "license" that one hasn't
seen.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: software suits, was Re: Long names are doom ?

[Marin David Condic]

Proof that the lawyers have quite obviously gone completely insane - and are
still in the courts, practicing law. (Yes sir! Quite obviously so sir! :-)

Clearly a case of "Blind Justice"? Acceptance of a contract you cannot see
until you accept? Doubt that it would hold up in court.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B278351.ED8C47E1@ftw.rsc.raytheon.com...
>
> You are criticizing words that imply acceptance of a product that
> one has not seen (and I agree with you) but I am criticizing the
> even stupider idea that one can accept a "license" that one hasn't
> seen.
>

Re: software suits, was Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9g61hj$35f$1@nh.pace.co.uk...
> Exactly! When you go to buy a house or a used car labeled "as is", a court
> would likely rule that you had reasonable opportunity to inspect the house
> or car and look for flaws & hence could have and should have known what
you
> were buying. (BTW: This also doesn't hold up across the board - there are
> exceptions - talk to a relator about "disclosure" and how that still may
not
> get you out of all troubles!)
>
> When you buy a piece of software at CompUSA, all you can do there is read
> the stuff on the outside of the box - and maybe the user's manuals if you
> bust open the box (and doing so does not constitute acceptance.) You
cannot
> inspect the actual product until you put it on your machine and go past
the
> "I Accept" button. That "contract" doesn't even promise that the software
> inside will even start up and execute *at*all*. It could be an .EXE full
of
> random zeros and ones and you have no way of knowing that until after you
go
> past the "I Accept". Hence, you can't really know what you are agreeing to
> and no contract takes place.


That would be covered under warranty which is separate from what we have
been discussing here. Under the warranty you probably have the right to
return it for a refund since it didn't work, but that is quite different
than suing over bugs.
--
 Dale King

Re: software suits, was Re: Long names are doom ?

[Marin David Condic]

Maybe you missed my point. First off, any lawyer can tell you that just
because it was written down in the install script and you hit the "I Accept"
button, doesn't mean a contract has taken place. (Ignorance not necessarily
being the defense here. Lots of other things come into play.) My point was
that if the only means I have of inspecting the goods is to hit the "I
Accept" button, then a court may decide that a contract did not take place.
I *had* to go through this motion in order to inspect the goods and
therefore a case might be made that the contract was unilaterally imposed.
(Trust me on this - I *don't* advocate the courts protecting me from my own
stupidity - just equalizing a mismatch of power in the transaction.)

Second off, I'd still contend that there is a mismatch of power in the
transaction. the software vendor is (or can be) knowledgable of all the
inner flaws of the product they are selling. They can hide behind their
install script and in effect tell you that you have to buy a pig in a polk.
You have no way of knowing what is in the software product until you hit the
"I Accept" key - and that is a disparity of power and information. Courts
have quite often sided with a plaintiff who had no reasonable opportunity to
inspect the goods and had to rely on the seller's assurances that the goods
were what they claimed them to be in their advertising.

That's why I think those install screens are a weak defense. Of course, the
only way to find out for sure is to take it to court and get a judge to rule
on it. That's the way it works in a common law legal system.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Dale King" <KingD@TCE.com> wrote in message news:3b267365$1@news.tce.com...
> "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
> message news:9g33oo$rp$1@nh.pace.co.uk...
> <completely unrelated example snipped>
> >
> > I think that a good trial lawyer would probably be able to find case law
> and
> > arguments that would nullify the usual disclaimers made for software in
> > extreme cases of software failure. Not being a lawyer nor do I play one
in
> > newsgroups, I could not say for sure, but it seems that a lot of those
> > standard disclaimers written in small type and easily blipped over when
> > installing software seem to be a bit unilaterally imposed and with a bit
> of
> > a disparity of power. How am I supposed to make an informed judgement
> about
> > accepting your software "as is" until I install it and test-drive it? I
> > can't adequately inspect the goods without installing it on my machine.
> And
> > by then I've walked past the screen saying 'I Accept' without being able
> to
> > find out that your software turns disk drives into a smouldering heap of
> > slag.
>
> I certainly do not put anything past a trial lawyer to attempt. But the
odds
> are stacked against them. And I have never seen a license agreement that
you
> could skip by without actually making a conscious effort to say that you
> accept the agreement. I even had one recently that would not let me just
hit
> accept if I didn't at least scroll down a little through the text of the
> agreement. It is very difficult to claim ignorance when you have to hit a
> button that  says "I accept the terms of this agreement". If you don't
> bother to read what you are agreeing to, that pretty much qualifies as
your
> problem.
>
> And they are not unilaterally imposed. You have all the power. Most
> agreements say if you do not agree to these terms, then return the
software.
> They can't make you agree, install, and use it.
>
> > I think the only reason more software companies have not been handed
their
> > asses in court is that for the most part end-users have just come to
> accept
> > as gospel that most software is buggy crap and there isn't anything they
> can
> > do about it.
>
> And the problem is that they have accepted an agreement with the software
> company that says this software may be a buggy piece of crap, so it is
> rather difficult to sue a company for living up to its agreement.
>
> --
>  Dale King
>
>

Re: software lawsuits

[Roedy Green]

On Tue, 12 Jun 2001 08:34:20 -0500, "Dale King" <KingD@TCE.com> wrote
or quoted :

>And I have never seen a license agreement that you
>could skip by without actually making a conscious effort to say that you
>accept the agreement. 
 
The other way around this legal roadblock is if shirking became
universal.  Ford cars would come with an agreement you had sign with
understanding this car was not actually guaranteed to move, or
transport humans or cargo. It was a mere formality of course to limit
liability in outrageous tire and safety lawsuits.

People might start selling software that more blatantly did absolutely
nothing, promising it would cure cancer, hypnotise your children into
believing in your favoured religion, cure baldness and get you laid.
Congress might just get mad enough to close this loophole.

Eventually congress would decide enough is enough and force everyone
to be liable for making their products perform as advertised or as
could reasonably be expected to behave. E.g. kettles should heat water
to boiling, cars should survive a 5 MPH crash without self-destructing
or killing the occupants, software should not crash all by itself
without provable driver error, just like cars.

There is the laugh test. Why would anyone pay for software if there
was not some implied claim it would do something useful? Perhaps you
nail vendors on deceptive advertising.

What is cute though is Microsoft seems way ahead of me on this one.
You might never guess from their ads that their product is software.
You would think it was some mood-elevating mildly-hallucinogenic drug.
I suppose though that might be a very easy claim to prove is false.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: software lawsuits

[Otis Bricker]

Roedy Green <roedy@mindprod.com> wrote in 
news:g2gditckvnpov9m2hff4o5l6evpapccdl3@4ax.com:

> On Tue, 12 Jun 2001 08:34:20 -0500, "Dale King" <KingD@TCE.com> wrote
> or quoted :
> 
>>And I have never seen a license agreement that you
>>could skip by without actually making a conscious effort to say that you
>>accept the agreement. 
>  
>

WHen did license stuff start?

I better pay more attention and stop letting my 9 year old daughter handle 
all of my system adminitration. I just tell her what I need and she 
installs it all for me. I am so grateful that the system is easy enough 
that my 9 years old(cannot enter into a legally binding agreement because 
of her age) daughter could learn to use it.

Otis B.

Re: software suits, was Re: Long names are doom ?

[Dale King]

<tmoran@acm.org> wrote in message
news:Kk6V6.82266$%i7.62035400@news1.rdc1.sfba.home.com...
> >Unfortunately, a software lawsuit would have little ground to stand on.
> >Imagine if McDonald's required all customers who order hot coffee to sign
an
> >agreement before they are given the coffee where they acknowledge that
the
> >...
> >agreement: "IBM does not warrant uninterrupted or error-free operation of
>   If my doctor used that IBM software and harmed me, I would sue the
> doctor *and* IBM.  If IBM then wants to sue the doctor for improperly
> using their clearly labeled dangerous software, that's between them and
> the doctor.  If my car crashed because of a software glitch I'd sue the
> car company, whether they created the buggy software themselves or
> bought it from IBM.  And if my doctor or auto dealer said I'd have to
> sign a "hold harmless" agreement, I'd go elsewhere.

Note that I didn't say that there is no grounds for a lawsuit, just very
reduced grounds. Yes, in extreme cases of negligence on the part of the
software companies when selling an application for a life-threatening
application (the term we use around here is a heart-lung machine as in the
software does not have to be perfect since it is not a heart-lung machine).
But in general it would be very difficult to sue when you agreed  that the
software might not work. If Word crashes and you lose 6 months worh of work,
can you sue and win? Not likely.

Re: software suits, was Re: Long names are doom ?

[James Kanze]

Dale King wrote:

> <tmoran@acm.org> wrote in message
> news:Kk6V6.82266$%i7.62035400@news1.rdc1.sfba.home.com...
> > >Unfortunately, a software lawsuit would have little ground to
> > >stand on.  Imagine if McDonald's required all customers who order
> > >hot coffee to sign an agreement before they are given the coffee
> > >where they acknowledge that the ...
> > >agreement: "IBM does not warrant uninterrupted or error-free
> > >operation of

> >   If my doctor used that IBM software and harmed me, I would sue
> > the doctor *and* IBM.  If IBM then wants to sue the doctor for
> > improperly using their clearly labeled dangerous software, that's
> > between them and the doctor.  If my car crashed because of a
> > software glitch I'd sue the car company, whether they created the
> > buggy software themselves or bought it from IBM.  And if my doctor
> > or auto dealer said I'd have to sign a "hold harmless" agreement,
> > I'd go elsewhere.

> Note that I didn't say that there is no grounds for a lawsuit, just
> very reduced grounds. Yes, in extreme cases of negligence on the
> part of the software companies when selling an application for a
> life-threatening application (the term we use around here is a
> heart-lung machine as in the software does not have to be perfect
> since it is not a heart-lung machine).  But in general it would be
> very difficult to sue when you agreed that the software might not
> work. If Word crashes and you lose 6 months worh of work, can you
> sue and win? Not likely.

I don't think that grounds only exist in the case of negligence, nor
in the case of critical systems.  The difference of power in the two
parties can provide grounds, as can general consumer protection laws.

In the case of software, the grounds are at least partitially
mitigated by the fact that this is the general state.
Ford/Bridgestone are required to replace a lot of tires because the
normal situation is that the tires aren't a problem.  No court would
require that they provide tires better than what you might reasonably
expect.  And what you reasonably expect is at least partially
determined by what is being offered.

If I sell a "word processor" which simply ignores all input, I'm
pretty sure that you could prosecute me regardless of what license
you'd clicked.  If it generally worked, however, and just crashed a
couple of times a day, well -- that's what a reasonable person
expects, isn't it?

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: software suits, was Re: Long names are doom ?

[Dale King]

"James Kanze" <James.Kanze@dresdner-bank.com> wrote in message
news:3B272435.B01F9F05@dresdner-bank.com...
> Dale King wrote:
>
> If I sell a "word processor" which simply ignores all input, I'm
> pretty sure that you could prosecute me regardless of what license
> you'd clicked.  If it generally worked, however, and just crashed a
> couple of times a day, well -- that's what a reasonable person
> expects, isn't it?

You could make a warranty claim if it did not work, which would mean you
could get your money back, but that is quite different than suing for
damages.



--
 Dale King

Re: Long names are doom ?

[James Kanze]

Dale King wrote:

> Unfortunately, a software lawsuit would have little ground to stand
> on.  Imagine if McDonald's required all customers who order hot
> coffee to sign an agreement before they are given the coffee where
> they acknowledge that the coffee is hot and can cause burns and that
> the customer assumes all responsibility for the proper handling of
> the coffee. If you got burnt from the coffee would you be able to
> win a suit agains McDonald's? Not likely, since you agreed to accept
> the responsibility.

Did you sign such an agreement when you bought your software?

> Read most software license agreements and you'll find that most are
> like my hypothetical coffee agreement. Here is a sample from an IBM
> license agreement: "IBM does not warrant uninterrupted or error-free
> operation of the Program or that we will correct all Program
> defects. You are responsible for the results obtained from the use
> of the Program." And since "IBM WILL LICENSE THE PROGRAM TO YOU ONLY
> IF YOU FIRST ACCEPT THE TERMS OF THIS AGREEMENT. " then you don't
> really have a legal leg to stand on. They even have clauses limiting
> their liability.

Can you read this agreement before purchasing?  If you aren't in
agreement, can you get a refund?

A license agreement is a contract.  It only exists if both parties are
in agreement.  IBM (or MS, or whoever) can say whatever they want, but
they cannot hold you to it unless you actively agree as well.  What
they are doing is about the same as if I added words at the bottom of
my posting, stating that the information within it is licensed, and by
reading the posting, you agree to pay me a consulting fee.

I don't know what the situation is in America, but I'm pretty sure
having read of a case here in Europe where such "licenses" were held
to be non-binding, because they lacked the informed agreement of one
of the parties.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Shrink-wrap licenses (was: Long names are doom ?)

[Ted Dennison]

In article <3B25D5FB.15C9B240@dresdner-bank.com>, James Kanze says...
>
>I don't know what the situation is in America, but I'm pretty sure
>having read of a case here in Europe where such "licenses" were held
>to be non-binding, because they lacked the informed agreement of one
>of the parties.

The situation here is that software companies do realize that they are skating
on thin legal ice, so they are making huge investments in lobbiests and
politicians to try and change the legal landscape so that there is no doubt that
such licenses are enforcable. They are meeting a great deal of resistance from
lawyers (the ones they haven't paid) and civil liberties groups, but the general
public is used to ignoring those groups (the public *loves* executions, which
both groups are overwhelmingly aginst). There's one law in particular that
software publishers are trying to pass through each state's legislature that
would make both shrinkwrap and click-through licenses legally binding. So far
they've pushed it through 2 (of 50). Both states thought the proposed law was so
hideous that they had to "improve" it some first, but they should still be
ashamed of themselves for passing it. Neither state has a significant
shrink-wrap software industry, so they essentially sold out their own citizens
for *nothing* in return.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Dan Mercer]

In article <3B25D5FB.15C9B240@dresdner-bank.com>,
James Kanze <James.Kanze@dresdner-bank.com> writes:
> Dale King wrote:
> 
>> Unfortunately, a software lawsuit would have little ground to stand
>> on.  Imagine if McDonald's required all customers who order hot
>> coffee to sign an agreement before they are given the coffee where
>> they acknowledge that the coffee is hot and can cause burns and that
>> the customer assumes all responsibility for the proper handling of
>> the coffee. If you got burnt from the coffee would you be able to
>> win a suit agains McDonald's? Not likely, since you agreed to accept
>> the responsibility.
> 
> Did you sign such an agreement when you bought your software?

The agreement is part of the installation process.  You can't
install the software unless you agree to the license terms.
This constitutes a legal "acceptance".

-- 
Dan Mercer
damercer@mmm.com

> 
>> Read most software license agreements and you'll find that most are
>> like my hypothetical coffee agreement. Here is a sample from an IBM
>> license agreement: "IBM does not warrant uninterrupted or error-free
>> operation of the Program or that we will correct all Program
>> defects. You are responsible for the results obtained from the use
>> of the Program." And since "IBM WILL LICENSE THE PROGRAM TO YOU ONLY
>> IF YOU FIRST ACCEPT THE TERMS OF THIS AGREEMENT. " then you don't
>> really have a legal leg to stand on. They even have clauses limiting
>> their liability.
> 
> Can you read this agreement before purchasing?  If you aren't in
> agreement, can you get a refund?
> 
> A license agreement is a contract.  It only exists if both parties are
> in agreement.  IBM (or MS, or whoever) can say whatever they want, but
> they cannot hold you to it unless you actively agree as well.  What
> they are doing is about the same as if I added words at the bottom of
> my posting, stating that the information within it is licensed, and by
> reading the posting, you agree to pay me a consulting fee.
> 
> I don't know what the situation is in America, but I'm pretty sure
> having read of a case here in Europe where such "licenses" were held
> to be non-binding, because they lacked the informed agreement of one
> of the parties.
> 

Re: Long names are doom ?

[Marin David Condic]

That's the part that gets legally questionable. In normal contract law,
there are many aspects that ride on your ability to inspect the goods for
sale. Do the goods match up with what is contracted? Are the goods
non-conforming? Have you accepted non-conforming goods sent by the seller in
leu of conforming goods? If I can't possibly inspect the software without
first installing it, how can the act of installing it constitute acceptance?
The whole thing is on legally shakey grounds.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Dan Mercer" <damercer@mmm.com> wrote in message
news:9g5as6$hbq$1@magnum.mmm.com...
>
> The agreement is part of the installation process.  You can't
> install the software unless you agree to the license terms.
> This constitutes a legal "acceptance".
>

Re: Long names are doom ?

[Dan Mercer]

In article <9g5ipg$roq$1@nh.pace.co.uk>,
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> That's the part that gets legally questionable. In normal contract law,
> there are many aspects that ride on your ability to inspect the goods for
> sale. Do the goods match up with what is contracted? Are the goods
> non-conforming? Have you accepted non-conforming goods sent by the seller in
> leu of conforming goods? If I can't possibly inspect the software without
> first installing it, how can the act of installing it constitute acceptance?
> The whole thing is on legally shakey grounds.

Considering the amount of legal talent applied to the problem,
I very much doubt they're on legally shakey grounds.   We could
debate the issue more,  but I would guess that the legal opinions
of amateurs are as amusing to lawyers as the depictions of
computers in the movies are to us.

-- 
Dan Mercer
damercer@mmm.com


> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> 
> "Dan Mercer" <damercer@mmm.com> wrote in message
> news:9g5as6$hbq$1@magnum.mmm.com...
>>
>> The agreement is part of the installation process.  You can't
>> install the software unless you agree to the license terms.
>> This constitutes a legal "acceptance".
>>
> 
> 
> 

Off Topic: Legal Issues In Software - was Re: Long names are doom ?

[Marin David Condic]

You have a point - obviously the legal questions need legal expertise. In a
class I had that was taught by a lawyer, he once posed this: "What do you
call the stupidest lawyer in the county?" (answer) "Your Honor!" - So not
everything is decided on the basis of some sort of logical algorithm. Good
to be aware of...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Dan Mercer" <damercer@mmm.com> wrote in message news:9g614i$at4>
>
> Considering the amount of legal talent applied to the problem,
> I very much doubt they're on legally shakey grounds.   We could
> debate the issue more,  but I would guess that the legal opinions
> of amateurs are as amusing to lawyers as the depictions of
> computers in the movies are to us.
>

Re: Long names are doom ?

[Roedy Green]

On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
quoted :

>Considering the amount of legal talent applied to the problem,
>I very much doubt they're on legally shakey grounds

The law in the US is just one part of the equation.  If even part of
the world community toughens the laws, you get the California effect.

E.g California creates stiffer emissions laws.  To play in that market
car makers must devise new technology to comply.  Eventually that
spins off to all jurisdictions.  It costs no more to do it right for
the other jurisdictions.

If Canada and Europe start demanding truth in advertising Americans
would immensely benefit.  It costs less to emit the good software to
everyone than maintain a separate buggy version.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Philip Anderson]

Roedy Green wrote:
> 
> If Canada and Europe start demanding truth in advertising Americans
> would immensely benefit.  It costs less to emit the good software to
> everyone than maintain a separate buggy version.

If Europe starts demanding anything which would cost US businesses
money, the US declares a trade war :-)


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Software Licensing (was: Long names are doom)

[Larry Kilgallen]

In article <enoditglutmp6d4bmlfaddt9qipf0n8cbp@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
> quoted :
> 
>>Considering the amount of legal talent applied to the problem,
>>I very much doubt they're on legally shakey grounds
> 
> The law in the US is just one part of the equation.  If even part of
> the world community toughens the laws, you get the California effect.
> 
> E.g California creates stiffer emissions laws.  To play in that market
> car makers must devise new technology to comply.  Eventually that
> spins off to all jurisdictions.  It costs no more to do it right for
> the other jurisdictions.
> 
> If Canada and Europe start demanding truth in advertising Americans
> would immensely benefit.  It costs less to emit the good software to
> everyone than maintain a separate buggy version.

In the US we are being told that gasoline is more expensive even though
there is lots in stock because variations in emissions control needs
across the nation mean wholesaler supplies of gasoline are not portable
to other regions.

Re: Long names are doom ?

[Marin David Condic]

I don't think that would work. The "California Effect" in all likelyhood is
going to be to drive business out of California. (Notice how California has
steadfastly produced stringent environmental regulations that have basically
made it impossible to build power plants or affordable housing. Now property
values are astronomical and electricity is in short supply. Net effect:
Businesses and individuals start looking for other places to live & work.)
The Law Of Unintended Consequences is what's going to get you here...

If (hypothetically) California were to produce stringent product liability
regulations on software and/or advertising laws, etc. that attempted to make
software manufacturers responsible for defects in quality and workmanship,
you'd likely see some strange effects. For example - a "gray market" - I
don't sell my software in California because of the liability - I sell it on
the Internet from the Caymen Islands. If I *do* sell it in California, the
price tag goes *way* up to cover all the liability lawsuits. Lots of things
would happen, but I don't think one of them would be better software across
the board - at least not any time soon. (and in the long run, I'll be dead!)

Better to rely on market forces for this kind of thing. If someone came out
with an equivalent to Micro$oft Office & made it more reliable & stable,
they'd have some advertising edge. "We - unlike our unnamed competitors whos
initials are "Micro$oft" - stand behind our product with the following
guarantee....." IOW, if it is *possible* to build a better mousetrap then
the answer is to *build* it and start selling it. The world will follow.
(Notice the threat posed to Micro$oft by Linux? Better moustrap? Path beaten
to the door? Markets can work to solve these problems.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:enoditglutmp6d4bmlfaddt9qipf0n8cbp@4ax.com...
> On 12 Jun 2001 21:21:22 GMT, damercer@mmm.com (Dan Mercer) wrote or
> quoted :
> The law in the US is just one part of the equation.  If even part of
> the world community toughens the laws, you get the California effect.
>
> E.g California creates stiffer emissions laws.  To play in that market
> car makers must devise new technology to comply.  Eventually that
> spins off to all jurisdictions.  It costs no more to do it right for
> the other jurisdictions.
>
> If Canada and Europe start demanding truth in advertising Americans
> would immensely benefit.  It costs less to emit the good software to
> everyone than maintain a separate buggy version.
>
>
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Ted Dennison]

In article <9g7r02$mni$1@nh.pace.co.uk>, Marin David Condic says...
>Better to rely on market forces for this kind of thing. If someone came out
>with an equivalent to Micro$oft Office & made it more reliable & stable,
>they'd have some advertising edge. "We - unlike our unnamed competitors whos

Its a fallacy that the market cares about quality. Sure users whine about lack
of it, once they get the product. But before that point, they just want the damn
product yesterday (and as cheap as possible), no matter how badly it works.
Mostly its us *developers* who care about quality. After all, who wants to spend
their life whole building shoddy crap? (Its rhetorical; please, don't answer.
:-) )

For a good reference on this subject read "Worse is Better" (
http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html )

It also provides a pretty good explanation of why C is more widely used than
pretty much every language whose group this thread is crossposted to.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

That seems to be a misunderstanding of markets. Seems a few years ago, GM,
Ford & Chrysler were having all sorts of hardships over "Quality" because
apparently, once "Quality" was available from another source, people were
staying away from American automakers in droves.

"Quality" means different things to different people at different times.
Sometimes "Quality" is a nice crystal Stubenware wineglass. Sometimes
"Quality" is an inexpensive Dixie cup that will hold water for a brief time
before failing. "Quality" is not synonymous with "never breaks". A
quick-and-dirty program that patches some disk problem for me at zero cost
can "break" in unusual conditions that I never produce & still be "Quality"

If market forces won't favor reliable software, I submit that this needs to
be demonstrated. Find an unreliable product with no competing reliable
product available. Produce a reliable product at a similar price and with
similar features and with a similar marketing budget. (IOW, all other
parameters held constant) Will the public purchase the Reliable product or
the P.O.S.?

I think if we duplicated the functionality of - say - Netscape, only wrote
it in Ada so that it didn't periodically lock up, core dump, etc., & made it
available under similar terms, it would probably become the browser of
choice. (Of course, my current copy of Explorer seems to be working with
more reliability than the version of Netscape I have, so there *is* a better
quality product in the market. Hard to test the theory unless AdaBrowser
(tm) is more reliable than that.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:kbLV6.6795$pb1.259296@www.newsranger.com...
> In article <9g7r02$mni$1@nh.pace.co.uk>, Marin David Condic says...
>
> Its a fallacy that the market cares about quality. Sure users whine about
lack
> of it, once they get the product. But before that point, they just want
the damn
> product yesterday (and as cheap as possible), no matter how badly it
works.
> Mostly its us *developers* who care about quality. After all, who wants to
spend
> their life whole building shoddy crap? (Its rhetorical; please, don't
answer.
> :-) )
>
> For a good reference on this subject read "Worse is Better" (
> http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html )
>
> It also provides a pretty good explanation of why C is more widely used
than
> pretty much every language whose group this thread is crossposted to.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Market pressures for more reliable software

[Roedy Green]

On Wed, 13 Jun 2001 12:22:43 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> Produce a reliable product at a similar price and with
>similar features and with a similar marketing budget.

The problem with software is you have to use it for at least a few
months to evaluate its quality and suitability FOR YOUR NEEDS. Adobe
may create some extremely good and expensive software, but their
packages could be overwhelming for a newbie.

BUT, by then it is too late. The vendor already has your money,
whether or not he has delivered a suitable, working product.

This problem with buying a pig in a poke greatly favours market
leaders who can afford advertising, and whose products will be
purchased by newcomers simply on name recognition. There is not enough
incentive for a market leader to produce a high quality product.

I see three ways around this:

1. try-before-you-buy which is becoming much more common.  Electronic
distribution lets you try several packages before making your final
decision.  My problem with the technique is software trials are TIME
limited rather than USE-limited.  I sometimes get sidetracked before
completing evaluating a package, then lose the right to examine it.

2. software rental.  You don't give the vendor all the money up front.
You can leave the vendor at any time and PUNISH him for not living up
to your expectations.

3. Consumer Reports so that new software is much less a pig in a poke.
General computer literacy should help along these lines too.  The new
generation coming up are not going to be such lambs lead to the
slaughter.
 

For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green says...
>
>This problem with buying a pig in a poke greatly favours market
>leaders who can afford advertising, and whose products will be
>purchased by newcomers simply on name recognition. There is not enough
>incentive for a market leader to produce a high quality product.
>
>I see three ways around this:
1..2..3..

4. Free Software. If it doesn't quite do what you want, you've lost nothing but
your evaluation time. Even better, you have more options than just trying
something else. You can fix it yourself to do what you want, or pay someone else
(preferably someone intamately familiar with the code) to do it for you.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Marin David Condic]

Yes, presuming the company that made the product is willing to go this
route. (Free in what sense?) They have to see their future income as coming
from selling support or other stuff if they are going to give away the
program. (Not all software has this potential - do people regularly buy
support for, say, a computer game?)

If they *sell* the program with the source code, you *do* have the option of
fixing it yourself - but there may be real good reasons why they don't fix
the bugs themselves. (If its crap code, it may be real hard or impossible to
fix.) So saying "Yeah, it's a turd, but you're welcome to polish it up for
yourself..." doesn't really get you out of it. They took your money and gave
you crap and had a little salve for their conscience because they gave you
the source.

Now there might be something to the notion of software developed under the
Ada Developer's Cooperative License (or similar) in that the guys who build
the code only get paid if the code gets used and sold. The only way for that
to work consistently is if what they wrote is reliable enough for other
developers to have confidence in it and reuse it. There is incentive to fix
and improve components rather than pitch them all and start from
bottom-dead-center as is often done in C/C++ consumer software development.
Its not like you can sell the code up front and say "Tough Noogies!" if it
turns out it sucks. So presuming someone builds "Ada$oft Works (tm)" in Ada
utilizing subsystems and components under the ADCL, it might increase the
probability that the end-product doesn't suck because a) the developers of
the code have a stake in its quality and b) its written in Ada which
improves the quality right there. Could it help?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:zeQV6.7400$pb1.285004@www.newsranger.com...
> In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green
says...
> 4. Free Software. If it doesn't quite do what you want, you've lost
nothing but
> your evaluation time. Even better, you have more options than just trying
> something else. You can fix it yourself to do what you want, or pay
someone else
> (preferably someone intamately familiar with the code) to do it for you.
>

RE: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.

Thank you for your kind words on the Ada Developer's Cooperative License.
Since you mentioned "or similar", I always have stated that what I wrote was
a draft. I would be gratified if others would enhance it.

I should explain that since a good part of my training is in biology, I
tried to create a system that would benefit from Darwinian selection or in
engineering terms feedback. Evolving a system with good feedback is an
excellent way to optimize. The combination of ASIS and the Ada package
structure offers the possibility of creating a market economy for software.
Or reverting to my biological training, we Ada mammals can destroy the
present software dinosaurs. We can develop a very low overhead distributed,
profitable, equitable software development system.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Wednesday, June 13, 2001 2:27 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Market pressures for more reliable software


Yes, presuming the company that made the product is willing to go this
route. (Free in what sense?) They have to see their future income as coming
from selling support or other stuff if they are going to give away the
program. (Not all software has this potential - do people regularly buy
support for, say, a computer game?)

If they *sell* the program with the source code, you *do* have the option of
fixing it yourself - but there may be real good reasons why they don't fix
the bugs themselves. (If its crap code, it may be real hard or impossible to
fix.) So saying "Yeah, it's a turd, but you're welcome to polish it up for
yourself..." doesn't really get you out of it. They took your money and gave
you crap and had a little salve for their conscience because they gave you
the source.

Now there might be something to the notion of software developed under the
Ada Developer's Cooperative License (or similar) in that the guys who build
the code only get paid if the code gets used and sold. The only way for that
to work consistently is if what they wrote is reliable enough for other
developers to have confidence in it and reuse it. There is incentive to fix
and improve components rather than pitch them all and start from
bottom-dead-center as is often done in C/C++ consumer software development.
Its not like you can sell the code up front and say "Tough Noogies!" if it
turns out it sucks. So presuming someone builds "Ada$oft Works (tm)" in Ada
utilizing subsystems and components under the ADCL, it might increase the
probability that the end-product doesn't suck because a) the developers of
the code have a stake in its quality and b) its written in Ada which
improves the quality right there. Could it help?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:zeQV6.7400$pb1.285004@www.newsranger.com...
> In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green
says...
> 4. Free Software. If it doesn't quite do what you want, you've lost
nothing but
> your evaluation time. Even better, you have more options than just trying
> something else. You can fix it yourself to do what you want, or pay
someone else
> (preferably someone intamately familiar with the code) to do it for you.
>

Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Marin David Condic]

Well, I'm grateful to you for sending me a copy of the license. I'm not sure
I understand it thoroughly or how the mechanics of it would work, but I like
the notion of being able to put software out for public consumption and
saying "Go ahead and use this freely - but if it starts to make a buck, give
me my cut..." Determining what the cut should be and how it is distributed
is unclear to me - but I think it would be attractive to offer developers a
piece of the action.

I'd like to hear from people interested in this - maybe there is some way to
get such a cooperative off the ground rather than just talk about it? (Lots
of us have made software available on the web - maybe we can figure out a
way to make it generate some $$$?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.992495488.13975.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
>
> Thank you for your kind words on the Ada Developer's Cooperative License.
> Since you mentioned "or similar", I always have stated that what I wrote
was
> a draft. I would be gratified if others would enhance it.
>
> I should explain that since a good part of my training is in biology, I
> tried to create a system that would benefit from Darwinian selection or in
> engineering terms feedback. Evolving a system with good feedback is an
> excellent way to optimize. The combination of ASIS and the Ada package
> structure offers the possibility of creating a market economy for
software.
> Or reverting to my biological training, we Ada mammals can destroy the
> present software dinosaurs. We can develop a very low overhead
distributed,
> profitable, equitable software development system.
>

RE: Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.

A good first step is to either have a birds of a feather meeting at SIGAda
2001 or if I am given the opportunity during a workshop on "Creating a
Symbiotic Relationship Between XML and Ada�. The software discussed during
this workshop could serve as the basis for future mainstream commercial
products.

As far as the mechanism is concerned, it is really a simple but imperfect
solution. The first assumption is that the sources for the commercial Ada
programs will be available. The second assumption is that an ASIS
application can be created that calculates the relative contribution of each
developer to a project. The third is that an imperfect, but predictable
objective calculation will be preferred by developers to individual,
expensive optimized negotiations. You may get less money; but, you will not
have to pay a lawyer and perhaps an accountant upfront. The second
assumption has the weakness that we can achieve a consensus on the relative
values of individual types of Ada source. This probably will need to include
some type of arbitration procedure.

The benefits are that individual software engineers are treated as investors
not, as Karl Marx aptly put it, as wage slaves. The benefit to the
capitalist entrepreneur is that for a small upfront cost, one has the chance
to become rich. I might note from previous business experience that the
capitalist should contribute significantly more than money and not be just a
passive investor.


-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Thursday, June 14, 2001 7:16 AM
To: comp.lang.ada@ada.eu.org
Subject: Ada Developer's Cooperative License (was) Re: Market pressures
for more reliable software


Well, I'm grateful to you for sending me a copy of the license. I'm not sure
I understand it thoroughly or how the mechanics of it would work, but I like
the notion of being able to put software out for public consumption and
saying "Go ahead and use this freely - but if it starts to make a buck, give
me my cut..." Determining what the cut should be and how it is distributed
is unclear to me - but I think it would be attractive to offer developers a
piece of the action.

I'd like to hear from people interested in this - maybe there is some way to
get such a cooperative off the ground rather than just talk about it? (Lots
of us have made software available on the web - maybe we can figure out a
way to make it generate some $$$?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.992495488.13975.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
>
> Thank you for your kind words on the Ada Developer's Cooperative License.
> Since you mentioned "or similar", I always have stated that what I wrote
was
> a draft. I would be gratified if others would enhance it.
>
> I should explain that since a good part of my training is in biology, I
> tried to create a system that would benefit from Darwinian selection or in
> engineering terms feedback. Evolving a system with good feedback is an
> excellent way to optimize. The combination of ASIS and the Ada package
> structure offers the possibility of creating a market economy for
software.
> Or reverting to my biological training, we Ada mammals can destroy the
> present software dinosaurs. We can develop a very low overhead
distributed,
> profitable, equitable software development system.
>

Re: Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Marin David Condic]

Well, assume for a minute that I write some code under ADCL and make it
available on the net. You pick it up and include it in your end product -
initially at no charge. My code (as measured by the ASIS tool) constitutes
10% of the overall product's source code. (No need to get into the fact that
some code is more valuable than others - no system can be perfect & if it
was *really* valuable, people would negotiate their own deals outside of
ADCL anyway.) To keep things simple:

You price your shrink-wrapped product at $100.
You sell 1000 units.

a) How much do I get?
b) Who do you write a check to so that I ultimately get paid?
c) How do I know that you didn't actually sell 10,000 units and are only
claiming 1000?

Change the scenario a little.

You now sell 1,000,000 at $10. (Wholesale or retail?) Do I still get the
same percentage even though your costs are now near totally in the
manufacture & distribution of the product, not in the engineering of it? You
might be making only a modest profit while taking an enormous risk, while I
sit back nearly risk free collecting X% of every retail sale? I could
imagine where 90% of the code came from ADCL sources and the entrepeneur who
pulled it all together only has 10% "glue" code involved - yet is still
stuck with all the production, marketing and distribution costs.

I suppose some models do exist: Musicians/Recording Artists get some
percentage of the sale of the "software" they author & record. It has to
sometimes be split among other musicians who contributed in a substantive
way to the software being sold. There's ASCAP as the clearinghouse for
paying/distributing the fees. The whole thing depends on basic honesty,
relatively low cost to be honest and the fear of how expensive it would be
to get caught cheating.

Another model is how people price out an RTOS like VxWorks or WinCE. Here
you're in effect buying the right to embed these things in your product the
same as if it were under ADCL (without source, maybe) and you have to pay
some sort of fee for each unit. Its a direct relationship between customer
and supplier, so no ASCAP-like thing is needed, but at least things like
volume discounts could be looked at as a model.

I don't think I would demand a *perfect* system for sharing in the success
of a software product, but my fear is that if the system is too unjust,
costly or difficult, it won't take long for most people to conclude that
they'd rather not have anything to do with it. I'd love to have 10% of Linux
being my code and have the right to some relative percentage of each unit
distributed by Red Hat, et alia, but would they have put any effort into
Linux as a commercial endeavor if the costs to be paid to me, et alia,
started becoming some major chunk of the overall fees charged? (Maybe there
needs to be some sort of "Volume Discount" built into it so that the fees
decrease roughly at the same rate that the engineering costs dilute over the
production run? Otherwise a company will just swollow the cost of
engineering whole - reinventing the wheel - rather than use the resources
available under ADCL.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.992544799.21844.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
>
> A good first step is to either have a birds of a feather meeting at SIGAda
> 2001 or if I am given the opportunity during a workshop on "Creating a
> Symbiotic Relationship Between XML and Ada". The software discussed during
> this workshop could serve as the basis for future mainstream commercial
> products.
>
> As far as the mechanism is concerned, it is really a simple but imperfect
> solution. The first assumption is that the sources for the commercial Ada
> programs will be available. The second assumption is that an ASIS
> application can be created that calculates the relative contribution of
each
> developer to a project. The third is that an imperfect, but predictable
> objective calculation will be preferred by developers to individual,
> expensive optimized negotiations. You may get less money; but, you will
not
> have to pay a lawyer and perhaps an accountant upfront. The second
> assumption has the weakness that we can achieve a consensus on the
relative
> values of individual types of Ada source. This probably will need to
include
> some type of arbitration procedure.
>
> The benefits are that individual software engineers are treated as
investors
> not, as Karl Marx aptly put it, as wage slaves. The benefit to the
> capitalist entrepreneur is that for a small upfront cost, one has the
chance
> to become rich. I might note from previous business experience that the
> capitalist should contribute significantly more than money and not be just
a
> passive investor.
>

RE: Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.

I will try to answer your questions. However, yours or others' answers are
equally relevant. I definitely do not wish to be the sole author of the
final license.

1) The royalties are paid after the supplier of the software is paid.
Somewhere between 30 to 90 days after the money from the sale has been
received. Traditionally, net at 90 days and some minor discount if the
royalties are paid earlier.

2) The royalties are based on the total price paid to the developing
organization. If the developing organization distributes directly, they
should have a lower rate than if they distribute via intermediates. It also
depends on who pays for the advertising. I do believe that the total royalty
rate has to be announced upfront by the developing organization. To simplify
matters, I will assume that the product is distributed directly by the
developing organization and that it does not have a significant advertising
budget. I would then guesstemate that the total royalty rate would be on 25%
of the net of the sales. Items, such as shipping and sales tax, have to be
subtracted first. I should note that I am R&D Vice President of my company
and am not one of the individuals who would actually set this rate.

Given my assumptions, I can now answer your questions.


1) My (MDC) code  (as measured by the ASIS tool) constitutes
10% of the overall product's source code.

You price your shrink-wrapped product at $100.
You sell 1000 units.

a) How much do I get?
100 * 1,000 *0.25 * 0.10 = 2,500. This is based on the assumption that code
includes design, testing software, and actual testing.

b) When do you write a check to so that I ultimately get paid?
30 to 90 days after receipt of payment from the customer.

c) How do I know that you didn't actually sell 10,000 units and are only
claiming 1000?

This question is totally independent of the proposed royalty scheme. The
licenses for my patents include the right to have an accountant audit the
licensees' books concerning sales of my products. The Developers' consortium
could have this right.

2) You now sell 1,000,000 at $10. (Wholesale or retail?) Do I still get the
same percentage even though your costs are now near totally in the
manufacture & distribution of the product, not in the engineering of it?

Yes, because you are an investor. Others might believe that the royalty rate
should decrease. However, in the real world, these sales will require an
upgrade. Therefore your relationship with the developing organization must
be maintained. However, the developing organization has the right to replace
any of your code provided it does not infringe on your copyright.

3) The whole thing depends on basic honesty,
relatively low cost to be honest and the fear of how expensive it would be
to get caught cheating.

Yes! And it would be very expensive if one cheated. The pool of developers
would dry up and the authors of the Ada source would loose interest in
maintaining it.

I essentially agree with your other statements below. The bottom line is
that we can use Ada technology to promote Ada and be justly rewarded for our
effort.



-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Thursday, June 14, 2001 2:10 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Ada Developer's Cooperative License (was) Re: Market
pressures for more reliable software


Well, assume for a minute that I write some code under ADCL and make it
available on the net. You pick it up and include it in your end product -
initially at no charge. My code (as measured by the ASIS tool) constitutes
10% of the overall product's source code. (No need to get into the fact that
some code is more valuable than others - no system can be perfect & if it
was *really* valuable, people would negotiate their own deals outside of
ADCL anyway.) To keep things simple:

You price your shrink-wrapped product at $100.
You sell 1000 units.

a) How much do I get?
b) Who do you write a check to so that I ultimately get paid?
c) How do I know that you didn't actually sell 10,000 units and are only
claiming 1000?

Change the scenario a little.

You now sell 1,000,000 at $10. (Wholesale or retail?) Do I still get the
same percentage even though your costs are now near totally in the
manufacture & distribution of the product, not in the engineering of it? You
might be making only a modest profit while taking an enormous risk, while I
sit back nearly risk free collecting X% of every retail sale? I could
imagine where 90% of the code came from ADCL sources and the entrepeneur who
pulled it all together only has 10% "glue" code involved - yet is still
stuck with all the production, marketing and distribution costs.

I suppose some models do exist: Musicians/Recording Artists get some
percentage of the sale of the "software" they author & record. It has to
sometimes be split among other musicians who contributed in a substantive
way to the software being sold. There's ASCAP as the clearinghouse for
paying/distributing the fees. The whole thing depends on basic honesty,
relatively low cost to be honest and the fear of how expensive it would be
to get caught cheating.

Another model is how people price out an RTOS like VxWorks or WinCE. Here
you're in effect buying the right to embed these things in your product the
same as if it were under ADCL (without source, maybe) and you have to pay
some sort of fee for each unit. Its a direct relationship between customer
and supplier, so no ASCAP-like thing is needed, but at least things like
volume discounts could be looked at as a model.

I don't think I would demand a *perfect* system for sharing in the success
of a software product, but my fear is that if the system is too unjust,
costly or difficult, it won't take long for most people to conclude that
they'd rather not have anything to do with it. I'd love to have 10% of Linux
being my code and have the right to some relative percentage of each unit
distributed by Red Hat, et alia, but would they have put any effort into
Linux as a commercial endeavor if the costs to be paid to me, et alia,
started becoming some major chunk of the overall fees charged? (Maybe there
needs to be some sort of "Volume Discount" built into it so that the fees
decrease roughly at the same rate that the engineering costs dilute over the
production run? Otherwise a company will just swollow the cost of
engineering whole - reinventing the wheel - rather than use the resources
available under ADCL.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.992544799.21844.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
>
> A good first step is to either have a birds of a feather meeting at SIGAda
> 2001 or if I am given the opportunity during a workshop on "Creating a
> Symbiotic Relationship Between XML and Ada". The software discussed during
> this workshop could serve as the basis for future mainstream commercial
> products.
>
> As far as the mechanism is concerned, it is really a simple but imperfect
> solution. The first assumption is that the sources for the commercial Ada
> programs will be available. The second assumption is that an ASIS
> application can be created that calculates the relative contribution of
each
> developer to a project. The third is that an imperfect, but predictable
> objective calculation will be preferred by developers to individual,
> expensive optimized negotiations. You may get less money; but, you will
not
> have to pay a lawyer and perhaps an accountant upfront. The second
> assumption has the weakness that we can achieve a consensus on the
relative
> values of individual types of Ada source. This probably will need to
include
> some type of arbitration procedure.
>
> The benefits are that individual software engineers are treated as
investors
> not, as Karl Marx aptly put it, as wage slaves. The benefit to the
> capitalist entrepreneur is that for a small upfront cost, one has the
chance
> to become rich. I might note from previous business experience that the
> capitalist should contribute significantly more than money and not be just
a
> passive investor.
>

Re: Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Marin David Condic]

Thanks for the reply. That clarifies a lot. Basically, if I understand you
correctly, the royalty would be 25% of gross sales, discounted by the
percentage of the contribution. I think that might be a little steep to keep
it attractive for an entrepeneur to want to use the code, but it is a number
to be kicked around. (Gotta find that balance where MC = MR!) I'd suggest
looking at typical royalty rates for things like books, music, movies, or
other types of "software" in which one party acts as a writer and another
party acts as a publisher. (What percentage of gross sales does Stephen King
get for a book he writes? What about lesser known writers? I don't see a
situation where the rate is constantly sliding or changes depending on who
wrote the code or what the subsystem is all about - it would just get too
complicated for anyone to want to deal with & they'd throw up their hands in
disgust and go write it themselves. Or do you see integrators negotiating
rates with individual writers over each piece of code they use?)

I'd still be concerned about the collection of royalties. In a one-to-one
relationship, the integrator of my software and I can negotiate the deal &
have the integrator send me a check once a quarter if that is convenient to
both of us. In a case where the integrator may have 90% of the code coming
from ADCL sources and there might be dozens of individual authors involved,
it would be difficult for the integrator to have relationships with all the
authors & track all the necessary payments. Likewise for the writers, they
wouldn't necessarily want to get hundreds of small checks from hundreds of
sources & track who should be making the payments. That kind of implies to
me a clearinghouse of some sort that gets some kind of dues and/or
transaction fees - as well as maintaining the ASIS tools needed to establish
the measurement metrics.

I would be interested in seeing how this could work. I'm thinking that it
ought to be possible to take some body of useful code and write some version
of the ADCL to put with it. It could be put on a website & see if anyone
bites. Would it get used? Would anyone start sending in checks - or even
bothering to contact the author? I'd bet that if *somebody* started making
even a *modest* amount of money distributing their software under these
terms, it would start breeding more writers. The question would be are there
enough integrators out there willing to use the code under those terms? No
way to really tell unless there is an actual experiment.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.992577440.29640.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
>
> I will try to answer your questions. However, yours or others' answers are
> equally relevant. I definitely do not wish to be the sole author of the
> final license.
>
> 1) The royalties are paid after the supplier of the software is paid.
> Somewhere between 30 to 90 days after the money from the sale has been
> received. Traditionally, net at 90 days and some minor discount if the
> royalties are paid earlier.
>
> 2) The royalties are based on the total price paid to the developing
> organization. If the developing organization distributes directly, they
> should have a lower rate than if they distribute via intermediates. It
also
> depends on who pays for the advertising. I do believe that the total
royalty
> rate has to be announced upfront by the developing organization. To
simplify
> matters, I will assume that the product is distributed directly by the
> developing organization and that it does not have a significant
advertising
> budget. I would then guesstemate that the total royalty rate would be on
25%
> of the net of the sales. Items, such as shipping and sales tax, have to be
> subtracted first. I should note that I am R&D Vice President of my company
> and am not one of the individuals who would actually set this rate.
>
> Given my assumptions, I can now answer your questions.
>
>
> 1) My (MDC) code  (as measured by the ASIS tool) constitutes
> 10% of the overall product's source code.
>
> You price your shrink-wrapped product at $100.
> You sell 1000 units.
>
> a) How much do I get?
> 100 * 1,000 *0.25 * 0.10 = 2,500. This is based on the assumption that
code
> includes design, testing software, and actual testing.
>
> b) When do you write a check to so that I ultimately get paid?
> 30 to 90 days after receipt of payment from the customer.
>
> c) How do I know that you didn't actually sell 10,000 units and are only
> claiming 1000?
>
> This question is totally independent of the proposed royalty scheme. The
> licenses for my patents include the right to have an accountant audit the
> licensees' books concerning sales of my products. The Developers'
consortium
> could have this right.
>
> 2) You now sell 1,000,000 at $10. (Wholesale or retail?) Do I still get
the
> same percentage even though your costs are now near totally in the
> manufacture & distribution of the product, not in the engineering of it?
>
> Yes, because you are an investor. Others might believe that the royalty
rate
> should decrease. However, in the real world, these sales will require an
> upgrade. Therefore your relationship with the developing organization must
> be maintained. However, the developing organization has the right to
replace
> any of your code provided it does not infringe on your copyright.
>
> 3) The whole thing depends on basic honesty,
> relatively low cost to be honest and the fear of how expensive it would be
> to get caught cheating.
>
> Yes! And it would be very expensive if one cheated. The pool of developers
> would dry up and the authors of the Ada source would loose interest in
> maintaining it.
>
> I essentially agree with your other statements below. The bottom line is
> that we can use Ada technology to promote Ada and be justly rewarded for
our
> effort.
>

Re: Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Colin Paul Gloster]

Bob Leif said:
"[..] or if I am given the opportunity during a workshop on "Creating a
Symbiotic Relationship Between XML and Ada". [..] The second assumption
is that an ASIS [..]"

On SIGADA-ASIS@ACM.org in the thread "Re: proposed ASIS-based tool"
did Erhard Pl�dereder not claim in his email timestamped
Thu, 3 May 2001 18:08:24 +0200 :
"I have some limited exposure to an actual implementation using XML in a
context where a semantically attributed intermediate language is mapped onto
XML.

XML turned out to be a "very fat" representation, i.e., the files get
rather large (consider this a European understatement -- it was barely
ok to do a proof-of-concept; a tool of practical use it was not in this
context)

[..]"? Perhaps XML is not practical in other contexts too.

RE: Ada Developer's Cooperative License (was) Re: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Colin Paul Gloster et al.
Although, it is quite correct that, "XML turned out to be a "very fat"
representation, i.e., the files get rather large (consider this a European
understatement", Microsoft Excel can now function in XML mode. This and the
rush of the other vendors to XML proves that XML is here to stay. I might
note that my own interest, Analytical Cytology, employs very large data
files. The simple solution for large binary data is to create an XML binary
form based upon an already existing data type. The description of the data,
patient, instrument, etc. can be left in somewhat bloated XML text files.

The important facts are: 1) XML is controlled by the World Wide Web
Consortium, W3C. 2) XML includes sufficient capabilities for a portable GUI
and printing. and 3) XML is a reasonable standard will a good mapping to
Ada. I will note that control by W3C www.w3.org is infinitely preferable to
proprietary standards imposed by companies such as Microsoft, SUN, or IBM.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Colin Paul Gloster
Sent: Thursday, June 21, 2001 12:12 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Ada Developer's Cooperative License (was) Re: Market
pressures for more reliable software


Bob Leif said:
"[..] or if I am given the opportunity during a workshop on "Creating a
Symbiotic Relationship Between XML and Ada". [..] The second assumption
is that an ASIS [..]"

On SIGADA-ASIS@ACM.org in the thread "Re: proposed ASIS-based tool"
did Erhard Pl�dereder not claim in his email timestamped
Thu, 3 May 2001 18:08:24 +0200 :
"I have some limited exposure to an actual implementation using XML in a
context where a semantically attributed intermediate language is mapped onto
XML.

XML turned out to be a "very fat" representation, i.e., the files get
rather large (consider this a European understatement -- it was barely
ok to do a proof-of-concept; a tool of practical use it was not in this
context)

[..]"? Perhaps XML is not practical in other contexts too.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9g8lrk$37c$1@nh.pace.co.uk>, Marin David Condic says...
>
>Yes, presuming the company that made the product is willing to go this
>route. (Free in what sense?) They have to see their future income as coming
>from selling support or other stuff if they are going to give away the
>program. (Not all software has this potential - do people regularly buy
>support for, say, a computer game?)

When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
Software".

Nearly all software is already developed as custom software under a system where
the deveopers are paid for the development. That includes *every* project I've
ever worked on in my career. Even for most of the "licensed" commercial software
I deal with, the "support" is the most expensive part. So using Free Software
models wouldn't even noticably impact the vast majority of the software
developed.

Of course this skirts around the issue that the small minority of software left
actually gets distributed the most. But there are still ways to make money using
Free Software in that realm. RedHat has shown that. They just won't make nearly
as *much* money as they would if they could somehow charge a toll on each copy.

You bring up games. To answer your question directly, yes people *do* pay for
"support" for games. 900-number "hint lines" for adventure games are not unheard
of. Also, nearly every game company has some kind of customer support (the money
to pay for for that obviously comes from game sales, so you can think of it as
sort of a "support tax"). 

I've played computer games avidly for over 20 years (since back when games were
distributed in compliation books as BASIC source code). So I have thought about
this a lot. For a computer game, what I'd try to sell is the manual. There's
already a racket going where the shipped manuals are useless, and anyone who
wants to know what's really going on buys a "game guide". They might as well
make it official. I also collect the boxes, and on one glorious occasion, got
one autographed by the heads of the development team (Sid Meyer, Brian Reynolds,
et al). So I'm quite confident that people would still pay for an official
"hard" copy (perhaps even more for a hand-autographed one).

>Now there might be something to the notion of software developed under the
>Ada Developer's Cooperative License (or similar) in that the guys who build
>the code only get paid if the code gets used and sold. The only way for that

That might work out OK in a world of mass-produced shrink-wrapped software. But
remember paragraph 1: the vast majority of software *developed* does not fit
that mold. In the world in which I work, I can't use any nifty routine that's
going to add to the system's costs, because *I* don't get to make those kinds of
decisions. The folks that do are my managager's manager, who's already obsessing
about overruns, and the paper-pushers off in accounting, who require all sorts
of paperwork and market research and competitive sourcing and several weeks to
make any kind of decision (You should see us trying to buy a PC video card
before it goes obsolete. Its sad, really). Unless we are talking some pretty
significant functionality, its far easier for me to just rewrite it all myself
(and what a shameful waste of human effort that is!). 

So that license might get some lucky package shipped in lots of software copies.
But for the vast majority of *developers*, its just going to render the package
useless.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Marin David Condic]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:jK3W6.8329$pb1.316095@www.newsranger.com...
> In article <9g8lrk$37c$1@nh.pace.co.uk>, Marin David Condic says...
> When I capitalize "Free", its to indicate that I'm talking about FSF-style
"Free
> Software".
>
Yeah, but even under FSF, I can *sell* you the program - I just have to give
you the source as well. That was my point.


> Nearly all software is already developed as custom software under a system
where
> the deveopers are paid for the development. That includes *every* project
I've
> ever worked on in my career. Even for most of the "licensed" commercial
software
> I deal with, the "support" is the most expensive part. So using Free
Software
> models wouldn't even noticably impact the vast majority of the software
> developed.
>
Custom software isn't where I'm worried about the quality. You get what you
pay for there. If you want something that runs forever and never crashes,
you pay for the quality steps involved. Where I think there is an issue is
with shrink-wrap products that you just either have to buy or ignore and
accept whatever it is you get.


> You bring up games. To answer your question directly, yes people *do* pay
for
> "support" for games. 900-number "hint lines" for adventure games are not
unheard
> of. Also, nearly every game company has some kind of customer support (the
money
> to pay for for that obviously comes from game sales, so you can think of
it as
> sort of a "support tax").
>
I was simply trying to illustrate that there are a lot of off-the-shelf
products purchased that you install, use and never go back to the company
for anything. Not even upgrades. Maybe there is some percentage of the
population that will want some kind of support, but probably most of the
people who have "Space Invaders" or "Pong" aren't paying for that. How does
the company make money if they don't charge for the software? If things like
that need to have higher reliability, there has to be some kind of market
pressure to do so.


> >Now there might be something to the notion of software developed under
the
> >Ada Developer's Cooperative License (or similar) in that the guys who
build
> >the code only get paid if the code gets used and sold. The only way for
that
>
> That might work out OK in a world of mass-produced shrink-wrapped
software. But
> remember paragraph 1: the vast majority of software *developed* does not
fit
> that mold. In the world in which I work, I can't use any nifty routine
that's
> going to add to the system's costs, because *I* don't get to make those
kinds of
> decisions. The folks that do are my managager's manager, who's already
obsessing
> about overruns, and the paper-pushers off in accounting, who require all
sorts
> of paperwork and market research and competitive sourcing and several
weeks to
> make any kind of decision (You should see us trying to buy a PC video card
> before it goes obsolete. Its sad, really). Unless we are talking some
pretty
> significant functionality, its far easier for me to just rewrite it all
myself
> (and what a shameful waste of human effort that is!).
>
Been there. Done that. I understand. I know it is hard to market
components - especially with restrictive licenses - especially to companies
building a custom product with limited sales potential. It typically has to
be some sort of major subsystem with well defined capabilities (databases?
graphics packages?) before anybody wants to include it in their product. I
don't know what the answer is. Perhaps there needs to be a variety of tiers
to the payment scheme that makes it *easy* for people to get into it, but if
there are any profits made from it, they give *something* to the developers
who contributed code to the project.


> So that license might get some lucky package shipped in lots of software
copies.
> But for the vast majority of *developers*, its just going to render the
package
> useless.
>
Even for the high-volume stuff, it gets problematic. Think about it. If I
sell "Ada$oft Works" to the general public with a worldwide distribution of
tens (hundreds?) of millions of copies, the *cost* is no longer in the
engineering - its in the stamping out of disks & manuals. I'm going to give
some geek in a garage 10% of each sale for having contributed 10% of the
code? Guess again! I'll *eat" the whole engineering cost because it falls
below the noise level. OTOH, if I have a product being custom built for some
govet. contract that maybe gets handed over to the govt for one lump sum,
suddenly getting me 10% of the way to completion in one transaction looks a
little more attractive. Especially if it is reliable, proven software.

There are still problems with the pricing structure that I think would need
to be worked out - just because I bill my customer $1m for 10,000 SLOCs and
you gave me 1,000 SLOCs doesn't mean I can still make a profit after giving
you $100,000. And then throw in all the complexities of accounting (ask
movie stars who sign up for a percentage of the profits how the studios can
make sure a picture *never* amkes a profit!). Its not an easy question.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9gaj53$nlp$1@nh.pace.co.uk>, Marin David Condic says...
>
>I was simply trying to illustrate that there are a lot of off-the-shelf
>products purchased that you install, use and never go back to the company
>for anything. Not even upgrades. Maybe there is some percentage of the
>population that will want some kind of support, but probably most of the
>people who have "Space Invaders" or "Pong" aren't paying for that. How does
>the company make money if they don't charge for the software? 

As I said, you don't *have* to stop charging for hard copies just because its
(capital 'F') Free, and there are actually lots of ways that those companies
*already* make money outside of charging for their software. (Starcraft even has
a line of dolls...er..."action figures" out). There are lots more things they
now do for free with the purchase price that folks would probably still pay for.


>... If things like
>that need to have higher reliability, there has to be some kind of market
>pressure to do so.

Ahh...that's the exact issue though. :-)  The way things are set up now, there
can be no market pressure for doing anything outside of pumping that baby out to
as many stores as possible as quickly as possible. If you move away from the
"copy toll" model, then suddenly you have to make your product good enough that
people will want a hard-copy that they can easily reinstall after hard-drive
wipes, etc. Suddenly you have an incentive to provide good hardcopy
documentation. Suddenly you have an incentive to continue to support the product
after initial release.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Gautier]

Marin David Condic:

> Even for the high-volume stuff, it gets problematic. Think about it. If I
> sell "Ada$oft Works" to the general public with a worldwide distribution of
[...]

BTW, there are at least two "Adasoft"s :
  http://www.adasoft.ch/   (you see their devices in lifts)
  http://www.adasoft.com/

G.

Re: Market pressures for more reliable software

[Marin David Condic]

Thanks for that info. In case anyone there is listening - I picked the name
strictly as a parody of Microsoft. Any relationship is purely coincidental.
:-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gautier" <gautier_niouzes@hotmail.com> wrote in message
news:17cd177c.0106150721.688aed8d@posting.google.com...
> Marin David Condic:
>
> > Even for the high-volume stuff, it gets problematic. Think about it. If
I
> > sell "Ada$oft Works" to the general public with a worldwide distribution
of
> [...]
>
> BTW, there are at least two "Adasoft"s :
>   http://www.adasoft.ch/   (you see their devices in lifts)
>   http://www.adasoft.com/
>
> G.

Re: Market pressures for more reliable software

[Wes Groleau]

> to be worked out - just because I bill my customer $1m for 10,000 SLOCs and
> you gave me 1,000 SLOCs doesn't mean I can still make a profit after giving

I need new glasses--but I never noticed before how much SLOCS looks like
SUCKS.
(Is Dr. Oliver listening?)


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[Ed Jensen]

In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
: When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
: Software".

Is anyone else annoyed that the FSF has decided to redefine the term
"free software" for marketing purposes?

I think I'll scoop up some doggie poo, put it in a bowl, and place a
sticker on it that says "Rose Petals".

-Ed, who thinks "Free Software" (GPL-style) is unethical.

Re: Market pressures for more reliable software

[Marin David Condic]

I'll second that notion. For better or worse, people have come to associate
the word "Free" as meaning "No $$$ Charged" when the word is connected to a
product. FSF wants to redefine it more to mean "Unrestricted Usage" - which
is *not* what most people think when they see the word. (Hence all the
confusion over "Free" meaning I can download it and evaluate it and it costs
me nothing but my time - not the case...) They probably should have used the
word "Open" as in "Open Architecture" or "Open Standard" or "Open Source" -
you can see inside and use it in any way you like - you might still have to
*pay* for it, but once you do, there are no unreasonable restrictions on its
use.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ed Jensen" <ejensen+usenet@tiny.net> wrote in message
news:tM4W6.14397$Dd5.3411079@ruti.visi.com...
> In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
> : When I capitalize "Free", its to indicate that I'm talking about
FSF-style "Free
> : Software".
>
> Is anyone else annoyed that the FSF has decided to redefine the term
> "free software" for marketing purposes?
>
> I think I'll scoop up some doggie poo, put it in a bowl, and place a
> sticker on it that says "Rose Petals".
>
> -Ed, who thinks "Free Software" (GPL-style) is unethical.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9ganmu$pj5$1@nh.pace.co.uk>, Marin David Condic says...
>
>I'll second that notion. For better or worse, people have come to associate
>the word "Free" as meaning "No $$$ Charged" when the word is connected to a
..
>me nothing but my time - not the case...) They probably should have used the
>word "Open" as in "Open Architecture" or "Open Standard" or "Open Source" -
>you can see inside and use it in any way you like - you might still have to
>*pay* for it, but once you do, there are no unreasonable restrictions on its
>use.
"Open" doesn't quite reach it, because there's no implication that the right to
redistribute is present, only the right to inspect.

"Liberated" is actually a little closer to what I think they were shooting for.
However, that word implies previous enslavement, which isn't quite right either.
"Free" really has the perfect meaning. The only problem is that is has other
seprate meanings as well. :-(

Anyway, better minds than ours (OK, better than mine at least) have been all
over this nomenclature issue to exhaustion. I doubt we'll be able to fix it
here, short of switching this whole thread to French.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Charles Hixson]

Ted Dennison wrote:

> In article <9ganmu$pj5$1@nh.pace.co.uk>, Marin David Condic says...
> ...
> Anyway, better minds than ours (OK, better than mine at least) have been all
> over this nomenclature issue to exhaustion. I doubt we'll be able to fix it
> here, short of switching this whole thread to French.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com
> 

Well, I don't suppose that too many people would misunderstand if you 
said software libre (sorry about the missing accent, but I don't know 
how to type one wo switching to html).  Unfortunatly for the "liberated 
software" suggestion, that also has a couple of overloaded meanings that 
context couldn't disambiguate. (i.e., prior enslavement and theft). 
Liberty software would have the right meaning if it were the right part 
of speech.

My personal choice is, e.g., GPL software.  That's too specific to cover 
the entire field, however, as, e.g., BSD, Artistic, NPL, MPL, ... etc. 
are all parts of the set currently designated by the term "free 
software".  Freedom software?  Again the wrong part of speech.  Open 
Software designates another, larger, group of licenses.  The set "Open 
Software" properly contains the set "Free Software".

It matters not.  By this stage, nobody would be willing to change what 
they were calling things, and if they did, then it would just increase 
the confusion, as you can be sure that not everybody would switch.  But 
there is reason behind the choice of name.  It just wasn't centered on 
money.
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 17:55:40 GMT, Charles Hixson
<charleshixsn@earthlink.net> wrote or quoted :

>Unfortunatly for the "liberated 
>software" suggestion, that also has a couple of overloaded meanings that 
>context couldn't disambiguate

The first meaning that comes to mind from a child of the 70s would be
"stolen".


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Larry Elmore]

Roedy Green wrote:
> 
> On Thu, 14 Jun 2001 17:55:40 GMT, Charles Hixson
> <charleshixsn@earthlink.net> wrote or quoted :
> 
> >Unfortunatly for the "liberated
> >software" suggestion, that also has a couple of overloaded meanings that
> >context couldn't disambiguate
> 
> The first meaning that comes to mind from a child of the 70s would be
> "stolen".

Not just a "child of the '70s", but anyone who's served in the American
military in  the last half-century or more.

Larry

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 17:32:21 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>"Open" doesn't quite reach it, because there's no implication that the right to
>redistribute is present, only the right to inspect.

Let's see what we can come up with for a less ambiguous term for "free
software".

Basically the only right you have is to inspect the software. You may
still be restricted from selling it or modifying it. You may still
have to pay to look.

"white box" software as opposed to "black box" software is my top
choice.

The term has some unwanted NeXT connotations. It also might me
confused to mean generic cheap packaging.

some other possibilities:

"glass box"

"clear box"

"inspectable"

"uncovered"

"unveiled"

"glass coffin"

"source-visible"

"transparent"

"visible"

"disclosed"

"sheer"

"not opaque"

"overt"   

"unconcealed"

"unwrapped"

"icy"

"ice cubed"

"iced"

"porous"

"goldfish bowl"

"naked"

"nude"

"topless"



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Ted Dennison]

In article <jj5iitksq0v75aavlrqpouuq9rmmdepdjj@4ax.com>, Roedy Green says...
>
>Basically the only right you have is to inspect the software. You may
>still be restricted from selling it or modifying it. You may still
>have to pay to look.

Not true. That's only one of the 4 freedoms you have, and you may *not* be
restricted from selling or modifying it. "Free Software" is in fact defined by
the 4 rights you have. They are (this is mostly a direct quote):

0) The freedom to run the software for any purpose.
1) The freedom to study how the program works, and adapt it to your needs 
2) The freedom to redistribute copies.
3) The freedom to improve the program, and release your improvements to the
public.

Note this has nothing to say about how you got it in the first place. It also
says nothing about any freedom to combine it with other stuff and distribute
that.

(rights text taken from http://www.fsf.org/philosophy/free-sw.html )

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 21:43:25 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>0) The freedom to run the software for any purpose.
>1) The freedom to study how the program works, and adapt it to your needs 
>2) The freedom to redistribute copies.
>3) The freedom to improve the program, and release your improvements to the
>public.

Do (1) and (2) imply free in the ordinary sense? May I do this without
having to pay a fee to the originator?



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Joseph T. Adams]

In comp.lang.java.advocacy Roedy Green <roedy@mindprod.com> wrote:
: On Thu, 14 Jun 2001 21:43:25 GMT, Ted Dennison<dennison@telepath.com>
: wrote or quoted :

:>0) The freedom to run the software for any purpose.
:>1) The freedom to study how the program works, and adapt it to your needs 
:>2) The freedom to redistribute copies.
:>3) The freedom to improve the program, and release your improvements to the
:>public.

: Do (1) and (2) imply free in the ordinary sense?


I consider "freedom" far more important than "price," but both terms
are part of the ordinary meaning of "free" although the context
implies that you are referring to the second meaning ("price").

Nothing in any of these items implies "zero price," but item (3)
places a practical upper limit on how much can be charged, because
once you have the software, you are free to redistribute it with or
without a fee.  So can anyone else.  In practice, this means you can't
sell free software itself, although you can sell packaging, branding,
support, and services in connection with it.


: May I do this without
: having to pay a fee to the originator?

Absolutely yes, because if you didn't, then you would not have freedom
#3.

The person *distributing* the software might ask you for a fee.  He or
she has every right to do so.  Of course you also have the right to
find another distributor who might charge less, or perhaps even
nothing at all.


Joe

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9lhlit0pt6711apais5d9o1n07i7q7u15p@4ax.com>, Roedy Green says...
>
>On Thu, 14 Jun 2001 21:43:25 GMT, Ted Dennison<dennison@telepath.com>
>wrote or quoted :
>
>>0) The freedom to run the software for any purpose.
>>1) The freedom to study how the program works, and adapt it to your needs 
>>2) The freedom to redistribute copies.
>>3) The freedom to improve the program, and release your improvements to the
>>public.
>
>Do (1) and (2) imply free in the ordinary sense? 

I suppose that's ultimately a matter of opinion. But the alternative in the case
of #1 is that there is someone out there who makes it their business what I do
with the software in my own home on my own computer. The alternative in case #2
is that I cannot share certian information with my neighbor without breaking the
law. That sure doesn't make me *feel* free. 

This is of couse just a list of freedoms, so you could argue that it isn't
comprehensive enough to merit the title "free". But then you'd have to come up
with some important freedom that isn't a result of one of the listed freedoms. 

Some like to argue that you aren't *truly* free without the right to make your
own proprietary (non-Free) software out of the "free software". However, some
also like to argue that we in the US aren't truly free people, as we are
prohibited from selling ourselves into slavery. :-)  I believe the operative
principle in our case was that you have to take away some rights to ensure that
the rest will always remain. At least that's what I remember them telling me in
school.

>May I do this without having to pay a fee to the originator?
If you are not allowed to do any of the above without first paying someone a
toll, then no, you are not free to do so.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

RE: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Roedy Green et al.

The term "topless" should be reserved for when the specifications are given
in source and the rest is binary. I might note that this is a familiar and
very useful compromise employed by the Ada community.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Roedy Green
Sent: Thursday, June 14, 2001 1:10 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Market pressures for more reliable software


On Thu, 14 Jun 2001 17:32:21 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>"Open" doesn't quite reach it, because there's no implication that the
right to
>redistribute is present, only the right to inspect.

Let's see what we can come up with for a less ambiguous term for "free
software".

Basically the only right you have is to inspect the software. You may
still be restricted from selling it or modifying it. You may still
have to pay to look.

"white box" software as opposed to "black box" software is my top
choice.

The term has some unwanted NeXT connotations. It also might me
confused to mean generic cheap packaging.

some other possibilities:

"glass box"

"clear box"

"inspectable"

"uncovered"

"unveiled"

"glass coffin"

"source-visible"

"transparent"

"visible"

"disclosed"

"sheer"

"not opaque"

"overt"

"unconcealed"

"unwrapped"

"icy"

"ice cubed"

"iced"

"porous"

"goldfish bowl"

"naked"

"nude"

"topless"



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Wes Groleau]

> The term "topless" should be reserved for when the specifications are given
> in source and the rest is binary. I might note that this is a familiar and
> very useful compromise employed by the Ada community.

Isn't that more like "bottomless"

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[The Ghost In The Machine]

In comp.lang.java.advocacy, Roedy Green
<roedy@mindprod.com>
 wrote
on Thu, 14 Jun 2001 20:09:41 GMT
<jj5iitksq0v75aavlrqpouuq9rmmdepdjj@4ax.com>:
>On Thu, 14 Jun 2001 17:32:21 GMT, Ted Dennison<dennison@telepath.com>
>wrote or quoted :
>
>>"Open" doesn't quite reach it, because there's no implication that
>>the right to redistribute is present, only the right to inspect.
>
>Let's see what we can come up with for a less ambiguous term for "free
>software".

<voice mode=paranoia>

The FSF license is inherently viral.  While allowing for a number of
operations on the source code, the following requirements must
be met:

[1] The authors of previous modifications must be preserved.  You can of
    course put your name in there for your bug fixes -- in fact, you
    have to.

[2] The source code of the GPL portion must be available on a
    machine-readable medium to anyone who is sold the derived work.
    For example, if one uses the GNU-licensed readln library, one
    must make it available to anyone who uses your product.  (This
    in itself isn't too onerous, but...)

[3] If your work can be shown to be a derived work of the GPLed
    software, then the entire work must be published under the GPL.
    (Hence the term "viral".)  There might be some issues here, of
    course -- is a proprietary, sophisticated CAD program which
    happens to depend on the GNU readline library a "derived work"?
    Or merely a user of the readline library's functionality, which
    happens to solve a particular subproblem?

    Of course, if one takes, say, geda (which is a GNU-licensed
    CAD program), and modifies it by adding a sophisticated but minor
    input method (assuming it hasn't done such already), and releases
    it, then that is most definitely a derived work.  At least, I
    for one would think so...

</voice>

Of course, this may be a feature; one nice thing about GNU-licensed
stuff is that one does have the opportunity to inspect and if
necessary modify it, and then release the modifications back to the
pool.  With so many eyes, bugs can't hide too well, but there
is the issue that, if interest wanes, the software will have problems.
One might call it software evolution in action....

>
>Basically the only right you have is to inspect the software. You may
>still be restricted from selling it or modifying it. You may still
>have to pay to look.

I'm not sure how, unless you're talking about a different license
(e.g., the Sun Community-type deal).  Mozilla's license is also
slightly strange -- part of that might simply be the fact that
Netscape was originally proprietary.

>
>"white box" software as opposed to "black box" software is my top
>choice.
>
>The term has some unwanted NeXT connotations. It also might me
>confused to mean generic cheap packaging.

It's also confusable with a specific testing method, although
I'm not sure if the term is precisely enough defined or not;
"black box" testing can only use public interfaces, but
"white box" can use anything and everything it can lay its
hands on.  A rough analogy would be testing a (populated?) PC board
by only electrically probing the fingers which plug into the motherboard,
versus probing anywhere it makes sense to on the board itself.

I can't say anything about NeXT, although I've been exposed to it;
it looked neat at the time, :-) although quite underpowered by
today's standards.  (Then again, that's a hardware issue; NeXT
could probably run on today's computers without problem, especially
since there is (was?) an x86 version floating around.)

>
>some other possibilities:
>

[rest snipped]

If one wants to be ultra-pedantic about it, how about
"[license-name]-licensed software"?  E.g., readline is
GPL-licensed software.

It's not free, although it's designed to be very easy to work with.
(A lot more so than, say, Microsoft Word's EULA.  It's not even
legal to disassemble the darned thing, and one wonders whether
one can even disassemble its output -- a Word-formatted file.)

-- 
ewill@aimnet.com -- insert random misquote here
EAC code #191       25d:20h:07m actually running Linux.
                    Most likely, no neutrinos were found during this message.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <slrn9mufsb.r0j.ewill@lexideb.athghost7038suus.net>, on 08/07/2001
   at 01:08 AM, ewill@lexideb.athghost7038suus.net (The Ghost In The
Machine) said:

>The FSF license is inherently viral. 

True. But so is micro$soft's license, in a much more onerous fashion.

>[2] The source code of the GPL portion must be available on a
>    machine-readable medium to anyone who is sold the derived work.

AFAIK you only need to distribute the source for the object code you
distribute. I'm not sure what you mean by GPL portion, since you must
license the modified version under the GPL if you distribute it.

>[3] If your work can be shown to be a derived work of the GPLed
>    software, then the entire work must be published under the GPL.

Note that the existence of the LGPL makes this less stringent than it
sounds.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[The Ghost In The Machine]

Followups restricted to the newsgroup I actually read. :-)

In comp.lang.java.advocacy, Shmuel (Seymour J.) Metz
<spamtrap@library.lspace.org.invalid>
 wrote
on Mon, 06 Aug 2001 22:38:56 -0400
<3b6f54c1$1$fuzhry$mr2ice@va.news.verio.net>:
>In <slrn9mufsb.r0j.ewill@lexideb.athghost7038suus.net>, on 08/07/2001
>   at 01:08 AM, ewill@lexideb.athghost7038suus.net (The Ghost In The
>Machine) said:
>
>>The FSF license is inherently viral. 
>
>True. But so is micro$soft's license, in a much more onerous fashion.

Agreed in part.  :-)  And at least the FSF GPL license says so.
Microsoft is insidious.

>
>>[2] The source code of the GPL portion must be available on a
>>    machine-readable medium to anyone who is sold the derived work.
>
>AFAIK you only need to distribute the source for the object code you
>distribute. I'm not sure what you mean by GPL portion, since you must
>license the modified version under the GPL if you distribute it.

The GPL portion is the portion licensed under the GPL, as opposed to
the portion of the proprietary package happening to use it.

>
>>[3] If your work can be shown to be a derived work of the GPLed
>>    software, then the entire work must be published under the GPL.
>
>Note that the existence of the LGPL makes this less stringent than it
>sounds.

Only if the library actually uses it.  :-)

[.sigsnip]

-- 
ewill@aimnet.com -- insert random misquote here
EAC code #191       32d:06h:43m actually running Linux.
                    [ ] Check here to always trust monopolistic software.

Re: Market pressures for more reliable software

[Joseph T. Adams]

In comp.lang.java.advocacy Ted Dennison <dennison@telepath.com> wrote:
: In article <9ganmu$pj5$1@nh.pace.co.uk>, Marin David Condic says...
:>
:>I'll second that notion. For better or worse, people have come to associate
:>the word "Free" as meaning "No $$$ Charged" when the word is connected to a
: ..
:>me nothing but my time - not the case...) They probably should have used the
:>word "Open" as in "Open Architecture" or "Open Standard" or "Open Source" -
:>you can see inside and use it in any way you like - you might still have to
:>*pay* for it, but once you do, there are no unreasonable restrictions on its
:>use.
: "Open" doesn't quite reach it, because there's no implication that the right to
: redistribute is present, only the right to inspect.

: "Liberated" is actually a little closer to what I think they were shooting for.
: However, that word implies previous enslavement, which isn't quite right either.


Free software by definition respects the freedom of users. 
Proprietary software by definition asks users to give up many of their
rights in exchange for using it, and most commonly, one of the rights
it asks them to give up is the right to see the source code and
therefore to know exactly what they are getting.

This differs from feudalism, and therefore slavery, only in degree,
not in kind.


Joe

Re: Market pressures for more reliable software

[Ed Jensen]

In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
: "Open" doesn't quite reach it, because there's no implication that the right to
: redistribute is present, only the right to inspect.

: "Liberated" is actually a little closer to what I think they were shooting for.
: However, that word implies previous enslavement, which isn't quite right either.
: "Free" really has the perfect meaning. The only problem is that is has other
: seprate meanings as well. :-(

: Anyway, better minds than ours (OK, better than mine at least) have been all
: over this nomenclature issue to exhaustion. I doubt we'll be able to fix it
: here, short of switching this whole thread to French.

The BSD license seems much closer to "free" than the
many-strings-attached GPL.

Of course, the true goal of the FSF, and their chosen tool, the GPL, is
not software freedom.  It is the destruction of commercial software,
which they find unethical.

The BSD license already offers software freedom.  The GPL is merely an
attempt to enforce their manifesto through brilliant viral-like
propagation.

-Ed

Re: Market pressures for more reliable software

[Roedy Green]

On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
wrote or quoted :

>The GPL is merely an
>attempt to enforce their manifesto through brilliant viral-like
>propagation.

See the Zen story of the box facing east.

A Zen master presented his student with a valuable box, with the
stipulation that it must always face east.  The student took the box
and placed it in his room.  However to place the box east, he had to
place the table against the wall on the opposite side of the room.
This meant he had to move the bed. This made getting in and out of the
room awkward, so he had to move the doorway in the wall.  This caused
a structural weakness in the house which required ....


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Roedy Green]

On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
wrote or quoted :

>The GPL is merely an
>attempt to enforce their manifesto through brilliant viral-like
>propagation.

My own equivalent is the "for non military use only" clause applied to
all the source I write.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[James A. Robertson]

Roedy Green wrote:
> 
> On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
> wrote or quoted :
> 
> >The GPL is merely an
> >attempt to enforce their manifesto through brilliant viral-like
> >propagation.
> 
> My own equivalent is the "for non military use only" clause applied to
> all the source I write.

Why?  

> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober@mail.com
<Talk Small and Carry a Big Class Library>

Re: Market pressures for more reliable software

[Roedy Green]

On Sat, 16 Jun 2001 14:25:17 GMT, "James A. Robertson"
<jarober@mail.com> wrote or quoted :

>> 
>> My own equivalent is the "for non military use only" clause applied to
>> all the source I write.
>
>Why?  

see http;//mindprod.com/roedy.html#NONMILITARY

For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[James A. Robertson]

So then, you would have objected to the allies using your code against
the Axis?  You have to accept the simple fact that sometimes, force is
the only alternative against evil.  And the UN isn't a viable option in
most cases either - non of the peace keeping operations they have run
have made things better.  At best, they delay further bloodshed into the
future (Balkans missions) - at worst, they achieve nothing at all or
make things worse (middle east)



The best way to ensure peace is to have the best preparedness for war -
so that no one dares bother you.  Follow that with a simple maxim to
stay out of the affairs of others (which the US frequently does <not>
do), and you don't have many problems.



Roedy Green wrote:
> 
> On Sat, 16 Jun 2001 14:25:17 GMT, "James A. Robertson"
> <jarober@mail.com> wrote or quoted :
> 
> >>
> >> My own equivalent is the "for non military use only" clause applied to
> >> all the source I write.
> >
> >Why?
> 
> see http;//mindprod.com/roedy.html#NONMILITARY
> 
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> 
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober@mail.com
<Talk Small and Carry a Big Class Library>

Re: Market pressures for more reliable software

[Ted Dennison]

In article <f0ilitkr3g1qdrffsqss5h8so9tgg1unt5@4ax.com>, Roedy Green says...
>
>On Fri, 15 Jun 2001 15:43:52 GMT, Ed Jensen <ejensen+usenet@tiny.net>
>wrote or quoted :
>
>>The GPL is merely an
>>attempt to enforce their manifesto through brilliant viral-like
>>propagation.
>
>My own equivalent is the "for non military use only" clause applied to
>all the source I write.

That's actually more restrictive than the GPL in many ways. I can and do use GPL
code on military projects. Mostly the GPL just requires that they get the
source, and don't deny it to anyone they give the software to. Since the
military requires the sources anyway, and refuses to give out the software in
most cases, they are quite compatabile with the GPL. I believe discriminating
aginst users automaticly renders software "non-free" too.

However, I understand where you are comming from. I've done DoD work all my
career, and I can feel good that most of my work (particularly the simulator
stuff) actually saves lives. But there are just some jobs even I can't
rationalize away enough to accept. (The tank simulator for the Chineese govt.
approx. 3 years after the Tianamen massacre being a prime example).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Al Christians]

Ted Dennison wrote:
> 
> Since the
> military requires the sources anyway, and refuses to give out the 
> software in most cases, they are quite compatabile with the GPL. 

That's a curious one.  GPL says:

"If ... conditions are imposed on you ... that contradict the conditions
of this License, they do       not excuse you from the conditions of
this License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent obligations,
then as a consequence you may not distribute the Program at all." 

This would appear to make it impossible, for example for a military
contractor that 'distributes' its products to military customers to
include GPL code in a weapons system that was under security
restrictions, or for one country to license military technology
that included GPL code to another country with any restrictions on 
to whom the weapons could be re-sold.  And is hurling a projectile 
that contains embedded software 'redistribution'?


Al

Re: Market pressures for more reliable software

[Ted Dennison]

In article <3B2E2261.303FE952@easystreet.com>, Al Christians says...
>
>This would appear to make it impossible, for example for a military
>contractor that 'distributes' its products to military customers to
>include GPL code in a weapons system that was under security
>restrictions, or for one country to license military technology

True. The GPL'ed stuff I used was all self-contained development tools
(compilers, editors, etc). So I guess that wasn't much of an issue. Also, it was
all for stuff that would not be redistributed anyway. (One thing I touched on
later in the post...I have not worked on anything considered a munition).

>that included GPL code to another country with any restrictions on 
>to whom the weapons could be re-sold.  And is hurling a projectile 
>that contains embedded software 'redistribution'?

That would be an interesting legal question indeed. On one hand, it would be
funny to see a bombed country sue its bomber for GPL violations (or the right to
examine the bomb's souce code). On the other, it would be interesting to see one
country sue another over reverse-engineering the software on captured miliatary
apparatus, under international copyright law, due to a closed-source software
license. (You've *really* ticked us off now. Call back the troops! Recall the
bombers! Tell everyone to stand down at the ICBM silos! We're sending in the
{shudder} lawyers.)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Marin David Condic]

If your customer is, say, the Air Force & you sell them a program that has
GPL code in it & give them the source, then I don't think that in the case
where the Air Force were to share the system with the Navy would mean that
the Navy must now get the source as well. After all, the United States of
America is in posession of the source code somewhere and if they decide not
to let the left hand know what the right hand is doing, that's not an issue
for the FSF to go suing over. (Besides, in order to sue the United States,
you first have to get the permission of the United States.) Same as if
Ford-Detroit decides not to send the source to Ford-England. Its an internal
matter for Ford.

Sending embedded code to some other location and energetically disassembling
the computer on which it is stored doesn't give the foreign government at
your new storage site/test facility on their soil the right to demand the
source under terms of the GPL. Its still your bomb - you just decided to put
it somewhere inconvenient to some other country and then turn it on and test
it. After all, you neither sold them nor gave them the software. Chances
are, they'd want you to take back the whole delivery package anyway. They
may return the favor and when one side or the other decides to give up, the
winner can make it part of the terms of surrender that they cough up the
GPL'ed code if they want.

As for the NATO allies getting some system that included GPL code? I'd guess
that the U.S. as a member of NATO could say that they are in posession of
the source - hence NATO is in posession of the source. No need for them to
give it to the branch office of NATO that calls itself France or England -
just like the first case.

Besides, its all moot under the terms and conditions of Catch 22 which
clearly states: "The Army can do anything you can't stop it from doing."
They're the guys holding all the guns and bombs. If they don't feel like
redistributing the source code and feel rather strongly about it, what can
FSF, et alia do about it? Go to war?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B2E2261.303FE952@easystreet.com...
>
> That's a curious one.  GPL says:
>
> "If ... conditions are imposed on you ... that contradict the conditions
> of this License, they do       not excuse you from the conditions of
> this License. If you cannot distribute so as to satisfy simultaneously
> your obligations under this License and any other pertinent obligations,
> then as a consequence you may not distribute the Program at all."
>
> This would appear to make it impossible, for example for a military
> contractor that 'distributes' its products to military customers to
> include GPL code in a weapons system that was under security
> restrictions, or for one country to license military technology
> that included GPL code to another country with any restrictions on
> to whom the weapons could be re-sold.  And is hurling a projectile
> that contains embedded software 'redistribution'?
>
>
> Al

Re: Market pressures for more reliable software

[Ted Dennison]

In article <9glcks$dvk$1@nh.pace.co.uk>, Marin David Condic says...
>Sending embedded code to some other location and energetically disassembling
>the computer on which it is stored doesn't give the foreign government at
>your new storage site/test facility on their soil the right to demand the
>source under terms of the GPL. Its still your bomb - you just decided to put
..
>Besides, its all moot under the terms and conditions of Catch 22 which
>clearly states: "The Army can do anything you can't stop it from doing."
>They're the guys holding all the guns and bombs. If they don't feel like

At work we pictured it going like this:

Serbia: It has come to our attention that your organization (hereafter referred
to as NATO) has redistributed thousands of copies of software to our cities
which is covered under the GNU Public License (hereafter referred to as the GPL)
inside of the casings of shells, missiles, and bombs. Under the redistribution
terms of the GPL, you are required to provide us with the sources to all the
GPL'ed code that you have distributed, and to all code linked with it, yet this
source code has been purposely and maliciously denied us. We are hereby suing
NATO for $1.5 Billion US in compensatory and punitive damages, and for full
compliance with the terms of the GPL.

NATO: We are currently in the process of formulating a full and complete
response to your legal brief. We respectfully request that Serbia provide the
GPS coordinates of its legal council, so that we may ensure that our response is
delivered properly...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Al Christians]

Marin David Condic wrote:
> 
> Same as if .....   ....  ... .... 
> ... Ford-Detroit decides not to send the source to Ford-England. Its 
> an  internal matter for Ford.
> 

Yes. It's  an internal matter until the GPL software gets 'distributed',
as from weapons maker to military.  If that happens, then either
(1) military can't prosecute spies for slipping source to Pottsylvanian  
OGPU, or (2) the whole deal should never have happened according to GPL,
or (3) if I tell you (3), the black helicopters will come back.


Al

Re: Market pressures for more reliable software

[Marin David Condic]

(plugging ears) "I can't hear you... YAYAYAYAYAYAYA!!!!" :-)

No, I think that from ACME Atom Bombs (Slogan: "Good to the last drop!") to
DoD, they'd have to provide source with the distribution, but that doesn't
*force* the DoD to redistribute it to anybody. Nor does it stop the DoD from
having an agreement with ACME Atom Bombs that they not distribute anything
either. It is, after all, their software and if they don't want to make it
public, that's their choice. Correct me if I am wrong, but the mere use of
GPL software AFAIK, doesn't suddenly obligate you to print up a CD full of
your software and mail it to everyone in the country, right? So you're still
free to take all of your software and lock it in a vault, correct?

I also don't believe that the GPL is going to override the government's
ability to slap a "Classified" sticker on top of anything they write and say
"Copyleft My A**!" They can already do this to software that *you* write in
your garage in your spare time if they feel like it - *and* lock you up in
prison for having written it in the first place. ("Catch 22" - Remember?)
Its been done before.

As for the black helecopters, I've found the solution: At night, you wear an
aluminum foil helmet, grounded to a cold water pipe. It keeps them from
monitoring your thoughts and they can't home in on you. It works best if you
shape it like a pyramid. Either that, or turn your whole house into a
Faraday cage. Both together work exceptionally well. I have not seen the
black choppers - or the Shadow People - for some weeks now. (Maybe they're
just getting better at it?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B2E42A9.F5ACF80E@easystreet.com...
> Yes. It's  an internal matter until the GPL software gets 'distributed',
> as from weapons maker to military.  If that happens, then either
> (1) military can't prosecute spies for slipping source to Pottsylvanian
> OGPU, or (2) the whole deal should never have happened according to GPL,
> or (3) if I tell you (3), the black helicopters will come back.
>

Re: Market pressures for more reliable software

[tmoran]

>... Ford-Detroit decides not to send the source to Ford-England.
>Its an internal matter for Ford.
  The solution is clear: When everything in the world is a subsidiary
of Microsoft then all distribution will be purely an internal matter!
;)
p.s.
  That also solves the problem of underproduction of software because
the producer cannot appropiate the buyer's full value - if the "buyer"
is just another division, then the overall company captures full value.

Re: Market pressures for more reliable software

[Charles Hixson]

Al Christians wrote:

> Ted Dennison wrote:
> 
>>Since the
>>military requires the sources anyway, and refuses to give out the 
>>software in most cases, they are quite compatabile with the GPL. 
>>
> 
> That's a curious one.  GPL says:
> 
> "If ... conditions are imposed on you ... that contradict the conditions
> of this License, they do       not excuse you from the conditions of
> this License. If you cannot distribute so as to satisfy simultaneously
> your obligations under this License and any other pertinent obligations,
> then as a consequence you may not distribute the Program at all." 
> 
> This would appear to make it impossible, for example for a military
> contractor that 'distributes' its products to military customers to
> include GPL code in a weapons system that was under security
> restrictions, or for one country to license military technology
> that included GPL code to another country with any restrictions on 
> to whom the weapons could be re-sold.  And is hurling a projectile 
> that contains embedded software 'redistribution'?
> 
> 
> Al
> 

The owner of the copyright has all necessary rights to do whatever he 
feels like with it.  GPL is one manifestation of this, and explicitly 
allows one to release it under other licenses.

OTOH, if you mean that including GPL code written by others would be a 
problem, only those who are have a legitimate binary copy  have the 
right to require source code, and the only person/company obligated to 
supply them with the source code is the person/company that they got the 
binary from.

The only time this becomes at all questionable is when military equiment 
is decomissioned.  In that case they might be required to either remove 
the binary code or to distribute the source.  OTOH, I believe that the 
current understanding is that having an embedded module that contains 
binary code is not the same as having the source code unless it contains 
some method for dumping the code.  But I'm less than certain about that.

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Al Christians]

> Al Christians wrote:
> 
> only those who are have a legitimate binary copy  have the
> right to require source code

My understanding is that once a work has been released under GPL, 
all copies are legitimate, source and/or binary.    You must allow
it to be licensed to any and all third parties without any conditions
beyond those in the GPL. There's a new  FAQ a few weeks ago from FSF on 
GPL that explains some of these issues.  


Al

Re: Market pressures for more reliable software

[Charles Hixson]

Al Christians wrote:

 >> Al Christians wrote:
 >>
 >> only those who are have a legitimate binary copy  have the right
 >> to require source code
 >>
 >
 > My understanding is that once a work has been released under GPL,  all
 >  copies are legitimate, source and/or binary.    You must allow it
 > to be licensed to any and all third parties without any conditions beyond
 >  those in the GPL. There's a new  FAQ a few weeks ago from FSF on  GPL
 >  that explains some of these issues.
 >
 >
 > Al
 >
Umn... not precisely.  Anyone you give or sell a copy to has the right 
to further release it, but that doesn't make all copies legitimate.  You 
could give it to a business associate for use in some project, and 
someone could steal it from him, or someone could break into your 
computer and steal a copy.  These would not be legitimate copies.  If 
they were to be distributed further, the holder could be required to 
provide source, but would not necessarily have any access to the 
appropriate source.

OTOH, practically speaking, anything which is widely distributed under 
the GPL has legitimate copies available to anyone.

P.S.:  Steal in this case simply means acquiring a copy illegally. 
E.g., a piece of software could be licensed GPL, but only be used 
internally in an organization (i.e., no public release).  And an 
employee who did not have the right to do so could e-mail it to an 
external associate.  No malice need be involved.  For that matter, I 
don't even assume any damages beyond the assumption of the requirement 
to make source available.  My statement is that there is no such 
requirement.  The employee didn't have the right to distribute it, so 
the copy is illegitimate.  And the firm doesn't have to keep the 
unchanged source on file for three years (presuming the source wasn't 
distributed with or instead of the binary).

Now IANAL, so there are lots of special cases in here that depend on 
points of law that I have no knowledge of.  But that's the broad outline.
-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <3B2E7263.9080804@earthlink.net>, on 06/18/2001
   at 09:29 PM, Charles Hixson <charleshixsn@earthlink.net> said:

>The only time this becomes at all questionable is when military
>equiment  is decomissioned.

If the source code is classified then the object code will be
protected. As part of decommissioning they will erase or destroy the
memory containing the object code. If they don't, they will have more
serious legal problems than GPL violations.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Florian Weimer]

Ted Dennison<dennison@telepath.com> writes:

> "Liberated" is actually a little closer to what I think they were
> shooting for.  However, that word implies previous enslavement,
> which isn't quite right either.

The EU is using the term "libre software", I think, to avoid such
connotations.

Re: Market pressures for more reliable software

[David Chase]

Ed Jensen wrote:

> In comp.lang.java.programmer Ted Dennison <dennison@telepath.com> wrote:
> : When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
> : Software".
> 
> Is anyone else annoyed that the FSF has decided to redefine the term
> "free software" for marketing purposes?

Compared to most for-profit marketing, it is incredibly tame.

> I think I'll scoop up some doggie poo, put it in a bowl, and place a
> sticker on it that says "Rose Petals".

Your implicit comparison of free software with dog poo is
completely unjustified, and reflects more on your experience
and judgement than it does on Free Software.

> -Ed, who thinks "Free Software" (GPL-style) is unethical.

If you think it's unethical, you aren't much of a thinker.  I
don't believe all the FSF dogma, but their code works as
advertised, and I always have the option of not
using their code as a basis for my own work.  That "option"
is the mandatory default if I use (just for example, and MS
is by no means the only example) Microsoft products.  We USE
Free software in our own work all the time, and we treat it
almost exactly (*) as we treat software that we pay for, because
in either case the licensing terms do not allow us unencumbered
modification and redistribution of the software.

(*) we're more likely to report bugs in Free software, partly
because we have access to the source code.  We also copy it
from machine to machine with less concern for licensing,
because their licensing doesn't include any significant
restrictions on the creation/distribution of binary copies
within a company.

I am also very impressed with the compatibility over time
that I have seen in one "Free" effort, which is MikTeX and
the new version of LaTeX.  It processed a 15-year old
document without any problems at all, and with only a
three-line change in the header the document could be
processed in modern (instead of "compatibility") mode,
allowing me access to features like generation of PDF
files with automatic inclusion of indexing and thumbnails.
Compare this with Word, which is not even compatible
between installations (of the same version) on different
machines.

The quality of Free software is also generally quite high.
I find bugs in it, but I find bugs in most software, and
the bug rate is no higher than that in un-Free products.

David Chase

Re: Market pressures for more reliable software

[James A. Robertson]

Ted Dennison wrote:
> When I capitalize "Free", its to indicate that I'm talking about FSF-style "Free
> Software".
> 

The problem occurs once your software reaches a 'mature' state - then
few are buying new licenses (there's no need), and few buy support (it's
mature and doesn't need it).  This is what is starting to happen with MS
Office, and is also something that has hit the development tools sector.

The answer that seems to work is a subscription model, which you can
find large numbers of people railing against.

The base problem is that over time, people in fact won't pay for support
- especially once the product gets to a state where it doesn't need a
lot of it.

> Nearly all software is already developed as custom software under a system where
> the deveopers are paid for the development. That includes *every* project I've
> ever worked on in my career. Even for most of the "licensed" commercial software
> I deal with, the "support" is the most expensive part. So using Free Software
> models wouldn't even noticably impact the vast majority of the software
> developed.
> 
> Of course this skirts around the issue that the small minority of software left
> actually gets distributed the most. But there are still ways to make money using
> Free Software in that realm. RedHat has shown that. They just won't make nearly
> as *much* money as they would if they could somehow charge a toll on each copy.
> 
> You bring up games. To answer your question directly, yes people *do* pay for
> "support" for games. 900-number "hint lines" for adventure games are not unheard
> of. Also, nearly every game company has some kind of customer support (the money
> to pay for for that obviously comes from game sales, so you can think of it as
> sort of a "support tax").
> 
> I've played computer games avidly for over 20 years (since back when games were
> distributed in compliation books as BASIC source code). So I have thought about
> this a lot. For a computer game, what I'd try to sell is the manual. There's
> already a racket going where the shipped manuals are useless, and anyone who
> wants to know what's really going on buys a "game guide". They might as well
> make it official. I also collect the boxes, and on one glorious occasion, got
> one autographed by the heads of the development team (Sid Meyer, Brian Reynolds,
> et al). So I'm quite confident that people would still pay for an official
> "hard" copy (perhaps even more for a hand-autographed one).
> 
> >Now there might be something to the notion of software developed under the
> >Ada Developer's Cooperative License (or similar) in that the guys who build
> >the code only get paid if the code gets used and sold. The only way for that
> 
> That might work out OK in a world of mass-produced shrink-wrapped software. But
> remember paragraph 1: the vast majority of software *developed* does not fit
> that mold. In the world in which I work, I can't use any nifty routine that's
> going to add to the system's costs, because *I* don't get to make those kinds of
> decisions. The folks that do are my managager's manager, who's already obsessing
> about overruns, and the paper-pushers off in accounting, who require all sorts
> of paperwork and market research and competitive sourcing and several weeks to
> make any kind of decision (You should see us trying to buy a PC video card
> before it goes obsolete. Its sad, really). Unless we are talking some pretty
> significant functionality, its far easier for me to just rewrite it all myself
> (and what a shameful waste of human effort that is!).
> 
> So that license might get some lucky package shipped in lots of software copies.
> But for the vast majority of *developers*, its just going to render the package
> useless.
> 
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

-- 
James A. Robertson
Product Manager (Smalltalk), Cincom
jarober@mail.com
<Talk Small and Carry a Big Class Library>

Re: Market pressures for more reliable software

[Al Christians]

"James A. Robertson" wrote:
> 
> The problem occurs once your software reaches a 'mature' state - then
> few are buying new licenses (there's no need), and few buy support (it's
> mature and doesn't need it).  This is what is starting to happen with MS
> Office, and is also something that has hit the development tools sector.
> 
> The answer that seems to work is a subscription model, which you can
> find large numbers of people railing against.
> 
> The base problem is that over time, people in fact won't pay for support
> - especially once the product gets to a state where it doesn't need a
> lot of it.
> 

The answer you propound is evidently the answer to the question "How
do I get a perpetual income from a single project?"  Good software 
may be usable in perpetuity,  but if the market is competitive,  the
price will compensate the seller only for what is sold and  will not 
saddle the buyer with additional costs (short-term or long-term) for 
what is neither wanted nor needed.  Reliable software ought to be 
produced in  a comparatively short time and last a comparatively long 
time.  The justification for market economies is that they produce a 
bounty for consumers (buyers).  Producers are supposed to be smart 
enough to deal with that.

Where I live there is some of the back end of the game development 
business.  That market has adapted to the economics of software as 
a permanent good. They produce a game and move on.  Embedded software
ought to work the same way.  I might not buy an appliance if I knew
there was a permanent development group somewhere continually turning 
out bug fixes for the appliance's embedded software.  If consumers
prefer to pay once and use forever, it's market failure if they can't
find a way to get what they want.


Al

Re: Market pressures for more reliable software

[tmoran]

>... but if the market is competitive, the price will compensate the
>seller only for what is sold and will not saddle the buyer with
>additional costs (short-term or long-term) for what is neither wanted
>nor needed.  ...  The justification for market economies is that they
>produce a bounty for consumers (buyers).  Producers are supposed to
>be smart enough to deal with that.
  And in a situation where the value to a buyer of an item is greater
than the value to a producer of supplying that item, there will be an
undersupply.  In particular, if support and upgrades are free, and
don't generate significant advertising, good will, or money to
producers, support and upgrades will cease, even if they would be
useful to some buyers.

Re: Market pressures for more reliable software

[Marin David Condic]

The basic idea ought to be this: Produce a really good word processor that
may evolve for a while as you discover the features people will want. When
it matures and stabilizes on a feature set, move on to the next frontier.
Don't keep trying to sell the word processor to the people who already own
it. Sell them a spreadsheet or a database instead.

You can't really get around a mature market. Sooner or later, you've filled
the pipeline and the only new sales are going to be to the handful of
consumers who are just entering the market or replacing what has worn out.
(In software terms, "wearing out" would be analogous to a new hardware or OS
technology - the end of useful life.) Put the product on the shelf & accept
the trickle of revenue it brings in with little or no cost to you & start
looking for the next thing you can build. Eventually, new technology will
come around that will demand you go rebuild the product but why waste the
resources to rebuild it constantly along the way?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <alc@PublicPropertySoftware.com> wrote in message
news:3B2BEA63.34116398@PublicPropertySoftware.com...
>
> The answer you propound is evidently the answer to the question "How
> do I get a perpetual income from a single project?"  Good software
> may be usable in perpetuity,  but if the market is competitive,  the
> price will compensate the seller only for what is sold and  will not
> saddle the buyer with additional costs (short-term or long-term) for
> what is neither wanted nor needed.  Reliable software ought to be
> produced in  a comparatively short time and last a comparatively long
> time.  The justification for market economies is that they produce a
> bounty for consumers (buyers).  Producers are supposed to be smart
> enough to deal with that.
>
> Where I live there is some of the back end of the game development
> business.  That market has adapted to the economics of software as
> a permanent good. They produce a game and move on.  Embedded software
> ought to work the same way.  I might not buy an appliance if I knew
> there was a permanent development group somewhere continually turning
> out bug fixes for the appliance's embedded software.  If consumers
> prefer to pay once and use forever, it's market failure if they can't
> find a way to get what they want.
>

Re: Market pressures for more reliable software

[Marin David Condic]

Is it a surprise that Bill Gates has noticed this and is busy trying to con
people into keeping their software & data on some central server for which
he can charge? Has anybody noticed that the model he suggests is absolutely
*no* different at its core from the model we used to have of a large
centralized datacenter that wrote all your software for you and stored all
your data for you and managed everything for you? Ever wonder why that model
fell on the wayside once computers got fast enough and cheap enough for the
average person to own one? (Synonym: Those in the Federal Govt who would say
"Send us all your money and we'll spend it for you and take care of you...")

What disturbs me is not that there are those out there who would suggest
such a large, centralized model and call it "new". What disturbs me is the
credit they give to our intelligence. That and the fact that there are
people out there who *will* swollow it whole - and they are allowed to vote
and drive cars.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James A. Robertson" <jarober@mail.com> wrote in message
news:3B2B6D5E.F9AE7CAB@mail.com...
> The problem occurs once your software reaches a 'mature' state - then
> few are buying new licenses (there's no need), and few buy support (it's
> mature and doesn't need it).  This is what is starting to happen with MS
> Office, and is also something that has hit the development tools sector.
>
> The answer that seems to work is a subscription model, which you can
> find large numbers of people railing against.
>
> The base problem is that over time, people in fact won't pay for support
> - especially once the product gets to a state where it doesn't need a
> lot of it.
>

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <9gl0sh$9gq$1@nh.pace.co.uk>, on 06/18/2001
   at 09:49 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>Is it a surprise that Bill Gates has noticed this and is busy trying
>to con people into keeping their software & data on some central
>server for which he can charge? Has anybody noticed that the model he
>suggests is absolutely *no* different at its core from the model we
>used to have of a large centralized datacenter that wrote all your
>software for you and stored all your data for you and managed
>everything for you?

A model that has no basis in reality. Applications developement was
decentralized for as far back as I can remember. Santayana.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Marin David Condic]

How far back can you remember? :-)

Seriously. I worked in a datacenter where the programming for the whole
organization was done in a central location by an MIS department and batch
jobs were run by the computer operators and all anybody had was dumb
terminals. There may have been *pockets* of development taking place outside
of MIS (the model was already beginning to crumble because of mini
computers) but basically, if you wanted some program developed or changed,
you had to go through MIS. (We were infinitely more responsive to customer
change requests than Microsoft will ever be given that your chances of
asking them to change something about MS-Word and getting anything but
laughter are zero.) The big mainframe stored all your code and all your data
and had all the advantages that Bill Gates is claiming for his internet
based central repository - access to your data & programs from wherever you
happen to be (if a terminal was there) and immediate updates of any code as
they occur. The disadvantages are all those we had with centralized MIS
departments/mainframes and then some.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b2f40fc$7$fuzhry$mr2ice@va.news.verio.net...
>
> A model that has no basis in reality. Applications developement was
> decentralized for as far back as I can remember. Santayana.
>

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <9gnn8m$979$1@nh.pace.co.uk>, on 06/19/2001
   at 10:23 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>How far back can you remember? :-)

Well before the term "MIS" came into vogue. My first computer was a
vacuum tube machine that I will never be nostalgic about.

>Seriously. I worked in a datacenter where the programming for the
>whole organization was done in a central location by an MIS
>department and batch jobs were run by the computer operators and all
>anybody had was dumb terminals. There may have been *pockets* of
>development taking place outside of MIS (the model was already
>beginning to crumble because of mini computers) 

No doubt there were organizations where all of the programming was
done by a centralized DP staff. But there were also organizations
where the programming of a single machine was decentralized and the DP
staff was only concerned with such issues as operations, maintenance
of systems software and scheduling. In fact, there were shops where
users were expected to run their own jobs as well as program them.

Santayana.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Charles Hixson]

Marin David Condic wrote:

> How far back can you remember? :-)
> 
> Seriously. I worked in a datacenter where the programming for the whole
> organization was done in a central location by an MIS department and batch
> jobs were run by the computer operators and all anybody had was dumb
> ...
> 

Well, back in 1960-64 I was in several different places.  Some were 
centralized and some weren't.  The keypunching was centrallized.  The 
computers were centralized.  But we did all the coding on paper or 
coding sheets.  And those were decentrallized.

Some people only created data, and a few others only created programs, 
and several did both, and most did neither.  But though the machinery 
was centrallized, in most of the places that I was the coding wasn't. 
There were exceptions.  OTOH, much (not all) of this experience was 
around a university, so that might skew things.

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Marin David Condic]

Well, the point was, at one time lots (if not most or all) of the computing
was done in some centralized manner. You had a mainframe to which you
connected and on that mainframe was where you had your data and programs.
That had the advantage (as Micro$oft will tell you) that you could access
your data from anywhere on any piece of equipment (a dumb terminal at the
time) and if some piece of software you used was supported by the central
location, you instantly got updates as they were made.

Eventually, this model began to wane because of the prevalence of mini and
microcomputers. People now had their software stored on their *own* personal
machine. You didn't need to ask permission of some central DP organization
to get something done (change software, update data, make backups, get more
disk quota, etc.) You just up and did it - including deciding if you wanted
to buy a new version of some software product or just live with what you
have.

Now Bill Gates, et alia, are suggesting that you go back to the old model
because this way, they can keep charging you every day for the storage of
your data and the execution of your programs. (That's basically what you had
in the old days, right? Or is the suggestion that somehow it wasn't this way
or that B.G., et al., are offering you something fundamentally different? Or
maybe it is just unclear what I meant when I said "Centralized"?) I suppose
you are free to do that if you like, but personally, I would rather have all
that stuff sitting on my desk at home & not keep buying Micro$oft Word every
time I want to execute it. (Nor trusting Micro$oft not to go "data mining"
through my private files. Assuming they aren't doing that already every time
I connect to the Internet... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
news:3B30C75D.2020507@earthlink.net...
> Marin David Condic wrote:
>
> > How far back can you remember? :-)
> >
> > Seriously. I worked in a datacenter where the programming for the whole
> > organization was done in a central location by an MIS department and
batch
> > jobs were run by the computer operators and all anybody had was dumb
> > ...
> >
>
> Well, back in 1960-64 I was in several different places.  Some were
> centralized and some weren't.  The keypunching was centrallized.  The
> computers were centralized.  But we did all the coding on paper or
> coding sheets.  And those were decentrallized.
>
> Some people only created data, and a few others only created programs,
> and several did both, and most did neither.  But though the machinery
> was centrallized, in most of the places that I was the coding wasn't.
> There were exceptions.  OTOH, much (not all) of this experience was
> around a university, so that might skew things.
>
> --
> Charles Hixson
>
> Copy software legally, the GNU way!
> Use GNU software, and legally make and share copies of software.
> See http://www.gnu.org
>      http://www.redhat.com
>      http://www.linux-mandrake.com
>      http://www.calderasystems.com/
>      http://www.linuxapps.com/
>

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <9gqkhf$c10$1@nh.pace.co.uk>, on 06/20/2001
   at 12:55 PM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>Well, the point was, at one time lots (if not most or all) of the
>computing was done in some centralized manner. You had a mainframe to
>which you connected and on that mainframe was where you had your data
>and programs.

That much is correct. However, it does not imply that maintenance of
either the data or the programs was centralized.

>You didn't need to ask permission of some central DP organization to
>get something done (change software, update data, make backups, get
>more disk quota, etc.) You just up and did it - including deciding
>if you wanted to buy a new version of some software product or just
>live with what you have.

Are you saying that you didn't have to budget for additional hardware,
personnel, etc.? On the centralized mainframe you were already free to
get something done (change software, update data, make backups, get
more disk quota, etc.) The only difference was that some things were
done automatically, e.g., periodic backups.

>Now Bill Gates, et alia, are suggesting that you go back to the old
>model

No such thing; he wants to go to a model that has never existed.

>(That's basically what you had
>in the old days, right? 

Wrong. The DP staff had to answer to the users. Gill bates doesn't
want that. The users were able to buy other software and install it
themselves if they could afford it. He certainly doesn't want that.



-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Roedy Green]

On Tue, 19 Jun 2001 10:23:17 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> centralized MIS

This is different from what is being proposed. Each vendor would look
after maintenance and installation of its own software and updates.
This is not the same as having it all done by one group.

However, to do it securely, you do need a fascist OS that has its
finger on the pulse to make sure no app meddles with data and programs
it has no business meddling with.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <3B28FAD5.5FFB643F@world.std.com>, on 06/14/2001
   at 05:56 PM, David Chase <chase@world.std.com> said:

>> I think I'll scoop up some doggie poo, put it in a bowl, and place a
>> sticker on it that says "Rose Petals".

>Your implicit comparison of free software with dog poo is completely
>unjustified, and reflects more on your experience and judgement than
>it does on Free Software.

I don't see where he has made any such comparison, implicit or
otherwise. What he was criticising was the spin control.

>> -Ed, who thinks "Free Software" (GPL-style) is unethical.
>If you think it's unethical, you aren't much of a thinker. 

Now there I agree with you. If I write a piece of software, it's my
property and, to a first approximation, I am free to decide who may
use it and under what circumstances. If I decide to release it under a
GPL, that's my right, whether mickey$oft likes it or not. 

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[tmoran]

>4. Free Software. If it doesn't quite do what you want, you've lost nothing but
>your evaluation time. Even better, you have more options than just trying
>something else. You can fix it yourself to do what you want, or pay someone else
>(preferably someone intamately familiar with the code) to do it for you.
  "Well of course it doesn't actually drive - the motor's in the back
seat.  You can cancel your purchase and not pay a dime (other than taxi
fare home), or you can install the motor yourself, or you can hire our
service department to install it.  You couldn't ask for more."

Re: Market pressures for more reliable software

[Larry Elmore]

Roedy Green wrote:
> 
> On Wed, 13 Jun 2001 12:22:43 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
> 
> > Produce a reliable product at a similar price and with
> >similar features and with a similar marketing budget.
> 
> The problem with software is you have to use it for at least a few
> months to evaluate its quality and suitability FOR YOUR NEEDS. Adobe
> may create some extremely good and expensive software, but their
> packages could be overwhelming for a newbie.
> 
> BUT, by then it is too late. The vendor already has your money,
> whether or not he has delivered a suitable, working product.
> 
> This problem with buying a pig in a poke greatly favours market
> leaders who can afford advertising, and whose products will be
> purchased by newcomers simply on name recognition. There is not enough
> incentive for a market leader to produce a high quality product.

Sure there is. There _is_ a lag time, but it's not really any different
than the original example of American-made automobiles. After all, it's
not at all obvious that a car will rust out in 4-5 years after only a
few months on the market -- but it will take years for that manufacturer
to rebuild its reputation once it's lost and it will lose a lot of sales
during that time period.

Larry

Re: Market pressures for more reliable software

[Charles Hixson]

Larry Elmore wrote:

 > Roedy Green wrote:
 >
 >> On Wed, 13 Jun 2001 12:22:43 -0400, "Marin David Condic" 
<marin.condic.auntie.spam@pacemicro.com>
 >>  wrote or quoted :
 >>
 >>
 >>> Produce a reliable product at a similar price and with similar
 >>> features and with a similar marketing budget.
 >>>
 >> The problem with software is you have to use it for at least a few 
months
 >>  to evaluate its quality and suitability FOR YOUR NEEDS. Adobe may
 >>  create some extremely good and expensive software, but their packages
 >>  could be overwhelming for a newbie.
 >>
 >> BUT, by then it is too late. The vendor already has your money, whether
 >>  or not he has delivered a suitable, working product.
 >>
 >> This problem with buying a pig in a poke greatly favours market leaders
 >>  who can afford advertising, and whose products will be purchased
 >>  by newcomers simply on name recognition. There is not enough incentive
 >>  for a market leader to produce a high quality product.
 >>
 >
 > Sure there is. ... but it will take years for that manufacturer to
 > rebuild its reputation once it's lost and it will lose a lot of
 > sales during that time period.
 >
 > Larry
 >

There seem to be an awful lot of companies that don't count that 
expense.  Considerably more than a mere majority.  And frequently the 
larger ones.  Marketing makes up for some horrendous blunders.

In general my experience it that if I pay a wad of cash, I'll get a much 
slicker product than a free one.  Free one's often even have text 
interfaces (though tcl and gtk are becoming more common).

OTOH, I'm not talking about custom software here.  I can't.  If I need 
custom software I either write it or do without.  (Or customize it 
myself, but that only applies to BSD and GPL style licensed products.)
That said, I must admit that I'm more likely to write it myself than to 
customize it, unless it's a *very* simple job.  Figuring out C code is 
generally nearly as bad as writing it in the first place, and that's 
what most of the source I see is.  (And with C++ it really depends alot 
on the coding style of the programmer.  That's another big chunk.)

-- 
Charles Hixson

Copy software legally, the GNU way!
Use GNU software, and legally make and share copies of software.
See http://www.gnu.org
     http://www.redhat.com
     http://www.linux-mandrake.com
     http://www.calderasystems.com/
     http://www.linuxapps.com/

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, on 06/13/2001
   at 07:48 PM, Roedy Green <roedy@mindprod.com> said:

>1. try-before-you-buy which is becoming much more common.  Electronic
>distribution lets you try several packages before making your final
>decision.  My problem with the technique is software trials are TIME
>limited rather than USE-limited.  I sometimes get sidetracked before
>completing evaluating a package, then lose the right to examine
>it.

I've found shareware authors to be generally cooperative on this. When
I've asked for an extension, they've usually gone along with it. I've
registered several shareware products after an extension that I would
have discarded without one.

>3. Consumer Reports so that new software is much less a pig in a
>poke.

That would help if CU had a clue about computers. Every
computer-related review of theirs that I've read has been seriously
flawed at best.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ted Dennison]

In article <3b28b7a7$4$fuzhry$mr2ice@va.news.verio.net>, Seymour J. says...
>
>That would help if CU had a clue about computers. Every
>computer-related review of theirs that I've read has been seriously
>flawed at best.

Among other problems, they have a nasty tendancy to consider price *way* out of
proportion to other factors (which is OK if you feel that way too, I guess). I
remember an issue back in the mid 80's where they recommended that everyone go
out and buy AtariST's. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 14 Jun 2001 09:09:59 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote or quoted :

>>3. Consumer Reports so that new software is much less a pig in a
>>poke.
>
>That would help if CU had a clue about computers. Every
>computer-related review of theirs that I've read has been seriously
>flawed at best.

You need something like CR though to avoid the problem of refraining
from giving the dirt to avoid hurting advertisers.

Perhaps there will be a way of organising reports from the field from
ordinary folk that are hard to forge.

But even then, you really need one person looking at all the packages
side by side, who represents a typical user.  So often the reviewer
has no idea what is important since he has never used such a package
in production.  They get hypnotised by cute features.

There are several TV shows now that talk about software.  One of them
seems to be on nearly all the time on Shaw Cable. The guy wings it and
tends thus to be unusually honest. 

I was hired once by such as a TV show,  Dotto on Data, as a "regular"
columnist, On my first live show I took a strip out of Compuserve.
That was my last show.  It turned out Compuserve was one of the
sponsors.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <407iitsqevc9j85mcuadk4ha392ega7jmj@4ax.com>, on 06/14/2001
   at 08:25 PM, Roedy Green <roedy@mindprod.com> said:

>You need something like CR though to avoid the problem of refraining
>from giving the dirt to avoid hurting advertisers.

You need somebody unbiased. But you also need somebody competent and
educated. The reviews in CR are full of techobable[1] and lack
awareness of the existence of alternatives to the
least-common-denominator products.

[1] E.g., legitimate words used with no understanding of what they
actually mean.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Larry Kilgallen]

In article <40gfitgrvd8cgu27r3vfib6eptmapb3pfl@4ax.com>, Roedy Green <roedy@mindprod.com> writes:

> This problem with buying a pig in a poke greatly favours market
> leaders who can afford advertising, and whose products will be
> purchased by newcomers simply on name recognition. There is not enough
> incentive for a market leader to produce a high quality product.
> 
> I see three ways around this:


> 3. Consumer Reports so that new software is much less a pig in a poke.
> General computer literacy should help along these lines too.  The new
> generation coming up are not going to be such lambs lead to the
> slaughter.

I fear use of reviews naturally degrades into faulty use of reviews.
Recently I commented that I bought something because of the reviews.
The response was -- I didn't see that getting the best score in the
reviews.  The response was correct, since I did not care about the
overall score from reviewers, but rather their detailed comments on
the aspects of the product about which I was most interested. The
easiest thing for a reviewer to write is a bullet-list of "features".
It wins points with editors, too, because it leads to a graphical
presentation.  So we are back at the old bugaboo of feature lists
prevailing over quality, since the latter is so subjective.

Re: Long names are doom ?

[Wes Groleau]

> be demonstrated. Find an unreliable product with no competing reliable
> product available. Produce a reliable product at a similar price and with
> similar features and with a similar marketing budget. (IOW, all other
> parameters held constant) Will the public purchase the Reliable product or
> the P.O.S.?

One or two years ago, somebody either in comp.lang.ada or on Team-Ada
reported having tried that.  Said he/she lost a sale as follows:

"So why should I buy this instead of [brand X]?"

"Because mine doesn't crash"

"Who are you trying to fool?  Everybody knows all software crashes!"  CLICK.

(not an exact quote)


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[Larry Kilgallen]

In article <9gl1h0$9rp$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> You can't really get around a mature market. Sooner or later, you've filled
> the pipeline and the only new sales are going to be to the handful of
> consumers who are just entering the market or replacing what has worn out.
> (In software terms, "wearing out" would be analogous to a new hardware or OS
> technology - the end of useful life.)

Another approach is to gain control of a related product (perhaps the
operating system upon which the first product depends) and introduce
changes that are desired in that related product but require a new
version of the first product in order to interoperate.

Re: Market pressures for more reliable software

[Larry Kilgallen]

In article <9gqkhf$c10$1@nh.pace.co.uk>, "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:
> Well, the point was, at one time lots (if not most or all) of the computing
> was done in some centralized manner. You had a mainframe to which you
> connected and on that mainframe was where you had your data and programs.
> That had the advantage (as Micro$oft will tell you) that you could access
> your data from anywhere on any piece of equipment (a dumb terminal at the
> time) and if some piece of software you used was supported by the central
> location, you instantly got updates as they were made.

But that was centralized within a legal entity, generally not across
legal entities like Microsoft is suggesting.

Re: Market pressures for more reliable software

[Marin David Condic]

I don't see how that matters in the context in which I was trying to make my
point. You could always lease mainframe time - McDonnel Douglas had a big
business doing exactly that (McAuto, if I recall) and there were others as
well. That's centralized computing across legal entities. We don't do that
much anymore - or if we do, I'd ask to see some evidence that the volume of
business computing done on PCs/Workstations/Other-Local-Arrangements is
exceeded by the volume of computing done by someone's centralized mainframe.
I have the evidence of my own eyes when I look around in various businesses.
If there's some evidence I'm not seeing, then I'd like someone to bring it
forward.

I seem to be getting misunderstood for reasons I don't comprehend. We
*used*to* have centralized computing. We moved to *distributed* computing
because it had big advantages over a centralized model. Microsoft is
*repackaging* a centralized model and telling us "No. Really. We were wrong
all along. It actually *is* Shinola!" and asking us to believe it is
something new and wonderful and that we should all want to get out our
checkbooks and start sending them money in order to get it.

I don't think my claim here is really a strong one. I'm *not* saying that it
is an exact duplicate of the centralized mainframe/data center concept. I'm
*not* saying that there aren't big and important differences between the
two. What I *am* saying is that we once had a centralized model and opted
out of it and that what Bill Gates is suggesting is essentially a
centralized model - with window dressing to try to fool us into believing it
is something new and wonderful.

Sort of like X-terminals being a "Glass-Teletype-With-Attitude" - it was a
rehash of something we once had and moved away from. Yes, X-terminals do
have important differences from teletypes (glass or otherwise) but the
notion that the central computer will do all the "real" computing and the
terminal will just be responsible for display of the information and input
from the user wasn't some sort of revolutionary new advancement in the field
of computer science. I wasn't fooled into thinking it was something new and
apparently most other people weren't either because when you go into your
garden-variety office you don't see thousands of x-terminals wired up to a
central mainframe. You see lots of PCs and workstations. If someone wants to
dispute this, I'd simply ask them for a reference to some kind of industry
survey that shows how X-terminals outnumber PCs/Workstations in the business
computing market.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:aPN5ieyHFSfT@eisner.encompasserve.org...
>
> But that was centralized within a legal entity, generally not across
> legal entities like Microsoft is suggesting.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
   at 08:21 AM, lesbell@nospam.lesbell.com.au said:

>"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:


>I seem to be getting misunderstood for reasons I don't comprehend.

You haven't been misunderstood, you've been corrected. Your knowledge
of DP history is faulty, and you haven't paid attention to those who
were there in the old days and told you the reality.

>We
>*used*to* have centralized computing. 

What you mean "we", kimosabi? As I said, it's not a question of
misunderstanding you, it's a question of correcting you. Maybe you
worked at a shop that had centralized computing, although I doubt it.
Such shops were not the norm.

>What I *am* saying is that we once had a centralized model and opted
>out of it 

And as long as you keep saying something demonstrably false your
conclusions remain suspect. The industry has had both decentralized
development on centralized hardware and centralized development on
decentralized hardware for as long as I can remember. Centralization
of one does not, has not and will not imply centralization of the
other.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...

: The industry has had both decentralized
: development on centralized hardware and centralized development on
: decentralized hardware for as long as I can remember.

Just out of curiosity, how long can you remember?

Re: Market pressures for more reliable software

[Ken Garlington]

"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:bbvZ6.1539$Cb1.798560367@newssvr17.news.prodigy.com...
: "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
: message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
:
: : The industry has had both decentralized
: : development on centralized hardware and centralized development on
: : decentralized hardware for as long as I can remember.
:
: Just out of curiosity, how long can you remember?

Let's say, just hypothetically, that you've been programming since 1960. How
long can you remember trends in the computing industry (which, presumably,
is different from either academic computing or hobbyist programming)?

In fact, let's go further - does your memory confirm that the OS/360
development effort described in Brooks was fairly typical (if not advanced)
for industrial computing in the early-to-mid 1960's?

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:


> Let's say, just hypothetically, that you've been programming since 1960. How
> long can you remember trends in the computing industry (which, presumably,
> is different from either academic computing or hobbyist programming)?

Trends were also different between scientific and commercial computing.
Centralized development was much more common in the commercial sector.

> In fact, let's go further - does your memory confirm that the OS/360
> development effort described in Brooks was fairly typical (if not advanced)
> for industrial computing in the early-to-mid 1960's?

I remember being shocked that the S/360 didn't include any relocation
capability. I remember that OS/360 inherited some nice features from
IBSYS/IBJOB. Overall, my memory confirms that it was less advanced but more
comprehensive than what was available from other vendors. In particular, both
UNIVAC and Burroughs had working multiprocessors on standard lines well before
the 65MP or even the 9020.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Gary Labowitz]

I'm curious what you mean by "relocation" that you were shocked that S/360
didn't have it. From the very outset the OS/360 design included a relocating
loader, which was very advanced for its time. The hardware redirection of
memory addresses (dynamic address translation -or DAT) came later (as I
recall about four years).
The development activity in Poughkeepsie was very untypical at the time.
The MP65 was pretty much a late-comer to market with multiprocessing, but it
never really went anywhere. Neither, BTW, did Burroughs, NCR, or Bendix.
Univac held on much longer. I remember losing a large contract to Univac in
the early '70's, but they later switched back to IBM.
As I went about learning PC's (and Apple) operating systems (including
Win32) I was struck with the fact that much of what was the "new" thing was
just a reimplementation of what we did on the S/360 in the mid '60's. Names
changed, and there was a lot more packed into the hardware, but a great deal
was the same. It has drifted a bit,by which I mean that there are some new
concepts pushing PC development in a different direction from the way OS/360
did things, but we were very close to what OOP is all about. IBM's biggest
mistake (like Apple) was trying to keep everything proprietary for market
advantage, and losing to the clones. I think Java is finally breaking into
the same sort of hold Microsoft has used by its "fully integrated" approach.
I will, of course, learn C#, but frankly I'm having more fun now with Java
than with VB (I never committed to C/C++). Perhaps it's just that it's newer
to me, but as long as the performance improves steadily, Java may well be
the challenge Microsoft needs for change, not court mandated crippling.
Gary
"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B387768.FF5E9744@acm.org...
>
>
> Ken Garlington wrote:
>
>
> > Let's say, just hypothetically, that you've been programming since 1960.
How
> > long can you remember trends in the computing industry (which,
presumably,
> > is different from either academic computing or hobbyist programming)?
>
> Trends were also different between scientific and commercial computing.
> Centralized development was much more common in the commercial sector.
>
> > In fact, let's go further - does your memory confirm that the OS/360
> > development effort described in Brooks was fairly typical (if not
advanced)
> > for industrial computing in the early-to-mid 1960's?
>
> I remember being shocked that the S/360 didn't include any relocation
> capability. I remember that OS/360 inherited some nice features from
> IBSYS/IBJOB. Overall, my memory confirms that it was less advanced but
more
> comprehensive than what was available from other vendors. In particular,
both
> UNIVAC and Burroughs had working multiprocessors on standard lines well
before
> the 65MP or even the 9020.
>
> --
> Shmuel (Seymour J.) Metz
>
>

Re: Market pressures for more reliable software

[Roedy Green]

On Wed, 27 Jun 2001 09:41:58 GMT, "Gary Labowitz" <garyl@enter.net>
wrote or quoted :

>I'm curious what you mean by "relocation" that you were shocked that S/360
>didn't have it.

The univac 1100, the IBM 360s predecessor, had a relocation register
so you could load a ram image and start executing without having to
make any adjustments.  

The 360 used absolute addresses. To load you had to adjust all the
address references to account for where in RAM the program was loaded.
This greatly slowed down the process of getting a program started.

Exploiting relocation hardware to speed loading is still not fully
exploited even in Windows NT.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[tmoran]

>The 360 used absolute addresses. To load you had to adjust all the
>address references to account for where in RAM the program was loaded.
>This greatly slowed down the process of getting a program started.
  IIRC in 1963 I was able to load and relocate on a CDC 1604 on
the fly as data came in from the high-speed tape drive (92 mics/word
or 46 mics/address, as I recall).  So relocation time shouldn't have
been a big problem for a 360.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Gary Labowitz wrote:

> I'm curious what you mean by "relocation" that you were shocked that S/360
> didn't have it.

At the time the S/360 was announced, CDC, GE and UNIVAC had block relocation in
the hardware. Ferranti had paging. Burroughs had segmented virtual memory. IBM
had paging in the laboratory. And S/360? S/360 had nada.

> From the very outset the OS/360 design included a relocating
> loader, which was very advanced for its time.

You're confusing S/360 with OS/360. Fetch was software. Further, once a program
was loaded it could not be moved, despite the vain hopes of those developing VMS
(no, not that VMS.)


> Neither, BTW, did Burroughs, NCR, or Bendix.
> Univac held on much longer.

Burroughs continued selling the B2500 and B6500 lines for a considerable amount
of time. More to the point, the degree of market success tells nothing about
what technological features were present.


> As I went about learning PC's (and Apple) operating systems (including
> Win32) I was struck with the fact that much of what was the "new" thing was
> just a reimplementation of what we did on the S/360 in the mid '60's.

There we agree. The PC industry has been characterized by reinventing the wheel
and by the NIH syndrome.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Gary Labowitz]

And now it's you that needs correction. Most shops in the early days were
centralized computing. And most of those were centralized development as
well. [Definition: centralized -- a single computer at a centralized
location. All computing is done on that computer. Users go physically to
that computer site and either submit jobs directly to the machine, being
given time on the machine to use it, or submit jobs to a checkpoint from
which operators submit the jobs for the user. If the site was large enough
to have several computers they were clustered in the same general area and
users selected which of the computers would be used for their individual
jobs.]

I can remember back to 1962 (when I started with IBM) but built my first
computer in 1956.
Your turn.
Gary
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
>    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
>
> >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:
>
>
> >I seem to be getting misunderstood for reasons I don't comprehend.
>
> You haven't been misunderstood, you've been corrected. Your knowledge
> of DP history is faulty, and you haven't paid attention to those who
> were there in the old days and told you the reality.
>
> >We
> >*used*to* have centralized computing.
>
> What you mean "we", kimosabi? As I said, it's not a question of
> misunderstanding you, it's a question of correcting you. Maybe you
> worked at a shop that had centralized computing, although I doubt it.
> Such shops were not the norm.
>
> >What I *am* saying is that we once had a centralized model and opted
> >out of it
>
> And as long as you keep saying something demonstrably false your
> conclusions remain suspect. The industry has had both decentralized
> development on centralized hardware and centralized development on
> decentralized hardware for as long as I can remember. Centralization
> of one does not, has not and will not imply centralization of the
> other.
>
> --
> -----------------------------------------------------------
>      Shmuel (Seymour J.) Metz, SysProg and JOAT
>      Atid/2
>      Team OS/2
>      Team PL/I
>
> Any unsolicited commercial junk E-mail will be subject to legal
> action.  I reserve the right to publicly post or ridicule any
> abusive E-mail.
>
> I mangled my E-mail address to foil automated spammers; reply to
> domain acm dot org user shmuel to contact me.  Do not reply to
> spamtrap@library.lspace.org
> -----------------------------------------------------------
>

Re: Market pressures for more reliable software

[Marin David Condic]

Maybe I'm just in the springtime of my senility, but that's pretty much how
I remember it and pretty much what I was trying to describe. "distributed"
computing was not around in the days of the ENIAC and vacuume tube
computing - so pretty much ipso facto, "centralized" computing existed
first. When all that existed in the entire universe were big gigundous
computers that had to be kept in hermetically sealed rooms, people didn't
have one of them sitting under their desk - so "centralized" computing
existed and "distributed" computing didn't.

Like I said, I didn't think I was making an extravagant claim here or going
against what was pretty much accepted interpretation of computing historical
facts. Since I'm not trying to say something like "The Earth Is Flat!" I'm
believing that somehow I'm miscommunicating. OTOH, if someone wants to
believe that computing only started when IBM invented the PC, then I suppose
that belief would lead one to conclude that "distributed" and "centralized"
computing have always existed side-by-side and it has never been otherwise.
I suppose there really isn't anything I can do about that belief.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gary Labowitz" <garyl@enter.net> wrote in message
news:AkCZ6.1988$Tt6.825475@monger.newsread.com...
> And now it's you that needs correction. Most shops in the early days were
> centralized computing. And most of those were centralized development as
> well. [Definition: centralized -- a single computer at a centralized
> location. All computing is done on that computer. Users go physically to
> that computer site and either submit jobs directly to the machine, being
> given time on the machine to use it, or submit jobs to a checkpoint from
> which operators submit the jobs for the user. If the site was large enough
> to have several computers they were clustered in the same general area and
> users selected which of the computers would be used for their individual
> jobs.]
>
> I can remember back to 1962 (when I started with IBM) but built my first
> computer in 1956.
> Your turn.
> Gary
> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
> message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> > In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
> >    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
> >
> > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:
> >
> >
> > >I seem to be getting misunderstood for reasons I don't comprehend.
> >
> > You haven't been misunderstood, you've been corrected. Your knowledge
> > of DP history is faulty, and you haven't paid attention to those who
> > were there in the old days and told you the reality.
> >
> > >We
> > >*used*to* have centralized computing.
> >
> > What you mean "we", kimosabi? As I said, it's not a question of
> > misunderstanding you, it's a question of correcting you. Maybe you
> > worked at a shop that had centralized computing, although I doubt it.
> > Such shops were not the norm.
> >
> > >What I *am* saying is that we once had a centralized model and opted
> > >out of it
> >
> > And as long as you keep saying something demonstrably false your
> > conclusions remain suspect. The industry has had both decentralized
> > development on centralized hardware and centralized development on
> > decentralized hardware for as long as I can remember. Centralization
> > of one does not, has not and will not imply centralization of the
> > other.
> >
> > --
> > -----------------------------------------------------------
> >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> >      Atid/2
> >      Team OS/2
> >      Team PL/I
> >
> > Any unsolicited commercial junk E-mail will be subject to legal
> > action.  I reserve the right to publicly post or ridicule any
> > abusive E-mail.
> >
> > I mangled my E-mail address to foil automated spammers; reply to
> > domain acm dot org user shmuel to contact me.  Do not reply to
> > spamtrap@library.lspace.org
> > -----------------------------------------------------------
> >
>
>

Re: Market pressures for more reliable software

[David C. Hoos]

It seems to me that what we have here is a semantic tempest in a teapot.

In 1958, I had an IBM 610 computer that operated in an office
environment, and certainly was not "centralized," in that any member of
the engineering staff who wished to use it in his work was free to do so.

A few years later we moved up to an IBM 1620, again in an office
environment and not "centralized."

Not until we moved up to a 360, was there any semblance of
"centralization," and this was mainly for scheduling purposes.  We still
did our own keypunching, and ran our own jobs.

----- Original Message -----
From: "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
Newsgroups:
comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.la
ng.java.advocacy
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, June 25, 2001 9:13 AM
Subject: Re: Market pressures for more reliable software


> Maybe I'm just in the springtime of my senility, but that's pretty much
how
> I remember it and pretty much what I was trying to describe. "distributed"
> computing was not around in the days of the ENIAC and vacuume tube
> computing - so pretty much ipso facto, "centralized" computing existed
> first. When all that existed in the entire universe were big gigundous
> computers that had to be kept in hermetically sealed rooms, people didn't
> have one of them sitting under their desk - so "centralized" computing
> existed and "distributed" computing didn't.
>
> Like I said, I didn't think I was making an extravagant claim here or
going
> against what was pretty much accepted interpretation of computing
historical
> facts. Since I'm not trying to say something like "The Earth Is Flat!" I'm
> believing that somehow I'm miscommunicating. OTOH, if someone wants to
> believe that computing only started when IBM invented the PC, then I
suppose
> that belief would lead one to conclude that "distributed" and
"centralized"
> computing have always existed side-by-side and it has never been
otherwise.
> I suppose there really isn't anything I can do about that belief.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
>
> "Gary Labowitz" <garyl@enter.net> wrote in message
> news:AkCZ6.1988$Tt6.825475@monger.newsread.com...
> > And now it's you that needs correction. Most shops in the early days
were
> > centralized computing. And most of those were centralized development as
> > well. [Definition: centralized -- a single computer at a centralized
> > location. All computing is done on that computer. Users go physically to
> > that computer site and either submit jobs directly to the machine, being
> > given time on the machine to use it, or submit jobs to a checkpoint from
> > which operators submit the jobs for the user. If the site was large
enough
> > to have several computers they were clustered in the same general area
and
> > users selected which of the computers would be used for their individual
> > jobs.]
> >
> > I can remember back to 1962 (when I started with IBM) but built my first
> > computer in 1956.
> > Your turn.
> > Gary
> > "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote
in
> > message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> > > In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
> > >    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
> > >
> > > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:
> > >
> > >
> > > >I seem to be getting misunderstood for reasons I don't comprehend.
> > >
> > > You haven't been misunderstood, you've been corrected. Your knowledge
> > > of DP history is faulty, and you haven't paid attention to those who
> > > were there in the old days and told you the reality.
> > >
> > > >We
> > > >*used*to* have centralized computing.
> > >
> > > What you mean "we", kimosabi? As I said, it's not a question of
> > > misunderstanding you, it's a question of correcting you. Maybe you
> > > worked at a shop that had centralized computing, although I doubt it.
> > > Such shops were not the norm.
> > >
> > > >What I *am* saying is that we once had a centralized model and opted
> > > >out of it
> > >
> > > And as long as you keep saying something demonstrably false your
> > > conclusions remain suspect. The industry has had both decentralized
> > > development on centralized hardware and centralized development on
> > > decentralized hardware for as long as I can remember. Centralization
> > > of one does not, has not and will not imply centralization of the
> > > other.
> > >
> > > --
> > > -----------------------------------------------------------
> > >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> > >      Atid/2
> > >      Team OS/2
> > >      Team PL/I
> > >
> > > Any unsolicited commercial junk E-mail will be subject to legal
> > > action.  I reserve the right to publicly post or ridicule any
> > > abusive E-mail.
> > >
> > > I mangled my E-mail address to foil automated spammers; reply to
> > > domain acm dot org user shmuel to contact me.  Do not reply to
> > > spamtrap@library.lspace.org
> > > -----------------------------------------------------------
> > >
> >
> >
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Market pressures for more reliable software

[Marin David Condic]

O.K. I give up. There never were centralized computer centers where people
logged on and did work on data and programs that were kept in a central
place. People always had computers on their desks and computing was always
distributed. Networks of computers existed since before the vacuume tube was
invented and were *instantly* in use the very same day that the very first
computer was turned on - even though there were no other computers to
connect to. Bill Gates is therefore proposing something brand new that the
world has never seen before. Everyone should run out and buy it now because
it will dramatically change your life in a way never before seen or heard or
even dreampt of!

Just think: For the very first time in the entire history of the universe,
you can store your data on a big disk shared by thousands of other users!
You'll be able to execute a program maintained by a team of experts that is
continually updated so that every time you execute it from its central
storage location, you automatically get the latest and greatest version!
Never before have your eyes witnessed such a monumental feat or such a huge
advancement in the field of computer science! Watch and be amazed as our
small team of highly trained technicians actually *back*up* your data on a
nightly basis so that for the first time ever, you'll be safe in the event
of a disk crash! Why, you'll be so amazed by the convenience that you'll
*instantly* scrap that antique PC on your desk in favor of Microsoft's
latest invention which the marketing guys are calling "The Teletype"
utilizing all new "Paper v1.0 (tm)" as its micro-thin display technology.
You'll be able to connect to the centralized computer from anywhere in the
world at any hour of the day or night using a device Microsoft just invented
called "The Modem".

Gosh, I'm just so glad that everyone here has disabused me of the notion
that this might have somehow sounded familiar. I've seen the light. I think
I'll get down on my knees and thank God that Bill Gates is in the world
inventing new things daily. Where do I sign up?

Now maybe I can start an argument in the other direction? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote in message
news:mailman.993483499.4923.comp.lang.ada@ada.eu.org...
> It seems to me that what we have here is a semantic tempest in a teapot.
>
> In 1958, I had an IBM 610 computer that operated in an office
> environment, and certainly was not "centralized," in that any member of
> the engineering staff who wished to use it in his work was free to do so.
>
> A few years later we moved up to an IBM 1620, again in an office
> environment and not "centralized."
>
> Not until we moved up to a 360, was there any semblance of
> "centralization," and this was mainly for scheduling purposes.  We still
> did our own keypunching, and ran our own jobs.
>
> ----- Original Message -----
> From: "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
> Newsgroups:
>
comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.la
> ng.java.advocacy
> To: <comp.lang.ada@ada.eu.org>
> Sent: Monday, June 25, 2001 9:13 AM
> Subject: Re: Market pressures for more reliable software
>
>
> > Maybe I'm just in the springtime of my senility, but that's pretty much
> how
> > I remember it and pretty much what I was trying to describe.
"distributed"
> > computing was not around in the days of the ENIAC and vacuume tube
> > computing - so pretty much ipso facto, "centralized" computing existed
> > first. When all that existed in the entire universe were big gigundous
> > computers that had to be kept in hermetically sealed rooms, people
didn't
> > have one of them sitting under their desk - so "centralized" computing
> > existed and "distributed" computing didn't.
> >
> > Like I said, I didn't think I was making an extravagant claim here or
> going
> > against what was pretty much accepted interpretation of computing
> historical
> > facts. Since I'm not trying to say something like "The Earth Is Flat!"
I'm
> > believing that somehow I'm miscommunicating. OTOH, if someone wants to
> > believe that computing only started when IBM invented the PC, then I
> suppose
> > that belief would lead one to conclude that "distributed" and
> "centralized"
> > computing have always existed side-by-side and it has never been
> otherwise.
> > I suppose there really isn't anything I can do about that belief.
> >
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas    www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> >
> > "Gary Labowitz" <garyl@enter.net> wrote in message
> > news:AkCZ6.1988$Tt6.825475@monger.newsread.com...
> > > And now it's you that needs correction. Most shops in the early days
> were
> > > centralized computing. And most of those were centralized development
as
> > > well. [Definition: centralized -- a single computer at a centralized
> > > location. All computing is done on that computer. Users go physically
to
> > > that computer site and either submit jobs directly to the machine,
being
> > > given time on the machine to use it, or submit jobs to a checkpoint
from
> > > which operators submit the jobs for the user. If the site was large
> enough
> > > to have several computers they were clustered in the same general area
> and
> > > users selected which of the computers would be used for their
individual
> > > jobs.]
> > >
> > > I can remember back to 1962 (when I started with IBM) but built my
first
> > > computer in 1956.
> > > Your turn.
> > > Gary
> > > "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote
> in
> > > message news:3b366a2b$6$fuzhry$mr2ice@va.news.verio.net...
> > > > In <YXDX6.1$MM4.254@nsw.nnrp.telstra.net>, on 06/19/2001
> > > >    at 08:21 AM, lesbell@nospam.lesbell.com.au said:
> > > >
> > > > >"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>
wrote:
> > > >
> > > >
> > > > >I seem to be getting misunderstood for reasons I don't comprehend.
> > > >
> > > > You haven't been misunderstood, you've been corrected. Your
knowledge
> > > > of DP history is faulty, and you haven't paid attention to those who
> > > > were there in the old days and told you the reality.
> > > >
> > > > >We
> > > > >*used*to* have centralized computing.
> > > >
> > > > What you mean "we", kimosabi? As I said, it's not a question of
> > > > misunderstanding you, it's a question of correcting you. Maybe you
> > > > worked at a shop that had centralized computing, although I doubt
it.
> > > > Such shops were not the norm.
> > > >
> > > > >What I *am* saying is that we once had a centralized model and
opted
> > > > >out of it
> > > >
> > > > And as long as you keep saying something demonstrably false your
> > > > conclusions remain suspect. The industry has had both decentralized
> > > > development on centralized hardware and centralized development on
> > > > decentralized hardware for as long as I can remember. Centralization
> > > > of one does not, has not and will not imply centralization of the
> > > > other.
> > > >
> > > > --
> > > > -----------------------------------------------------------
> > > >      Shmuel (Seymour J.) Metz, SysProg and JOAT
> > > >      Atid/2
> > > >      Team OS/2
> > > >      Team PL/I
> > > >
> > > > Any unsolicited commercial junk E-mail will be subject to legal
> > > > action.  I reserve the right to publicly post or ridicule any
> > > > abusive E-mail.
> > > >
> > > > I mangled my E-mail address to foil automated spammers; reply to
> > > > domain acm dot org user shmuel to contact me.  Do not reply to
> > > > spamtrap@library.lspace.org
> > > > -----------------------------------------------------------
> > > >
> > >
> > >
> >
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >
>

Re: Market pressures for more reliable software

[Wes Groleau]

> Not until we moved up to a 360, was there any semblance of
> "centralization," and this was mainly for scheduling purposes.  We still
> did our own keypunching, and ran our own jobs.

While I was in high school, "OTIS" was introduced:
the "Oregon Total Information System"  This was a 360
that contained ALL public school grade records for the
whole state.  How's that for centralization?

At the same time, my algebra teacher's husband had
full control of a PDP-8 (eight-bit computer bigger
than a file cabinet!) in his nuclear physics lab.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Market pressures for more reliable software

[Al Christians]

Wes Groleau wrote:
> 
> > Not until we moved up to a 360, was there any semblance of
> > "centralization," and this was mainly for scheduling purposes.  We still
> > did our own keypunching, and ran our own jobs.
> 
> While I was in high school, "OTIS" was introduced:
> the "Oregon Total Information System"  This was a 360
> that contained ALL public school grade records for the
> whole state.  How's that for centralization?
> 
> At the same time, my algebra teacher's husband had
> full control of a PDP-8 (eight-bit computer bigger
> than a file cabinet!) in his nuclear physics lab.
> 

These things live forever.  I think that OTIS still lives.
It's not run statewide anymore, but it is run by school
districts and extended school districts covering large
areas but not many kids.  I think that the commercial 
group that was supporting OTIS has just closed up, though,
and that the districts are picking up newer alternatives.

That ought to be a good market for Ada.  OTIS demonstrates
that these systems have a very long lifecycle, which is 
what Ada was designed for.  There is also some need for
reliability.  Note that about 10,000 kids in New York went
to summer school on account of a computer error in scoring
tests, and some principals have had their careers suffer on 
account of school software errors.  And then there are all
the security worries about kids trying to hack into everything. 

Anyone know if there are any competitors in that market that
make it an unattractive proposition for product development?


Al

Re: Market pressures for more reliable software

[David Thompson]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote :
...
> At the same time, my algebra teacher's husband had
> full control of a PDP-8 (eight-bit computer bigger
> than a file cabinet!) in his nuclear physics lab.

The PDP-8 was a 12-bit architecture, and
bigger than a file cabinet only if you had a
very large -8 configuration (lots of peripherals
to fill up a rack) or a very small file cabinet.
Might it have been a PDP-11?  Early models
of that family (before LSI) were usually at least
one full-height 19" rack and often several,
and the primary data paths are 16-bit
it does address 8-bit bytes (in memory).

--
- David.Thompson 1 now at worldnet.att.net

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Marin David Condic wrote:

> Maybe I'm just in the springtime of my senility, but that's pretty much how
> I remember it and pretty much what I was trying to describe. "distributed"
> computing was not around in the days of the ENIAC and vacuume tube
> computing - so pretty much ipso facto, "centralized" computing existed
> first. When all that existed in the entire universe were big gigundous
> computers that had to be kept in hermetically sealed rooms, people didn't
> have one of them sitting under their desk - so "centralized" computing
> existed and "distributed" computing didn't.

ENIAC was before my time, but I'd agree that development was probably
centralized in those days. What is in dispute is whether development was
centralized in the years or decades immediately preceding the PC. But
distributed development occurred even when the computer was centralized, even
before the 7090.

> Like I said, I didn't think I was making an extravagant claim here or going
> against what was pretty much accepted interpretation of computing historical
> facts. Since I'm not trying to say something like "The Earth Is Flat!" I'm
> believing that somehow I'm miscommunicating. OTOH, if someone wants to
> believe that computing only started when IBM invented the PC, then I suppose
> that belief would lead one to conclude that "distributed" and "centralized"
> computing have always existed side-by-side and it has never been otherwise.
> I suppose there really isn't anything I can do about that belief.

Actually, IBM didn't invent the personal computer, although it did significantly
alter the accepted architecture. IBM did push "personal computing" before there
was a noticeable personal computer industry, with such products as CALL/360 and
VSPC.

Re: Market pressures for more reliable software

[David C. Hoos]

"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B3879CE.AC550F8E@acm.org...
>
<snip>
> Actually, IBM didn't invent the personal computer, although it did
significantly
> alter the accepted architecture. IBM did push "personal computing" before
there
> was a noticeable personal computer industry, with such products as
CALL/360 and
> VSPC.
And such products as the 5100 and 5110.

Re: Market pressures for more reliable software

[Al Christians]

"Shmuel (Seymour J.) Metz" wrote:
> 
> Marin David Condic wrote:
> 
> 
> Actually, IBM didn't invent the personal computer, although it did significantly
> alter the accepted architecture. IBM did push "personal computing" before there
> was a noticeable personal computer industry, with such products as CALL/360 and
> VSPC.

And there was Joss, which ran on the Johnniac.  That was an early step
toward end-user programming.

Al

Re: Market pressures for more reliable software

[Marin David Condic]

Just for the record, I did not make the statement below. Depending on just
what sort of definition one has for "Personal Computer" - crediting IBM with
its invention becomes either true or false. I believe it is accurate to say
that IBM was the first to use the words "Personal Computer" in
characterizing a computer that they manufactured (Here is sunny Boca Raton,
BTW) in their advertising. However they were not the first to manufacture a
small, inexpensive computer designed to be used primarily by a single
individual.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B38975D.7BE3BDE7@easystreet.com...
> "Shmuel (Seymour J.) Metz" wrote:
> >
> > Marin David Condic wrote:
> >
> >
> > Actually, IBM didn't invent the personal computer, although it did
significantly
> > alter the accepted architecture. IBM did push "personal computing"
before there
> > was a noticeable personal computer industry, with such products as
CALL/360 and
> > VSPC.
>
> And there was Joss, which ran on the Johnniac.  That was an early step
> toward end-user programming.
>
> Al

Re: Market pressures for more reliable software

[Wes Groleau]

.... they [IBM] were not the first to manufacture a
> small, inexpensive computer designed to be used primarily by a single
> individual.

But they  did  unintentionally give that market a big boost.
Hundreds of businessmen (women, too?) were scratching their
heads in front of computer store windows, wondering whether
it was worth the risk, when the stock clerk set out something
with the IBM logo, and the decision was made.  Ironically,
engineering-wise, PC meant Piece of Crap for that model.
Only thing worse, to my knowledge, for that era was the
appropriately nicknamed Trash-80.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

RE: Market pressures for more reliable software

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: Marin David Condic et al.
Texas Instruments had a better computer running the UCSD Pascal system. When
the IBM PC appeared, TI dropped their good design and built an imperfect
clone. I believe Compac was started by some disgruntled TI engineers, who
wanted to build a proper clone. Altair, Sphere, and I believe Apple came
before the IBM PC. Amusingly, IBM had a scientific PC based on the Intel
Multibus and a Motorola processor. This scientific PC, which was
subsequently killed, was a better design than the Intel powered PC.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of Marin David Condic
Sent: Tuesday, June 26, 2001 8:00 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Market pressures for more reliable software


Just for the record, I did not make the statement below. Depending on just
what sort of definition one has for "Personal Computer" - crediting IBM with
its invention becomes either true or false. I believe it is accurate to say
that IBM was the first to use the words "Personal Computer" in
characterizing a computer that they manufactured (Here is sunny Boca Raton,
BTW) in their advertising. However they were not the first to manufacture a
small, inexpensive computer designed to be used primarily by a single
individual.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B38975D.7BE3BDE7@easystreet.com...
> "Shmuel (Seymour J.) Metz" wrote:
> >
> > Marin David Condic wrote:
> >
> >
> > Actually, IBM didn't invent the personal computer, although it did
significantly
> > alter the accepted architecture. IBM did push "personal computing"
before there
> > was a noticeable personal computer industry, with such products as
CALL/360 and
> > VSPC.
>
> And there was Joss, which ran on the Johnniac.  That was an early step
> toward end-user programming.
>
> Al

Re: Market pressures for more reliable software

[Marin David Condic]

Well, there were certainly a lot of computers before the IBM-PC. I seem to
recall that it was IBM who coined the phrase "Personal Computer" - prior to
that people called them "home computers" or "microcomputers" or a variety of
other terminology. If the name is what's important, then it would seem that
IBM "invented" the first "PC". If the architecture is what's important,
again IBM wins by simple definition - they designed the architecture that
everyone else followed. If its the concept of a "small computer for personal
use" that's important, then we have a whole slew of possible winners. It's
all just a matter of definition... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert C. Leif, Ph.D." <rleif@rleif.com> wrote in message
news:mailman.993612920.5656.comp.lang.ada@ada.eu.org...
> From: Bob Leif
> To: Marin David Condic et al.
> Texas Instruments had a better computer running the UCSD Pascal system.
When
> the IBM PC appeared, TI dropped their good design and built an imperfect
> clone. I believe Compac was started by some disgruntled TI engineers, who
> wanted to build a proper clone. Altair, Sphere, and I believe Apple came
> before the IBM PC. Amusingly, IBM had a scientific PC based on the Intel
> Multibus and a Motorola processor. This scientific PC, which was
> subsequently killed, was a better design than the Intel powered PC.
>

Re: Market pressures for more reliable software

[tmoran]

>And there was Joss, which ran on the Johnniac.  That was an early step
>toward end-user programming.
  Toward the other end of the time-scale, T/Maker (an early competitor to
Visicalc) came from a programmer in a bank MIS department who got sick
of requests for simple tabular data reports that came to the MIS
department and spent months getting approved and assigned and then
hours getting implemented.  So that style still existed in the early '80s.

Re: Market pressures for more reliable software

[Roedy Green]

On Tue, 26 Jun 2001 08:02:24 -0400, "Shmuel (Seymour J.) Metz"
<nospam@acm.org> wrote or quoted :

>
>distributed development occurred even when the computer was centralized, even
>before the 7090.
 
That was true at universities, but not true at utilities.  There was a
computer department that handled all programming.

For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Roedy Green wrote:

> That was true at universities, but not true at utilities.  There was a
> computer department that handled all programming.

There were a number of market segments. The financial sector tended more to
centralized development, the scientific and engineering segments more to
decentralized development. As costs came down, there was also movement towards
departmental mainframes lined with NJE.


--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 28 Jun 2001 07:50:51 -0400, "Shmuel (Seymour J.) Metz"
<nospam@acm.org> wrote or quoted :

>As costs came down, there was also movement towards
>departmental mainframes lined with NJE.

At the utilities I am familiar with that is what happened. Engineering
groups in the 80s went for minis, e.g. Vax, Prime, Data General, that
were easier to program for engineering.  There were great political
battles to keep everything in the IBM camp under central control.

I learned about the power of politics.  The entire evaluation and
implementation team was "released" after we picked the "wrong"
computer (Burroughs instead of IBM) for a new gas project to track
where all the pipes were in the ground.  Released means you are
effectively fired, but you are still on salary, free to roam the
company seeking something useful to do.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Roedy Green wrote:

> That was true at universities, but not true at utilities.  There was a
> computer department that handled all programming.

There were a number of different market segments, and practices differed. The
financial sector was more prone to centralized development and the scientific and
engineering sectors were more prone to decentralized development. Then there were
departmental mainframes linked by NJE, once prices came down.

Re: Market pressures for more reliable software

[Lao Xiao Hai]

"Shmuel (Seymour J.) Metz" wrote:

> ENIAC was before my time, but I'd agree that development was probably
> centralized in those days. What is in dispute is whether development was
> centralized in the years or decades immediately preceding the PC. But
> distributed development occurred even when the computer was centralized, even
> before the 7090.

Perhaps.  But, for most organizations, emphasis on the word most, computing
resources within an organization was under the centralized managment of
one central authority.  Moreover, most of the computing was located in one
place.  It is true that some very large corporations had computers distributed
across their divisions, but that was a luxury not affordable by most of industry.

This centralization, during the 70's and through the mid-80's even extended to
collections of companies.   Ever hear of a service bureau.   In service bureaus
we centralized the computing for vertical markets as well as for such things
as payroll, general accounting, and other business applications.   There was
very little distributed development before the advent of, first the minicomputer,
and later the microcomputer.

Networks were still a mystery for most people.   Programmers were busy
grinding out programs in COBOL.   Compilers needed large memory spaces
and operating systems and these were hosted on million dollar plus machines,
making it too expensive to distribute them all over the place.  The exceptions
were the Fords, Chryslers, and other industrial giants with money to burn.

I spent a lot of years consulting to, developing software for, and cleaning up
after these centralized computing facilities.

Things are a lot more distributed now.   Frankly, as I look at the quality of some
of the software, I am not sure that can be classified as progress.

Richard Riehle

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Lao Xiao Hai wrote:"Perhaps.  But, for most organizations, emphasis on the word most,
computing

> resources within an organization was under the centralized managment of
> one central authority.  Moreover, most of the computing was located in one
> place.  It is true that some very large corporations had computers distributed
> across their divisions, but that was a luxury not affordable by most of industry.

You're missing the point the centralized equipment does not imply centralized use of
the equipment.


> This centralization, during the 70's and through the mid-80's even extended to
> collections of companies.   Ever hear of a service bureau.

ROTF,LMAO! Heard of them? I've worked for them. I've never heard of a service bureau
where the programming was centralized; the norm was that the customer did his own
programming.


> Networks were still a mystery for most people.

Most people didn't work with computers. Dialup access was common in the late '60s.


> Programmers were busy
> grinding out programs in COBOL.

I take it that you never had anything to do with scientific computing?


> Compilers needed large memory spaces
> and operating systems and these were hosted on million dollar plus machines,

Yeah, like the 650, 1401, 1620 and 1130? Maybe they weren't glamorous, and they were
too small to be of interest to service bureaus except for the odd 1401 used as c/t and
t/p, but there were a lot of them.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Lao Xiao Hai]

"Shmuel (Seymour J.) Metz" wrote:

> Lao Xiao Hai wrote:"Perhaps.  But, for most organizations, emphasis on the word most,
> computing
>
> > resources within an organization was under the centralized managment of
> > one central authority.  Moreover, most of the computing was located in one
> > place.  It is true that some very large corporations had computers distributed
> > across their divisions, but that was a luxury not affordable by most of industry.
>
> You're missing the point the centralized equipment does not imply centralized use of
> the equipment.

I must be missing the point.    What was not centralized?   Programming was pretty
much centralized and under the control of a data processing manager.  Computers
were pretty much centralized, and there weren't that many that could drive remote
terminals really well.  Most of the data processing was in batch mode.

> > This centralization, during the 70's and through the mid-80's even extended to
> > collections of companies.   Ever hear of a service bureau.
>
> ROTF,LMAO! Heard of them? I've worked for them. I've never heard of a service bureau
> where the programming was centralized; the norm was that the customer did his own
> programming.

That is not how I remember it.  Most of the programs I recall were written by the
programmers
at the service bureau.  Some were packages purchased from elsewhere.   It was the rare
customer who had programming resources on which they could rely for their own software.
Usually, this task was contracted by the programmers within the service bureau.  Later,
there
were independent contractors who could do this for hire by the service bureau customer.

> > Networks were still a mystery for most people.
>
> Most people didn't work with computers. Dialup access was common in the late '60s.

Not that common.  And it was expensive.   We used it quite sparingly in most places.

> > Programmers were busy
> > grinding out programs in COBOL.
>
> I take it that you never had anything to do with scientific computing?

I have done both.   Certainly a lot of scientific computing was done using remote
computers.   However, I recall quite vividly those sites that had their own IBM 1130
and did their own Fortran programming.   I spent many late night hours writing Fortran II
and debugging on the 1130.

> > Compilers needed large memory spaces
> > and operating systems and these were hosted on million dollar plus machines,
>
> Yeah, like the 650, 1401, 1620 and 1130? Maybe they weren't glamorous, and they were
> too small to be of interest to service bureaus except for the odd 1401 used as c/t and
> t/p, but there were a lot of them.

The IBM 1401 was the workhorse of industry for a long time.   It was the first machine
I learned to program.   It was not cheap.   In the companies where I worked on that
computer, we usually had more than one, just to get the work done.  There were almost
no programmers from outside the company.   The other computers you named were
certainly small, but they were also under the control/guidance of the MIS manager
at many companies.   Oh, and you forgot one of my personal favorites, the CDC
160 series.   The IBM System 360 series came along in 1964 and, along with its
clones and cousins, did required lots of memory, lots of dollars, and lots of
programming talent.  Most of those machines were still centralized up through
the mid-1970's when the minicomputers became common.   Even those minicomputers
were pretty much centralized in the small businesses that leased them.

There was some decentralization.   But I don't recall it being as widespread as you do.
This is particularly true of data processing, which was almost always centralized in
those early days.   It was certainly not decentralized in the way it is today.    Even so,

I am noticing that some very large organizations are moving back to a more centralized
computing authority.    User developed applications  (UDA's) are getting out-of-hand
and instead of saving money, are costing money.     Worse, many of the amateur
programmers who create UDA's are failing to build in the kinds of error control and
security one would expect of more rigorously defined software.   This is creating
vulnerabilities that would not have been tolerated in the centralized era.

Richard Riehle

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Lao Xiao Hai wrote:

> I must be missing the point.    What was not centralized?

As I said multiple times, programming.


> Programming was pretty
> much centralized and under the control of a data processing manager.  Computers
> were pretty much centralized, and there weren't that many that could drive remote
> terminals really well.

Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP Multileaving? And
that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and Wylbur on S/360, and
others on non-IBM hardware. There was enough time sharing and remote batch to drive a market
in plug-compatible terminals and modems.

> Most of the data processing was in batch mode.

Which doesn't make it centralized.


> That is not how I remember it.

Clearly. Either your experience was limited or your memory is faulty.



> Most of the programs I recall were written by the
> programmers
> at the service bureau.  Some were packages purchased from elsewhere.   It was the rare
> customer who had programming resources on which they could rely for their own software.

By the 70s most service bureaus were offering remote access. Ever wonder why?


> Not that common.

Common enough to drive a market in brand X clones of terminals and modems, e.g., Cope 45 for
remote batch, Vadic modems.


> And it was expensive.

TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.


> I have done both.   Certainly a lot of scientific computing was done using remote
> computers.   However, I recall quite vividly those sites that had their own IBM 1130
> and did their own Fortran programming.   I spent many late night hours writing Fortran II
> and debugging on the 1130.

And how many of those 1130s cost $150,000? To say nothing of the fact that a lot of them were
submitting jobs to larger machines.


> The IBM 1401 was the workhorse of industry for a long time.

And cost nowhere near $150,000.


> Oh, and you forgot one of my personal favorites, the CDC
> 160 series.

I didn't forget it, any more than I forgot LGP or RCA; I omitted it because I was
concentrating on the IBM marketplace.

> The IBM System 360 series came along in 1964 and, along with its
> clones and cousins, did required lots of memory, lots of dollars, and lots of
> programming talent.

The S/360 may have required lots of memory, but the most it would take was 64K. The 360/20 was
even smaller.


> I am noticing that some very large organizations are moving back to a more centralized
> computing authority.    User developed applications  (UDA's) are getting out-of-hand
> and instead of saving money, are costing money.     Worse, many of the amateur
> programmers who create UDA's are failing to build in the kinds of error control and
> security one would expect of more rigorously defined software.   This is creating
> vulnerabilities that would not have been tolerated in the centralized era.

Those shops that were centralized in the old days had their own horror stories. Things like
configuration management and backups were often slipshod, if they existed at all. Some of the
decentralized shops had their act together better than some of the centralized shops.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Phil Robyn]

"Shmuel (Seymour J.) Metz" wrote:

> <<<snip>>>
> Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP Multileaving? And
> that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and Wylbur on S/360

I'm still using Wylbur (the PC version) on WinNT!!!!

> , and
> others on non-IBM hardware. There was enough time sharing and remote batch to drive a market
> in plug-compatible terminals and modems.
>
> <<<snip>>>

--
Phil Robyn
Univ. of California, Berkeley

u n z i p    m y    a d d r e s s    t o    s e n d    e - m a i l

Re: Market pressures for more reliable software

[Gary Labowitz]

Ah, Universities! Seat of knowledge! Seat of learning! Seat of being
out-of-date in computer technology!
("... Be not the last to lay the old aside.")

"Phil Robyn" <probyn@zipuclink.berkeley.edu> wrote in message
news:3B4383D3.49C13CED@zipuclink.berkeley.edu...
> "Shmuel (Seymour J.) Metz" wrote:
>
<<snip>>
> I'm still using Wylbur (the PC version) on WinNT!!!!
 <<<snip>>>
>
> --
> Phil Robyn
> Univ. of California, Berkeley
>
> u n z i p    m y    a d d r e s s    t o    s e n d    e - m a i l
>
>

Re: Market pressures for more reliable software

[Phil Robyn]

Gary Labowitz wrote:

> Ah, Universities! Seat of knowledge! Seat of learning! Seat of being
> out-of-date in computer technology!
> ("... Be not the last to lay the old aside.")
>
> "Phil Robyn" <probyn@zipuclink.berkeley.edu> wrote in message
> news:3B4383D3.49C13CED@zipuclink.berkeley.edu...
> > "Shmuel (Seymour J.) Metz" wrote:
> >
> <<snip>>
> > I'm still using Wylbur (the PC version) on WinNT!!!!
>  <<<snip>>>
> >
>

Don't knock it if you haven't tried it....  Wylbur is still head and
shoulders above all other batch command interpreters.  Even
Windows Scripting Host still cannot put up a screen with multiple
fields for user input ....

--
Phil Robyn
Univ. of California, Berkeley

u n z i p    m y    a d d r e s s    t o    s e n d    e - m a i l

Re: Market pressures for more reliable software

[Gary Labowitz]

This is getting ridiculous. You are SO hoping that computing and programming
were not centralized that you skip an entrie generation.
When most people talk about early days, they mean when computers actually
came into the marketplace and were large centralized systems. Certainly
programmers could be stationed anywhere. But terminal systems (starting with
the various 1050-type systems) weren't available in the "early days."
Actually, I remember the introduction of the 1050 as a big deal (about 1963
or so, maybe a little later). To get programming into the machine it first
had to be keypunched, and that was almost always "centralized." You sent
your coding sheets to the center to be keypunched. Some of us would go there
ourselves and do our own keypunching (those that typed). On the Univac-I we
went to the computer and used the console keypunch.
Anyway, the later systems developed the RJE-type systems, which
decentralized the point at which program streams could be entered and
printed. They still connected to centralized processing, however. Since all
the terminals were dumb, there was only decentralized job entry and
printing.
The real point is: so what? So you said "in the early days we had
decentralized computing" and were wrong.
Live with it.
Let's get on with today's problems.
Gary
"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B432AD8.3828FB9@acm.org...
>
>
> Lao Xiao Hai wrote:
>
> > I must be missing the point.    What was not centralized?
>
> As I said multiple times, programming.
>
>
> > Programming was pretty
> > much centralized and under the control of a data processing manager.
Computers
> > were pretty much centralized, and there weren't that many that could
drive remote
> > terminals really well.
>
> Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP
Multileaving? And
> that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and
Wylbur on S/360, and
> others on non-IBM hardware. There was enough time sharing and remote batch
to drive a market
> in plug-compatible terminals and modems.
>
> > Most of the data processing was in batch mode.
>
> Which doesn't make it centralized.
>
>
> > That is not how I remember it.
>
> Clearly. Either your experience was limited or your memory is faulty.
>
>
>
> > Most of the programs I recall were written by the
> > programmers
> > at the service bureau.  Some were packages purchased from elsewhere.
It was the rare
> > customer who had programming resources on which they could rely for
their own software.
>
> By the 70s most service bureaus were offering remote access. Ever wonder
why?
>
>
> > Not that common.
>
> Common enough to drive a market in brand X clones of terminals and modems,
e.g., Cope 45 for
> remote batch, Vadic modems.
>
>
> > And it was expensive.
>
> TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.
>
>
> > I have done both.   Certainly a lot of scientific computing was done
using remote
> > computers.   However, I recall quite vividly those sites that had their
own IBM 1130
> > and did their own Fortran programming.   I spent many late night hours
writing Fortran II
> > and debugging on the 1130.
>
> And how many of those 1130s cost $150,000? To say nothing of the fact that
a lot of them were
> submitting jobs to larger machines.
>
>
> > The IBM 1401 was the workhorse of industry for a long time.
>
> And cost nowhere near $150,000.
>
>
> > Oh, and you forgot one of my personal favorites, the CDC
> > 160 series.
>
> I didn't forget it, any more than I forgot LGP or RCA; I omitted it
because I was
> concentrating on the IBM marketplace.
>
> > The IBM System 360 series came along in 1964 and, along with its
> > clones and cousins, did required lots of memory, lots of dollars, and
lots of
> > programming talent.
>
> The S/360 may have required lots of memory, but the most it would take was
64K. The 360/20 was
> even smaller.
>
>
> > I am noticing that some very large organizations are moving back to a
more centralized
> > computing authority.    User developed applications  (UDA's) are getting
out-of-hand
> > and instead of saving money, are costing money.     Worse, many of the
amateur
> > programmers who create UDA's are failing to build in the kinds of error
control and
> > security one would expect of more rigorously defined software.   This is
creating
> > vulnerabilities that would not have been tolerated in the centralized
era.
>
> Those shops that were centralized in the old days had their own horror
stories. Things like
> configuration management and backups were often slipshod, if they existed
at all. Some of the
> decentralized shops had their act together better than some of the
centralized shops.
>
> --
> Shmuel (Seymour J.) Metz
>
>

Re: Market pressures for more reliable software

[Marin David Condic]

You're wasting your breath. Sometimes people have such a strong need to be
right that they'll ignore all the reasoning and evidence to the contrary -
convoluting logic, redefining terminology, etc.. Often the original point is
totally forgotten in defending a position that isn't even related to it.

Move on to more productive concerns.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gary Labowitz" <garyl@enter.net> wrote in message
news:zWX07.100$9d.9473@newshog.newsread.com...
> This is getting ridiculous. You are SO hoping that computing and
programming
> were not centralized that you skip an entrie generation.
> When most people talk about early days, they mean when computers actually
> came into the marketplace and were large centralized systems. Certainly
> programmers could be stationed anywhere. But terminal systems (starting
with
> the various 1050-type systems) weren't available in the "early days."
> Actually, I remember the introduction of the 1050 as a big deal (about
1963
> or so, maybe a little later). To get programming into the machine it first
> had to be keypunched, and that was almost always "centralized." You sent
> your coding sheets to the center to be keypunched. Some of us would go
there
> ourselves and do our own keypunching (those that typed). On the Univac-I
we
> went to the computer and used the console keypunch.
> Anyway, the later systems developed the RJE-type systems, which
> decentralized the point at which program streams could be entered and
> printed. They still connected to centralized processing, however. Since
all
> the terminals were dumb, there was only decentralized job entry and
> printing.
> The real point is: so what? So you said "in the early days we had
> decentralized computing" and were wrong.
> Live with it.
> Let's get on with today's problems.
> Gary
> "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
> news:3B432AD8.3828FB9@acm.org...
> >
> >
> > Lao Xiao Hai wrote:
> >
> > > I must be missing the point.    What was not centralized?
> >
> > As I said multiple times, programming.
> >
> >
> > > Programming was pretty
> > > much centralized and under the control of a data processing manager.
> Computers
> > > were pretty much centralized, and there weren't that many that could
> drive remote
> > > terminals really well.
> >
> > Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS?
HASP
> Multileaving? And
> > that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and
> Wylbur on S/360, and
> > others on non-IBM hardware. There was enough time sharing and remote
batch
> to drive a market
> > in plug-compatible terminals and modems.
> >
> > > Most of the data processing was in batch mode.
> >
> > Which doesn't make it centralized.
> >
> >
> > > That is not how I remember it.
> >
> > Clearly. Either your experience was limited or your memory is faulty.
> >
> >
> >
> > > Most of the programs I recall were written by the
> > > programmers
> > > at the service bureau.  Some were packages purchased from elsewhere.
> It was the rare
> > > customer who had programming resources on which they could rely for
> their own software.
> >
> > By the 70s most service bureaus were offering remote access. Ever wonder
> why?
> >
> >
> > > Not that common.
> >
> > Common enough to drive a market in brand X clones of terminals and
modems,
> e.g., Cope 45 for
> > remote batch, Vadic modems.
> >
> >
> > > And it was expensive.
> >
> > TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.
> >
> >
> > > I have done both.   Certainly a lot of scientific computing was done
> using remote
> > > computers.   However, I recall quite vividly those sites that had
their
> own IBM 1130
> > > and did their own Fortran programming.   I spent many late night hours
> writing Fortran II
> > > and debugging on the 1130.
> >
> > And how many of those 1130s cost $150,000? To say nothing of the fact
that
> a lot of them were
> > submitting jobs to larger machines.
> >
> >
> > > The IBM 1401 was the workhorse of industry for a long time.
> >
> > And cost nowhere near $150,000.
> >
> >
> > > Oh, and you forgot one of my personal favorites, the CDC
> > > 160 series.
> >
> > I didn't forget it, any more than I forgot LGP or RCA; I omitted it
> because I was
> > concentrating on the IBM marketplace.
> >
> > > The IBM System 360 series came along in 1964 and, along with its
> > > clones and cousins, did required lots of memory, lots of dollars, and
> lots of
> > > programming talent.
> >
> > The S/360 may have required lots of memory, but the most it would take
was
> 64K. The 360/20 was
> > even smaller.
> >
> >
> > > I am noticing that some very large organizations are moving back to a
> more centralized
> > > computing authority.    User developed applications  (UDA's) are
getting
> out-of-hand
> > > and instead of saving money, are costing money.     Worse, many of the
> amateur
> > > programmers who create UDA's are failing to build in the kinds of
error
> control and
> > > security one would expect of more rigorously defined software.   This
is
> creating
> > > vulnerabilities that would not have been tolerated in the centralized
> era.
> >
> > Those shops that were centralized in the old days had their own horror
> stories. Things like
> > configuration management and backups were often slipshod, if they
existed
> at all. Some of the
> > decentralized shops had their act together better than some of the
> centralized shops.
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> >
>
>

Re: Market pressures for more reliable software

[Ken Garlington]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9i1q0r$324$1@nh.pace.co.uk...
: You're wasting your breath. Sometimes people have such a strong need to be
: right that they'll ignore all the reasoning and evidence to the contrary -
: convoluting logic, redefining terminology, etc.. Often the original point
is
: totally forgotten in defending a position that isn't even related to it.
:
: Move on to more productive concerns.
:
: MDC

If I understand the argument right, the proposed definition of
"decentralized programming" is "the programmer did not physically stand at
the CPU while working." By that definition, there *was* very little
centralized programming. Even when I had to submit batch cards to an
operator, who ran them through a reader standing next to the machine, I may
have punched the cards myself on a remote keypunch. Even when I had to have
someone sitting in the same room as the CPU punch the cards, I usually wrote
the contents down at my desk via card layout sheets. Even when I had to
physically key in programs at the console, I at least wrote flowcharts at my
desk. So, for the given definition, I suppose the argument is technically
true.

However, if you consider the environment described by Brooks as "centralized
programming," there was huge bunches of that when I got into the business,
both in academia and commercial worlds. Anyone who would claim that the
existence of HASP/JES (yay Houston!) significantly affected that model
didn't work in the places where I worked (which had both, but still followed
the Brooks model). The technology may have existed for large-scale
"distributed" (in the sense of time-sharing, significant distance from the
host, etc.), but a lot of organizations in the 70s and even 80s used a
tightly controlled batch job scheduling approach to manage assets.

To this day, if anyone says "OPTCD=Q" to me, I vow to hunt them down and
kill them.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:

> If I understand the argument right, the proposed definition of
> "decentralized programming" is "the programmer did not physically stand at
> the CPU while working."

That might be Condic's definition; it certainly isn't mine. I'm referring to
such <dws>unimportant</dws> matters as analysis, design, coding, documentation,
configuration control, debugging and resource allocation.


> However, if you consider the environment described by Brooks as "centralized
> programming," there was huge bunches of that when I got into the business,
> both in academia and commercial worlds. Anyone who would claim that the
> existence of HASP/JES (yay Houston!) significantly affected that model
> didn't work in the places where I worked (which had both, but still followed
> the Brooks model). The technology may have existed for large-scale
> "distributed" (in the sense of time-sharing, significant distance from the
> host, etc.), but a lot of organizations in the 70s and even 80s used a
> tightly controlled batch job scheduling approach to manage assets.

I have no doubt that there were organizations where development was centralized.
I never worked in one even though I've been programming since 1960 and worked
for a hardware vendor, and only once did I work for a company that had a
customer with centralized development. I've said repeatedly that different
market sectors tended to have different organizations, but Condic et al seem to
prefer rebutting things that I didn't say instead of addressing what I did say.

> To this day, if anyone says "OPTCD=Q" to me, I vow to hunt them down and
> kill them.

Why? Kill the people that developed the translate tables instead.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B4648A3.BECC1FE8@acm.org...
:
: Ken Garlington wrote:
:
: > If I understand the argument right, the proposed definition of
: > "decentralized programming" is "the programmer did not physically stand
at
: > the CPU while working."
:
: That might be Condic's definition; it certainly isn't mine. I'm referring
to
: such <dws>unimportant</dws> matters as analysis, design, coding,
documentation,
: configuration control, debugging and resource allocation.

Oddly enough, this is precisely the definition I *thought* you were using.
This definition, of course, means that there has never been truly
centralized programming, anywhere - even before the advent of computers -
for any organization of more than one or two people. (See the part of my
discussion that was snipped.) Sort of takes all of the meaning out of the
words "decentralized" and "centralized," doesn't it? Personally, I prefer my
words to have meaning...

: > However, if you consider the environment described by Brooks as
"centralized
: > programming," there was huge bunches of that when I got into the
business,
: > both in academia and commercial worlds. Anyone who would claim that the
: > existence of HASP/JES (yay Houston!) significantly affected that model
: > didn't work in the places where I worked (which had both, but still
followed
: > the Brooks model). The technology may have existed for large-scale
: > "distributed" (in the sense of time-sharing, significant distance from
the
: > host, etc.), but a lot of organizations in the 70s and even 80s used a
: > tightly controlled batch job scheduling approach to manage assets.
:
: I have no doubt that there were organizations where development was
centralized.
: I never worked in one even though I've been programming since 1960 and
worked
: for a hardware vendor, and only once did I work for a company that had a
: customer with centralized development.

Brooks describes the S/360 OS development environment in "Silver Bullet."
IIRC, that was an IBM product. Wasn't IBM a "hardware vendor" back then? (I
think they even had a pretty good market share :)

Those who worked *directly* for organizations developing business
application software might have a different perspective than those who
developed the hardware on which those machines operated.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Ken Garlington wrote:

> "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
> news:3B4648A3.BECC1FE8@acm.org...
> :
> : Ken Garlington wrote:
> :
> : > If I understand the argument right, the proposed definition of
> : > "decentralized programming" is "the programmer did not physically stand
> at
> : > the CPU while working."
> :
> : That might be Condic's definition; it certainly isn't mine. I'm referring
> to
> : such <dws>unimportant</dws> matters as analysis, design, coding,
> documentation,
> : configuration control, debugging and resource allocation.
>
> Oddly enough, this is precisely the definition I *thought* you were using.
> This definition, of course, means that there has never been truly
> centralized programming, anywhere - even before the advent of computers -
> for any organization of more than one or two people. (See the part of my
> discussion that was snipped.) Sort of takes all of the meaning out of the
> words "decentralized" and "centralized," doesn't it? Personally, I prefer my
> words to have meaning...

ROTF,LMAO!

There's never been truly decentralized analysis? There's never been truly
decentralized design? There's never been truly decentralized coding? There's
never been truly decentralized documentation? There's never been truly
decentralized configuration control? There's never been truly decentralized
resource allocation? Maybe in an anthill there isn't, but in any human
organization there certainly is.

If you want your words to have meaning, then you should invest some thought in
them before setting finger to keyboard.


> Brooks describes the S/360 OS development environment in "Silver Bullet."
> IIRC, that was an IBM product. Wasn't IBM a "hardware vendor" back then? (I
> think they even had a pretty good market share :)

Please learn the difference between an existential quantifier and a universal
quantifier. Although if George Mealy is to believe things weren't as well
controlled at IBM as they ought to have been, I never made any claims about how
IBM was run.

> Those who worked *directly* for organizations developing business
> application software might have a different perspective than those who
> developed the hardware on which those machines operated.

I've worked for both. Most of my experience has been on the customer side.

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
news:3B47CB75.234C0543@acm.org...
:
:
: Ken Garlington wrote:
:
: > "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
: > news:3B4648A3.BECC1FE8@acm.org...
: > :
: > : Ken Garlington wrote:
: > :
: > : > If I understand the argument right, the proposed definition of
: > : > "decentralized programming" is "the programmer did not physically
stand
: > at
: > : > the CPU while working."
: > :
: > : That might be Condic's definition; it certainly isn't mine. I'm
referring
: > to
: > : such <dws>unimportant</dws> matters as analysis, design, coding,
: > documentation,
: > : configuration control, debugging and resource allocation.
: >
: > Oddly enough, this is precisely the definition I *thought* you were
using.
: > This definition, of course, means that there has never been truly
: > centralized programming, anywhere - even before the advent of
computers -
: > for any organization of more than one or two people. (See the part of my
: > discussion that was snipped.) Sort of takes all of the meaning out of
the
: > words "decentralized" and "centralized," doesn't it? Personally, I
prefer my
: > words to have meaning...
:
: ROTF,LMAO!
:
: There's never been truly decentralized analysis? There's never been truly
: decentralized design? There's never been truly decentralized coding?
There's
: never been truly decentralized documentation? There's never been truly
: decentralized configuration control? There's never been truly
decentralized
: resource allocation? Maybe in an anthill there isn't, but in any human
: organization there certainly is.
:
: If you want your words to have meaning, then you should invest some
thought in
: them before setting finger to keyboard.

Errr... hello? Note that I am saying that *your definition* of decentralized
programming would lead one to the exact ridiculous conclusion that you take
so much care in ridiculing. I quote from my prior statement: "This
definition, of course, means..."

I'm glad that we agree that defining "decentalized" in the manner you appear
to espouse is silly, since then there would then be no possible chance to
have a "centralized" environment. Perhaps you could refocus your energy on a
better definition - one that would not lead to such an illogical conclusion.

I find your last statement satisfyingly ironic.

: > Brooks describes the S/360 OS development environment in "Silver
Bullet."
: > IIRC, that was an IBM product. Wasn't IBM a "hardware vendor" back then?
(I
: > think they even had a pretty good market share :)
:
: Please learn the difference between an existential quantifier and a
universal
: quantifier. Although if George Mealy is to believe things weren't as well
: controlled at IBM as they ought to have been, I never made any claims
about how
: IBM was run.

Actually, I made an A in my logic course. How did you do in your debate
course?

As I said below, I do not believe the experience described by Brooks is
atypical. Most respondents to this thread agree. Therefore, if we are to
build a case on which is position is merely based on an isolated anecdote,
and which represented the "usual" state of affairs, the weight of evidence
appears to be on my side.

: > Those who worked *directly* for organizations developing business
: > application software might have a different perspective than those who
: > developed the hardware on which those machines operated.
:
: I've worked for both. Most of my experience has been on the customer side.

So, you experience on the customer side indicates that the Brooks
description is atypical? Interesting. Perhaps you could justify such a
belief with some examples from your extensive business applications
development resume.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <eZq47.410$rt2.150095027@newssvr11.news.prodigy.com>, on 07/16/2001
   at 12:56 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>Errr... hello? Note that I am saying that *your definition* of
>decentralized programming would lead one to the exact ridiculous
>conclusion that you take so much care in ridiculing. 

I noted that you said that; I also noted that your claim was bogus.

>I'm glad that we agree that defining "decentalized" in the manner
>you appear to espouse is silly, since then there would then be no
>possible chance to have a "centralized" environment. 

Really? No chance of having centralized control over programming, etc?
It's not only possible, it's been done, quite often. My claim was that
it was done only in specific contexts rather than as an industry norm.

However, now I'm quite puzzled at what position you are trying to
defend. JUst what is it that you claim was universally centralized
prior to the PC, and by what definition, since you deny that
cetralization of the obvious is possible?

>Actually, I made an A in my logic course.

Then you must have forgotten quite a bit. Either that, or you are
deliberate refraining from logic.

>How did you do in your debate course?

Ah, so you have decided that winning a debate is more important than
being correct?

>So, you experience on the customer side indicates that the Brooks
>description is atypical?

My experience on the customer side indicates that there is massive
variation in management style. I don't recall Brooks denying that.
Brooks was describing how things were at IBM, or at least how he
perceived them.

>Perhaps you could justify such a
>belief with some examples from your extensive business applications
>development resume.

Are you asking for examples of centralized development or for examples
of decentralized development? Or just trying to muddy the water?


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b52d7f5$1$fuzhry$mr2ice@va.news.verio.net...
: In <eZq47.410$rt2.150095027@newssvr11.news.prodigy.com>, on 07/16/2001
:    at 12:56 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:
:
: >Errr... hello? Note that I am saying that *your definition* of
: >decentralized programming would lead one to the exact ridiculous
: >conclusion that you take so much care in ridiculing.
:
: I noted that you said that; I also noted that your claim was bogus.

Unfortunately, your argument was a straw man, since you used a definition
different than the one I referenced in my premise.

: >I'm glad that we agree that defining "decentalized" in the manner
: >you appear to espouse is silly, since then there would then be no
: >possible chance to have a "centralized" environment.
:
: Really? No chance of having centralized control over programming, etc?
: It's not only possible, it's been done, quite often. My claim was that
: it was done only in specific contexts rather than as an industry norm.

Since your definition of "centralized programming" seems now to be based on
organizational structures, not technology (making your earlier discussion of
remote job entry somewhat puzzling), perhaps you could post some examples of
"centralized programming" from this list of historical precedents which
occured "quite often," yet not frequently enough to be an "industry norm",
and discuss what key concepts they shared to make them "centralized". Per
your previous post, such "centralization" should encompass analysis, design,
coding, documentation, configuration control, debugging and resource
allocation. (This would seem to be more "software engineering" than
programming, but that's a minor point.)

: However, now I'm quite puzzled at what position you are trying to
: defend. JUst what is it that you claim was universally centralized
: prior to the PC, and by what definition, since you deny that
: cetralization of the obvious is possible?

As I noted previously, one definition of "centralized" programming is the
business environment as described in Brooks (and other respondents to this
thread), with the key concepts of (a) the CPUs are physically located close
together, in a single room or suite and (b) where the task of programming
(coding) requires the programmers to either enter the program at a single
"master" console, or to submit the programming job to a centrally located
operator corps for entry.

By contrast, "decentralized" programming has automation routinely available
at the programmer's work station (desk, etc.) without need of an
intermediary. (Brooks describes this as "interactive programming," and
indicates that it was rarely used at the time even though the technology was
available - see pg. 136.) We can further refine this by distinguishing
between the use of time-sharing systems connected directed to the
centralized set of CPUs described above using "dumb" terminals, etc., vs.
the availability of individual CPUs (PCs, etc.) from each programmer's desk.
The former case would still be considered "centralized" by some, since a
failure in the main computing cluster took down all available services, the
availability of tools, etc. could still be centrally controlled, and so
forth.

My claim (supported by Brooks and other respondents to this thread) is that
this concept of "decentralized programming," certainly the more "permissive"
second type described above, was not typically used in business computing in
the early years of that field. The definition presented above notes the
relevance of the PC to this argument.

: >Actually, I made an A in my logic course.
:
: Then you must have forgotten quite a bit. Either that, or you are
: deliberate refraining from logic.

Or that the logic taught in computer science in mathematics is a subset of
that needed for logical argument (see below).

: >How did you do in your debate course?
:
: Ah, so you have decided that winning a debate is more important than
: being correct?

Based on this evasive answer (and the inability to see more than two
possibilities in the previous statement), I assume you've never taken a
debate course and are unfamiliar with its goals. There are several resources
on the web that describe constructing a logical argument, and the associated
fallacies often committed by the uneducated or devious. I recommend

http://faqs.jmas.co.jp/FAQs/atheism/logic

I suppose that you could establish "being correct" through some means other
than the logic steps taught in debate classes (faith, etc.), but it would be
hypocritical to use these methods and then castigate others for "refraining
from logic."

: >So, you experience on the customer side indicates that the Brooks
: >description is atypical?
:
: My experience on the customer side indicates that there is massive
: variation in management style. I don't recall Brooks denying that.
: Brooks was describing how things were at IBM, or at least how he
: perceived them.

Actually, if you haven't read "Mythical Math-Month" (or have forgotten it),
you might want to read it (again). Certainly, no one who reads it should
come away thinking he was limiting himself to IBM. His description of
organizational structures is on pg. 78-79; given the various forms of your
definition of "decentralized programming", I couldn't say whether he
describes a "decentralized" organizational structure or a "centralized"
structure.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <lDF47.539$9H.206790759@newssvr11.news.prodigy.com>, on 07/16/2001
   at 05:37 PM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>Unfortunately, your argument was a straw man, since you used a
>definition different than the one I referenced in my premise.

ROTF,LMAO!

>Since your definition of "centralized programming" seems now to be
>based on organizational structures, not technology

Now? That's been the case all along.

>(making your earlier discussion of
>remote job entry somewhat puzzling),

Only to one who doesn't understand the logistics.

perhaps you could post some examples of
"centralized programming" from this list of historical precedents
which occured "quite often,"

MAX, aka ALS.

>and discuss what key concepts they shared to make them
>"centralized". 

I've already enumerated them.

>As I noted previously, one definition of "centralized" programming
>is the business environment as described in Brooks (and other
>respondents to this thread), with the key concepts of (a) the CPUs
>are physically located close together, in a single room or suite and
>(b) where the task of programming (coding) requires the programmers
>to either enter the program at a single "master" console, 

What have you been smoking. That mode of operation died in the 50s, if
not earlier. Certainly by 1960 programs were entered from cards, paper
tape or magnetic tape, not from the console.

>or to submit the programming job to a centrally located operator
>corps for entry.

I'm not sure what you mean by "programming job". If you mean "batch
job", there were plenty of "self serve" card readers at computer
centers in the late sixties, to say nothing of the Bisync work
stations you seem not to believe in.

>By contrast, "decentralized" programming has automation routinely
>available at the programmer's work station (desk, etc.) without need
>of an intermediary. (Brooks describes this as "interactive
>programming,"

ROTF,LMAO! You're conflating unrelated terms.

>I suppose that you could establish "being correct" through some
>means other than the logic steps taught in debate classes (faith,
>etc.), but it would be hypocritical to use these methods and then
>castigate others for "refraining from logic."

So we agree that you're a hypocrite.

>Actually, if you haven't read "Mythical Math-Month"

I have.

>(or have forgotten it),

I haven't. Including the discrepancies that went over your head.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b538445$1$fuzhry$mr2ice@va.news.verio.net...
: In <lDF47.539$9H.206790759@newssvr11.news.prodigy.com>, on 07/16/2001
:    at 05:37 PM, "Ken Garlington" <Ken.Garlington@computer.org> said:
:
: >Unfortunately, your argument was a straw man, since you used a
: >definition different than the one I referenced in my premise.
:
: ROTF,LMAO!

Based on this non-response response, you apparently concede that you cannot
dispute this point.

: >Since your definition of "centralized programming" seems now to be
: >based on organizational structures, not technology
:
: Now? That's been the case all along.
:
: >(making your earlier discussion of
: >remote job entry somewhat puzzling),
:
: Only to one who doesn't understand the logistics.

Based on this ad hominem response, you apparently concede that you cannot
dispute this fallacy (attempting to prove the widespread existence of an
organizational structure through the existence of technology), and accept
that it weakens your argument.

: perhaps you could post some examples of
: "centralized programming" from this list of historical precedents
: which occured "quite often,"
:
: MAX, aka ALS.

This does not appear to be an organizational structure. It appears to be a
technology. It also appears to be a single example, which would make the
support of the statement "quite often" to be tenuous at best. Therefore, it
does not support your argument.

: >and discuss what key concepts they shared to make them
: >"centralized".
:
: I've already enumerated them.

Based on this ad nauseum response, you apparently concede that you cannot
dispute this point.

: >As I noted previously, one definition of "centralized" programming
: >is the business environment as described in Brooks (and other
: >respondents to this thread), with the key concepts of (a) the CPUs
: >are physically located close together, in a single room or suite and
: >(b) where the task of programming (coding) requires the programmers
: >to either enter the program at a single "master" console,
:
: What have you been smoking. That mode of operation died in the 50s, if
: not earlier. Certainly by 1960 programs were entered from cards, paper
: tape or magnetic tape, not from the console.

The assertion that programs were *never* entered from a console would
surprise IBM 360 series operators, to say the least. However, since your
statement is covered in the very next clause, it is also irrelevant.

: >or to submit the programming job to a centrally located operator
: >corps for entry.
:
: I'm not sure what you mean by "programming job". If you mean "batch
: job", there were plenty of "self serve" card readers at computer
: centers in the late sixties, to say nothing of the Bisync work
: stations you seem not to believe in.

I assume the term "plenty" here is used in the same content as "quite often"
above; i.e. there was at least one example. Again, the availability of
technology is not particularly related to how it is routinely used within a
business organization. Coupled with the ad hominem non-response, the lack of
anything more than sparse anecdotal evidence fails to adequately support
your point. (Contrast this with my use of contemporary authoritative
references in the previous post).

: >By contrast, "decentralized" programming has automation routinely
: >available at the programmer's work station (desk, etc.) without need
: >of an intermediary. (Brooks describes this as "interactive
: >programming,"
:
: ROTF,LMAO! You're conflating unrelated terms.

Based on the absence of an explanation as to why these are "unrelated"
terms, I assume you're merely inserting a red herring to compensate for a
lack of a rational rebuttal.

: >I suppose that you could establish "being correct" through some
: >means other than the logic steps taught in debate classes (faith,
: >etc.), but it would be hypocritical to use these methods and then
: >castigate others for "refraining from logic."
:
: So we agree that you're a hypocrite.

No. You may believe I'm a hypocrite for using formal debate logic; this of
course does not advance your position any more than the other logical
fallacies (ad hominem attacks, in particular) that comprise this post.

: >Actually, if you haven't read "Mythical Math-Month"
:
: I have.
:
: >(or have forgotten it),
:
: I haven't. Including the discrepancies that went over your head.

Based on this ad hominem attack, coupled with the inability to support your
position through anything other than repeated assertions (e.g. by providing
references to MMM that were "over my head"), I see that you have no further
value to add to your position. Feel free to post additional irrelevant
observations if you like; however, I believe your position has been shown to
be fatally flawed. I can't see any reason to discuss it further.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <6pY57.813$Jv7.375807090@newssvr11.news.prodigy.com>, on 07/20/2001
   at 03:48 PM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>Based on this non-response response, you apparently concede that you
>cannot dispute this point.

No, just that I don't suffer fools gladly. I make a statement, you
attempt to change what I said by applying a bogus definition and then
expect me to take you seriously? No way.

No, if you want to start with a discussion of what terms to use, agree
to definitions and then discuss what positions we take in terms of
those definitions, fine. Bute as long as you want to play those
rhetorical games, I will respond to them as they deserve.

>Based on this ad hominem response, you apparently concede that you
>cannot dispute this fallacy (attempting to prove the widespread
>existence of an organizational structure through the existence of
>technology), and accept that it weakens your argument.

Nope, I'm just pointing out that there is an issue that you are either
deliberately refusing to address or don't understand. Techology
constrains organizational structure but does not determine it. More
specifically, improved speed of comminications makes structures viable
that are impractical without it.

>It also appears to be a single example,

Why waste time with more, when you've denied that any are even
possible. One is all that it takes to demonstrate your error.

>The assertion that programs were *never* entered from a console
>would surprise IBM 360 series operators, to say the least

ROTF,LMAO! Programmers have been know to enter code from a S/360
console during, and probably CEs, but that was not the mode of
operation for production, development or most testing.

>I assume

Yes you do, frequently and erroneously.

>the term "plenty" here is used in the same content as "quite often"
>above; i.e. there was at least one example.

No, in the context of companies believing that there was enough of a
market to warrant developing plug compatible peripheral devices for
the purpose, e.g. the Cope 45.

>(Contrast this with my use of contemporary authoritative references
>in the previous post).

ROTF,LMAO!

>Based on the absence of an explanation as to why these are
>"unrelated" terms,

No, just refusing to explain the obvious to one unable to understand
it. If someone other than you wants an explanation, I'll be glad to
provide it.

>No. You may believe I'm a hypocrite for using formal debate logic;

No, for using rhetorical devices that have nothing to do with logic.

>Feel free to post additional irrelevant
>observations if you like;

No, I'll leave that to you; you seem so good at it.

>I can't see any reason to discuss it further.

Don't let the door hit you on the way out.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[Ken Garlington]

I know you are, but what am I?

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <pcM67.212$bN2.9929795@newssvr16.news.prodigy.com>, on 07/23/2001
   at 02:44 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>I know you are, but what am I?

You know nothing, and you are a liar, for you said that you were
ending this thread.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: [OT] Market pressures for more reliable software

[Ken Garlington]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b5bf7d9$1$fuzhry$mr2ice@va.news.verio.net...
: In <pcM67.212$bN2.9929795@newssvr16.news.prodigy.com>, on 07/23/2001
:    at 02:44 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:
:
: >I know you are, but what am I?
:
: You know nothing, and you are a liar, for you said that you were
: ending this thread.

Wrong again! Quoting from my own post:

"Feel free to post additional irrelevant observations if you like; however,
I believe your position has been shown to be fatally flawed. I can't see any
reason to discuss it further."

I am no longer discussing your position with respect to technology,
organizations, etc. (although, given how you debase yourself with your
responses, I can see how you'd make such a mistake). I am discussing *you*,
personally. Therefore, I did not lie. In other words:

You're the liar, not me! Liar, liar, pants on fire!

"ROTF,LMAO!"

Re: [OT] Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <b_T67.263$bO.33705001@newssvr16.news.prodigy.com>, on 07/23/2001
   at 11:35 AM, "Ken Garlington" <Ken.Garlington@computer.org> said:

>I am no longer discussing your position with respect to technology,

Trying to weasel out of it again? If you read your own text, you might
note that you said "your position", not "your position with respect to
techological". But then, you've already demonstrated your inability to
make distinctions, so I will accept your defense that you are a fool
rather than a liar. Since you have implicitly admitted to being a
fool, and since you have ceased being amusing, it is time to add you
to my filters. Feel free to continue making up your history as you go;
there may be others who will still get a chuckle out of your errors.
AMF.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: [OT] Market pressures for more reliable software

[Ken Garlington]

...and THEN?...

(only meaningful for the three fans of "Dude, Where's My Car"...)

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Marin David Condic wrote:

> You're wasting your breath. Sometimes people have such a strong need to be
> right that they'll ignore all the reasoning and evidence to the contrary -
> convoluting logic, redefining terminology, etc.. Often the original point is
> totally forgotten in defending a position that isn't even related to it.

ITYM that they'll resort to ad hominem arguments like the above.


> Move on to more productive concerns.

I'll take that advice.  FOAD. HTH. HAND.

*PLONK*

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

Gary Labowitz wrote:

> This is getting ridiculous. You are SO hoping that computing and programming
> were not centralized that you skip an entrie generation.

No, I'm simply taking into account the context of this thread, which is the
alleged difference before and after the PC became a major factor in the
marketplace.


> When most people talk about early days, they mean when computers actually
> came into the marketplace and were large centralized systems.

I see no evidence of that.  I believe that most of the current generation of
programmers would regard the era before S/370 as the early days.


> Certainly
> programmers could be stationed anywhere. But terminal systems (starting with
> the various 1050-type systems) weren't available in the "early days."
> Actually, I remember the introduction of the 1050 as a big deal (about 1963
> or so, maybe a little later).

While I certainly was using punched cards in those days, I was also reading
about systems that didn't. Certainly terminals were available on IBM computers
prior to 1963, even on the lowly 650.


> Anyway, the later systems developed the RJE-type systems, which
> decentralized the point at which program streams could be entered and
> printed. They still connected to centralized processing, however. Since all
> the terminals were dumb, there was only decentralized job entry and
> printing.
> The real point is: so what? So you said "in the early days we had
> decentralized computing" and were wrong.

Which part of "programming" don't you understand?


> Live with it.

Live with what? The fact that you can't read. I never denied that there was
centralized hardware.


> Let's get on with today's problems.

Santayan.

--
Shmuel (Seymour J.) Metz

Re: Long names are doom ?

[Wes Groleau]

D
> > first installing it, how can the act of installing it constitute acceptance?
> > The whole thing is on legally shakey grounds.
> 
> Considering the amount of legal talent applied to the problem,
> I very much doubt they're on legally shakey grounds.   We could

I think the "grounds" are just firm enough for their lawyers
to stand on until the plaintiff (who works for a living)
runs out of legal fees.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9g5ipg$roq$1@nh.pace.co.uk>, on 06/12/2001
   at 01:16 PM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>That's the part that gets legally questionable. In normal contract
>law,

I assume that by "normal" you mean common law. Various states have
introduced legislation to make shrink-wrap licenses enforcable. 


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

Well, O.K., my usage may not be precise. I *do* mean "common law". There are
countries (and I think the State of Louisiana) that have "code" law. There
is something called the UCC which is increasingly accepted in most states
for dealing with business transactions. I have some passing familiarity with
all of this from a course in contract law I took for an MBA, but I'm no
expert by any stretch. The point was that there are circumstances under
which the UCC gets invoked or where you might be dealing with a state that
has "code" law for how to deal with the particulars of *this* situation.
Understanding what happens there means knowing what the code says. Then you
have the more general "common law" interpretations of when a contract
becomes a contract. When it comes to software licenses, I couldn't tell you
for sure that it falls under common law or if it comes under UCC. Therefore
my qualification of the statement.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b28b36a$1$fuzhry$mr2ice@va.news.verio.net...
> In <9g5ipg$roq$1@nh.pace.co.uk>, on 06/12/2001
>    at 01:16 PM, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> said:
>
> >That's the part that gets legally questionable. In normal contract
> >law,
>
> I assume that by "normal" you mean common law. Various states have
> introduced legislation to make shrink-wrap licenses enforcable.
>

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9gafcr$lsk$1@nh.pace.co.uk>, on 06/14/2001
   at 09:49 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>Well, O.K., my usage may not be precise. I *do* mean "common law".
>There are countries (and I think the State of Louisiana) that have
>"code" law. There is something called the UCC which is increasingly
>accepted in most states for dealing with business transactions. 

There's also a FPOS called UCITA that has passed in a couple of states
with some really anticonsumer provisions.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[James Kanze]

Dan Mercer wrote:

> In article <3B25D5FB.15C9B240@dresdner-bank.com>,
> James Kanze <James.Kanze@dresdner-bank.com> writes:
> > Dale King wrote:

> >> Unfortunately, a software lawsuit would have little ground to
> >> stand on.  Imagine if McDonald's required all customers who order
> >> hot coffee to sign an agreement before they are given the coffee
> >> where they acknowledge that the coffee is hot and can cause burns
> >> and that the customer assumes all responsibility for the proper
> >> handling of the coffee. If you got burnt from the coffee would
> >> you be able to win a suit agains McDonald's? Not likely, since
> >> you agreed to accept the responsibility.

> > Did you sign such an agreement when you bought your software?

> The agreement is part of the installation process.  You can't
> install the software unless you agree to the license terms.  This
> constitutes a legal "acceptance".

I've never signed anything when installing software.  I have clicked a
lot of buttons, but that's part of the operations necessary to install
the software.  I'd be very surprised if any court here would say that
just by clicking a particular button, particularly during a sequence
of button clicks, constituted accepting a contract.

Note that most software also comes with a README file.  I read them;
I'm a professional, and I'm often doing fairly complicated things.  My
wife, on the other hand, might start to read it, but would soon
realize that she doesn't understand any of the technical jargon
anyway.  And of course, she would not read anything further during the
installation process, supposing as well that it was technical jargon.
And would doubtlessly click on accept thinking it was just another
button for enter.  To make the machine do anything, you just click on
buttons until it does it, and the lables on the buttons don't really
mean anything.  After all, to stop the machine, she first clicks on a
button labled start.

In sum, a reasonable person cannot be expected to understand, or even
to read, the license before clicking on accept.  And thus, cannot be
held to have entered into a contract.

(This ignores the fact that much of the software on one of my machines
was actually installed by my son.  Who is underage, and cannot enter
into a legally binding contract anyway.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Blaikie]

> In sum, a reasonable person cannot be expected to understand, or even
> to read, the license before clicking on accept.  And thus, cannot be
> held to have entered into a contract.

a reasonable person is often not expected to understand most contracts they
sign.
db

Re: Long names are doom ?

[Wes Groleau]

> > In sum, a reasonable person cannot be expected to understand, or even
> > to read, the license before clicking on accept.  And thus, cannot be
> > held to have entered into a contract.
> 
> a reasonable person is often not expected to understand most contracts they
> sign.

It doesn't only happen in software. How many of us have bought a house or car,
been handed multiple double-sided legal sized pages of fine print, been told
to initial here, here, here, here, here, and here, and sign here" and obeyed.

How many of us even read the last paragraph before the signature?  The one
that says,
   "I have read and understood this document and have received a copy."

What, you read that paragraph?  So you were lying when you signed it?
Or you read 5,000 words per minute?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Ted Dennison]

In article <3B278996.4DE8D7A8@ftw.rsc.raytheon.com>, Wes Groleau says...
>
>It doesn't only happen in software. How many of us have bought a house or car,
>been handed multiple double-sided legal sized pages of fine print, been told
>to initial here, here, here, here, here, and here, and sign here" and obeyed.

I don't do that unless my lawyer has read it over already and is the one telling
me this. However, I can tell from the reactions I get when reading over those 20
page legal documents that this behavior is pretty unusual.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Roedy Green]

On Wed, 13 Jun 2001 10:41:10 -0500, Wes Groleau
<wwgrol@ftw.rsc.raytheon.com> wrote or quoted :

>How many of us even read the last paragraph before the signature?  The one
>that says,
>   "I have read and understood this document and have received a copy."
>

Would there not be some principle that said if the vendor hid a clause
that you promised your first born son, that it would be unenforceable
because no reasonable person would expect to find such a clause in
such a contract.  Surely such a strange provision should be widely
known.

Part of the problem with trying to reform the legal rules of software
is that a reasonable person expects very little for his money.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Software Lawsuits (was: LOng names are doom ?)

[Larry Kilgallen]

In article <sfifitgiul1253c6vn1ug2q2puehssp1kf@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On Wed, 13 Jun 2001 10:41:10 -0500, Wes Groleau
> <wwgrol@ftw.rsc.raytheon.com> wrote or quoted :
> 
>>How many of us even read the last paragraph before the signature?  The one
>>that says,
>>   "I have read and understood this document and have received a copy."
>>
> 
> Would there not be some principle that said if the vendor hid a clause
> that you promised your first born son, that it would be unenforceable
> because no reasonable person would expect to find such a clause in
> such a contract.  Surely such a strange provision should be widely
> known.

A Westlaw search finds one such case decided in the manner you describe,
but there are not many decided on that point (in either direction).

Re: Software Lawsuits (was: LOng names are doom ?)

[Marin David Condic]

One has an obligation to read and understand the contract before signing and
courts are very reluctant to overturn a contract on the grounds that you
didn't. There *are* cases, but they tend to be rare and usually involve
unusual circumstances. Courts tend to want to favor your freedom to enter
into a binding legal arrangement - at least in part because the alternative
is to have them constantly reviewing everything and fashioning "just"
solutions for you. If every agreement is automatically thrown out and
renegotiated in a courtroom, then what is the point of fashioning contracts
in the first place?

My advise is *never* sign anything without reading it. I'd add the advice I
got from my contract law prof: 1) *Never* turn loose of the money! 2)
*NEVER* - under any circumstances - do business with children!!!

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:d3n+NB1QLFsf@eisner.encompasserve.org...
> In article <sfifitgiul1253c6vn1ug2q2puehssp1kf@4ax.com>, Roedy Green
<roedy@mindprod.com> writes:
> > On Wed, 13 Jun 2001 10:41:10 -0500, Wes Groleau
> > <wwgrol@ftw.rsc.raytheon.com> wrote or quoted :
> >
> >>How many of us even read the last paragraph before the signature?  The
one
> >>that says,
> >>   "I have read and understood this document and have received a copy."
> >>
> >
> > Would there not be some principle that said if the vendor hid a clause
> > that you promised your first born son, that it would be unenforceable
> > because no reasonable person would expect to find such a clause in
> > such a contract.  Surely such a strange provision should be widely
> > known.
>
> A Westlaw search finds one such case decided in the manner you describe,
> but there are not many decided on that point (in either direction).

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> 
> On Wed, 13 Jun 2001 10:41:10 -0500, Wes Groleau
> <wwgrol@ftw.rsc.raytheon.com> wrote or quoted :
> 
> >How many of us even read the last paragraph before the signature?  The one
> >that says,
> >   "I have read and understood this document and have received a copy."
> >
> 
> Would there not be some principle that said if the vendor hid a clause
> that you promised your first born son, that it would be unenforceable
> because no reasonable person would expect to find such a clause in
> such a contract.  Surely such a strange provision should be widely
> known.

Various Names at Lloyds used an argument like this some years ago, that
they had been persuaded to sign unlimited-liability agreements by unscrupulous
syndicate managers who promised that they'd get rich. When asked to honour
the agreement they'd signed by forking out for insurance payouts all the
way to the bottom of their wallets, they squealed long and loud (and I
believe they managed to convince a judge to let them off the hook).

Personally I think that anyone who signs pieces of paper with scary words like
"unlimited liability" on them deserves everything they get, but then...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9g5as6$hbq$1@magnum.mmm.com>, on 06/12/2001
   at 03:01 PM, damercer@mmm.com (Dan Mercer) said:

>The agreement is part of the installation process.  You can't install
>the software unless you agree to the license terms. This constitutes
>a legal "acceptance".

That egregious provision is in UCITA, but it's certainly not in common
law. I believe that in most states the terms must be presented at the
time of sale.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Larry Elmore]

Marin David Condic wrote:
> 
> Ladders are supposed to be so overly expensive here specifically because of
> all the product liability insurance the manufacturers have to carry. What
> I'd like to know is how come a woman can spill hot coffee in her lap, sue
> McDonalds for making the coffee hot & *win*, yet nobody seems to be able to
> sue Bell Labs or Micro$oft for manufacturing operating systems with *known*
> unsafe technology. (Comes The Revolution, the lawyers will be the second
> ones up against the wall, right after the entire marketing department of
> Cirrus Cybernetics Corporation! :-)

Try reading the instructions on a can of instant coffee. Most tell you
to heat water to boiling and pour it over the powder/crystals, stir it,
and then to enjoy it -- _carefully_ (dont gulp it) because the coffee
will be HOT. Duh...
 
> As for the hammer? I'd suggest OSHA require they all be wrapped in
> styrofoam. :-)

Though you'd never guess it from TV news, more small children die in the
US from drowning in large buckets than from firearms accidents. OSHA
carefully studied this. Among the recommended possible solutions
suggested by their committee were to require _holes_ in the bottoms of
large buckets, or rounded, non-flat bottoms so they can't stand up on
their own and so tip over! This got a lot of ridicule in the press some
years ago as a prime example of government bureaucrats at their finest.

Larry

Re: Long names are doom ?

[Gary Labowitz]

You (or OSHA) have got to be putting us on.
"Larry Elmore" <ljelmore@home.com> wrote in message
news:3B204C82.C2681D79@home.com...
>
> Though you'd never guess it from TV news, more small children die in the
> US from drowning in large buckets than from firearms accidents. OSHA
> carefully studied this. Among the recommended possible solutions
> suggested by their committee were to require _holes_ in the bottoms of
> large buckets, or rounded, non-flat bottoms so they can't stand up on
> their own and so tip over! This got a lot of ridicule in the press some
> years ago as a prime example of government bureaucrats at their finest.
>
> Larry

Re: Long names are doom ?

[Larry Elmore]

Gary Labowitz wrote:
> 
> You (or OSHA) have got to be putting us on.
> "Larry Elmore" <ljelmore@home.com> wrote in message
> news:3B204C82.C2681D79@home.com...
> >
> > Though you'd never guess it from TV news, more small children die in the
> > US from drowning in large buckets than from firearms accidents. OSHA
> > carefully studied this. Among the recommended possible solutions
> > suggested by their committee were to require _holes_ in the bottoms of
> > large buckets, or rounded, non-flat bottoms so they can't stand up on
> > their own and so tip over! This got a lot of ridicule in the press some
> > years ago as a prime example of government bureaucrats at their finest.

I wish I was putting you on. But remember, this is the same government
that also spent $15,000 (IIRC) on a study to determine whether tequila
makes Siamese fighting fish more aggressive than rum does...

Larry

Re: Long names are doom ?

[Roedy Green]

On Fri, 08 Jun 2001 03:54:03 GMT, Larry Elmore <ljelmore@home.com>
wrote or quoted :

>Among the recommended possible solutions
>suggested by their committee were to require _holes_ in the bottoms of
>large buckets,

I suppose eventually they will equip kids with cone shape collars like
they put on goats or dogs to keep them from licking themselves.

If we eliminated death by disease or old age, you would live on
average 200 years before you died by accident.  This suggests to me
that our ancestors will be insanely safety-minded from our point of
view.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Eric The Read]

Roedy Green <roedy@mindprod.com> writes:
> If we eliminated death by disease or old age, you would live on
> average 200 years before you died by accident.  This suggests to me
> that our ancestors will be insanely safety-minded from our point of
> view.

I imagine our ancestors will be long dead by then.  Our descendants,
OTOH....

-=Eric
-- 
Everything should be made as simple as possible, but not simpler.
    -- Albert Einstein
    -- BSD fortune file

Re: Long names are doom ?

[Roedy Green]

On 08 Jun 2001 11:06:10 -0600, Eric The Read <emschwar@rmi.net> wrote
or quoted :

>I imagine our ancestors will be long dead by then.  Our descendants,
>OTOH....

Thank you.  I stared at my post, knowing something was wrong, but that
word "descendant" just would not come to me.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Larry Elmore]

Roedy Green wrote:
> 
> On Fri, 08 Jun 2001 03:54:03 GMT, Larry Elmore <ljelmore@home.com>
> wrote or quoted :
> 
> >Among the recommended possible solutions
> >suggested by their committee were to require _holes_ in the bottoms of
> >large buckets,
> 
> I suppose eventually they will equip kids with cone shape collars like
> they put on goats or dogs to keep them from licking themselves.
> 
> If we eliminated death by disease or old age, you would live on
> average 200 years before you died by accident.  This suggests to me
> that our ancestors will be insanely safety-minded from our point of
> view.

Larry Niven wrote a good SF short story based on that very idea. I can't
remember the title, but the story was memorable (to me, anyway).

Larry

Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Marin David Condic]

Well that raises a whole can of worms - how the media, et alia are out
screaming how we need all kinds of gun safety laws "to protect the children"
when in point of fact, more are killed every year in back yard swimming
pools. The proper algorithm ought to be to sort on the number of deaths per
anum & get them in descending order. Start at the top of the list and work
your way down.

But there is a whole class of people in this world who can't seem to be
happy unless they are running everyone else's life. Maybe it gives them a
sense of superiority. ("You're too stupid to live unless I'm here to help
you...") Or maybe it makes them feel needed. ("I must be a good person
because I'm protecting the poor wretches who would otherwise lie down in
traffic if I weren't there to stop them...") In any event, they generally
forget the most fundamental of all human rights: Free Will.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Elmore" <ljelmore@home.com> wrote in message
news:3B204C82.C2681D79@home.com...
>
> Try reading the instructions on a can of instant coffee. Most tell you
> to heat water to boiling and pour it over the powder/crystals, stir it,
> and then to enjoy it -- _carefully_ (dont gulp it) because the coffee
> will be HOT. Duh...
>
> > As for the hammer? I'd suggest OSHA require they all be wrapped in
> > styrofoam. :-)
>
> Though you'd never guess it from TV news, more small children die in the
> US from drowning in large buckets than from firearms accidents. OSHA
> carefully studied this. Among the recommended possible solutions
> suggested by their committee were to require _holes_ in the bottoms of
> large buckets, or rounded, non-flat bottoms so they can't stand up on
> their own and so tip over! This got a lot of ridicule in the press some
> years ago as a prime example of government bureaucrats at their finest.
>
> Larry

Re: Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Philip Anderson]

Marin David Condic wrote:
> 
> Well that raises a whole can of worms - how the media, et alia are out
> screaming how we need all kinds of gun safety laws "to protect the children"

Is there a difference between (1) being over-protective of a responsible
adult, who can be assumed to know the potential dangers in a hammer or
cup of coffee, and (2) protecting 'innocent' users or passers-by,
including children, from dangers they have no control over, such as a
hammer whose head flies off or a psychotic teenager with a gun?

If a bad programming technique is (mis-)used by a games writer and
causes a PC to crash, where does that fit in?  Or if the same mistake is
made in Flight Control Software leading to a plane crash?


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Earl R Coker]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3313 bytes --]

Hi Philip,

IMHO, the answer is YES there is a difference.  The best way to cope with
this counter productiveness is personal engagement of a thought process
which can be described as "personal responsibility using common sense".  One
could go on and on and on about the many many facets of that too.  And...
Politicians are really good at it in a very counter-productive way.  So they
pass "stupid nonsensical" laws and regulations.  <g>   Watching our local
Gummint (Mayor and Aldermen and Alderwomen) "live and in action" on the TV
is a real riot.  <G>

Let me give you a couple of personal examples, the first one from just about
an hour or so ago.

There is a rental property behind us.  A duplex.  Some "people" live in it.
They have children... some of which are teenagers.  The powers that be
please help home owners who live next to rental properties in the US.

One of the them, a boy about 12-14 (and once in a while a friend of his too)
seems to like to take baseball bats, tennis rackets, golf clubs etc... and
hit balls, rocks, etc... in the direction of our property then climb over
the fence to retrieve the "missiles" and proceed to do it all over again.
It "pi--es" me off no end to see the little f---er do that and the urge to
do him harm comes up rather strongly.  (I begin to use profanity when I
REALLY get upset.)

But I am using common sense and personal responsibility and not harming the
little bastard severely.  IF I WANTED TO, (but I don't want to) I could kill
him with my bare hands even.  Yes... I know there are laws to deal with me
if I were to damage the little b---ard but I am NOT relying on those "laws"
(e.g. someone else) to "make it all right" by going ahead and doing harm to
him or his family in some way and then letting the "law" handle it.

Before that, one of the families had a bow and arrow freak living on one
side of the duplex.  He used to put up a target on a bale of hay in the back
yard and proceed to always miss it and much of the time the arrow would end
up in our yard.  Once in a while he would use a pellet rifle.  One day we
came home and found an arrow sticking in our house.  He seemed to stop after
that for some reason.  Then, lucky for us, they moved out.  <g>

--
Regards,
Earl R. Coker
Buy the System, Gain the Knowledge.
Sales and Business Management Systems.
www.kwiksystems.com
ksa@muscanet.com


"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3B20E4FC.7A7762AD@amsjv.com...
> Marin David Condic wrote:
> >
> > Well that raises a whole can of worms - how the media, et alia are out
> > screaming how we need all kinds of gun safety laws "to protect the
children"
>
> Is there a difference between (1) being over-protective of a responsible
> adult, who can be assumed to know the potential dangers in a hammer or
> cup of coffee, and (2) protecting 'innocent' users or passers-by,
> including children, from dangers they have no control over, such as a
> hammer whose head flies off or a psychotic teenager with a gun?
>
> If a bad programming technique is (mis-)used by a games writer and
> causes a PC to crash, where does that fit in?  Or if the same mistake is
> made in Flight Control Software leading to a plane crash?
>
>
> --
> hwyl/cheers,
> Philip Anderson
> Alenia Marconi Systems
> Cwmbr�n, Cymru/Wales

Re: Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Blaikie]

> If a bad programming technique is (mis-)used by a games writer and
> causes a PC to crash, where does that fit in?  Or if the same mistake is
> made in Flight Control Software leading to a plane crash?

all programs used in devices which could have any effect on the longevity of
human life are cross checked and double cross checked. if a language is not
designed to cope with such stringent requirements, in the case of Java, it
is noted that it should not be used in such circumstances. flight control
systems both hardware and software for space flights are years behind
current technology, because the devices need those years to be checked for
errors.
db

Re: Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Chris Smith]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote ...
> Well that raises a whole can of worms - how the media, et alia are out
> screaming how we need all kinds of gun safety laws "to protect the
children"
> when in point of fact, more are killed every year in back yard swimming
> pools. The proper algorithm ought to be to sort on the number of deaths
per
> anum & get them in descending order.

Unfortunately, neither Ada nor awk nor Clarion nor Java not PL/1 nor VRML
are capable of solving this problem.  (Well, I've never heard of Clarion...
perhaps it can, but I doubt it).

Chris Smith

Re: Long Threads are doom? (was Re: Long names are doom ?)

[Benjamin.Altman]

how about new group long.names.are.doom....

Re: Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Roedy Green]

On Fri, 8 Jun 2001 11:26:06 -0500, "Chris Smith" <cdsmith@twu.net>
wrote or quoted :

>Unfortunately, neither Ada nor awk nor Clarion nor Java not PL/1 nor VRML
>are capable of solving this problem.  (Well, I've never heard of Clarion...
>perhaps it can, but I doubt it).

I did write some Java code for just this sort of problem, calculating
the risks of HIV infection from various sexual activities depending on
how often you performed them.  See http://mindprod.com/safesex.html

The raw data are imprecise, and depend on many factors difficult to
quantify, but at least the tables let you make more rational
risk/benefit decisions.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

mismatch between actual threat and perceived threat

[Roedy Green]

On Fri, 8 Jun 2001 09:52:04 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

>The proper algorithm ought to be to sort on the number of deaths per
>anum & get them in descending order. Start at the top of the list and work
>your way down.

But safety consciousness works the other way around.  The rarer a
catastrophe, the more it grabs the public imagination, say a child
strangulation, or a contaminated Tylenol pill and therefore the
greatest concern about prevention.

Ordinary things like drowning, fires, floods, earthquakes, hunger,
drug overdose, being shot, being beaten up, getting HIV, being killed
in a car crash, get less attention.

I maintain web pages about HIV and safe sex and risk factors.
http://mindprod.com/safesex.html  People write me terribly worried
about things they have done that have much less risk of harming them
than being hit by lightning.  Yet they will paralyse themselves with
fear over the remote possibility.

In terms of absolute risk people are not afraid "enough" of speed.  We
have a fear of heights, but not a fear of the corresponding speed that
you would attain from dropping from that height.

You see Bush worried about Iraq attacking the US with an ICBM, while
ignoring the ease Saddam could paralyse the Internet or attack
biologically.

In Java, you see great concern about theoretical holes in the Applet
Sandbox, but very little worry about ACCIDENTAL errors programmers
make. Security experts further ignore that the sandbox is a Maginot
line any self respecting hacker would simply bypass, attacking via the
back door of Windows instead.

Are there websites that mathematically estimate the ACTUAL risks of
all the potential disasters that people worry about?

I tend to worry most about global disasters, ones that could
potentially destroy civilisation and my beloved computers and cetacea.
So on my list of worries are global warming, environmental collapse,
nuclear war, overpopulation, biological warfare and the earth being
hit by an asteroid.

My girlfriend tends to worry most about earthquakes and tidal waves.
Major disasters of that sort are expected some time in the next
century where I live. The Azores are in for a major earthquake and
tidal wave what would wipe out the entire east coast of the US, any
time now, geologically speaking.  There is not much anyone can do to
avoid such disaster but move to high ground. Life never avoids
exploiting a niche, even when that niche is temporary.

Long ago, I decided to put most of my life effort into helping
computers evolve.  I figured that if computers could get very very
good at prediction, people would not have to wait until it was too
late before they took appropriate action to avert global catastrophes.
They would learn to act in enlightened self interest with computers
assuring them new approaches were safe.




For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: mismatch between actual threat and perceived threat

[Ted Dennison]

In article <vcn2itcjoscsqfppcmrabm2441uuvblfoa@4ax.com>, Roedy Green says...
>
>Long ago, I decided to put most of my life effort into helping
>computers evolve.  I figured that if computers could get very very
>good at prediction, people would not have to wait until it was too
>late before they took appropriate action to avert global catastrophes.

Great. Now if we can find someone to help *humans* evolve so that the'll
listen...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: mismatch between actual threat and perceived threat

[Roedy Green]

On Mon, 11 Jun 2001 13:25:48 GMT, Ted Dennison<dennison@telepath.com>
wrote or quoted :

>Great. Now if we can find someone to help *humans* evolve so that the'll
>listen...

My great hope is computers will get so good, their simulations will be
as good as hindsight.  Perhaps they can use 3D holodeck simulation to
make the consequences so real, that humans will take action the way
they usually do once they viscerally experience the catastrophe.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: mismatch between actual relevant newsgroups and perceived relevant newsgroups

[Kenny McCormack]

In article <wF3V6.3766$pb1.137507@www.newsranger.com>,
Ted Dennison <dennison@telepath.com> wrote:
>In article <vcn2itcjoscsqfppcmrabm2441uuvblfoa@4ax.com>, Roedy Green says...
>>
>>Long ago, I decided to put most of my life effort into helping
>>computers evolve.  I figured that if computers could get very very
>>good at prediction, people would not have to wait until it was too
>>late before they took appropriate action to avert global catastrophes.
>
>Great. Now if we can find someone to help *humans* evolve so that the'll
>listen...

Now if we could only get people to stop posting this crap to comp.lang.awk...

Re: mismatch between actual relevant newsgroups and perceived relevant newsgroups

[Shmuel (Seymour J.) Metz]

In <9g2i2p$mut$1@yin.interaccess.com>, on 06/11/2001
   at 08:46 AM, gazelle@yin.interaccess.com (Kenny McCormack) said:

>Now if we could only get people to stop posting this crap to
>comp.lang.awk...

Now, if we could only get people to start setting followups instead of
simply whining . . .


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Off Topic: Stupid Bureaucrats (was Re: Long names are doom ?)

[Leif Roar Moldskred]

In comp.lang.ada Marin David Condic <marin.condic.auntie.spam@pacemicro.com> wrote:
> The proper algorithm ought to be to sort on the number of deaths per
> anum & get them in descending order. Start at the top of the list and work
> your way down.

Assuming unlimited resources, yes. 

However, the different causes of death will cost various amount of
effort, time and money to reduce by a given fraction. It might be
relatively cheap to, for instance, reduce the number of deaths from
swimming-pool accidents by a fourth, but very expensive to reduce it
by half.

The goal then becomes to find the optimum distribution of a fixed
total of resources to each of the causes of death, that will give the
highest total reduction in deaths.

Obligatory Computer - is this problem NP-hard?


-- 
Leif Roar Moldskred

Re: Long names are doom ?

[tmoran]

>Real-world tools are actually a damn good analogy here. For example, whenever
>...
>(I know, I know. Lawsuits are actually an issue here, and they aren't typically
>in the software world.
  I await with interest the first lawsuit in which a harmed party sues
a software manufacturer for using known-dangerous techniques instead of
best practices.  ;)

Re: Long names are doom ?

[Wes Groleau]

> >I hear you. I agree with this. I'd prefer a language design that does not
> >ALLOW something like what you just described, no matter how much "expressive
> >power" can be gained for the attainment of Good And Noble goals. (Sort of an
> 
> Well.. it's always hard to predict how creative the programmer can be.  Java
> was supposed to be "clean"... of course it didn't take too long for people to
> prove otherwise  :)    On the flip side, be too restrictive, and you could end
> up with a dead language.  People complained about Pascal because it was so
> "structured".
> 
> It really depends on the programmer - like you said, anything can be taken to
> the extremes, and even the greatest language in the world can end up looking
> horrible in the hands of a talented (ahem) programmer, and there's not much we
> can do to "fix" this.  I've accepted this about C/C++:  I know it's not
> perfect, and I do bitch about it off and on, but it works well for me for what
> I need to do.
> 
> A hammer's just so damn useful, but I still sometimes hit my thumb.

Compare the last remark to the nested quote, then consider:

  Hit (What => Thumbnail, With => Hammer);
               ^^^^^ type mismatch

  -- #%^%*&$^%& stupid babysitter language won't let me do what I want!

  -- Let's see, ..... oh yeah:

  function Other_Nail is
        new Unchecked_Conversion (Source => Fingernail,
                                  Target => Construction_Nail);
  ...

  Hit (What => Other_Nail (Thumbnail),
       With => Hammer);

  -- #$%^#^% stupid verbose language has 95% more keystrokes than necessary!!!

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[James Kanze]

Pete Thompson wrote:

    [...]
> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
> encourages obfuscation.  However, it also promotes flexibility.

Just curious, but what can you do with pointer arithmetic in C/C++
that you couldn't do otherwise, in a cleaner fashion?

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Pete Thompson]

On Fri, 08 Jun 2001 16:31:12 +0200, James Kanze <James.Kanze@dresdner-bank.com>
wrote:

>Pete Thompson wrote:
>
>    [...]
>> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>> encourages obfuscation.  However, it also promotes flexibility.
>
>Just curious, but what can you do with pointer arithmetic in C/C++
>that you couldn't do otherwise, in a cleaner fashion?

Well... I'm not saying that there's anything that would be impossible to do
without pointer arithmetics -- there's always another way to do things, after
all.  I'm just saying that there are cases where using pointer arithmetics are
simply faster.  I find it convenient for when dealing with strings/substrings,
images, special effects, filters, masks, reading the system memory, etc.  One
might argue that arrays are an abstract form of pointer arithmetics.  Whether
you agree with that or not, that's up to you.  

The same argument could be applied to recursive functions (another thing that's
inherently unsafe and encourages obfuscation) - there's ALWAYS a way to do it
non-recursively and avoid the risk of clobbering the stack.  There are certain
things that it just makes sense for, though, such as partitioning.

I could use a nerf ball instead of a hammer to drive a nail into a wall.  Sure,
it'd take me a lot longer, but it'll still get the job done (given enough
decades), and at no personal danger!  :)  

Re: Long names are doom ?

[Larry Kilgallen]

In article <7q32itc596euq7tgic3qgd4qpov9bocaj5@4ax.com>, Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> On Fri, 08 Jun 2001 16:31:12 +0200, James Kanze <James.Kanze@dresdner-bank.com>
> wrote:
> 
>>Pete Thompson wrote:
>>
>>    [...]
>>> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>>> encourages obfuscation.  However, it also promotes flexibility.
>>
>>Just curious, but what can you do with pointer arithmetic in C/C++
>>that you couldn't do otherwise, in a cleaner fashion?
> 
> Well... I'm not saying that there's anything that would be impossible to do
> without pointer arithmetics -- there's always another way to do things, after
> all.  I'm just saying that there are cases where using pointer arithmetics are
> simply faster.  I find it convenient for when dealing with strings/substrings,
> images, special effects, filters, masks, reading the system memory, etc.  One
> might argue that arrays are an abstract form of pointer arithmetics.

Others would argue that arrays are a safe paradigm for doing what
is done with pointer arithmetic.

Re: Long names are doom ?

[James Kanze]

Larry Kilgallen wrote:
> In article <7q32itc596euq7tgic3qgd4qpov9bocaj5@4ax.com>, Pete
> Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:
> > On Fri, 08 Jun 2001 16:31:12 +0200, James Kanze
> > <James.Kanze@dresdner-bank.com> wrote:

> >>Pete Thompson wrote:

> >>    [...]
> >>> Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe
> >>> and encourages obfuscation.  However, it also promotes
> >>> flexibility.

> >>Just curious, but what can you do with pointer arithmetic in C/C++
> >>that you couldn't do otherwise, in a cleaner fashion?

> > Well... I'm not saying that there's anything that would be
> > impossible to do without pointer arithmetics -- there's always
> > another way to do things, after all.  I'm just saying that there
> > are cases where using pointer arithmetics are simply faster.  I
> > find it convenient for when dealing with strings/substrings,
> > images, special effects, filters, masks, reading the system
> > memory, etc.  One might argue that arrays are an abstract form of
> > pointer arithmetics.

> Others would argue that arrays are a safe paradigm for doing what is
> done with pointer arithmetic.

Which was, of course, my point.  It only holds for real arrays,
though; not for the cheap imiations in C.  And there are a (very) few
exceptions; I find pointer arithmetic convenient when writing memory
management code (malloc or a garbage collector), for example.  But
most applications don't have to deal with that level, and for them,
broken arrays and pointer arithmetic are just a source of errors.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <FaDxOvYsY8oI@eisner.encompasserve.org>, on 06/08/2001
   at 08:15 PM, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)
said:

>Others would argue that arrays are a safe paradigm for doing what is
>done with pointer arithmetic.

That is, if they had never seen an array or had never seen a pointer.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Patricia Shanahan]

James Kanze wrote:
> 
> Pete Thompson wrote:
> 
>     [...]
> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
> > encourages obfuscation.  However, it also promotes flexibility.
> 
> Just curious, but what can you do with pointer arithmetic in C/C++
> that you couldn't do otherwise, in a cleaner fashion?
...

Manage memory. A memory allocator, such as malloc, or the corresponding
kernel code, or the code underlying "new", has a split view of memory.
It must perform calcuations to determine where to put the the newly
created object. It must return a pointer to it.

Patricia

Re: Long names are doom ?

[James Kanze]

Patricia Shanahan wrote:

> James Kanze wrote:

> > Pete Thompson wrote:

> >     [...]
> > > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe
> > > and encourages obfuscation.  However, it also promotes
> > > flexibility.

> > Just curious, but what can you do with pointer arithmetic in C/C++
> > that you couldn't do otherwise, in a cleaner fashion?
> ...

> Manage memory. A memory allocator, such as malloc, or the
> corresponding kernel code, or the code underlying "new", has a split
> view of memory.  It must perform calcuations to determine where to
> put the the newly created object. It must return a pointer to it.

True.  Although there is something to be said for considering the
memory as one big array, and the "pointers" as indexes into it.  In
fact, in this case, C's pointers have just enough type checking to get
in the way and make the code a sloppy mess of typecasting.  IMHO, a
better solution would be to use real arrays (and indexes) where arrays
are appropriate, and have an untyped pointer to raw memory for this
sort of thing.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Memory Allocation without pointer arithmetic ? (was: Long names...)

[Larry Kilgallen]

In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan <pats@acm.org> writes:
> James Kanze wrote:
>> 
>> Pete Thompson wrote:
>> 
>>     [...]
>> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>> > encourages obfuscation.  However, it also promotes flexibility.
>> 
>> Just curious, but what can you do with pointer arithmetic in C/C++
>> that you couldn't do otherwise, in a cleaner fashion?
> ...
> 
> Manage memory. A memory allocator, such as malloc, or the corresponding
> kernel code, or the code underlying "new", has a split view of memory.
> It must perform calcuations to determine where to put the the newly
> created object. It must return a pointer to it.

That is an interesting example, even though it should only occur once
per operating system.  I have never tried to do that in Ada.

Does anyone have experience trying to subdivide memory objects (the
free pool) without using the equivalent of pointer arithmetic ?

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Kenny McCormack]

In article <9BiaJoj4VeFk@eisner.encompasserve.org>,
Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
>In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan <pats@acm.org> writes:
>> James Kanze wrote:
>>>
>>> Pete Thompson wrote:
>>>
>>>     [...]
>>> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>>> > encourages obfuscation.  However, it also promotes flexibility.
>>>
>>> Just curious, but what can you do with pointer arithmetic in C/C++
>>> that you couldn't do otherwise, in a cleaner fashion?
>> ...
>>
>> Manage memory. A memory allocator, such as malloc, or the corresponding
>> kernel code, or the code underlying "new", has a split view of memory.
>> It must perform calcuations to determine where to put the the newly
>> created object. It must return a pointer to it.
>
>That is an interesting example, even though it should only occur once
>per operating system.  I have never tried to do that in Ada.
>
>Does anyone have experience trying to subdivide memory objects (the
>free pool) without using the equivalent of pointer arithmetic ?

You know, I wish you guys would take comp.lang.awk out of this newsgroup
list for this ever changing thread (that started out being about long
variable names).  It never had anything to do with AWK and it keeps changing
names, thereby thwarting my killfile...

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Jane Williams]

On 9 Jun 2001 09:58:11 -0500, gazelle@yin.interaccess.com (Kenny
McCormack) wrote:

>You know, I wish you guys would take comp.lang.awk out of this newsgroup
>list for this ever changing thread (that started out being about long
>variable names).  It never had anything to do with AWK and it keeps changing
>names, thereby thwarting my killfile...

It doesn't have a lot to do with comp.lang.vrml, either.

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Patricia Shanahan]

Larry Kilgallen wrote:
> 
> In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan <pats@acm.org> writes:
> > James Kanze wrote:
> >>
> >> Pete Thompson wrote:
> >>
> >>     [...]
> >> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
> >> > encourages obfuscation.  However, it also promotes flexibility.
> >>
> >> Just curious, but what can you do with pointer arithmetic in C/C++
> >> that you couldn't do otherwise, in a cleaner fashion?
> > ...
> >
> > Manage memory. A memory allocator, such as malloc, or the corresponding
> > kernel code, or the code underlying "new", has a split view of memory.
> > It must perform calcuations to determine where to put the the newly
> > created object. It must return a pointer to it.
> 
> That is an interesting example, even though it should only occur once
> per operating system.  I have never tried to do that in Ada.

I would expect a few times per OS. For example:

1. User malloc. That can also be the function underlying "new" in C++.

2. Implementation of Java "new". While I suppose it may be based on
malloc, there may be additional requirements to support GC making it
different. The fact that the Java heap has a predetermined size limit
suggests that it is separate, because the malloc space is supposed to
grow as big as the OS will let it.

3. Kernel equivalent of malloc. It can use similar algorithms to malloc,
but will need different handling when it runs out of currently available
memory. This may be subdivided depending on whether the allocations can
be pageable or not.

4. Kernel buffer allocation. The kernel will need to allocate a lot of
buffers whose sizes will be multiples of a moderately large power of
two. It may be more efficient to use a different allocation system
rather than throwing them into the main kernel pool.

There may be other specialized allocators, tuned to particular types of
requests, in either the kernel or in user programs.

> 
> Does anyone have experience trying to subdivide memory objects (the
> free pool) without using the equivalent of pointer arithmetic ?

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Mark Yudkin]

And since any PL/I programmer would just say AREAs and why don't you RTFM? -
you can pull it from comp.lang.pl1 too.

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
news:9BiaJoj4VeFk@eisner.encompasserve.org...
> In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan <pats@acm.org>
writes:
> > James Kanze wrote:
> >>
> >> Pete Thompson wrote:
> >>
> >>     [...]
> >> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
> >> > encourages obfuscation.  However, it also promotes flexibility.
> >>
> >> Just curious, but what can you do with pointer arithmetic in C/C++
> >> that you couldn't do otherwise, in a cleaner fashion?
> > ...
> >
> > Manage memory. A memory allocator, such as malloc, or the corresponding
> > kernel code, or the code underlying "new", has a split view of memory.
> > It must perform calcuations to determine where to put the the newly
> > created object. It must return a pointer to it.
>
> That is an interesting example, even though it should only occur once
> per operating system.  I have never tried to do that in Ada.
>
> Does anyone have experience trying to subdivide memory objects (the
> free pool) without using the equivalent of pointer arithmetic ?

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Larry Kilgallen]

In article <3B221877.BBE3A49F@acm.org>, Patricia Shanahan <pats@acm.org> writes:
> 
> 
> Larry Kilgallen wrote:
>> 
>> In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan <pats@acm.org> writes:
>> > James Kanze wrote:
>> >>
>> >> Pete Thompson wrote:
>> >>
>> >>     [...]
>> >> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>> >> > encourages obfuscation.  However, it also promotes flexibility.
>> >>
>> >> Just curious, but what can you do with pointer arithmetic in C/C++
>> >> that you couldn't do otherwise, in a cleaner fashion?
>> > ...
>> >
>> > Manage memory. A memory allocator, such as malloc, or the corresponding
>> > kernel code, or the code underlying "new", has a split view of memory.
>> > It must perform calcuations to determine where to put the the newly
>> > created object. It must return a pointer to it.
>> 
>> That is an interesting example, even though it should only occur once
>> per operating system.  I have never tried to do that in Ada.
> 
> I would expect a few times per OS. For example:
> 
> 1. User malloc. That can also be the function underlying "new" in C++.
> 
> 2. Implementation of Java "new". While I suppose it may be based on
> malloc, there may be additional requirements to support GC making it
> different. The fact that the Java heap has a predetermined size limit
> suggests that it is separate, because the malloc space is supposed to
> grow as big as the OS will let it.

The underlying allocation mechanism on the operating system with which
I am most familiar has an optional size limit.  I don't know whether
Java uses it or not, since I am not a Java person, but it does not
_need_ to have a separate implementation (of the pointer arithmetic
part).  GC is "just" a matter of deciding when to deallocate the
memory, nothing inherent in the pointer arithmetic part.

> 3. Kernel equivalent of malloc. It can use similar algorithms to malloc,
> but will need different handling when it runs out of currently available
> memory. This may be subdivided depending on whether the allocations can
> be pageable or not.

Actions in the case of failure are outside the scope of the memory
allocation mechanism.  I could decide to have my (suitably privileged)
user mode program crash the machine in the event of failure.  Running
two (or more) allocation pools does not require separate allocation
code -- just a pool choice parameter.

> 4. Kernel buffer allocation. The kernel will need to allocate a lot of
> buffers whose sizes will be multiples of a moderately large power of
> two. It may be more efficient to use a different allocation system
> rather than throwing them into the main kernel pool.

I did not mean to imply that the single allocation implementation
should not support lookaside lists (as an option) or in any other
sense be built with "least common denominator" features.

So my question stands:

>> Does anyone have experience trying to subdivide memory objects (the
>> free pool) without using the equivalent of pointer arithmetic ?

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Larry Kilgallen]

You misunderstand the question.

It is not a matter of how to allocation memory in a PL/I program.

The question is whether it is possible for the PL/I runtime system
implementation of memory allocation to be accomplished without use
of pointer arithmetic.  The PL/I implementation with which I am
most familiar relies on the operating system (not written in PL/I)
for memory allocation, so provides no guidance.

There is a problem with cross-posted topics.  The most I could do
would be to pull this particular response from the PL/I group, but
that would not stop all the other ones, and this reponse is the one
that _should_ be relevant to PL/I.

Larry Kilgallen

In article <9fv5ll$b0k$1@sshuraab-i-1.production.compuserve.com>, "Mark Yudkin" <myudkin@compuserve.com> writes:
> And since any PL/I programmer would just say AREAs and why don't you RTFM? -
> you can pull it from comp.lang.pl1 too.
> 
> "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message
> news:9BiaJoj4VeFk@eisner.encompasserve.org...
>> In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan <pats@acm.org>
> writes:
>> > James Kanze wrote:
>> >>
>> >> Pete Thompson wrote:
>> >>
>> >>     [...]
>> >> > Well, sure.  Pointer arithmetic in C/C++ is inherently unsafe and
>> >> > encourages obfuscation.  However, it also promotes flexibility.
>> >>
>> >> Just curious, but what can you do with pointer arithmetic in C/C++
>> >> that you couldn't do otherwise, in a cleaner fashion?
>> > ...
>> >
>> > Manage memory. A memory allocator, such as malloc, or the corresponding
>> > kernel code, or the code underlying "new", has a split view of memory.
>> > It must perform calcuations to determine where to put the the newly
>> > created object. It must return a pointer to it.
>>
>> That is an interesting example, even though it should only occur once
>> per operating system.  I have never tried to do that in Ada.
>>
>> Does anyone have experience trying to subdivide memory objects (the
>> free pool) without using the equivalent of pointer arithmetic ?
> 
> 
-- 
==============================================================================
Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters
==============================================================================

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Kenny McCormack]

In article <$l53AZgRoQvs@eisner.encompasserve.org>,
Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
>You misunderstand the question.
>
>It is not a matter of how to allocation memory in a PL/I program.
>
>The question is whether it is possible for the PL/I runtime system
>implementation of memory allocation to be accomplished without use
>of pointer arithmetic.  The PL/I implementation with which I am
>most familiar relies on the operating system (not written in PL/I)
>for memory allocation, so provides no guidance.
>
>There is a problem with cross-posted topics.  The most I could do
>would be to pull this particular response from the PL/I group, but
>that would not stop all the other ones, and this reponse is the one
>that _should_ be relevant to PL/I.

But completely irrelevant to AWK.  And, yes, you personally cannot
ensure that I never see this crap in comp.lang.awk again, but if
everyone did as I ask, then the deed will be done.

Re: Memory Allocation without pointer arithmetic ? (was: Long names...)

[Chris Smith]

[Groups snipped as some have requested]

"Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote ...
> > 2. Implementation of Java "new". While I suppose it may be based on
> > malloc, there may be additional requirements to support GC making it
> > different. The fact that the Java heap has a predetermined size limit
> > suggests that it is separate, because the malloc space is supposed to
> > grow as big as the OS will let it.
>
> The underlying allocation mechanism on the operating system with which
> I am most familiar has an optional size limit.  I don't know whether
> Java uses it or not, since I am not a Java person, but it does not
> _need_ to have a separate implementation (of the pointer arithmetic
> part).  GC is "just" a matter of deciding when to deallocate the
> memory, nothing inherent in the pointer arithmetic part.

The mention of heap size limits was merely to point out that it appears that
Java manages its heap differently.  In fact, the Sun implementation of Java
does.

GC implemented on top of conventional malloc() can be quite slow.  Most
modern garbage collectors use copying collection, which partially offsets
the overhead of garbage collection when releasing memory with a far-reduced
performance impact of allocation; allocation becomes bumping a pointer,
analogous in performance to a stack allocation, rather than a far more
expensive explicitly managed heap allocation.

There are other garbage collection algorithms, such as mark/sweep, that are
common implemented on top of an explicitly managed heap architecture, but
IME they are mostly used for easy implementation or compatibility, and lag
behind copying collectors in performance, both because of poor interactions
with the memory hierarchy and because of the increase in allocation times.

Chris Smith

Re: Long names are doom ?

[Roedy Green]

On Tue, 05 Jun 2001 16:08:23 -0700, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> wrote or quoted :

>I feel the same way about code:  being verbose is all well and good, but
>pointless verbosity can do more harm than good. 

From the tone of the entire post, I suspect Pete is the kind of guy
team leaders dream of having as their right hand man.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com>, on 06/05/2001
   at 04:08 PM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>I feel the same way about code:  being verbose is all well and good,
>but pointless verbosity can do more harm than good.

Pointless *anything* in code can do more harm then good, especially
pointless terseness.

>Does it really make sense to make your code as
>newbie-ish as possible for them? 

Why are you equating "readable" with "newbie"? I've been at this for
decades, and in my experience one of the signs of a newbie is that he
doesn't understand the importance of readable and maintainable code.
Please note that neither "terse" nor "verbose" will satisfy the
requirement; it has to be readable.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 22:20:32 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>>Does it really make sense to make your code as
>>newbie-ish as possible for them? 
>
>Why are you equating "readable" with "newbie"? I've been at this for
>decades, and in my experience one of the signs of a newbie is that he
>doesn't understand the importance of readable and maintainable code.
>Please note that neither "terse" nor "verbose" will satisfy the
>requirement; it has to be readable.

Because we've been talking about hiring newbie programmers in this thread.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <hqhvhtgalmjoa0arv9hj5tehsa3q6s44vl@4ax.com>, on 06/07/2001
   at 11:27 AM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>Because we've been talking about hiring newbie programmers in this
>thread.

We've also been talking about white space, but that doesn't make a
newbie white space. The fact that two concepts appear in the same
discussion doesn't make them synonymous, or even close.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Simon Wright]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> And where is this rule written ?  Most programs I have seen can be
> made more clear by tripling their length with well-written comments
> (once good identifier names have been chosen).

I would have agreed, I think, but an alternative strategy is the one
Martin Fowler mentions in Refactoring (essentially, use good
*operation* (aka subprogram) names, then you probably don't even need
the comments.

Of course, you end up with more subprograms.

Re: Long names are doom ?

[Pete Thompson]

On Mon, 04 Jun 2001 15:05:12 GMT, Ted Dennison<dennison@telepath.com> wrote:

>In article <aqvfhtk583och27tjjaagpt783kn21c6sp@4ax.com>, Pete Thompson says...
>>
>>...  C/C++ are terse languages.  Being terse allows you to
>>do more in a shorter period of time.  I like using the i++ statement instead of
>
>Yowch. You lost me right there. Typing in the program is nowhere *near* the most
>time-consuming part of developing software. That distinction belongs to the
>"getting it to work" phase, along with maintanence in general. The focus needs
>to be on doing things that will make those phases go quicker.
>
>This statement is a perfect illustration of how the ancient design of C
>encourages developers to worry about optimizing the wrong things. Back in '72
>when C was designed, the size of a source file was a real issue, and programs
>were generally much smaller (and thus simpler to get running). But none of this
>is true today.

No, that is not what I mean.  Yes, it is quite bad to be so terse that the code
becomes obfuscated and unreadable  (side topic:  look up the obfuscated C
contest on goodle for a bit of fun).

I'm talking about terse in the sense that you get a better picture of the
overall picture in a few lines.  I'm talking about being terse for the sake of
readability, *NOT* for the sake of simply being terse.

Consider the following examples:

Terse way:

for (int i = 0; i < n; i++)
{
	cout << "i = " << i << endl;
}

Non-terse way:

for (int iIterationCounter = ITERATIONSTART; iIterationCounter <
iMaximumIteration; iIterationCounter = iIterationCounter + ITERATIONSTEP)
{
	cout << "iIterationCounter = " << endl;
}

You're going to have to look up the #define's to find out what those constants
mean in another file.

By design, this is a good thing, actually.  However, this can also lead to code
that's harder to read once you run into a good chunk of code that spans a
couple of pages that really could have been done in half a page and still be
just as readable (if not more so because it's all right in front of you).  

The first example is terse, but not necessarily cryptic as long as you don't
try to be terse for the sake of being terse.  A bad example of being terse
would be:

if (*i++ < ++j) *k++;

I don't want to be forced to think about operator precedence, ok?  :)

For those of you who are super-picky:  I am *NOT* advocating the use of
single-character variable names.  I (depending on the variable's scope) prefer

char* pClientName;

instead of:

char* p;
or char* pNameOfAClientInDatabase;

Bottom line:  don't be pointlessly terse and don't be pointlessly verbose
either.

I hope I've explained myself a bit better.

Re: Long names are doom ?

[Simon Wright]

Pete Thompson <blackpete@nowhere.somewhere.anywhere.com> writes:

> Terse way:
> 
> for (int i = 0; i < n; i++)
> {
> 	cout << "i = " << i << endl;
> }
> 
> Non-terse way:
> 
> for (int iIterationCounter = ITERATIONSTART; iIterationCounter <
> iMaximumIteration; iIterationCounter = iIterationCounter + ITERATIONSTEP)
> {
> 	cout << "iIterationCounter = " << endl;
> }

Given C, anyone whose standards required your second example would be
past praying for. There is an interesting value there (n) which is
probably less than obvious, and just "n" is probably terser than one
would like.

I've always found automations like

  for (int i = 0; i < sizeof(ARRAY)/sizeof(ARRAY[0]); i++) {
    // do something with ARRAY[i]
  }

helpful.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <glcqht423b2ik3sgrnitsoccvpl0rporoq@4ax.com>, on 06/05/2001
   at 12:56 PM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>You're going to have to look up the #define's to find out what those
>constants mean in another file.

The names should tell you what they mean. You don't need to know the
values.

>The first example is terse, but not necessarily cryptic as long as
>you don't try to be terse for the sake of being terse.  A bad
>example of being terse would be:

>if (*i++ < ++j) *k++;

I hate, loathe and despise C, yet I still find that code to be
perfectly understandable, with the exception of the variable names..


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Dale King]

"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b1ee2d5$2$fuzhry$mr2ice@va.news.verio.net...
> >The first example is terse, but not necessarily cryptic as long as
> >you don't try to be terse for the sake of being terse.  A bad
> >example of being terse would be:
>
> >if (*i++ < ++j) *k++;
>
> I hate, loathe and despise C, yet I still find that code to be
> perfectly understandable, with the exception of the variable names..


 Actually it is quite cryptic. The first question is why is k being
dereferenced and the value thrown away? Unless it is reading from some
memory mapped I/O device where the actual act of reading is important then
the dereference can be gotten rid of. If this were not true, this would
still be bad, because the compiler might optimize it away.

Wouldn't the following be more readable (keeping the bad variable names
since I don't know what the purpose of this code is)? It would certainlybe
much easier to step through this code and figure out what it is doing. And
yes I realize that this version does reorder some of the steps (such as i is
not incremented until after k is incremented, but if you have those sort of
constraints they should be spelled out and made explicit.

    j ++;

    if( *i < j )
    {
        k++;
    }

    i++;
--
 Dale King

Re: Long names are doom ?

[Donald L. Dobbs]

Dale King wrote:
> 
> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
> message news:3b1ee2d5$2$fuzhry$mr2ice@va.news.verio.net...
> > >The first example is terse, but not necessarily cryptic as long as
> > >you don't try to be terse for the sake of being terse.  A bad
> > >example of being terse would be:
> >
> > >if (*i++ < ++j) *k++;
> >
> > I hate, loathe and despise C, yet I still find that code to be
> > perfectly understandable, with the exception of the variable names..
> 
>  Actually it is quite cryptic. The first question is why is k being

===============

Here is some C code I had to contend with -- it adds a new dimension to
cryptic write-only code:

x=(--(p)->_cnt>=0?(*(p)->_ptr++=x)&0xff:_flsbuf(x&0xff,p))

Unless you were the original programmer of the above you don't have a
prayer on this one without some additional commentary somewhere...

===============

> dereferenced and the value thrown away? Unless it is reading from some
> memory mapped I/O device where the actual act of reading is important then
> the dereference can be gotten rid of. If this were not true, this would
> still be bad, because the compiler might optimize it away.
> 
> Wouldn't the following be more readable (keeping the bad variable names
> since I don't know what the purpose of this code is)? It would certainlybe
> much easier to step through this code and figure out what it is doing. And
> yes I realize that this version does reorder some of the steps (such as i is
> not incremented until after k is incremented, but if you have those sort of
> constraints they should be spelled out and made explicit.
> 
>     j ++;
> 
>     if( *i < j )
>     {
>         k++;
>     }
> 
>     i++;
> --
>  Dale King

Re: Long names are doom ?

[AG]

"Goran Larsson" <hoh@invalid.invalid> wrote in message
news:GELwCw.K0r@approve.se...
> In article <3B2056A5.86396F55@home.com>,
> Donald L. Dobbs <donaldldobbs@home.com> wrote:
>
> > Here is some C code I had to contend with -- it adds a new dimension to
> > cryptic write-only code:
>
> > x=(--(p)->_cnt>=0?(*(p)->_ptr++=x)&0xff:_flsbuf(x&0xff,p))
>
> > Unless you were the original programmer of the above you don't have a
> > prayer on this one without some additional commentary somewhere...
>
> I'm not the original programmer, but this is obviously the contents of a
> implementation specific macro for a broken version of the C stdio
> function putc.

Looks like you have just defined what the "obviously" means in the the
context
of the "of a implementation specific macro for a broken version of the C"
So, what about the hope for someone who really needs to read THAT?
And what's so "obvious" about that?

>
> Why are you taking extremely compiler specific code that is implemented
> as a macro expansion for speed as an example of how typical C code
> looks like?

I'm afraid I lost you there... Do you mean that this sort of thing is
something
compiler-specific thing and NOT acceptable by other C compilers? And if
it's NOT then how exactly is it C?

Re: Long names are doom ?

[AG]

"Goran Larsson" <hoh@invalid.invalid> wrote in message
news:GEnxK3.3n8@approve.se...

> Only two entities need to read that code:
>  * the author of this specific standard C library

Actually, the author doesn't really need to read it either - just type it in
;)

>  * the C compiler this standard C library is intended for

So, in other words it is a throw-away code? Written once and NEVER
under ANY circumstances to be revisited? Never needing ANY modifications and
totally free of any bugs present or introduced in the future by the changing
environment?

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3B2056A5.86396F55@home.com>, on 06/08/2001
   at 04:38 AM, "Donald L. Dobbs" <donaldldobbs@home.com> said:

>Here is some C code I had to contend with -- it adds a new dimension
>to cryptic write-only code:

>x=(--(p)->_cnt>=0?(*(p)->_ptr++=x)&0xff:_flsbuf(x&0xff,p))

The problem that I have with that code is the variable names rather
than the syntax. Plug in appropriate variiable names and I might be
able to say whether some comments are necessary. Rewrite it with "if"
but using the same names and it wiol remain cryptic.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <3b20009c$2@news.tce.com>, on 06/07/2001
   at 10:34 AM, "Dale King" <KingD@TCE.com> said:

> Actually it is quite cryptic. The first question is why is k being
>dereferenced and the value thrown away?

I must admit that I missed that one; i read the last value as (*k)++
instead of *(k++). But I haven't used C for a decade and a half;
someone using it on a daily basis would remember the precedence for
such common operators.

>Unless it is reading from some
>memory mapped I/O device where the actual act of reading is
>important then the dereference can be gotten rid of. If this were
>not true, this would still be bad, because the compiler might
>optimize it away.

I thought that the current C language had a means to suppress such
optimizations.

>Wouldn't the following be more readable <clipped>

>    j ++;
>    if( *i < j )
>    {
>        k++;
>    }
>    i++;

No. And it wouldn't do the same thing. I wouldn't throw away the
memory reference unless I knew that it wasn't needed.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[John English]

"Shmuel (Seymour J.) Metz" wrote:
> 
> In <3b20009c$2@news.tce.com>, on 06/07/2001
>    at 10:34 AM, "Dale King" <KingD@TCE.com> said:
> 
> > Actually it is quite cryptic. The first question is why is k being
> >dereferenced and the value thrown away?
> 
> I must admit that I missed that one; i read the last value as (*k)++
> instead of *(k++). But I haven't used C for a decade and a half;
> someone using it on a daily basis would remember the precedence for
> such common operators.

Not necessarily. I've come across C developers with many years experience
who occasionally write "if (a = b) ..." instead of "if (a == b)..."
because, even with all that experience, it stills looks plausible
and the fingers will still occasionally betray the mind. 

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Pete Thompson]

On Wed, 06 Jun 2001 22:11:33 -0400, "Shmuel (Seymour J.) Metz"
<spamtrap@library.lspace.org.invalid> wrote:

>In <glcqht423b2ik3sgrnitsoccvpl0rporoq@4ax.com>, on 06/05/2001
>   at 12:56 PM, Pete Thompson
><blackpete@nowhere.somewhere.anywhere.com> said:
>
>>You're going to have to look up the #define's to find out what those
>>constants mean in another file.
>
>The names should tell you what they mean. You don't need to know the
>values.

Sometimes yes you do. You're building a GUI, and some components look a bit
off, or a colour looks funny.  Or you have absolutely no idea what the colour
"vermillion" looks like.  Or you want to add your own components.  

>
>>The first example is terse, but not necessarily cryptic as long as
>>you don't try to be terse for the sake of being terse.  A bad
>>example of being terse would be:
>
>>if (*i++ < ++j) *k++;
>
>I hate, loathe and despise C, yet I still find that code to be
>perfectly understandable, with the exception of the variable names..

I hope you aren't suggesting that this is the recommended way to write
statements.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <oghvhtkgpsd6stkffto8njpc0klcjduks2@4ax.com>, on 06/07/2001
   at 11:26 AM, Pete Thompson
<blackpete@nowhere.somewhere.anywhere.com> said:

>Sometimes yes you do. You're building a GUI, and some components look
>a bit off, or a colour looks funny.  Or you have absolutely no idea
>what the colour "vermillion" looks like.  Or you want to add your own
>components.  

No, if I'm reading the code I don't need to know that vermilion is
666, and knowing that won't tell me what it looks like. If it turns
out that 666 is the wrong value, I really to want to change it every
place it occurs, in the process changing a 666 that doesn't represent
vermilion but rather the weight of a foo.

>I hope you aren't suggesting that this is the recommended way to
>write statements.

I'd have to see them in context before I would issue a judgement.
Modulo variable names, I could well approve.

-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[HarryO]

In article <3b1ee2d5$2$fuzhry$mr2ice@va.news.verio.net>, "Unknown"
<spamtrap@library.lspace.org.invalid> wrote:

>>if (*i++ < ++j) *k++;
> 
> I hate, loathe and despise C, yet I still find that code to be perfectly
> understandable, with the exception of the variable names..

Of course, it looks reasonable, but (and I realise it was probably
not a real piece of code) as it is, the code probably doesn't do what is
intended and certainly doesn't do what one might guess it does.

The reason is that the "++" binds more tightly than the "*", so all this
code actually does is increment k some number of times, hence the '*' is
totally superflous.  Persumably, what was intended was "(*k)++".

Just another example as to why "terse" can lead to  "buggy", I guess :-).

While I wouldn't (generally) make that mistake, because I know the
precedence, I'd probably be less terse and use "*k += 1" in this case or
maybe even "(*k) += 1" to make it obvious to the next person that this
code is fiddly.  Who knows, I might even go overboard and put in a
comment to explain it :-).

Re: Long names are doom ?

[John English]

Pete Thompson wrote:
> Anyways, regarding the underscore.  I'm a C/C++ programmer (now learning Java)
> and I don't like the underscore because of its location on my keyboard, and it
> affects my typing speed.  C/C++ are terse languages.  Being terse allows you to
> do more in a shorter period of time.  I like using the i++ statement instead of
> i = i + 1.   I like being able to code as fast as my train of thought allows
> me, and having to pause to type out the underscores can throw me off.  Typing
> This_Is_A_Variable takes me far longer than typing ThisIsAVariable.  Reading
> the code isn't much of an issue as long as you capitalize each word in the
> variable name.  Yes, 'Thisisavariable' would be quite horrible.

I find ThisIsAVariable harder to read than This_Is_A_Variable, and IMHO
readability is much more important than coding speed (unless it's a
10 line noddy to be thrown away in an hour's time). As far as typing
speed is concerned, I would have thaought that all the asterisks and
plusses and curly brackets in C/C++/Java would be more of an issue...

Mind you, I type one-fingered (but very quickly after 30 years of
practice :-) so I find I'm more keyboard-layout-insensitive than a
real typist.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <3B1CC17D.DD6F730C@brighton.ac.uk>, John English says...
>
>Mind you, I type one-fingered (but very quickly after 30 years of
>practice :-) so I find I'm more keyboard-layout-insensitive than a
>real typist.

I can actually touch-type. But I've found its *very* rare that this skill comes
in handy while writing code. Perhaps there are some people out there who *think*
in C or Ada, but I have to stop every couple of lines to translate or
strategize.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Jon Skeet]

Ted Dennison <dennison@telepath.com> wrote:
> In article <3B1CC17D.DD6F730C@brighton.ac.uk>, John English says...
> >
> >Mind you, I type one-fingered (but very quickly after 30 years of
> >practice :-) so I find I'm more keyboard-layout-insensitive than a
> >real typist.
> 
> I can actually touch-type. But I've found its *very* rare that this skill comes
> in handy while writing code. Perhaps there are some people out there who *think*
> in C or Ada, but I have to stop every couple of lines to translate or
> strategize.

Interesting. This doesn't tend to be the way I work in Java. Someone 
will give me a problem, and I'll spend the next couple of days reading 
news, surfing the web, playing games, etc - occasionally consciously 
thinking about the problem, and subconsciously thinking about it most of 
the time (I believe - obviously I can't easily measure that!)

After that couple of days, I'll sit at a keyboard and write a large 
block of code. I may stop every so often if I'm writing a block of code 
which needs thinking about at a low level, but I relatively rarely need 
to reconsider a high-level design decision - at that stage, anyway. (Of 
course it all changes when the original requirements change!)

To that end, my overall coding speed *does* have a slight bottleneck in 
typing speed, but I don't believe it's significant.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Larry Kilgallen]

In article <sv5T6.507$SQ2.19684@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <3B1CC17D.DD6F730C@brighton.ac.uk>, John English says...
>>
>>Mind you, I type one-fingered (but very quickly after 30 years of
>>practice :-) so I find I'm more keyboard-layout-insensitive than a
>>real typist.
> 
> I can actually touch-type. But I've found its *very* rare that this skill comes
> in handy while writing code. Perhaps there are some people out there who *think*
> in C or Ada, but I have to stop every couple of lines to translate or
> strategize.

I can rapidly enter (including underscores) what I think is Ada.

The fact that I have to revise it when the compiler gives me its
opinion regarding whether it is Ada does not seem to me to slow
the process much.

Re: Long names are doom ?

[James Kanze]

Ted Dennison wrote:

> In article <3B1CC17D.DD6F730C@brighton.ac.uk>, John English says...

> >Mind you, I type one-fingered (but very quickly after 30 years of
> >practice :-) so I find I'm more keyboard-layout-insensitive than a
> >real typist.

> I can actually touch-type. But I've found its *very* rare that this
> skill comes in handy while writing code. Perhaps there are some
> people out there who *think* in C or Ada, but I have to stop every
> couple of lines to translate or strategize.

It depends on what the code is actually doing; I can knock out
boilerplate code pretty quickly thanks to touch-typing.  And even on
those two or three lines, typing them faster allows me to start
thinking about the next lines sooner.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[tmoran]

>It depends on what the code is actually doing; I can knock out
>boilerplate code pretty quickly thanks to touch-typing.  And even on
>those two or three lines, typing them faster allows me to start
>thinking about the next lines sooner.
  Has anyone ever published a time & motion study of programmers?
I've toyed with setting up a TV camera to look over my shoulder
and see just how much time actually is spent typing/waiting for
compiles/thinking/etc.  Hard data, not "it seems to me I'm always..."

Re: Long names are doom ?

[AG]

<tmoran@acm.org> wrote in message
news:c98U6.73619$%i7.55960791@news1.rdc1.sfba.home.com...
> >It depends on what the code is actually doing; I can knock out
> >boilerplate code pretty quickly thanks to touch-typing.  And even on
> >those two or three lines, typing them faster allows me to start
> >thinking about the next lines sooner.
>   Has anyone ever published a time & motion study of programmers?
> I've toyed with setting up a TV camera to look over my shoulder
> and see just how much time actually is spent typing/waiting for
> compiles/thinking/etc.  Hard data, not "it seems to me I'm always..."

I once read a study which measured the eye movement as compared
to the hand movement solving simple cognitive problems - like recognizing
a shape for what it is and making a choice amongst several possibilities.
Granted, it may not be directly related to the programming, but human
nature been what it is it's still suggestive. The eye movement outrun hand
movement (including involantory spastic movements) by more then two
orders of magnitude.
The way it was done was to attach tiny sensors to the eyeball, fingertips
etc.
Of course under those conditions *anyone* would be nervous but the results
were consistent as far as the ratios were concerned.

Re: Long names are doom ?

[Philip Anderson]

Pete Thompson wrote:
> Typing
> This_Is_A_Variable takes me far longer than typing ThisIsAVariable.  

But I for one would type "this_is_a_variable" in (case-insensitive) Ada,
and let the editor capitalise each word for me; three '_' to type but I
save on use of the shift key.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Long names are doom ?

[James Kanze]

Pete Thompson wrote:

> Another issue about the underscore's location on the keyboard: I
> avoid it as much as possible to cut down on the risks of carpal
> tunnel.  The side of my right hand is already getting sore from
> having to reach over for +, =, {, }, \, backspace, and enter.
> Throwing the underscore in there would just make it worse and more
> painful.

That might be true for a C/C++ (or Java) programmer.  I doubt that it
is a problem for an Ada programmer, however -- the _ is about the only
key he needs to hit with his pinky.  (In practice, I've not found
using the pinky to be a problem.  The contorsions required by native
emacs, yes, but viper mode solves that.)

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Marin David Condic]

Things like underscores or hyphens or whatever are really substitutes for
the space key. I'd like someone to build a keyboard that had a
split-space-bar (or shift-space?) and have an editor map one side of the
space bar to the "non-space-space" for the language at hand. (usually
underscore, but IIRC, Jovial used the tick'mark as its virtual space...) I
think it would be more convenient than the usual shift-stretch one has to do
to get the underscore character...

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James Kanze" <James.Kanze@dresdner-bank.com> wrote in message
news:3B1CECCA.65285DB3@dresdner-bank.com...
> Pete Thompson wrote:
>
> That might be true for a C/C++ (or Java) programmer.  I doubt that it
> is a problem for an Ada programmer, however -- the _ is about the only
> key he needs to hit with his pinky.  (In practice, I've not found
> using the pinky to be a problem.  The contorsions required by native
> emacs, yes, but viper mode solves that.)
>

Re: Long names are doom ?

[Philip Anderson]

Marin David Condic wrote:
> 
> Things like underscores or hyphens or whatever are really substitutes for
> the space key. I'd like someone to build a keyboard that had a
> split-space-bar (or shift-space?) and have an editor map one side of the
> space bar to the "non-space-space" for the language at hand. (usually
> underscore, but IIRC, Jovial used the tick'mark as its virtual space...) I
> think it would be more convenient than the usual shift-stretch one has to do
> to get the underscore character...

CORAL 66 conveniently allowed spaces in identifier names (but keywords
were quoted so they stood out).


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Long names are doom ?

[Marin David Condic]

Must have been kind of tough to parse.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Philip Anderson" <phil.anderson@amsjv.com> wrote in message
news:3B1D0357.645C9FAE@amsjv.com...
>
> CORAL 66 conveniently allowed spaces in identifier names (but keywords
> were quoted so they stood out).
>

Re: Long names are doom ?

[Dale King]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9fj23f$6oo$1@nh.pace.co.uk...
> Must have been kind of tough to parse.
>
> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
> news:3B1D0357.645C9FAE@amsjv.com...
> >
> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
> > were quoted so they stood out).

Not necessarily (I know nothing of CORAL in particular). I have brought the
subject up before (in the Java groups) asking whether having a language
allow spaces in identifiers would be a good thing. If you design the
language grammar well enough it would be easy to parse unambiguously. You
have to make sure that there is some form of operator or punctuation between
any identifiers. C-ish grammar wouldn't work because there is reliance on
whitespace to separate identifiers (e.g. int variable). Pascal-ish or
Modula-ish grammars would probably be pretty close except for the control
structures which use words to denote the beginning and end.

Re: Long names are doom ?

[Philip Anderson]

Marin David Condic wrote:
> 
> Must have been kind of tough to parse.

I doubt it since IIRC spaces were purely white space, just there for
readability with no syntactic significance; it's a few years since I
last wrote it, but I think "An Integer" and "AnInteger" would have been
regarded as the same.

Quoted keywords, semicolons and parentheses etc separated identifiers,
eg:
'Integer' I;


I imagine a compiler just ignored spaces, but anyway making things a
little harder for the compiler to make things easier for the
writer/reader should not bother anyone.


-- 
hwyl/cheers,
Philip Anderson
Alenia Marconi Systems
Cwmbr�n, Cymru/Wales

Re: Long names are doom ?

[John English]

Marin David Condic wrote:
> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
> news:3B1D0357.645C9FAE@amsjv.com...
> >
> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
> > were quoted so they stood out).
> 
> Must have been kind of tough to parse.

Why? The lexer just treats whitespace as it would treat underlines
in Ada:
  identifier = letter (letter|digit|whitespace)*
or more likely ignores whitespace inside identifiers.

Using 'BEGIN' and 'END' was a pain, though, and even worse was that
comments were Algol-60 style:
  'COMMENT' ... ;
Leaving out the semicolon would silently lose the next statement and
was it nearly impossible to spot the lack of a near-invisible punctuation
mark... :-(

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Ted Dennison]

In article <3B1DF628.4951B79A@brighton.ac.uk>, John English says...
>
>Marin David Condic wrote:
>> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
>> news:3B1D0357.645C9FAE@amsjv.com...
>> >
>> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
>> > were quoted so they stood out).
>> 
>> Must have been kind of tough to parse.
>
>Why? The lexer just treats whitespace as it would treat underlines
>in Ada:

When I'm in one of those weirder moods and I think Intercal didn't go far
enough, I've occasionaly considered creating a language where the *only*
significant characters are the whitespace. Everything would have to coded using
sequences of spaces, tabs, and newlines, separated by text. Since the text
itself wouldn't matter, you could use all of it for comments. Thus this language
would be inherently self-documenting! :-)

I think I was inspired by my initial frustration with make's tabs.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Marin David Condic]

Space = '0'; Tab = '1'. Go forth and write machine code in binary.

Hard as it may be to imagine, I think such a language would be even *more*
perverse than my favorite perverse language: Befunge.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:vuqT6.996$bA3.39007@www.newsranger.com...
> In article <3B1DF628.4951B79A@brighton.ac.uk>, John English says...
> >
> >Marin David Condic wrote:
> >> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
> >> news:3B1D0357.645C9FAE@amsjv.com...
> >> >
> >> > CORAL 66 conveniently allowed spaces in identifier names (but
keywords
> >> > were quoted so they stood out).
> >>
> >> Must have been kind of tough to parse.
> >
> >Why? The lexer just treats whitespace as it would treat underlines
> >in Ada:
>
> When I'm in one of those weirder moods and I think Intercal didn't go far
> enough, I've occasionaly considered creating a language where the *only*
> significant characters are the whitespace. Everything would have to coded
using
> sequences of spaces, tabs, and newlines, separated by text. Since the text
> itself wouldn't matter, you could use all of it for comments. Thus this
language
> would be inherently self-documenting! :-)
>
> I think I was inspired by my initial frustration with make's tabs.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B1DF628.4951B79A@brighton.ac.uk>, John English <je@brighton.ac.uk> writes:
> Marin David Condic wrote:
>> "Philip Anderson" <phil.anderson@amsjv.com> wrote in message
>> news:3B1D0357.645C9FAE@amsjv.com...
>> >
>> > CORAL 66 conveniently allowed spaces in identifier names (but keywords
>> > were quoted so they stood out).
>> 
>> Must have been kind of tough to parse.
> 
> Why? The lexer just treats whitespace as it would treat underlines
> in Ada:
>   identifier = letter (letter|digit|whitespace)*
> or more likely ignores whitespace inside identifiers.
> 
> Using 'BEGIN' and 'END' was a pain, though, and even worse was that
> comments were Algol-60 style:
>   'COMMENT' ... ;
> Leaving out the semicolon would silently lose the next statement and
> was it nearly impossible to spot the lack of a near-invisible punctuation
> mark... :-(

Languages certainly have come a long way from when it was possible to
lose subsequent lines due to lack of a comment terminator.  Now it is
just a matter of getting people to use the advanced languages.

Re: Long names are doom ?

[Matthew Woodcraft]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> writes:

> Things like underscores or hyphens or whatever are really substitutes for
> the space key. I'd like someone to build a keyboard that had a
> split-space-bar (or shift-space?) and have an editor map one side of the
> space bar to the "non-space-space" for the language at hand.

I've had shift-space producing underscore for some time, and it works
fine for me.

-M-

Re: Long names are doom ?

[Jacob Sparre Andersen]

Marin:

> Things like underscores or hyphens or whatever are really substitutes for
> the space key. I'd like someone to build a keyboard that had a
> split-space-bar (or shift-space?)

What a great idea. I have just fixed my setup.

I you use X, then the following command modifies the meaning of
Shift-Space to "_":

   echo "keycode  65 = space underscore" | xmodmap -

Put it a suitable place in your login scripts, and you should
be up and running.

Jacob
-- 
Warning: Dates in calendars are closer than they appear.

Re: Long names are doom ?

[Marin David Condic]

This must be some flavor of Unix? I've got a PC and a variety of tools used
to edit text that may not be configurable in that way. I'll have to see if I
can do something similar for AdaGIDE and CodeWright on a PC

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:3B1F56C8.28C881ED@nbi.dk...
> Marin:
>
> > Things like underscores or hyphens or whatever are really substitutes
for
> > the space key. I'd like someone to build a keyboard that had a
> > split-space-bar (or shift-space?)
>
> What a great idea. I have just fixed my setup.
>
> I you use X, then the following command modifies the meaning of
> Shift-Space to "_":
>
>    echo "keycode  65 = space underscore" | xmodmap -
>
> Put it a suitable place in your login scripts, and you should
> be up and running.
>
> Jacob
> --
> Warning: Dates in calendars are closer than they appear.

Re: Long names are doom ?

[Jacob Sparre Andersen]

Marin:

> This must be some flavor of Unix?

X, or "The X Window System", is the most commonly used graphical
user interface system for Unix-like operating systems[1].

> I've got a PC

So have I (in the "IBM compatible Intel 32 bit architechture
based computer" sense), but it may be because my machine is
running Linux while yours is running DOS, OS/2 or Windows.

> and a variety of tools used to edit text that may not be
> configurable in that way.

:-(

> I'll have to see if I can do something similar for AdaGIDE and
> CodeWright on a PC

I hope you can. It is actually quite nice, even though I haven't
gotten quite used to it yet.

Jacob
-- 
"simply because no one had discovered a cure for the universe as a
 whole - or rather the only one that did exist had been abolished"

Re: Long names are doom ?

[James Kanze]

Marin David Condic wrote:

> This must be some flavor of Unix?

He said is was X; X is the standard windows manager for Unix.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Simon Wright]

James Kanze <James.Kanze@dresdner-bank.com> writes:

> Marin David Condic wrote:
> 
> > This must be some flavor of Unix?
> 
> He said is was X; X is the standard windows manager for Unix.

Not really; it's the GUI support mechanism. The window manager is a
separate thing, there are lots of them out there.

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B1CECCA.65285DB3@dresdner-bank.com>, James Kanze <James.Kanze@dresdner-bank.com> writes:
> Pete Thompson wrote:
> 
>> Another issue about the underscore's location on the keyboard: I
>> avoid it as much as possible to cut down on the risks of carpal
>> tunnel.  The side of my right hand is already getting sore from
>> having to reach over for +, =, {, }, \, backspace, and enter.
>> Throwing the underscore in there would just make it worse and more
>> painful.
> 
> That might be true for a C/C++ (or Java) programmer.  I doubt that it
> is a problem for an Ada programmer, however -- the _ is about the only
> key he needs to hit with his pinky.  (In practice, I've not found
> using the pinky to be a problem.  The contorsions required by native
> emacs, yes, but viper mode solves that.)

I find I use my ring finger, but I don't remember whether my typing
class in 1959 had underscore on the keyboard, or where it was located.

Re: Long names are doom ?

[James Kanze]

Roedy Green wrote:

> On Fri, 1 Jun 2001 11:09:30 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

> >I tend to use "_Type" at the end of type names

> I trust you are not a Java programmer from the long list of cross
> posts.  Here in Java land we have a convention: lower case =
> variable/method.  upper case = class, all upper case = named
> constant.

> Nice and compact.  The only problem is the compiler does not enforce
> it.  Every once in a while you run into some Bozo who refuses to
> follow the convention and it is hell understanding the code because
> you can't HELP but unconsciously presume he IS following it even
> when you know he is not.

Another problem is that it doesn't read well over the telephone.  One
of my criteria for a good naming convention is that people from the
project should be able to talk about the code over the telephone with
no ambiguities.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Jon Skeet]

James Kanze <James.Kanze@dresdner-bank.com> wrote:

> > Nice and compact.  The only problem is the compiler does not enforce
> > it.  Every once in a while you run into some Bozo who refuses to
> > follow the convention and it is hell understanding the code because
> > you can't HELP but unconsciously presume he IS following it even
> > when you know he is not.
> 
> Another problem is that it doesn't read well over the telephone.  One
> of my criteria for a good naming convention is that people from the
> project should be able to talk about the code over the telephone with
> no ambiguities.

Is that "no ambiguities if both people know a) the problem space and b) 
the naming convention", or no ambiguities regardless?

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[James Kanze]

Jon Skeet wrote:

> James Kanze <James.Kanze@dresdner-bank.com> wrote:

> > > Nice and compact.  The only problem is the compiler does not
> > > enforce it.  Every once in a while you run into some Bozo who
> > > refuses to follow the convention and it is hell understanding
> > > the code because you can't HELP but unconsciously presume he IS
> > > following it even when you know he is not.

> > Another problem is that it doesn't read well over the telephone.
> > One of my criteria for a good naming convention is that people
> > from the project should be able to talk about the code over the
> > telephone with no ambiguities.

> Is that "no ambiguities if both people know a) the problem space and
> b) the naming convention", or no ambiguities regardless?

The problem occurs when the naming convention gives semantic meaning
to aspects which aren't verbalized, like case.  If you have a variable
and a typename which only differ in the case of the initial letter,
there will be ambiguity when you talk about program text over the
telephone.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Wes Groleau]

> Debate", anyone?) it is probably best to write one down and then stick to
> it. Consistency being more important than the exact details of the naming
> convention.

For a naming convention, perhaps.  But when one style  (such as all caps) is
empirically proven to be significantly less readable than another.....

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[AG]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9f8b7b$h0e$1@nh.pace.co.uk...
> Using plurals for type names and singulars for object names can work - but
> not always.

Just think of some other (non-English) language users, are you sure what is
the plural
of something like "fish" in their respective languages?

Re: Long names are doom ?

[Wes Groleau]

> Ages and ages ago, I suggested to the editors of Ada Quality and
> Style (as part of the public comment process) that they use the
> following convention:
> 
>         type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
>         Dog : Dogs;
> 
> That is, plural for type names, singular for object names.  You'd be
> surprised how often that works out.  The editors even adopted it as
> their recommendation in an early edition of AQ&S.
> 
> Evidently some CS professor types were aghast at the simplicity of this

I think it's more a matter of "sounding like English"

> proposal, and a later version of AQ&S changed it to something like
> "abstract words for type names, specific words for object names" --
> advice that's impossible to understand, much less follow.

I would say "easy to understand, not too hard to follow, and makes
the code very readable."

> I found this culture clash perfectly understandable: I'd come from an
> engineering background, so type names like Amperes and Foot_Pounds came
> naturally.  

But you  ARE  following the abstract/specific guideline if you say

   type Amperes is .....
   
   Widget_Current : Amperes;


-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Simon Wright]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> > Ages and ages ago, I suggested to the editors of Ada Quality and
> > Style (as part of the public comment process) that they use the
> > following convention:
> > 
> >         type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
> >         Dog : Dogs;
> > 
> > That is, plural for type names, singular for object names.  You'd be
> > surprised how often that works out.  The editors even adopted it as
> > their recommendation in an early edition of AQ&S.
> > 
> > Evidently some CS professor types were aghast at the simplicity of this
> 
> I think it's more a matter of "sounding like English"
> 
> > proposal, and a later version of AQ&S changed it to something like
> > "abstract words for type names, specific words for object names" --
> > advice that's impossible to understand, much less follow.
> 
> I would say "easy to understand, not too hard to follow, and makes
> the code very readable."
> 
> > I found this culture clash perfectly understandable: I'd come from an
> > engineering background, so type names like Amperes and Foot_Pounds came
> > naturally.  
> 
> But you  ARE  following the abstract/specific guideline if you say
> 
>    type Amperes is .....
>    
>    Widget_Current : Amperes;

I suspect it's a matter of whether the thing we want to name is
fungible or not :-)

Your ampere is quite indistinguishable from my ampere. Your metre is
the same as mine. So when we're naming quantities it seems to come
quite naturally to use plurals:

  type Watts is new Float;
  Present_Dissipation : Watts;

and indeed I found myself the other day doing that perfectly
naturally.

On the other hand, when you're discussing things that are
distinguishable, the use of plurals gets pretty uncomfortable. It's
the same distinction as between 'less' and 'fewer', I think.

If you think of a department store, you might be interested in the
number of employees:

  sybtype Employees is Natural;
  Staff_Number : Employees;

but if you are interested in Alice, Bob and Carol specifically it
seems very odd indeed to say

  type Employees is record
    ..
  end record;
  Alice : Employees;

if for no other reason than that you also need a word to name the type
'collection of employees' (the database table you keep the employee
records in, for example).

I'm not so sure about enumeration types. Seems that the Dogs type
above would be more natural as Dog_Kind or, in this universe, Breed. I
agree you get into trouble with naming variabls of type Breed
(The_Breed, anyone!). [I do somewhat question the validity of
Dog_Pound_Dog; I think it should probably be Mongrel, even sheepdogs
may find themseleves in the pound.]


However ..

I made the distinction between 'less' and 'fewer' above. I get the
impression that fewer and fewer people would understand what I mean
there, and the last thing I want is to send the team off into a half
hour of navel gazing every time someone needs to name a new type!
Perhaps a simpler rule set that meant they only needed to take 15
minutes would be better .. note, I think names are important, it's
worth spending time on them, naming is real work, you need Name
Police, it's just not the only thing to think about!

-Simon

Re: Long names are doom ?

[Marin David Condic]

How about this: All type identifiers will be exactly 32 characters in
length. All object identifiers will be exactly 16 characters in length. Its
easy to check & enforce automatically. Its visually distinctive even if you
have a perverted programmer who likes names like: oooo0000OOOOoooo and
ll11ll11llll1111. It is an uncomplicated convention that anybody can
understand. Nobody has to go off and gaze at their navel for an hour to come
up with a name for something - pick anything and truncate to fit. It works
for any language as well.

Now I think I should have that highly caffeinated cup of coffee & engage my
brain - lest I tempt someone to actually take me seriously here & develop a
coding standard like this. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7vn17rv1x2.fsf@smaug.pushface.org...
> I made the distinction between 'less' and 'fewer' above. I get the
> impression that fewer and fewer people would understand what I mean
> there, and the last thing I want is to send the team off into a half
> hour of navel gazing every time someone needs to name a new type!
> Perhaps a simpler rule set that meant they only needed to take 15
> minutes would be better .. note, I think names are important, it's
> worth spending time on them, naming is real work, you need Name
> Police, it's just not the only thing to think about!
>

Re: Long names are doom ?

[Roedy Green]

On Fri, 01 Jun 2001 13:50:22 -0000, revbob@the.rectory (Rev. Bob 'Bob'
Crispen) wrote or quoted :

>That is, plural for type names, singular for object names.  
 

I still have not made up my mind if array names should be plural.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Edward Rosten]

> On Fri, 01 Jun 2001 13:50:22 -0000, revbob@the.rectory (Rev. Bob 'Bob'
> Crispen) wrote or quoted :
> 
>>That is, plural for type names, singular for object names.  
>  
> 
> I still have not made up my mind if array names should be plural.


This is probably another of those holy war type things, but they always
made sense to me as singular, since to me English works more like that.

Eg, if you had a bunch of objects (apples, for example) in a row, you
would refer to apple[5] as the 5th apple, not the 5th apples. That's 
why I would write the array as apple[] not apples[].

-Ed


-- 
(You can't go wrong with psycho-rats.)               (u98ejr)(@)(ecs.ox)(.ac.uk)

/d{def}def/f{/Times-Roman findfont s scalefont setfont}d/s{10}d/r{roll}d f 5 -1
r 230 350 moveto 0 1 179{2 1 r dup show 2 1 r 88 rotate 4 mul 0 rmoveto}for/s 15
d f pop 240 420 moveto 0 1 3 {4 2 1 r sub -1 r show}for showpage

Re: Long names are doom ?

[James Kanze]

"Rev. Bob 'Bob' Crispen" wrote:

> The kindly Rev. overheard Alvaro Segura <asegura@facilnet.es> saying
> on 01 Jun 2001:

> >Anyway I do like some consistency like capitalized class names and
> >lowercase variable names, but not adding letters (my pet is a Dog,
> >not a CDog or a TDog or a Dog_t).

> Ages and ages ago, I suggested to the editors of Ada Quality and
> Style (as part of the public comment process) that they use the
> following convention:

>         type Dogs is (German_Shepherd, Sheep_Dog, Dog_Pound_Dog);
>         Dog : Dogs;

> That is, plural for type names, singular for object names.  You'd be
> surprised how often that works out.  The editors even adopted it as
> their recommendation in an early edition of AQ&S.

The plurial doesn't always work.  A type States would suggest that it
held several states, not just one.  A more general rule is to use
unqualified nouns as typenames, qualified nouns as variables.  So you
get:

    State currentState ;
    State previousState ;

Of course, what is qualified and what isn't depends on context.
HardwareState could be a type or a variable, according to whether you
consider the Hardware as a qualifier (which it is, grammatically), or
something fundamental to the type (as is often the case in programs).

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B177EF7.2A2470F4@facilnet.es>, Alvaro Segura <asegura@facilnet.es> writes:

> Anyone likes the MS convention of using "lpstrzLastName" instead of just
> "LastName"?
> They say it helps you see the type of the variable. But what is a last
> name going to be? A floating-point number maybe? :-)

I believe they felt they could only go so far in copying VMS and did
not want to include the dollar signs.  On VMS QRT$GL_WHATEVER is a
globally accessible longword from the QRT facility.  That convention
is quite helpful in Bliss or Macro, but even C has enough type checking
to make the GL_ part unnecessary.  Of course the QRT$ tells the facility
(and hence the vendor) to whose namespace it belongs.

Re: Long names are doom ?

[Wes Groleau]

> > That's why consistency is a valid goal.  Java *does* have a nearly universal
> > convention on naming of identifiers, and that makes things much easier, as
> > long as people follow it.


"As long as people follow it" -- a pipe dream.  Depending on a convention
that in turn depends on the goodness of human nature is betting Murphy that
his law doesn't apply.

Plus, this convention assumes that knowing the implementation details is
more important than understanding the requirements (abstractions). 
One of the reasons Ada works so well is that its users know the opposite
is (usually) true.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Jon Skeet]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> 
> > > That's why consistency is a valid goal.  Java *does* have a nearly universal
> > > convention on naming of identifiers, and that makes things much easier, as
> > > long as people follow it.
> 
> "As long as people follow it" -- a pipe dream.  Depending on a convention
> that in turn depends on the goodness of human nature is betting Murphy that
> his law doesn't apply.

No-one said anything about *depending* on a convention. *Encouraging* a 
convention is a different matter, and in fact almost all experienced 
Java programmers I know of *do* seem to follow the conventions, to a 
greater or lesser extent.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Wes Groleau]

Jon Skeet wrote:
> 
> Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> >
> > > > That's why consistency is a valid goal.  Java *does* have a nearly universal
> > > > convention on naming of identifiers, and that makes things much easier, as
> > > > long as people follow it.
> >
> > "As long as people follow it" -- a pipe dream.  Depending on a convention
> > that in turn depends on the goodness of human nature is betting Murphy that
> > his law doesn't apply.
> 
> No-one said anything about *depending* on a convention. *Encouraging* a

I believe someone DID say
> It helps people to understand the code *without* prior familiarity with the

> convention is a different matter, and in fact almost all experienced
> Java programmers I know of *do* seem to follow the conventions, to a
> greater or lesser extent.

The eleven people that attended the same Java class I did are not following
this convention unless someone took them aside afterward and explained it to
them.  

A written coding, naming, or commenting convention for encoding essential
information that can't be enforced (or isn't) is at best useless (because
you know you can't depend on it and at worst disastrous (because someone
will depend on it when its wrong).

Any convention, enforced or not, for encoding information that is not
important is increasing the chance of being distracted from what IS
important.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Jon Skeet]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:

> > No-one said anything about *depending* on a convention. *Encouraging* a
> 
> I believe someone DID say

Any references? I can't remember seeing it.

> > It helps people to understand the code *without* prior familiarity with the
> 
> > convention is a different matter, and in fact almost all experienced
> > Java programmers I know of *do* seem to follow the conventions, to a
> > greater or lesser extent.
> 
> The eleven people that attended the same Java class I did are not following
> this convention unless someone took them aside afterward and explained it to
> them.  

If they were attending a Java class, I *suspect* I wouldn't call them 
experienced Java programmers.

The more experienced you get, the more other people's code you read - 
and as almost all the code you read (especially Sun's, obviously) use 
the same conventions, it makes sense to adopt them. It helps not to have 
to remember where you got a package from in order to easily work out 
what the methods are likely to be called.

> A written coding, naming, or commenting convention for encoding essential
> information that can't be enforced (or isn't) is at best useless (because
> you know you can't depend on it and at worst disastrous (because someone
> will depend on it when its wrong).

No, at best it's very helpful, as it means I can read other people's 
code faster than I would if they didn't follow the same convention as I 
do.

In the middle it's reasonably helpful, as if someone uses *a* convention 
but it's not the same as me, then I can get to grips with their 
convention then I can learn to read their code quickly too.

The worst situation is when someone doesn't follow a convention *at 
all*, changing capitalisation etc at a whim - at that stage, you have to 
look up method names etc every time you want to use them.

> Any convention, enforced or not, for encoding information that is not
> important is increasing the chance of being distracted from what IS
> important.

So you believe that

package TeST;class SHowArGS{public static void main (String[]ARgS){for
(int SOMeThINg=0;SOMeThINg<ARgs.length;SOMeThINg++)System.out.println
(ARgS[SOMeThINg]);}}

is *more* likely to create distraction than:

package test;

class ShowArguments
{
    public static void main (String [] args)
    {
        for (int i=0; i < args.length; i++)
            System.out.println (args[i]);
    }
}

Sorry, but I think that's crazy.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Georg Bauhaus]

Jon Skeet (skeet@pobox.com) wrote:
: Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:

: The worst situation is when someone doesn't follow a convention *at 
: all*, changing capitalisation etc at a whim - at that stage, you have to 
: look up method names etc every time you want to use them.

: > Any convention, enforced or not, for encoding information that is not
: > important is increasing the chance of being distracted from what IS
: > important.

: So you believe that

: package TeST;class SHowArGS{public static void main (String[]ARgS){for
: (int SOMeThINg=0;SOMeThINg<ARgs.length;SOMeThINg++)System.out.println
: (ARgS[SOMeThINg]);}}

: is *more* likely to create distraction than:

What is important is not just syntax and letter case. E.g.,
I've had no difficulties in reading and understanding your
example in the form above, left to right as in books.
(After all, letter case is an invention that came relatively
late in the use of latin alphabets, sometime after carolingean
minuscules in the 9c, I believe. (Side note: Serif Courier is very different
from sans serif Windoze Fixedsys, so whether it is easy
to distinguish characters in Marin's ll11l1 depends on the font...))

There is a distinction to be made between reading and inspecting.
There is    no    use   in    using a     tabular
layout      when  it    is    not   useful      as
it    does  not   at    all   help  readers,
but it is useful when you are inspecting interface definitions, say.


: package test;

: class ShowArguments
: {
:     public static void main (String [] args)
:     {
:         for (int i=0; i < args.length; i++)
:             System.out.println (args[i]);
:     }
: }


(Due to a local convention that what
carries meaning in a function declaration is return type,
name, and arguments, to a larger extent than modifiers,
I was distracted by the leading modifier "clutter", and
by the same convention,  where are those helpful brackets
around the non-block statement? Ah, those correct width
stripes on ties arguments ... :-)

By the way, if you like being shocked, have a look at tex.web,
the file that has the sources for TeX in it. Still not an
unmaintainable program, which leads me to the conclusion that
the programmer's responsability is to write source code that
can be understood by others, _possibly with the help of
tools(used by them)_ to make sources fit the most productive taste.

Seems difficult to arrive at this idea, given that HTML has
first brought us absurdities like font-tags, instead of style
sheets. :-)


Georg Bauhaus
---
Microsoft Windows--a whole new perspective on information hiding!

Re: Long names are doom ?

[Jon Skeet]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> Jon Skeet (skeet@pobox.com) wrote:
> : Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> 
> : The worst situation is when someone doesn't follow a convention *at 
> : all*, changing capitalisation etc at a whim - at that stage, you have to 
> : look up method names etc every time you want to use them.
> 
> : > Any convention, enforced or not, for encoding information that is not
> : > important is increasing the chance of being distracted from what IS
> : > important.
> 
> : So you believe that
> 
> : package TeST;class SHowArGS{public static void main (String[]ARgS){for
> : (int SOMeThINg=0;SOMeThINg<ARgs.length;SOMeThINg++)System.out.println
> : (ARgS[SOMeThINg]);}}
> 
> : is *more* likely to create distraction than:
> 
> What is important is not just syntax and letter case. E.g.,
> I've had no difficulties in reading and understanding your
> example in the form above, left to right as in books.
> (After all, letter case is an invention that came relatively
> late in the use of latin alphabets, sometime after carolingean
> minuscules in the 9c, I believe. (Side note: Serif Courier is very different
> from sans serif Windoze Fixedsys, so whether it is easy
> to distinguish characters in Marin's ll11l1 depends on the font...))

Why does when the date of the invention of letter case have anything to 
do with readability *now*? I found it *much* harder to write the above 
than the conventional version, as every time I wanted to use an 
argument, I had to *check* the case rather than being able to accurately 
guess it.

> There is a distinction to be made between reading and inspecting.

I'm not *entirely* sure what you mean here. When talking about human-
readability of code, I suspect that "reading" is always used to mean 
"inspecting".

> There is    no    use   in    using a     tabular
> layout      when  it    is    not   useful      as
> it    does  not   at    all   help  readers,
> but it is useful when you are inspecting interface definitions, say.

True. When considering the readability of code, however, I suspect it's 
always helpful.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[John English]

Chris Smith wrote:
> That's why consistency is a valid goal.  Java *does* have a nearly universal
> convention on naming of identifiers, and that makes things much easier, as
> long as people follow it.

"Nearly". It's a pity about examples in the standard API like
"Hashtable" as compared to "HashMap"... I've forgotten the number
of times I've seen students adhere to the convention and write
HashTable, and then sigh deeply and waste several minutes looking
it up in the API reference when the compiler starts bellyaching.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

pragma Tongue_In_Cheek (On) ;

C/C++ programmers are born with a short pinky-finger on their right hand.
They can't easily make that stretch from the home keys to reach the "_"
character. Since you don't ever attempt to read C/C++ programs - just throw
them out and start over - it never seemed to be a problem to not bother with
readability, and that stretch to the "_" key was causing wrist sprains and
resulting in lost time at work that could have been spent debugging. Hence,
coding standards for these projects took as a productivity step, the
outlawing of underscore characters.

When training former C/C++ programmers to write Ada code, it is important to
make them do exercises to use the ring finger of the right hand to reach the
"_" key. This will help with productivity on Ada projects. Also, don't say
to them the words: "What's a debugger?" - they look at you funny.

pragma Tongue_In_Cheek (Off) ;

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Wes Groleau" <wwgrol@ftw.rsc.raytheon.com> wrote in message
news:3B1411D0.3AAF42E7@ftw.rsc.raytheon.com...
>
> > I once saw some code which used (in the same namespace) identifiers
> > PassThruID  and PassThroughIDs. They were apparently introduced
>
> And I once had to use a 200-page set of program documentation,
> upper-case only, poor quality, line-printer output, in which
> it was very important not to confuse the two modes of the software:
>
> EXECUTIVE  and
> EXECUTION
>
> The issue is not short or long, it's readability and likelihood
> of error.  From that viewpoint, I find it hard to understand why,
> in the name of "consistency" some folks _vociferously_ castigate
> those of us who prefer
>
>    View_Preferences_General_Options_Action
>
> over
>
>    viewPreferencesGeneralOptionsAction
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[Roedy Green]

On Wed, 30 May 2001 10:14:23 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

>When training former C/C++ programmers to write Ada code, it is important to
>make them do exercises to use the ring finger of the right hand to reach the
>"_" key. T


Another solution in the Kinesis keyboard that makes the _ key  much
easier reach.  Or go whole hog and get the DSK version.

See http://mindprod.com/dsk.html#KINESIS

In that same essay is a programmer's DSK keyboard that puts
programmer's more commonly used keys more accessibly with a reference
to some source for keyboard drivers you can modify to roll your own
custom keyboard layout.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Shmuel (Seymour J.) Metz]

In <9f2v82$hp7$1@nh.pace.co.uk>, on 05/30/2001
   at 10:14 AM, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> said:

>When training former C/C++ programmers to write Ada code, it is
>important to make them do exercises to use the ring finger of the
>right hand to reach the "_" key. This will help with productivity on
>Ada projects. Also, don't say to them the words: "What's a debugger?"
>- they look at you funny.

When I programmed in Ada we had a debugger. We also used names long
enough to be intelligible to other programmers. Use opaque
abbreviations and you wouldn't make it through code review.

"What's a code review?"


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Long names are doom ?

[Marin David Condic]

Oh, I *have* a debugger with the Ada compiler I use. I just never turn it
on. I don't even know how. :-)

Here's a thing: Debuggers in and of themselves are not a bad thing. This is
especially true with embedded systems where you need a debugger (or maybe
more properly a "monitor") in order to watch the code run - something often
invisible within an embedded machine. The thing is that in my experience,
use of C/C++ means you end up heavily reliant on the debugger in the act of
code development because you just have no choice.

I've spent probably over 15 years in active, full time, professional Ada
development and almost never used a debugger. (Monitors in embedded machines
being a sort-of exception.) When I started using MSVC++ on a regular, full
time basis, I was impressed with the capabilities of the debugger that came
with it. It *had* to be impressive, because you *had* to use it to get the
code working. There may be debuggers that work with Ada that have ten times
the capability. I just couldn't tell you because I never needed one to get
an Ada program working. Ever. (Maybe that's just because I'm so brilliant,
but I don't think so. I think its because the compiler catches all the
stupid mistakes up front or at least gives you runtime exceptions if it has
to wait until then to detect the error.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote in
message news:3b1ad864$4$fuzhry$mr2ice@va.news.verio.net...
> When I programmed in Ada we had a debugger. We also used names long
> enough to be intelligible to other programmers. Use opaque
> abbreviations and you wouldn't make it through code review.
>
> "What's a code review?"
>
>

Re: Long names are doom ?

[Roedy Green]

On Mon, 4 Jun 2001 10:41:55 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

>I've spent probably over 15 years in active, full time, professional Ada
>development and almost never used a debugger.

I'm finding a similar thing with Java.  I almost never use the
debugger anymore.  I was used to C/C++ coding where I wanted to WATCH
every line of code run to make sure it did not do anything unexpected
on me before I would release it on the unsuspecting public.

The equivalent sort of thing I do now in Java is a re-read top to
bottom of all the code to make sure everything is still in sync, and
to prune out old junk no longer needed.


For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Marin David Condic]

Java - while still not IMHO the best expression of the years of language
design research & development - was an improvement over C/C++ in many
respects. The designers *did* take out some of the worst aspects of C/C++
which greatly reduced the need to constantly watch the execution of code
through a debugger. This is a good thing.

You might be pleasantly surprised with Ada if you ever used it to develop a
serious program. Like any language, its hard initially to make the shift
from what you're used to to what the new language does, but once you become
fluent enough with it, you start finding it has some *really* nice
capabilities.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:os2oht834uarc6gmbjje2qgsu9dhqo7b8u@4ax.com...
> On Mon, 4 Jun 2001 10:41:55 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
>
> >I've spent probably over 15 years in active, full time, professional Ada
> >development and almost never used a debugger.
>
> I'm finding a similar thing with Java.  I almost never use the
> debugger anymore.  I was used to C/C++ coding where I wanted to WATCH
> every line of code run to make sure it did not do anything unexpected
> on me before I would release it on the unsuspecting public.
>
> The equivalent sort of thing I do now in Java is a re-read top to
> bottom of all the code to make sure everything is still in sync, and
> to prune out old junk no longer needed.
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[James Kanze]

Marin David Condic wrote:

> Oh, I *have* a debugger with the Ada compiler I use. I just never
> turn it on. I don't even know how. :-)

> Here's a thing: Debuggers in and of themselves are not a bad
> thing. This is especially true with embedded systems where you need
> a debugger (or maybe more properly a "monitor") in order to watch
> the code run - something often invisible within an embedded
> machine. The thing is that in my experience, use of C/C++ means you
> end up heavily reliant on the debugger in the act of code
> development because you just have no choice.

Why do you say this?  I've used C/C++ regularly for over 15 years, and
I don't use a debugger for anything other than for getting a stack
trace on a post-mortem.

Of course, my C/C++ code is riddled with assertions, so if there is an
error, the program generally falls over quite near the point of error,
rather than somewhere unrelated.  Java takes care of a (very) few of
the cases you have to handle be hand in C++: array bounds, for
example.  But on the whole, I've found debugging a lot more difficult
in Java.  No assertion, no enforcement of contracts at the interface
level, etc.

-- 
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient�e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Re: Long names are doom ?

[Steve Bellenot]

In article <3B0DBD4A.82943473@my-deja.net>,
00001111  <00001111@my-deja.net> wrote:
>
> Hi All,
>
>  Anybody use variables/names longer than 31 character
>and finds it really useful ?
>
>Then please respond  why, where, when.
>I have folks here in comp.lang.fortran who will die claiming that they
>
>- "never seen a well written, legible program
>  that uses any identifiers longer than 18-20 characters..".
>- "long variables names are *hard* to read.  And, you have to
>  read though all the characters of every instance of them...".
>- "it degrades the legibility of a program to use identifiers that
>  can't be easily remembered...."
>
>As a result, despite 90% of computer languages have long, very
>long or 'infinite' identifiers, fortran folks seems plan to stay
>with their 6...aargh ...sorry this was just not far ago... 31 character
>limit intil year 3000.

While 31 is arbitrary and obviously ``wrong'' for not being 0, 1 or
infinity, I must agree that identifiers longer that most Russian novels
are worst. [Especially to those of us who have worked with people who
indent 2 spaces at a time, use a 132 column editor and consider the
whitespace as a goal to fill.] That is there must be some number n
where the pain of seeing identifiers of length > n is worst than the
pain of having to make all identifers have length <= n. It is more
likely that the answer is 42, but it could be 31. 

-- 
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu 
+1.850.644.7189 (4053fax)

Re: Long names are doom ?

[Peter Fitzgibbons]

bellenot@math.fsu.edu (Steve Bellenot) wrote in message news:<9ekrc2$hk0$1@news.fsu.edu>...
> In article <3B0DBD4A.82943473@my-deja.net>,
> 00001111  <00001111@my-deja.net> wrote:
> >
> the number n ... is more
> likely that the answer is 42, but it could be 31.

As in the answer to life.

6 x 9
     (13)

Re: Long names are doom ?

[Marin David Condic]

If you're going to have an arbitrary and capricious limit on identifier
length, then 42 is a better number than 31.

One can argue all day about programming style. Hemmingway had a very
different writing style when compared to James Joyce. (And we can compare
the both of them to Douglas Adams if you like.:-) Were both good writers?
While the analogy doesn't hold across all cases, consider that it is
possible to write good programs with short identifiers and with long
identifiers. Which to use and when may be a matter of the project at hand
and the style chosen for the project. (Short shell scripts probably don't
need extensive naming conventions but multi-million SLOC rocket control
systems will probably benefit if all identifiers are not restricted to 6
characters.)

I think that engineers have to make some stylistic choices when undertaking
a particular project, and those choices will have tradeoffs. It would be
wrong for a language to force you to *never* use identifiers longer than 6
(or 31) characters. Computers are big. If you're going to have an arbitrary
limitation for ease of implementation, why not make it 256? Nobody is likely
to complain that they can't write code because the identifiers they use need
to be bigger than that.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Steve Bellenot" <bellenot@math.fsu.edu> wrote in message
news:9ekrc2$hk0$1@news.fsu.edu...
> While 31 is arbitrary and obviously ``wrong'' for not being 0, 1 or
> infinity, I must agree that identifiers longer that most Russian novels
> are worst. [Especially to those of us who have worked with people who
> indent 2 spaces at a time, use a 132 column editor and consider the
> whitespace as a goal to fill.] That is there must be some number n
> where the pain of seeing identifiers of length > n is worst than the
> pain of having to make all identifers have length <= n. It is more
> likely that the answer is 42, but it could be 31.

Re: Long names are doom ?

[Roedy Green]

On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
<marin.condic.auntie.spam@pacemicro.com> wrote or quoted :

>If you're going to have an arbitrary and capricious limit on identifier
>length, then 42 is a better number than 31.

You could ask it this way. Who is better able to judge whether a given
long variable is justified, somebody versed in the project or somebody
who has never seen it?

This is a matter of style, and such a thing MIGHT be enforceable on a
PROJECT basis.

I would like it if there were lint-like tools that guarded the
repository.  They would beautify code to project standards, and
enforce restrictions decided on a per-project basis.

They would enforce the naming rules, see Coding Conventions in the
Java glossary.

You might even demand that each element of a variable name live in a
dictionary.  What drives me nuts is maintaining somebody else's code
who can't spell. 

I could imagine that a SCID would have a project dictionary with
special terminology carefully defined.  Coming cold into a project
learning the undocumented vocabulary is the hardest thing. All words
used in variable names would have to be defined if the standard Oxford
definition did not suffice.

We need to evolve computer languages more toward communication: human
<=> human and machine => human, rather than just human => machine.

One example would be avoiding nested scope to resolve ambiguity.
Computers have no problem with it, but in many cases it befuddles
humans.


-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/gloss.html or http://209.153.246.39/gloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963.
Almost ready to take on new work.

Re: Long names are doom ?

[Larry Hazel]

Roedy Green wrote:
> 
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
> 
> >If you're going to have an arbitrary and capricious limit on identifier
> >length, then 42 is a better number than 31.
> 
> You could ask it this way. Who is better able to judge whether a given
> long variable is justified, somebody versed in the project or somebody
> who has never seen it?
> 
> This is a matter of style, and such a thing MIGHT be enforceable on a
> PROJECT basis.
> 
> I would like it if there were lint-like tools that guarded the
> repository.  They would beautify code to project standards, and
> enforce restrictions decided on a per-project basis.
> 
> They would enforce the naming rules, see Coding Conventions in the
> Java glossary.
> 
> You might even demand that each element of a variable name live in a
> dictionary.  What drives me nuts is maintaining somebody else's code
> who can't spell.
> 
> I could imagine that a SCID would have a project dictionary with
> special terminology carefully defined.  Coming cold into a project
> learning the undocumented vocabulary is the hardest thing. All words
> used in variable names would have to be defined if the standard Oxford
> definition did not suffice.
> 
> We need to evolve computer languages more toward communication: human
> <=> human and machine => human, rather than just human => machine.
> 
> One example would be avoiding nested scope to resolve ambiguity.
> Computers have no problem with it, but in many cases it befuddles
> humans.
> 
> -
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at:
> http://mindprod.com/gloss.html or http://209.153.246.39/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963.
> Almost ready to take on new work.

I worked on a FORTRAN project once (F4J pilot trainer).  All variable names were
in a data dictionary.  The compile script ran the code through a parser and
looked all variable names up in the data dictionary.  If you misspelled a
variable or made up a new one, the program wouldn't compile.  To get a new
variable, you had to submit it with definition and justification to the
maintainer of the data dictionary.  It kept the error rate down a bunch.

The project was converted to Ada as a company funded R&D project in 1985.  The
conversion went very smoothly.

Larry

Re: Long names are doom ?

[Larry Kilgallen]

In article <cubtgtcnrrnkb1nj3khtapapse7cbsl20q@4ax.com>, Roedy Green <roedy@mindprod.com> writes:
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
> 
>>If you're going to have an arbitrary and capricious limit on identifier
>>length, then 42 is a better number than 31.
> 
> You could ask it this way. Who is better able to judge whether a given
> long variable is justified, somebody versed in the project or somebody
> who has never seen it?
> 
> This is a matter of style, and such a thing MIGHT be enforceable on a
> PROJECT basis.
> 
> I would like it if there were lint-like tools that guarded the
> repository.  They would beautify code to project standards, and
> enforce restrictions decided on a per-project basis.

I would guess it would be a very simple ASIS program to detect
unacceptable (for the project) identifiers, on the basis of
length or some other standards.  That one ASIS program should
be quite portable between different brands of Ada compilers.

Re: Long names are doom ?

[John English]

Roedy Green wrote:
> I would like it if there were lint-like tools that guarded the
> repository.  They would beautify code to project standards, and
> enforce restrictions decided on a per-project basis.
> 
> They would enforce the naming rules, see Coding Conventions in the
> Java glossary.

Sounds ambitious. How could a tool decide that a particular arbitrary
method should be called length() rather than getExtent(), for example?

Also you have the inconsistencies that plague the current Java API
(and which are significant due to case sensitivity) such as the name
Hashtable (lowercase t) but HashMap (capital M). How do you decide
where one "word" ends and the next begins within an identifier?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Long names are doom ?

[Roedy Green]

On Tue, 29 May 2001 10:41:09 +0100, John English <je@brighton.ac.uk>
wrote or quoted :

>
>Sounds ambitious. How could a tool decide that a particular arbitrary
>method should be called length() rather than getExtent(), for example?

With today's technology you could not to that.  But you could have the
lint tool scream about names such as 

getStuff

sEtValue

getqbt

What causes me more trouble than anything else coming
late onto a project is: 

1. learning that some words have a specific project meaning.

2. discovering that this vocabulary evolved over time, and that there
are variants. The project vocabulary is inconsistently used.

A lint tool might get people thinking more about this project
vocabulary and using it consistently right from the get go.





For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 
If you don't see what you were looking for, complain!
or send your contribution for the glossary.

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Long names are doom ?

[Marin David Condic]

Welcome to the Tower of Babel. It shall always be thus. Better to find ways
of easing the pain than to try to eliminate the problem because I suspect it
is something intractable in human nature. Will the entire world ever learn
to speak English? If they do under force or persuasion, how long before the
English everyone speaks start to diverge into regional dialects? Its been
said the England and the United States are two countries separated by a
common language. :-) Its as good an example as any of why project vocabulary
is going to both become specialized and diverge within pockets of the
project.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:utt7hto6rm0o9a8qked9muns28n7lrnvi6@4ax.com...
> What causes me more trouble than anything else coming
> late onto a project is:
>
> 1. learning that some words have a specific project meaning.
>
> 2. discovering that this vocabulary evolved over time, and that there
> are variants. The project vocabulary is inconsistently used.
>
> A lint tool might get people thinking more about this project
> vocabulary and using it consistently right from the get go.
>

Re: Long names are doom ?

[Marin David Condic]

I probably should have put a :-) next to that comment. See "A Hitchhikers
Guide To The Galaxy"

If you've followed my other comments in this thread, you'll know that I'm in
favor of specific projects deciding for themselves what (and even if) limits
should be imposed on identifiers. I am strongly against language & compiler
designers deciding this issue for you by placing arbitrary and capricious
limits on identifiers. (Beyond what is necessary for practical engineering
concerns. These days, if there is going to be a limit at all {and I don't
think there needs to be} it ought to stem from line lengths in source files
or be set to some really big number that in practice will never be
exceeded - like 256 or 512.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Roedy Green" <roedy@mindprod.com> wrote in message
news:cubtgtcnrrnkb1nj3khtapapse7cbsl20q@4ax.com...
> On Fri, 25 May 2001 09:34:15 -0400, "Marin David Condic"
> <marin.condic.auntie.spam@pacemicro.com> wrote or quoted :
>
> >If you're going to have an arbitrary and capricious limit on identifier
> >length, then 42 is a better number than 31.
>
> You could ask it this way. Who is better able to judge whether a given
> long variable is justified, somebody versed in the project or somebody
> who has never seen it?
>
> This is a matter of style, and such a thing MIGHT be enforceable on a
> PROJECT basis.
>
> I would like it if there were lint-like tools that guarded the
> repository.  They would beautify code to project standards, and
> enforce restrictions decided on a per-project basis.
>
> They would enforce the naming rules, see Coding Conventions in the
> Java glossary.
>
> You might even demand that each element of a variable name live in a
> dictionary.  What drives me nuts is maintaining somebody else's code
> who can't spell.
>
> I could imagine that a SCID would have a project dictionary with
> special terminology carefully defined.  Coming cold into a project
> learning the undocumented vocabulary is the hardest thing. All words
> used in variable names would have to be defined if the standard Oxford
> definition did not suffice.
>
> We need to evolve computer languages more toward communication: human
> <=> human and machine => human, rather than just human => machine.
>
> One example would be avoiding nested scope to resolve ambiguity.
> Computers have no problem with it, but in many cases it befuddles
> humans.
>
>
> -
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at:
> http://mindprod.com/gloss.html or http://209.153.246.39/gloss.html
> If you don't see what you were looking for, complain!
> or send your contribution for the glossary.
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963.
> Almost ready to take on new work.
>

Re: Long names are doom ?

[Kent Dahl]

Marin David Condic wrote:
> or be set to some really big number that in practice will never be
> exceeded - like 256 or 512.)

I keep seeing 256 and thinking of Visual C++ 6.0 warnings that the STL
identifiers get truncated. So the arbitrary large (from a human point of
view)  256 limit is pretty small (from a machine point of view).

Oh, but then again C++ is off-topic on all the ng's :-P

-- 
<[ Kent Dahl ]>================<[ http://www.stud.ntnu.no/~kentda/ ]>
  )____(stud.techn.;ind.�k.data)||(softwareDeveloper.at(Trustix))_( 
 /"Opinions expressed are mine and not those of my Employer,      "\
( "the University, my girlfriend, stray cats, banana fruitflies,  " )
 \"nor the frontal lobe of my left cerebral hemisphere.           "/

Re: Long names are doom ?

[Wes Groleau]

> One example would be avoiding nested scope to resolve ambiguity.
> Computers have no problem with it, but in many cases it befuddles
> humans.

Computers might not, but compilers are written by humans.
I once spent days trying to find a bug that turned out to
be caused by the compiler confusing a formal parameter 
and a global variable several scope levels higher,

And it WAS the most logical name for each.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: Long names are doom ?

[tmoran]

>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
> Then please respond  why, where, when.

  When I'm in too big a hurry to do it right?
Coming up with good names is neither quick nor easy.  Sometimes it's
better to be verbose and clean it up later, than to be cryptic and
try to clean it up later.

Re: Long names are doom ?

[Patrick Logan]

"00001111" <00001111@my-deja.net> wrote
in message news:3B0DBD4A.82943473@my-deja.net...
>
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
>
> Then please respond  why, where, when.

(1) Source code generators can easily generate new names when
     they do not have to consider name length.

    [All kinds of limits can be reached more easily by automatic
     generator tools. This used to be very common. Newer compilers
     have taken this into consideration based on experience.]

(2) Editors with completion make long names tolerable. Languages
     without name space mechanisms make long names necessary.
    Readable code includes names longer than 31 character sometimes
    when programmers combine longer, unabbreviated names. But
    hopefully not often.

--
Patrick Logan
mailto:patrickdlogan@home.com

Re: Long names are doom ?

[Florian Weimer]

00001111 <00001111@my-deja.net> writes:

>   Anybody use variables/names longer than 31 character
> and finds it really useful ?

Constants for Unicode characters?

GREEK_CAPITAL_LETTER_ALPHA_WITH_DASIA_AND_PERISPOMENI_AND_PROSGEGRAMMENI
ARABIC_LIGATURE_UIGHUR_KIRGHIZ_YEH_WITH_HAMZA_ABOVE_WITH_ALEF_MAKSURA_ISOLATED_FORM

SCNR.

Re: Long names are doom ?

[Larry Kilgallen]

In article <3B0DBD4A.82943473@my-deja.net>, 00001111 <00001111@my-deja.net> writes:

>   Anybody use variables/names longer than 31 character
> and finds it really useful ?

Absolutely.

> Then please respond  why, where, when.

In an Ada package automatically generated from ASN.1 specifications.
The long names contain the exact derivation of each identifier,
based on combining the names used for the ASN.1 modules from which
they are derived and their names within those modules.

> I have folks here in comp.lang.fortran who will die claiming that they
> 
> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."

Yes, the identifiers are hard to read, but that is better than having
the information missing.  Recently I had the opportunity to read
some code in C that regularly exceeds a length of 31 characters.  I
tried (before I understood my compiler for C, not my native language)
to come up with shorter names for these identifiers, and found that
my human-shortened names were _never_ as meaningful as the original
for someone who understands the problem domain.

> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.

Those who implement Ada compilers are required to support at least
200 characters.  I made the mistake of inadvertently going over that
limit on a more permissive compiler, only to redo the generator when
I tried to use the result on a less permissive compiler.  You would
be well advised to require at least the capability for a warning at
whatever the minimum number of siginificant characters is to be.

Re: Long names are doom ?

[Marin David Condic]

Is this a troll? :-)

I've used, and seen used, identifiers longer than 31 characters. If done
judiciously and with a proper sense of purpose, this can be a big aid in
understanding a program. It may avoid cryptic abbreviations and possibly
help you sort out variables v constants v procedures v types and so forth.
As with anything, it can be badly overdone. (To index an array, what's wrong
with "for X in Some_Array'Range"? Would someone find it superior to say "for
An_Index_For_The_Array_Called_Some_Array in Some_Array'Range"?)

One may choose not to use names longer than 6 characters. That's their
judgement call. However, I see no reason to put this sort of restriction
into the language design. Not in the days of megabytes of memory and
gigabytes of disk space.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"00001111" <00001111@my-deja.net> wrote in message
news:3B0DBD4A.82943473@my-deja.net...
>
>  Hi All,
>
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
>
> Then please respond  why, where, when.
> I have folks here in comp.lang.fortran who will die claiming that they
>
> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."
>
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
>
> cheers
>
>

Re: Long names are doom ?

[tmoran]

> Anybody use variables/names longer than 31 character
> ...
> I have folks here in comp.lang.fortran who will die claiming that
> [various objections to long names]

  There may actually exist data on this normally faith-based question:
Section 3.3, "Naming Conventions", in "Ada Quality and Style -
Guidelines for Professional Programmers" says "...  you can further
improve comprehension if your variable names are not excessively long."
and references p.7 of Schneiderman, B.  1986 "Empirical Studies of
Programmers:  The Territory, Paths and Destinations" in "Empirical
Studies of Programmers" ed. E. Soloway and S. Iyengar.

Re: Long names are doom ?

[Marin David Condic]

Data is A Good Thing. What these sort of style debates degenerate to is
usually personal preference backed up with "evidence" arrived at through
rectal extraction.

Perhaps a controlled study could be performed? Take a single module of
reasonable complexity (a hundred lines or so) and code it with long and
short names. Insert a bug. Determine how long it takes a few dozen
programmers to find and fix the bug. Similarly, code a system of higher
complexity - say 10 packages of 5 subprograms each (find one already out
there?) and code it both ways. (Auto-translate long names to short names).
Insert a bug. See how long it takes the programmers to find and fix it.

That sort of test would not be impossible to construct and could be done
relatively easily in a controlled environment. If well constructed, it ought
to settle the debate and suggest what we ought to be doing when coding
things of different sizes. At least with respect to evolving systems. Throw
away code (write only memory?) may be faster to develop with only single
character identifiers and who cares about understanding it?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:EJwP6.33931$%i7.27394225@news1.rdc1.sfba.home.com...
>   There may actually exist data on this normally faith-based question:
> Section 3.3, "Naming Conventions", in "Ada Quality and Style -
> Guidelines for Professional Programmers" says "...  you can further
> improve comprehension if your variable names are not excessively long."
> and references p.7 of Schneiderman, B.  1986 "Empirical Studies of
> Programmers:  The Territory, Paths and Destinations" in "Empirical
> Studies of Programmers" ed. E. Soloway and S. Iyengar.

Re: Long names are doom ?

[Jon Skeet]

tmoran@acm.org <tmoran@acm.org> wrote:
> > Anybody use variables/names longer than 31 character
> > ...
> > I have folks here in comp.lang.fortran who will die claiming that
> > [various objections to long names]
> 
>   There may actually exist data on this normally faith-based question:
> Section 3.3, "Naming Conventions", in "Ada Quality and Style -
> Guidelines for Professional Programmers" says "...  you can further
> improve comprehension if your variable names are not excessively long."
> and references p.7 of Schneiderman, B.  1986 "Empirical Studies of
> Programmers:  The Territory, Paths and Destinations" in "Empirical
> Studies of Programmers" ed. E. Soloway and S. Iyengar.

Note that data which was accurate in 1986 may not be applicable now - 
screen space isn't at quite such a premium now, and syntax highlighting 
(maybe it was available then; I don't know) helps readability too.

-- 
Jon Skeet - skeet@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time

Re: Long names are doom ?

[Tom Spilman]

    People will abuse language features no matter what precautions are taken
by the language designers.  Limiting maximum length for identifiers for
reasons other than technical limits or ease of implementation is naive and
forces an unnecessary constraint for legitimate uses.  Tom

"00001111" <00001111@my-deja.net> wrote in message
news:3B0DBD4A.82943473@my-deja.net...
>
>  Hi All,
>
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
>
> Then please respond  why, where, when.
> I have folks here in comp.lang.fortran who will die claiming that they
>
> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."
>
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
>
> cheers
>
>

Re: Long names are doom ?

[Gary Scott]

Hi, I think that none of these points being made were lost on the
language committee.  Fortran does not specify the MAXIMUM length of
identifiers, it specifies the MINIMUM length that must be supported by a
compiler.  Some compilers support "infinite" length names.  Some
compiler vendors were also against extremely long names because it would
have severely broken their existing compiler (complete redesign
required).  

The minimum length of 31 was likely chosen for C compatibility.  There
unfortunately has always been a war between factions that want to make
Fortran more "general purpose" and those that want to retain (hold back
(er limit compiler complexity)) its niche status in the numerical
computation arena.  Mathematical algorithms with extremely long names
used as variables are usually less clear.  Math is highly
symbolic/mnemonic oriented.  Most scientists and engineers (i.e.
"non-professional"-programmers) are extremely comfortable with
abbreviations/symbols/mnemonics.  I personally like the shorter limit,
but I WOULD like to see some sort of a name ALIAS facility for externals
to aid interfacing with other languages (that decorate names, or with
otherwise different naming rules, or that allow characters within a name
that Fortran does not allow, etc).

Tom Spilman wrote:
> 
>     People will abuse language features no matter what precautions are taken
> by the language designers.  Limiting maximum length for identifiers for
> reasons other than technical limits or ease of implementation is naive and
> forces an unnecessary constraint for legitimate uses.  Tom
> 
> "00001111" <00001111@my-deja.net> wrote in message
> news:3B0DBD4A.82943473@my-deja.net...
> >
> >  Hi All,
> >
> >   Anybody use variables/names longer than 31 character
> > and finds it really useful ?
> >
> > Then please respond  why, where, when.
> > I have folks here in comp.lang.fortran who will die claiming that they
> >
> > - "never seen a well written, legible program
> >   that uses any identifiers longer than 18-20 characters..".
> > - "long variables names are *hard* to read.  And, you have to
> >   read though all the characters of every instance of them...".
> > - "it degrades the legibility of a program to use identifiers that
> >   can't be easily remembered...."
> >
> > As a result, despite 90% of computer languages have long, very
> > long or 'infinite' identifiers, fortran folks seems plan to stay
> > with their 6...aargh ...sorry this was just not far ago... 31 character
> > limit intil year 3000.
> >
> > cheers
> >
> >


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://g95.sourceforge.net

Re: Long names are doom ?

[00001111]

00001111 wrote:

>  Hi All,
>
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
>I have folks here in comp.lang.fortran who will die claiming that they
>
> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."




Christian Brolin (comp.lang.functional) wrote the program
which abbreviates identifiers.
  In fact if you look deeply you start to smile.
This definitely is not human respond on these 3 initial claims but
Computer's one  where even 'cyber brain'  laughs full of irony.



Christian Brolin (comp.lang.functional) wrote:
>
> I have a program that can abbreviate names, e.g.:
>
>   [(len,abbreviate len "Anybody_use_names_longer_than_31_characters")
>    | len <- [43,42..10]];
>   [(43, "Anybody_use_names_longer_than_31_characters"),
>    (42, "Anybody_use_names_longer_than_31_charactrs"),
>    (41, "Anybody_use_names_longer_than_31_charctrs"),
>    (40, "Anybody_use_names_longer_than_31_chrctrs"),
>    (39, "Anybody_use_names_longer_thn_31_chrctrs"),
>    (38, "Anybody_use_names_longr_thn_31_chrctrs"),
>    (37, "Anybody_use_names_lngr_thn_31_chrctrs"),
>    (36, "Anybody_use_nams_lngr_thn_31_chrctrs"),
>    (35, "Anybody_use_nms_lngr_thn_31_chrctrs"),
>    (34, "Anybdy_use_nms_lngr_thn_31_chrctrs"),
>    (33, "Anbdy_use_nms_lngr_thn_31_chrctrs"),
>    (32, "Anbdy_us_nms_lngr_thn_31_chrctrs"),
>    (31, "Anbd_us_nms_lngr_thn_31_chrctrs"),
>    (30, "Anbd_us_nms_lngr_thn_31chrctrs"),
>    (29, "Anbd_us_nms_lngr_thn31chrctrs"),
>    (28, "Anbd_us_nms_lngrthn31chrctrs"),
>    (27, "Anbd_us_nmslngrthn31chrctrs"),
>    (26, "Anbd_usnmslngrthn31chrctrs"),
>    (25, "Anbdusnmslngrthn31chrctrs"),
>    (24, "Anbdusnmslngrthn31chrctr"),
>    (23, "Anbdusnmslngrthn31chrct"),
>    (22, "Anbdusnmslngrthn31chrc"),
>    (21, "Anbdusnmslngrthn31chr"),
>    (20, "Anbdusnmslngrthn31ch"),
>    (19, "Anbdusnmslngrthn31c"),
>    (18, "Anbdusnmslngrthn31"),
>    (17, "Anbdusnmslngrthn3"),
>    (16, "Anbdusnmslngrthn"),
>    (15, "Anbdusnmslngrth"),
>    (14, "Anbdusnmslngrt"),
>    (13, "Anbdusnmslngr"),
>    (12, "Anbdusnmslng"),
>    (11, "Anbdusnmsln"),
>    (10, "Anbdusnmsl")
>
>

Continuing little bit

  (9,...)
  (8,...)
  (7,...)
  (6,...)
  (5,...)
  (4,...)
  (3,...)
  (2,An)
  (1,A)
  (0, ERROR:  FORTRAN NAME IS TOO SHORT.
CHOOSE IT BETWEEN 1 and 6 CHARACTERS.  STOP. END)



Bravo Christian ! That's just real Classics!






Christian Brolin (comp.lang.functional) wrote:


>
>
>
>
>
>
>
>   Code:
>
>   abbreviate :: Int -> String -> String
>   abbreviate maxlen
>     = truncate
>     . reverse
>     . remove wordSeparators
>     . remove allButFirstVowels
>     . remove adjacentDuplicates
>     . remove vowelsEmbeddedInConsonants
>     . reverse
>     where
>       isVowel c = elem c "aeiouy"
>       isConsonant c = isAlpha c && not (isVowel c)
>       remove rule name = remove' (length name) rule name
>       remove' _ _ [] = []
>       remove' len rule name
>         | len > maxlen = let (keep,del,test) = rule name
>                          in keep ++ remove' (len - del) rule test
>         | otherwise = name
>       vowelsEmbeddedInConsonants (f:e:d:rest)
>         | isConsonant d && isVowel e && isConsonant f = ([f],1,d:rest)
>         | otherwise = ([f],0,e:d:rest)
>       vowelsEmbeddedInConsonants name = (name,0,[])
>       adjacentDuplicates (e:d:rest)
>         | d==e = ([],1,d:rest)
>         | otherwise = ([e],0,d:rest)
>       adjacentDuplicates name = (name,0,[])
>       allButFirstVowels (e:d:rest)
>         | isAlpha d && isVowel e = ([],1,d:rest)
>         | otherwise = ([e],0,d:rest)
>       allButFirstVowels name = (name,0,[])
>       wordSeparators (u:rest)
>         | u=='_' = ([],1,rest)
>         | otherwise = ([u],0,rest)
>       wordSeparators name = (name,0,[])
>       truncate = take maxlen
>
>   --
>   Christian Brolin -> Det �r fult att peka
> Then please respond  why, where, when.

Re: Long names are doom ?

[Phil K]

00001111 <00001111@my-deja.net> wrote in message news:<3B0DBD4A.82943473@my-deja.net>...
> Hi All,
> 
>   Anybody use variables/names longer than 31 character
> and finds it really useful ?
> 
> Then please respond  why, where, when.
> I have folks here in comp.lang.fortran who will die claiming that they
> 
> - "never seen a well written, legible program
>   that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read.  And, you have to
>   read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
>   can't be easily remembered...."
> 
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
> 
> cheers


Anyone who has worked on a code generator has probably found that
generated names are often longer than expected.  They often contain
class, method, and context information, which often leads to more than
31 characters.  They have probably also found that making readable
code from a generator is not always the easiest thing to do.  At the
same time though, those long names often make it absolutely clear
where the names came from.  You know exactly which file and often
where in the file it came from.

-PK

Re: Market pressures for more reliable software

[robin]

Roedy Green <roedy@mindprod.com> writes: > On Wed, 27 Jun 2001 09:41:58 GMT, "Gary Labowitz" <garyl@enter.net>
> wrote or quoted :
> 
> >I'm curious what you mean by "relocation" that you were shocked that S/360
> >didn't have it.
> 
> The univac 1100, the IBM 360s predecessor, had a relocation register
> so you could load a ram image and start executing without having to
> make any adjustments.  
> 
> The 360 used absolute addresses.

No. It used relative addressing, and base-relative addressing.
(strictly speaking, it used base-displacement-indexed addressing.)
The assembler allowed "absolute" addresses to be specified,
which had to be filled in by the loader.

Any program can be loaded anywhere in memory.
Programs can be made dynamically relocatable, but only with some effort.

In the days when the 360 first came out, dynamin program relocation
would have been an advantage (programs were relatively small, say, 200K bytes).
These days the disadvantage of dynamic relocation is that the
time taken to relocate a large program 10Mb, 100Mb becomes significant.

> To load you had to adjust all the
> address references to account for where in RAM the program was loaded.

No, only those words that had been specified as containing an absolute
address.

> This greatly slowed down the process of getting a program started.
> 
> Exploiting relocation hardware to speed loading is still not fully
> exploited even in Windows NT.
> --
> Roedy Green, Canadian Mind Products

Re: Market pressures for more reliable software

[Roedy Green]

On Thu, 28 Jun 2001 04:01:02 GMT, robin <robin_v@bigpond.nospam.com>
wrote or quoted :

>> To load you had to adjust all the
>> address references to account for where in RAM the program was loaded.
>
>No, only those words that had been specified as containing an absolute
>address.

you only had a 12 bit displacement, so you needed great many ADCONS
(address constants), to fill your base registers with before you could
get at anything. On load, all these had to be adjusted to account for
where the program was actually loaded in RAM.



For more detail, please look up the key words mentioned in this post in
the Java Glossary at: http://mindprod.com/gloss.html 

--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Dale King]

Guys, I think this has strayed way off topic for any of these newsgroups. If
you want to continue it I suggest finding a more suitable place and subject
line. Perhaps comp.misc?

--
 Dale King

"Roedy Green" <roedy@mindprod.com> wrote in message
news:s0nljt02faoreuqrftur6k9qpmjsotv6hc@4ax.com...
> On Thu, 28 Jun 2001 04:01:02 GMT, robin <robin_v@bigpond.nospam.com>
> wrote or quoted :
>
> >> To load you had to adjust all the
> >> address references to account for where in RAM the program was loaded.
> >
> >No, only those words that had been specified as containing an absolute
> >address.
>
> you only had a 12 bit displacement, so you needed great many ADCONS
> (address constants), to fill your base registers with before you could
> get at anything. On load, all these had to be adjusted to account for
> where the program was actually loaded in RAM.
>
>
>
> For more detail, please look up the key words mentioned in this post in
> the Java Glossary at: http://mindprod.com/gloss.html
>
> --
> Roedy Green, Canadian Mind Products
> Custom computer programming since 1963. Ready to take on new work.

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

robin wrote:


> No. It used relative addressing, and base-relative addressing.
> (strictly speaking, it used base-displacement-indexed addressing.)
> The assembler allowed "absolute" addresses to be specified,
> which had to be filled in by the loader.

You're confusing two different things. The S/360 used absolute addresses, but they were not present in
instructions. At least, it did until prefixing came along. As to assembler language, it was relocatable addresses
that had to be adjusted by the loader; if the program specified an absolute address, then the loader did not have
to adjust it.

> Any program can be loaded anywhere in memory.
> Programs can be made dynamically relocatable, but only with some effort.

That was the theory in VMS; IBM had to scrap it and replace it with MVS.


> In the days when the 360 first came out, dynamin program relocation
> would have been an advantage (programs were relatively small, say, 200K bytes).
> These days the disadvantage of dynamic relocation is that the
> time taken to relocate a large program 10Mb, 100Mb becomes significant.

No, it's insignificant, because you only need to change the page tables.

--
Shmuel (Seymour J.) Metz

Re: Market pressures for more reliable software

[Shmuel (Seymour J.) Metz]

In <2_x_6.6808$e5.26279@newsfeeds.bigpond.com>, on 06/28/2001
   at 04:01 AM, robin <robin_v@bigpond.nospam.com> said:

>No. It used relative addressing, and base-relative addressing.
>(strictly speaking, it used base-displacement-indexed addressing.)
>The assembler allowed "absolute" addresses to be specified, which had
>to be filled in by the loader.

See "Address Generation" on page 13 of the S/369 Principles of
Operation. The displacement is not an address. The address that the
processor generates form the base, displacement and index is an
absolute address except on a 65MP or 360/67.

>The assembler allowed "absolute" addresses to be specified, which
>had to be filled in by the loader.

You're confusing absolute with reolcatable. A relocatable adress had
to be adjusted by the loader; an absolute address did not.

>No, only those words that had been specified as containing an
>absolute address.

See above.


-- 
-----------------------------------------------------------
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2
     Team OS/2
     Team PL/I

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me.  Do not reply to
spamtrap@library.lspace.org
-----------------------------------------------------------

Re: Market pressures for more reliable software

[robin]

Lao Xiao Hai <laoxhai@ix.netcom.com> writes: > 
> 
> "Shmuel (Seymour J.) Metz" wrote:
> 
> > ENIAC was before my time, but I'd agree that development was probably
> > centralized in those days. What is in dispute is whether development was
> > centralized in the years or decades immediately preceding the PC. But
> > distributed development occurred even when the computer was centralized, even
> > before the 7090.
> 
> Perhaps.  But, for most organizations, emphasis on the word most, computing
> resources within an organization was under the centralized managment of
> one central authority.  Moreover, most of the computing was located in one
> place.  It is true that some very large corporations had computers distributed
> across their divisions, but that was a luxury not affordable by most of industry.
> 
> This centralization, during the 70's and through the mid-80's even extended to
> collections of companies.   Ever hear of a service bureau.   In service bureaus
> we centralized the computing for vertical markets as well as for such things
> as payroll, general accounting, and other business applications.   There was
> very little distributed development before the advent of, first the minicomputer,
> and later the microcomputer.
> 
> Networks were still a mystery for most people.   Programmers were busy
> grinding out programs in COBOL.   Compilers needed large memory spaces
> and operating systems and these were hosted on million dollar plus machines,
> making it too expensive to distribute them all over the place.

Neither large nor expensive.
One machine we had cost (then) $150,000 and had 402 words of main
memory and 32K bytes of rotating storage.
The smaller IBM 360 machines had 16K bytes to 32K bytes.

>  The exceptions
> were the Fords, Chryslers, and other industrial giants with money to burn.
> 
> I spent a lot of years consulting to, developing software for, and cleaning up
> after these centralized computing facilities.
> 
> Things are a lot more distributed now.   Frankly, as I look at the quality of some
> of the software, I am not sure that can be classified as progress.
> 
> Richard Riehle

Re: Market pressures for more reliable software

[R. Vowels]

"Gary Labowitz" <garyl@enter.net> writes: 
> This is getting ridiculous. You are SO hoping that computing and programming
> were not centralized that you skip an entrie generation.
> When most people talk about early days, they mean when computers actually
> came into the marketplace and were large centralized systems. Certainly
> programmers could be stationed anywhere. But terminal systems (starting with
> the various 1050-type systems) weren't available in the "early days."
> Actually, I remember the introduction of the 1050 as a big deal (about 1963
> or so, maybe a little later). To get programming into the machine it first
> had to be keypunched, and that was almost always "centralized."

We did almost ALL of our own keypunching until 1970 and even then
quite some after that.

> You sent
> your coding sheets to the center to be keypunched. Some of us would go there
> ourselves and do our own keypunching (those that typed).

I finished up buying a keypunch in about 1977 so that I could do some
at home..

> On the Univac-I we
> went to the computer and used the console keypunch.
> Anyway, the later systems developed the RJE-type systems, which
> decentralized the point at which program streams could be entered and
> printed. They still connected to centralized processing, however. Since all
> the terminals were dumb, there was only decentralized job entry and
> printing.
> The real point is: so what? So you said "in the early days we had
> decentralized computing" and were wrong.
> Live with it.
> Let's get on with today's problems.
> Gary
> "Shmuel (Seymour J.) Metz" <nospam@acm.org> wrote in message
> news:3B432AD8.3828FB9@acm.org...
> >
> >
> > Lao Xiao Hai wrote:
> >
> > > I must be missing the point.    What was not centralized?
> >
> > As I said multiple times, programming.
> >
> >
> > > Programming was pretty
> > > much centralized and under the control of a data processing manager.
> Computers
> > > were pretty much centralized, and there weren't that many that could
> drive remote
> > > terminals really well.
> >
> > Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP
> Multileaving? And
> > that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and
> Wylbur on S/360, and
> > others on non-IBM hardware. There was enough time sharing and remote batch
> to drive a market
> > in plug-compatible terminals and modems.
> >
> > > Most of the data processing was in batch mode.
> >
> > Which doesn't make it centralized.
> >
> >
> > > That is not how I remember it.
> >
> > Clearly. Either your experience was limited or your memory is faulty.
> >
> >
> >
> > > Most of the programs I recall were written by the
> > > programmers
> > > at the service bureau.  Some were packages purchased from elsewhere.
> It was the rare
> > > customer who had programming resources on which they could rely for
> their own software.
> >
> > By the 70s most service bureaus were offering remote access. Ever wonder
> why?
> >
> >
> > > Not that common.
> >
> > Common enough to drive a market in brand X clones of terminals and modems,
> e.g., Cope 45 for
> > remote batch, Vadic modems.
> >
> >
> > > And it was expensive.
> >
> > TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers.
> >
> >
> > > I have done both.   Certainly a lot of scientific computing was done
> using remote
> > > computers.   However, I recall quite vividly those sites that had their
> own IBM 1130
> > > and did their own Fortran programming.   I spent many late night hours
> writing Fortran II
> > > and debugging on the 1130.
> >
> > And how many of those 1130s cost $150,000? To say nothing of the fact that
> a lot of them were
> > submitting jobs to larger machines.
> >
> >
> > > The IBM 1401 was the workhorse of industry for a long time.
> >
> > And cost nowhere near $150,000.
> >
> >
> > > Oh, and you forgot one of my personal favorites, the CDC
> > > 160 series.
> >
> > I didn't forget it, any more than I forgot LGP or RCA; I omitted it
> because I was
> > concentrating on the IBM marketplace.
> >
> > > The IBM System 360 series came along in 1964 and, along with its
> lots of
> >