Ada generics are bad

Ada generics are bad

[Glenden Lee]

Is it just our compiler or are all compilers this dumb... When a package 
body that contains the body of generic units get changed, all other 
packages that instantiate the generics must be recompiled as well.  This 
is contrary to the claim that generics save compilation time as some 
literature states...

That's all... I just wanted to vent some frustration... and besides the 
compiler is recompiling everything right now just because I did the above...

G.
-- 
Glenden Lee
Array Systems Computing
1120 Finch Avenue West
North York, Ontario

Re: Ada generics are bad

[Tucker Taft]

Glenden Lee (glee@array.ca) wrote:

: Is it just our compiler or are all compilers this dumb... When a package 
: body that contains the body of generic units get changed, all other 
: packages that instantiate the generics must be recompiled as well.  This 
: is contrary to the claim that generics save compilation time as some 
: literature states...

Generics are primarily intended to save (human) programming/testing time, 
not (machine) compilation time.  In some compilers, there is some
degree of code sharing between instantiations, but in many compilers
(both Ada and C++), each instantiation requires its own code,
and generating that code needs to be done anew whenever the generic
itself is changed.  You would be wise to put the source code for
a generic in its own source file (e.g. as a child library unit)
to minimize the likelihood that a change to unrelated code makes
it look like the generic itself has changed.

: That's all... I just wanted to vent some frustration... and besides the 
: compiler is recompiling everything right now just because I did the above...

: G.
: -- 
: Glenden Lee
: Array Systems Computing
: 1120 Finch Avenue West
: North York, Ontario

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Ada generics are bad

[Anonymous]

On Wed, 8 Apr 1998 14:46:40 GMT, glee@array.ca (Glenden Lee) wrote:

> Is it just our compiler or are all compilers this dumb... When a package 
> body that contains the body of generic units get changed, all other 
> packages that instantiate the generics must be recompiled as well.  This 
> is contrary to the claim that generics save compilation time as some 
> literature states...
> 
> That's all... I just wanted to vent some frustration... and besides the 
> compiler is recompiling everything right now just because I did the above...
> ...

I've never seen this claim (that generics save compilation time).
Generics reduce the amount of source code (in your case, I suspect,
significantly).

While generics can, and in some cases have been, implemented using code
sharing (RR Software's Janus Ada comes to mind), many compilers treat a
generic as a kind of template for macro expansion, and effectively
compile a modified version of the code for each instantiation. In such
cases, a generic instantiation creates a dependency on the body of the
generic, requiring recompilation of the instantiation whenever the body
of the generic changes.

Generics should be mature pieces of code that are frequently reused, so
their bodies should rarely change. However, such maturity is difficult
to achieve at first writing, so such "growing pains" should be expected
when using generics that are still under development. However, the
savings in duplicate code are well worth the pain. You are to be
commended for taking the long view and doing this right from the start.

Compare this to one DOD project I had the pleasure of working on: As one
example out of very many, we found about 350 procedures named
Open_The_Window which were identical except for the name of the window
being opened. Imagine the joys of modifying that system when the time
comes (as it comes to all).

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"I unclog my nose towards you."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Ada generics are bad

[Christopher Green]

In article <Er3npt.4sK@array.ca>, Glenden Lee <glee@array.ca> wrote:
>Is it just our compiler or are all compilers this dumb... When a package 
>body that contains the body of generic units get changed, all other 
>packages that instantiate the generics must be recompiled as well.  This 
>is contrary to the claim that generics save compilation time as some 
>literature states...
>
>That's all... I just wanted to vent some frustration... and besides the 
>compiler is recompiling everything right now just because I did the above...
>
>G.
>-- 
>Glenden Lee
>Array Systems Computing
>1120 Finch Avenue West
>North York, Ontario

Some compilers (Apex is one) have an option for "function form" generics.
This allows the generic body to be compiled once and reused for each
instance of the generic.  Function form generics are often not quite as
efficient in code speed (because they can't be inlined), and there are
a few cases in which they can't be used at all.

With "function form" generics, updating and recompiling the generic body
does not obsolete units that instantiate it or depend on instantiations,
and it is possible to deliver libraries that include only object code
for such bodies (this is a key concern for developers of commercial Ada
software such as ourselves, who are wary of releasing more source code
than we absolutely have to).
-- 
Chris Green                                  Email cgreen@atc.com
Advanced Technology Center                   Phone (714) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (714) 583-9213

Re: Ada generics are bad

[Brian Rogoff]

On 10 Apr 1998, Christopher Green wrote:
> In article <Er3npt.4sK@array.ca>, Glenden Lee <glee@array.ca> wrote:
> > ... complaints about generics leading to recompilation snipped ...
> 
> Some compilers (Apex is one) have an option for "function form" generics.
> This allows the generic body to be compiled once and reused for each
> instance of the generic.  Function form generics are often not quite as
> efficient in code speed (because they can't be inlined), and there are
> a few cases in which they can't be used at all.

I think this can be phrased very simply, at the risk of some
oversimplification. Generics which share code rely on some level of 
uniform representation, and hence pointers/access-types. This indirection 
allows one to get away with fewer recompiles. The same issue arises
without generics if you look at the representation information in the 
private section of a package spec. If the size of some data type changes
there than you have to recompile dependent packages. If you use the 
trick of making all datatypes pointers to things in the body, than you
shouldn't have to recompile. 

Ada compilers typically implement generics by macro expanding, ML
is typically like Lisp in that everything is a poinetr "under the hood".
Each has its advantages and disadvantages. One could argue that the 
method of implementation should be specified; I tend to write Ada as 
though macro expansion of generics is a given.

-- Brian

> With "function form" generics, updating and recompiling the generic body
> does not obsolete units that instantiate it or depend on instantiations,
> and it is possible to deliver libraries that include only object code
> for such bodies (this is a key concern for developers of commercial Ada
> software such as ourselves, who are wary of releasing more source code
> than we absolutely have to).
> -- 
> Chris Green                                  Email cgreen@atc.com
> Advanced Technology Center                   Phone (714) 583-9119
> 22982 Mill Creek Drive                                   ext. 220
> Laguna Hills, CA 92653                       Fax   (714) 583-9213
> 
> 

Re: Ada generics are bad

[Robert Dewar]

Chris Green says

<<With "function form" generics, updating and recompiling the generic body
does not obsolete units that instantiate it or depend on instantiations,
and it is possible to deliver libraries that include only object code
for such bodies (this is a key concern for developers of commercial Ada
software such as ourselves, who are wary of releasing more source code
than we absolutely have to).
>>

Very often an approach that works well is to isolate the "generic" parts
of the body, and use common code for the non-generic parts. Look at the
GNAT code for an example of how this is done, in particular, look at
the code for Float_IO. Almost nothing of interest is in the generic itself,
all the "good stuff" is in the common units.

This could be used to "solve" the "problem" of releasing more source code
than you absolutely have to, although from a users point of view, using
libraries where you do not have the source and do not know what is going
on seems pretty dubious. I suppose if the only option you have is to use
closed software of this kind, then the risk may be acceptable. 

Re: Ada generics are bad

[Christopher Green]

In article <dewar.892345837@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Chris Green says
>
><<With "function form" generics, updating and recompiling the generic body
>does not obsolete units that instantiate it or depend on instantiations,
>and it is possible to deliver libraries that include only object code
>for such bodies (this is a key concern for developers of commercial Ada
>software such as ourselves, who are wary of releasing more source code
>than we absolutely have to).
>>>
>
>Very often an approach that works well is to isolate the "generic" parts
>of the body, and use common code for the non-generic parts. Look at the
>GNAT code for an example of how this is done, in particular, look at
>the code for Float_IO. Almost nothing of interest is in the generic itself,
>all the "good stuff" is in the common units.

All good; however, sometimes one is stuck with maintaining existing code
that was not written with an eye to isolating generics in packages that
are not widely depended upon.  Then one finds, as the original poster did, 
that updating the generic body has a high cost in recompilation of other,
often quite unrelated, code.  Function-form generics and compilers with
smart recompilation are helpful in dealing with this kind of problem,
though they are no substitute for doing good design up front.

>This could be used to "solve" the "problem" of releasing more source code
>than you absolutely have to, although from a users point of view, using
>libraries where you do not have the source and do not know what is going
>on seems pretty dubious. I suppose if the only option you have is to use
>closed software of this kind, then the risk may be acceptable. 

Such closed software is standard (though far from universal) practice in 
the commercial "C" world.  

Whether it is desirable is a different question entirely:  from the de-
veloper's point of view, the more control retained over the source, the
better; from the user's point of view, the more access to the source, the
better.  The marketplace has a way of forcing sellers and buyers to reach
reasonable compromises.

-- 
Chris Green                                  Email cgreen@atc.com
Advanced Technology Center                   Phone (714) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (714) 583-9213

Re: Ada generics are bad

[Matthew Heaney]

In article <6gs5qa$s46@newshub.atmnet.net>, cgreen@yosemite.atc.com
(Christopher Green) wrote:

>>This could be used to "solve" the "problem" of releasing more source code
>>than you absolutely have to, although from a users point of view, using
>>libraries where you do not have the source and do not know what is going
>>on seems pretty dubious. I suppose if the only option you have is to use
>>closed software of this kind, then the risk may be acceptable. 
>
>Such closed software is standard (though far from universal) practice in 
>the commercial "C" world.  
>
>Whether it is desirable is a different question entirely:  from the de-
>veloper's point of view, the more control retained over the source, the
>better; from the user's point of view, the more access to the source, the
>better.  The marketplace has a way of forcing sellers and buyers to reach
>reasonable compromises.

I for one am tired of being held hostage by "developers who retain control
over the source."  If there's a problem, and I have the source, then at
least I can fix it; otherwise, I'm SOL.

This attitude of a developer "needing to retain control of source" is only
a sign that the developer has no other resource to control, such as a
software development process.  It's a desperate attempt to conceal the fact
that he barely knows what he is doing.

Claiming that the "marketplace" forces sellers and buyers to reach
"reasonable compromises" is a specious argument.  All you're doing is
trying to avoid taking personal responsibility for a choice YOU have made,
by blaming the "marketplace."  If you keep source closed, it is because you
decided to, not because the marketplace, God, the Easter Bunny, or anybody
else made you.

Somehow, when I buy a car, Toyota sells me...a car!  And when a buy a
microwave oven, Sears sells me...a microwave oven!  How do Toyota and Sears
even manage to stay in business at all, giving away all that technology
that the world can see and copy?

Here's a hint: a mature software development shop owns a process, not
software.  Software is merely the output of the process.  Just like the
manufacturing line at Toyota.  Or Sony. Or Motorola. Or any other
manufacturer of material goods.

Motorola's asset isn't CPU cards, it's a six-sigma process.  Imagine that,
letting me see the actual hardware inside my Mac!  But heaven forbid anyone
should get a look at my source code!

Retaining control of source does not bode well for the developer's ability
to write any other software, and customers are admonished to stay away when
they have the choice.  And let me tell you, there are many programmers out
there who make it their business to see that consumers of software do have
that choice.

If you persist in this anachronistic idea that it's better for the
developer to "retain control" of source, then you only prevent yourself
from improving your ability to develop any software at all.

Suppose we take a little unscientific survey of comp.lang.ada readers: Who
do you think has the more mature process: the Advanced Technology Center,
or Ada Core Technologies?  If you had a choice in buying software from ATC
or ACT, one of whom (ATC) said the source was closed, and the other (ACT)
open, from whom would you buy?

Or compare Microsoft and the Free Software Foundation.  Who would you
rather write software for you: Bill Gates, or Richard Stallman?

The software world is changing, Chris.  Why not change with it?

Re: Ada generics are bad

[Christopher Green]

In article <matthew_heaney-ya023680001304980058230001@news.ni.net>,
Matthew Heaney <matthew_heaney@acm.org> wrote:
>In article <6gs5qa$s46@newshub.atmnet.net>, cgreen@yosemite.atc.com
>(Christopher Green) wrote:
[snip]
>Or compare Microsoft and the Free Software Foundation.  Who would you
>
>rather write software for you: Bill Gates, or Richard Stallman?
>
>The software world is changing, Chris.  Why not change with it?

I don't make policy for my employer.  Persons whom I have no standing to
argue the point with have decided that we do not release complete source
code for our products.  I go along with their policy or work elsewhere.

Beyond that, I make no further response to ad hominem attacks.
-- 
Chris Green                                  Email cgreen@atc.com
Advanced Technology Center                   Phone (714) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (714) 583-9213

Re: Ada generics are bad

[nabbasi]

In article <matthew_heaney-ya023680001304980058230001@news.ni.net>,
matthew_heaney@acm.org says...

>Somehow, when I buy a car, Toyota sells me...a car!  And when a buy a
>microwave oven, Sears sells me...a microwave oven!  How do Toyota and Sears
>even manage to stay in business at all, giving away all that technology
>that the world can see and copy?
>

this is a good point. but software is different. copying a car engine by
just looking at it without having access to the design and the engineering
calculations that went behind building the engine is very hard. 
while in software, if one release the source code,  the "engineering" and 
the "caluclations" are sent out with the product itself. one can find
everything they want by examining the code. offcourse design docs whould
make it much easier to figure what the code is doing, but they are not
that neccessary for someone who wants to find how it works. 

Also, more important is that copying software is MUCH easier than 
copying a car engine. with software you just
make copies of it ! but with car engines, you have to build a plant, and hire
pepole and engineers, etc.. it is much more expensive, even if you know HOW
it is build, you can not build it as easily without lots of money, not the
case with making copies of software if you have the code.

having said this, it is not uncommon for car manufacturares such as GM, ford,
etc.. to buy a new car model that was just released by another compnay,  
take it to their plant, and disassemble it piece by piece, to find out 
how it was build, and to learn about how the competition builds its products. 


>Here's a hint: a mature software development shop owns a process, not
>software.  Software is merely the output of the process.  Just like the
>manufacturing line at Toyota.  Or Sony. Or Motorola. Or any other
>manufacturer of material goods.
>

true.

>Motorola's asset isn't CPU cards, it's a six-sigma process.  Imagine that,
>letting me see the actual hardware inside my Mac!  But heaven forbid anyone
>should get a look at my source code!
>

again. source code is different. Motorola whill let you see the chip, but
ask them for the software that designed the chip, will they give it to you?
offcourse no. because the competition will find out how Motorola designs
the chips from the inside out. 


>Or compare Microsoft and the Free Software Foundation.  Who would you
>rather write software for you: Bill Gates, or Richard Stallman?
>

Richard offcourse ! (just because my NT just froze on me again).

>The software world is changing, Chris.  Why not change with it?

But lets be realistic here. as long as there are companies who work for
profit, there will always be companies who will guard the source code they
develop. to remove this protection, you have to remove the need for companies
to make profit out of software. it is the America dream, to make money, and
make more money, isn't? :)  

Nasser

future of proprietry source code (was: Ada generics are bad)

[Fergus Henderson]

nabbasi@earthlink.net writes:

>But lets be realistic here. as long as there are companies who work for
>profit, there will always be companies who will guard the source code they
>develop. to remove this protection, you have to remove the need for companies
>to make profit out of software.

No, all you need to do is to make it uneconomic to hoard source code.

Today, in many (most?) areas of the software industry it is already
uneconomic to write products from scratch, without reusing existing
software such as GUI libraries, for example.  Furthermore, this trend
towards dependence on code reuse looks set to increase even further as
times goes by.  Currently these libraries are mostly proprietry,
but imagine what would happen if they were GPL'd!

Given the amazing rate of progress of GPL'd software since the birth of
the internet, it is far from unimaginable that in the future GPL'd
libraries may outpace and outcompete all the proprietry libraries.
This could lead to a situation in which refusal to release source code
would incur such a competitive disadvantage, due to the resulting inability
to reuse all this GPL'd code, that it was utterly uneconomic.

I don't know whether or not this scenario will eventuate, but
it is not unrealistic, IMHO, given a sufficiently long time frame.

If this scenario _does_ eventuate, however, then I think it could lead
to a much more efficient use of resources than is currently the case
in the software industry.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: future of proprietry source code (was: Ada generics are bad)

[David Masterson]

Fergus Henderson wrote:
> 
> nabbasi@earthlink.net writes:
> 
> >But lets be realistic here. as long as there are companies who work for
> >profit, there will always be companies who will guard the source code they
> >develop. to remove this protection, you have to remove the need for companies
> >to make profit out of software.
> 
> No, all you need to do is to make it uneconomic to hoard source code.
> 
> Today, in many (most?) areas of the software industry it is already
> uneconomic to write products from scratch, without reusing existing
> software such as GUI libraries, for example.  Furthermore, this trend
> towards dependence on code reuse looks set to increase even further as
> times goes by.  Currently these libraries are mostly proprietry,
> but imagine what would happen if they were GPL'd!

Fah!  This is a smokescreen that should be obvious by now.  GPL'd
software is not conducive to building a software development business
around.  Over the years of watching the rise of the GNU Manifesto and
GPL'd software, I've come to the following conclusions:

* GPL and a tools development business seem incompatible.
** GPL "frees" the source code for the tools of the business.
** "Free" source code dilutes the tool business' "competitive
advantage".
* GPL and a consulting business seems more (but not completely)
compatible.
** Tools to aid in the consulting work become "freely" available.
** Acquiring tools is no longer a barrier to entering the business.
** Improving the tools can attract new customers and hurt competitors.
** Improving the tools too much can hurt business ("works well for me").
* No business based upon the GPL will be a huge money maker.
** Large money attracts competition which dilutes the customer base.
** The GPL cuts the time for entering the market (copy a competitor).
** The GPL removes business incentive for developing good products.
* The ideals of the GNU Manifesto drove the development of the GPL.
** The GM and GPL target software but seem to have broader implications.
** The GM and GPL are controversial in their application to business.
** Controversy is bad for business.

> Given the amazing rate of progress of GPL'd software since the birth of
> the internet, it is far from unimaginable that in the future GPL'd
> libraries may outpace and outcompete all the proprietry libraries.
> This could lead to a situation in which refusal to release source code
> would incur such a competitive disadvantage, due to the resulting inability
> to reuse all this GPL'd code, that it was utterly uneconomic.

The amazing rate of progress in GPL'd software is largely due to people
on their own and without pay creating software that they are interested
in.  This is all well and good, but it isn't a business model.  When you
factor business concerns into this model, isn't it just another way of
saying "free labor"?

> I don't know whether or not this scenario will eventuate, but
> it is not unrealistic, IMHO, given a sufficiently long time frame.

The current interest in "free" software is largely due to a backlash
against Microsoft.  If Microsoft succeeds in quelling this backlash,
then the fervor for "free" software will die down (it won't go away) and
so will the progress that GPL'd software is making.

> If this scenario _does_ eventuate, however, then I think it could lead
> to a much more efficient use of resources than is currently the case
> in the software industry.

Again, can you say -- "free labor"...?

-- 
=========================
David Masterson
KLA-Tencor Corp.
One Technology Dr.
Milpitas, CA 95035
408-875-6836                           
David.Masterson@kla-tencor.com
=========================
I only speak for myself
  it keeps me out of trouble

Re: future of proprietry source code (was: Ada generics are bad)

[David Kastrup]

David Masterson <David.Masterson@kla-tencor.com> writes:

> The current interest in "free" software is largely due to a backlash
> against Microsoft.  If Microsoft succeeds in quelling this backlash,
> then the fervor for "free" software will die down (it won't go away)
> and so will the progress that GPL'd software is making.

The problem is that the "backlash" is not a mere temporary greed
symptom but is caused by the exact business practices that make
Microsoft successful at the inconvenience of their users and the
global market.

If it is going to stop, the business practices have to change to the
better.  But actual developments seem to go openly into the other
direction.


-- 
David Kastrup                                     Phone: +49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax: +49-234-709-4209
Institut f�r Neuroinformatik, Universit�tsstr. 150, 44780 Bochum, Germany

Re: future of proprietry source code (was: Ada generics are bad)

[David Masterson]

David Kastrup wrote:
> 
> David Masterson <David.Masterson@kla-tencor.com> writes:
> 
> > The current interest in "free" software is largely due to a backlash
> > against Microsoft.  If Microsoft succeeds in quelling this backlash,
> > then the fervor for "free" software will die down (it won't go away)
> > and so will the progress that GPL'd software is making.
> 
> The problem is that the "backlash" is not a mere temporary greed
> symptom but is caused by the exact business practices that make
> Microsoft successful at the inconvenience of their users and the
> global market.
> 
> If it is going to stop, the business practices have to change to the
> better.  But actual developments seem to go openly into the other
> direction.

Which suggests...  what?

-- 
=========================
David Masterson
KLA-Tencor Corp.
One Technology Dr.
Milpitas, CA 95035
408-875-6836                           
David.Masterson@kla-tencor.com
=========================
I only speak for myself
  it keeps me out of trouble

Re: future of proprietry source code (was: Ada generics are bad)

[David Kastrup]

David Masterson <David.Masterson@kla-tencor.com> writes:

> David Kastrup wrote:
> > 
> > David Masterson <David.Masterson@kla-tencor.com> writes:
> > 
> > > The current interest in "free" software is largely due to a backlash
> > > against Microsoft.  If Microsoft succeeds in quelling this backlash,
> > > then the fervor for "free" software will die down (it won't go away)
> > > and so will the progress that GPL'd software is making.
> > 
> > The problem is that the "backlash" is not a mere temporary greed
> > symptom but is caused by the exact business practices that make
> > Microsoft successful at the inconvenience of their users and the
> > global market.
> > 
> > If it is going to stop, the business practices have to change to the
> > better.  But actual developments seem to go openly into the other
> > direction.
> 
> Which suggests...  what?

That this "backlash" effect of interest in free software is probably
going to stay with us for quite a while.  As any technology advance of
properly free software is permanent, this interest and corresponding
developments will have lasting effects on the availability of free
alternatives to cut-throat business products.

Meaning that the longer Microsoft and consorts play rough, the worse
they'll damage their business.  And getting reasonable does not merely
mean a campaign with faked letters to editors, testimonials and other
stuff Microsoft is planning currently (see current press coverings).

-- 
David Kastrup                                     Phone: +49-234-700-5570
Email: dak@neuroinformatik.ruhr-uni-bochum.de       Fax: +49-234-709-4209
Institut f�r Neuroinformatik, Universit�tsstr. 150, 44780 Bochum, Germany

Re: future of proprietry source code (was: Ada generics are bad)

[campo]

In article <3533DD6A.B2EB8D16@kla-tencor.com>,
  David Masterson <David.Masterson@kla-tencor.com> wrote:

> Fah!  This is a smokescreen that should be obvious by now.  GPL'd
> software is not conducive to building a software development business
> around.  Over the years of watching the rise of the GNU Manifesto and
> GPL'd software, I've come to the following conclusions:

[snip]

GPL'd software leads to competition; hoarded software leads to monopolistic
practices.  It may be bad for a few (or just one :) giant\x12corporation, but
it can be much better for end users (I won't write "consumers") and for
smaller, dynamic enterprises.

[mega snip]

> The current interest in "free" software is largely due to a backlash
> against Microsoft.  If Microsoft succeeds in quelling this backlash,
> then the fervor for "free" software will die down (it won't go away) and
> so will the progress that GPL'd software is making.

The current *hype* in free software (a very recent phenomenon) may be due
to a backlash against Microsoft.  But the *interest* in free software has
a much deeper ground.  Now that complete, high-quality free software
systems are available and popular, they spread on their own merit; not
only technical merit, relying too much on hoardware *is* dangerous.

--
        Massimo Campostrini,
Istituto Nazionale di Fisica Nucleare, Sezione di Pisa.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: future of proprietry source code (was: Ada generics are bad)

[Tim Smith]

Fergus Henderson <fjh@cs.mu.oz.au> wrote:
>Today, in many (most?) areas of the software industry it is already
>uneconomic to write products from scratch, without reusing existing
>software such as GUI libraries, for example.  Furthermore, this trend
>towards dependence on code reuse looks set to increase even further as
>times goes by.  Currently these libraries are mostly proprietry,
>but imagine what would happen if they were GPL'd!

For large categories of software, the majority of customers don't want,
don't need, and could not make effective use of, source code, whereas one's
competitors could make effective use of it.  As long as that remains true,
a company can, all other things being equal, make more money keeping their
source secret.

That difference will probably be enough to ensure that there will be
companies that develop and sell development tools that can be used to make
proprietary software, so I don't think it is likely that it will ever come
to pass that all the major libraries are GPL'ed.

--Tim Smith

Re: future of proprietry source code (was: Ada generics are bad)

[Thomas Bushnell, n/BSG]

tzs@halcyon.com (Tim Smith) writes:

> For large categories of software, the majority of customers don't want,
> don't need, and could not make effective use of, source code, whereas one's
> competitors could make effective use of it.  As long as that remains true,
> a company can, all other things being equal, make more money keeping their
> source secret.

Those people STILL have a benefit to source code, which is that there
will be a free market for support.  That means that they will be able
to get their bugs fixed.

Thomas

Re: future of proprietry source code (was: Ada generics are bad)

[Bill Gribble]

tb@mit.edu (Thomas Bushnell, n/BSG) writes:
> tzs@halcyon.com (Tim Smith) writes: 
> > For large categories of software, the majority of customers don't want,
> > don't need, and could not make effective use of, source code, whereas one's
> > competitors could make effective use of it.  As long as that remains true,
> > a company can, all other things being equal, make more money keeping their
> > source secret.
> 
> Those people STILL have a benefit to source code, which is that there
> will be a free market for support.  That means that they will be able
> to get their bugs fixed.

I believe he's talking about software for embedded computers.  For
most of the embedded computers out there, there's no way to upgrade
the software without contracting to make your own CPUs with different
programs in the on-chip mask ROM.

In this case, there's no reasonable expectation that the user or any
third party can actually do *anything* with the source to fix bugs or
otherwise alter the behavior of the product.  

Bill Gribble

Re: future of proprietry source code (was: Ada generics are bad)

[Ole-Hjalmar Kristensen]

Bill Gribble <grib@cs.utexas.edu> writes:

> tb@mit.edu (Thomas Bushnell, n/BSG) writes:
> > tzs@halcyon.com (Tim Smith) writes: 
> > > For large categories of software, the majority of customers don't want,
> > > don't need, and could not make effective use of, source code, whereas one's
> > > competitors could make effective use of it.  As long as that remains true,
> > > a company can, all other things being equal, make more money keeping their
> > > source secret.
> > 
> > Those people STILL have a benefit to source code, which is that there
> > will be a free market for support.  That means that they will be able
> > to get their bugs fixed.
> 
> I believe he's talking about software for embedded computers.  For
> most of the embedded computers out there, there's no way to upgrade
> the software without contracting to make your own CPUs with different
> programs in the on-chip mask ROM.
> 
> In this case, there's no reasonable expectation that the user or any
> third party can actually do *anything* with the source to fix bugs or
> otherwise alter the behavior of the product.  
> 
> Bill Gribble

There is still an adavntage, in that the user may analyze the program
and find out what the system really does, as opposed to what the
documentation claims it does. :-)
Seriously, I have come across cases where reading the documentation
has been much less helpful than looking at the source.

Re: future of proprietry source code (was: Ada generics are bad)

[William Tanksley]

In article <6gthdp$bje$1@mulga.cs.mu.OZ.AU> fjh@cs.mu.oz.au (Fergus Henderson) writes:
>nabbasi@earthlink.net writes:

>>But lets be realistic here. as long as there are companies who work for
>>profit, there will always be companies who will guard the source code they
>>develop. to remove this protection, you have to remove the need for companies
>>to make profit out of software.

>No, all you need to do is to make it uneconomic to hoard source code.

I'm not sure I see how to do that -- at least not without attempting to
encroach.  It would seem to be more effective to make it economic to share
source code.

>Today, in many (most?) areas of the software industry it is already
>uneconomic to write products from scratch, without reusing existing
>software such as GUI libraries, for example.  Furthermore, this trend
>towards dependence on code reuse looks set to increase even further as
>times goes by.  Currently these libraries are mostly proprietry,
>but imagine what would happen if they were GPL'd!

>Given the amazing rate of progress of GPL'd software since the birth of
>the internet, it is far from unimaginable that in the future GPL'd
>libraries may outpace and outcompete all the proprietry libraries.
>This could lead to a situation in which refusal to release source code
>would incur such a competitive disadvantage, due to the resulting inability
>to reuse all this GPL'd code, that it was utterly uneconomic.

But this is a nice analysis which happens to look a good deal further into
the future than mine did.

On the other hand, you're not considering the effects of less restrictive
licenses.  I expect that companies will prefer to release any stuff they
make under the GPL, since that's the only way they can be sure of seeing
and being able to use improvements to their code.  However, I wouldn't be
suprised to see 'normal' programmers -- that is, those of us who have a
choice -- tending to gravitiate towards the less restrictive licenses.

Thus it's hard to tell.  I really think the the final result will be a
pretty steady and relatively even equilibrium.  Assuming, of course, that
there's always something profitable to discover.  If not, my theory goes
down the tubes after a fairly short amount of time.

>Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit

-Billy

Re: Ada generics are bad

[Al Christians]

Matthew Heaney wrote:
> 
> Or compare Microsoft and the Free Software Foundation.  Who would you
> rather write software for you: Bill Gates, or Richard Stallman?
> 

No.


Al

Re: Ada generics are bad

[Robert Munck]

On Mon, 13 Apr 1998 00:58:23 -0700, matthew_heaney@acm.org (Matthew
Heaney) wrote:
>... If there's a problem, and I have the source, then at
>least I can fix it; ...

Nonsense.  You fix a "broken" feature so that it works the way
you want it to, and then the developer comes out with a new 
release in which that feature either stays the way it was or
is changed to work a different way.  Now what do you do? "Fix"
it again?  Change all of you existing documents that use that
feature of the app?  Either way, you end up spending all of 
your time fixing all of your application packages.


>This attitude of a developer "needing to retain control of source" is only
>a sign that the developer has no other resource to control, such as a
>software development process.  It's a desperate attempt to conceal the fact
>that he barely knows what he is doing.

So say I hire ten great software engineers and establish a Level 6
development process. Then we spend a year and $2 million developing
a killer app.  You are saying that we have nothing to show for that?
That the system we've developed isn't worth anything? It would have
been easier just to burn the money.


>Here's a hint: a mature software development shop owns a process, not
>software.  Software is merely the output of the process.  Just like the
>manufacturing line at Toyota.  Or Sony. Or Motorola. Or any other
>manufacturer of material goods.

OK, I have a great process.  I've never developed any software,
but SEI says I'm level XVII.  No programmers, either, but one
insanely-great process.  How many investors do you think I'll get?
Would you be willing to send me your life's savings?


>Retaining control of source does not bode well for the developer's ability
>to write any other software,

Nor does it bode ill.  In fact, choosing not to give away the product
of your work has nothing whatsoever to do with your ability to do
more work.


>... and customers are admonished to stay away when
>they have the choice.

"Admonished?" By whom?


> there are many programmers out there who make it their business
>to see that consumers of software do have that choice. ... Who would
>you rather write software for you: Bill Gates, or Richard Stallman?

Let's see, Bill Gates is worth $50 billion.  Richard Stallman is
worth maybe $4.95.  Those programmers aren't "making it their
business...", they're making it their hobby.


>If you persist in this anachronistic idea that it's better for the
>developer to "retain control" of source, then you only prevent yourself
>from improving your ability to develop any software at all.

Again, there's no logical connection between the two things.


>Suppose we take a little unscientific survey of comp.lang.ada readers: Who
>do you think has the more mature process: the Advanced Technology Center,
>or Ada Core Technologies?

No idea.


>  If you had a choice in buying software from ATC
>or ACT, one of whom (ATC) said the source was closed, and the other (ACT)
>open, from whom would you buy?

The one that thinks that what they do has some value and doesn't
give it away to all comers.


>The software world is changing, Chris.  Why not change with it?

If you think that it's changing in the direction of increased
release of source code by developing companies, you're living
in a software dreamworld. 

Bob Munck
Mill Creek Systems LC

Re: Ada generics are bad

[Matthew Heaney]

In article <3533d2b3.81874922@news.mindspring.com>, munck@acm.org wrote:

>Nonsense.  You fix a "broken" feature so that it works the way
>you want it to, and then the developer comes out with a new 
>release in which that feature either stays the way it was or
>is changed to work a different way.  Now what do you do? "Fix"
>it again?  Change all of you existing documents that use that
>feature of the app?  Either way, you end up spending all of 
>your time fixing all of your application packages.

Not necessarily.  I could send the fix to the original developer, and then
(hopefully) he'll incorporate it into the next release.  (That will be
completed within hours or days.)

>If you think that it's changing in the direction of increased
>release of source code by developing companies, you're living
>in a software dreamworld. 

Then at least provide decent customer support.  If there's a problem with
the software, and I tell you about it, then how about repairing the
software and sending me the repaired version?

I'm not saying I'm unwilling to pay for software.  I am and I do.  I even
pay my shareware fees!  It's just that if there's a problem, and I don't
have the source, then I'm pretty much powerless to do anything about it.

With my car, if there's a problem with my carburetor, I can go to my local
parts store and buy a new carburetor.  I can even drive the car to the
dealer, and get it fixed on the spot.

Why shouldn't software be the same way?  Why do we even call it _soft_ware
anyway, if repairs and enhancements take so long?  Why does software come
with a disclaimer, instead of a warranty?

I guess what I'm really asking for is better customer service.  When
there's a problem, my desire is that I get a fixed version within a few
hours of my letting you know about it.  I'm not even asking for
enhancements - just that the errors get repaired.

In the end we're all in the "needs satisfaction" business.  If my needs as
a consumer of software are satisfied by the vendor, without him releasing
the source, then so be it.  But this is frequently not the case.

Re: Ada generics are bad

[Jonathan Guthrie]

In comp.lang.ada Robert Munck <munck@Mill-Creek-Systems.com> wrote:
> On Mon, 13 Apr 1998 00:58:23 -0700, matthew_heaney@acm.org (Matthew
> Heaney) wrote:
> >... If there's a problem, and I have the source, then at
> >least I can fix it; ...

> Nonsense.  You fix a "broken" feature so that it works the way
> you want it to, and then the developer comes out with a new 
> release in which that feature either stays the way it was or
> is changed to work a different way.  Now what do you do? "Fix"
> it again?  Change all of you existing documents that use that
> feature of the app?  Either way, you end up spending all of 
> your time fixing all of your application packages.

Actually, the third option is the one we take.  We ignore the new
release.  Since "free software" means never having to upgrade,
we don't need to bear the burden of an operating system that has
to be upgraded at someone else's whim.  We can continue to use "old,
but working fine" forever.

If a newer version of some software provides a feature that we feel
is important, then we evaluate the cost of performing the upgrade and
compare that to the expected benefits of performing the upgrade and
make an informed decision about OUR needs, not the needs of some
marketing VP whose revenues are a little short for the quarter.

What we give up for this freedom to use what we choose is the so-called
"support" that people try to get from the major software companies.  If
I have a package that basically works, and I have the source (for those
times when it does not) I don't need support.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.