Re: in defense of GC

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Georg Bauhaus <bauhaus@arcor.de> writes:

> On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote:
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>> 
>
>> > If you do this, perhaps you can find the time to use a, uh, stop-watch
>> > to measure the time it takes to produce, read, and change the programs?
>> > I.e., to technically manage significant software. The times will be
>> > important input for deciding whether or not static typing does indeed
>> > help in production.
>> > The only thing that relates to economic efficiency, if you want it :-)
>> 
>> So the how long a beginner in a specific language takes to do
>> something is "important input for deciding ..." if compared to what,
>> exactly?

<snipped>

> Now before I try singing old wisdom from the neighbourhood of
> The Mythical Man Month ...
> How will a piece of source code, your own or someone else's, and
> a language with tools fit these and the market as we might think
> it is now?

I find myself a bit confused on what you're talking about now --
exactly against what do you propose that I defend myself? Since Ray
Blaak expressed past interest in OCaml I had the cheek to encourage
him to really go and have a deeper look into OCaml when he finds
time. 

That was it. I certainly miss, how all that here comes in:

> project size,
> project duration,
> forced language,
> availability of programmers (need to hire?),
> job changes,
> programmer skills,
> multiple projects at the same time,
> language switching e.g. between projects every other week,
> time needed for education,
> documentation needs,
> future modification done by others,
> future modification to be done by the author,
> ...

But let me give a real short answer to your request as it stands:

> How will a piece of source code, your own or someone else's, and
> a language with tools fit these and the market as we might think
> it is now?

It will depend on the ability of mine or someone else to code in this
unnamed language with arbitrary tools. Note that I doubt that "we
think" the same about the market and what counts -- finally -- is how
the market is, not how we think about it, which might be a different
thing altogether.

Does that answer satisfy you? No? I thought so. You have to ask better
questions then.

> A rich set of opportunities for collecting some input, if only

Questions as those rather wide ranging ones you just posed above are
not "opportunities for collecting some input". They just stay
questions. I fail to see the opportunity. Even if R.B. would use the
suggested "stop watch" (and we all know how little the time alone will
tell you), I hope you don't try to draw conclusion on all those topics:


> project size,
> project duration,
> forced language,
> availability of programmers (need to hire?),
> job changes,
> programmer skills,
> multiple projects at the same time,
> language switching e.g. between projects every other week,
> time needed for education,
> documentation needs,
> future modification done by others,
> future modification to be done by the author,
> ...

> in order to convince ourselves that some things might have changed
> in software production (due to language changes?) while others

Well, things have changed, but you're probably missing how.

> haven't changed --for example we might get carried away by a

Care not to use that all-inclusive sick-nurse style "we" here?  If you
get carried away: Your problem. If you insist I did, then say so.

And note that I didn't give a specific factor of improvement of
productivity. Brooks excludes "magical" improvements for large
projects in orders of magnitude, not

  (a) for small projects (in large projects it's not the
      implementation that dominates)

  (b) not for reasonable factors.

In small day-to-day development I don't think a factor of

> subjective estimate of the usability of our preferred language.

> In accord with the findings of Leon Festinger (1957).

Good. That might be. How's than that C is rumoured to be so much less
productive than Ada?

Bah!

George, you're not trying to find out things, but to win. At, I might
say, every price. 

As I already said: Just ignore what I say and we'll be fine. I'm not
conducting paid scientific research here on language usability and
I've no interest in making converts. Just say that what I say cannot
be proven, you refuse to believe anything of it and let it be
done. _I_ do not see any way to help you here, esp. since above you
just sketched a many man year research program as the things you need
to get answered. How to you propose I answer to 

> How will a piece of source code, your own or someone else's, and
> a language with tools fit these and the market as we might think
> it is now? (...)

Say "They fit well?". Would I be done then? Or would you call me
deluded (not with that word of course) and we'd argue over what I say
until I bring sworn affidavits? You know, I'm already convinced
(though I doubt you exactly grasped of what), so I don't need to
conduct any experiments or research in the directions _you_
require. You're not convinced and IMO unconvincable, but as I said:
YMMV and I'll let you you're point of view and practice of
programming. Since I don't work for or with you I don't have to find a
common style with you. And for the rest: Well -- I just don't have the
time. As I already said: I'm not even sure I know what you want.

I reserve the right, though, to give some, perhaps not well recieved
or well like answers to questions like "Why is Ada not more popular"
or oppose some views on GC or type inference. Oppose, mind you. That
means some statement of dissenting opinion and experience (which
anybody can ignore at their will), but that doesn't mean I've to slug
it out. That is what scientific studies are for and they usually take
a bit more time than 30 minutes on usenet. I know a number of people
who'd happily accept some research grants on these topics, so if you
just happen to have some spare money and the need to answer

> project size,
> project duration,
> forced language,
> availability of programmers (need to hire?),
> job changes,
> programmer skills,
> multiple projects at the same time,
> language switching e.g. between projects every other week,
> time needed for education,
> documentation needs,
> future modification done by others,
> future modification to be done by the author,
> ...

is just so urgent and important to you, you might consider sponsoring them.

Regards -- Markus