Re: Parameter Modes, In In Out and Out

[dmitry6243@my-deja.com]

In article <93n2co$alq$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <93modu$36k$1@nnrp1.deja.com>,
>   dmitry6243@my-deja.com wrote:

> In the days of the PDP-11, the remarkable thing was that people
> could write small programs that had impressive functionality.

Yes, EDT (and later LSE) is the best text editor of all times.

> For example, Unix was a very small fraction of the size of
> mainframe OS's.

That time Unix was considered as a large, ugly, slow and unstable OS
compared to RSX-11M.

> In any case, if you want to talk about typical sizes of large
> programs, you look at mainframes THEN, and NOW you can look
> at ordinary PC's, since PC's have plenty of memory these days.

Let's be scientific (:-)) and build a histogram: number of computers
over the model price. The mediane of such histogram in 1985 will
correspond to the computers comparable with PDP-11. Today it is a PC.
Now take a "simple" program: a text processor. In 1985 for PDP-11 it
was EDT + ROFF (only a fanatic would use a Unix on PDP-11 (:-)). Size
~50K. Now turn to PC and, well, what about MS-Word? (:-))

> > This is not a scientific issue. It is about
> > feeling and belief.
>
> If science to you is strictly restricted to things that can
> be objectively measured (not all scientists would accept this
> limitation (*)) then that's absolutely right. But it is
> probably more accurate to replace "feeling and belief" with
> expert judgment (going back to my earlier analogy, the
> excellence of certain paintings is a little more than just
> some individuals feeling and belief, it is the result of a
> consensus of expert judgment).

Yes, a consensus of expert's feelings (:-)). [ Actually this is a
good criterion to decide whether something is a science. Scientific
issues are not subject of voting. ]

> If I find that my opinion is not shared
> by anyone else then I conclude that either
>
>  a) I am arguing my case incompetently
>  b) I am wrong
>
> I never end up being the 1 in an N-1 vote on language design
> issues, since neither a) nor b) justifies such a position.

Robert, you are too merciless to yourself. Even in such pure sciences
as mathematcs there is no consensus. Especially if it is about
fundamental issues like set theory. I think you would argree that
the issues of acceptance of MD and MI are fundamental for programing.

> > But it is not enough for me to change my feeling
> > that MD will be universally adopted in the near future
>
> But an individual "feeling" is not very convincing if it is
> not backed up by good arguments, especially when you are in
> a small technical minority.

Absolutely.

> So far, you really have not presented any arguments.

First, we have not yet decided what is argued. Is is about MD in
general? Is it about Ada extension, or an intrusive Ada redesign?

Second, MD is extremely obscure. Alone the question whether this
obscurity an inherent property of MD, or we simply do not understand
something, is a good theme for a plethora of PhD works.

You surely do not think that I am able to produce a complete proposal,
how to incorporate MD in Ada (:-)).

> I do NOT accept the "PL/1 style" argument that says "never mind, if
> you don't want to use this feature, you don't have to, so it can't
> harm you".

I am with you here (I did my MS work in PL/1). Though it was PL/1 that
opened exceptions and overloading to me. Interesting is that from
the height of our current knowledge they were purely implemented.

> To make your case, why not do the following
>
>   a) propose, in rough form, no need to tie up the details
>   an MD addition to Ada
>
>   b) show one example where this MD addition really adds
>   to expressive power.
>
> I think that's a reasonable request, the burden of proof is
> definitely on your side for adding new features. What is
> interesting then is to contrast the best possible solution
> without MD to the example you show.

I agree with you. But this is a good way for relatively small, well
defined and "indestructive" proposals. Like "should we have fixed
numeric types of e-radix?" (:-))

In contrary to this, the MD issue can potentially affect all parts
of the language, which is not the smallest one. It is more like,
someone says 'It would be nice to fly to stars', another answers
'well, give us the blueprints of the starship'. Technically the later
one is correct. But he should be prepared to reconsider the idea
time to time (:-)).

> Also, a casual approach to considering the semantics often
> covers up complex details. For example, in the case of
> multiple inheritance, the mess we get into when we have
> common base classes.

"Mess" is not an argument, if I dare quote you (:-)). Common bases
could be made distinguishable by an explicit inheritance path
specification and enforcing naming of the immediate bases (like names
of subroutine parameters). Converting to a class-wide should be
parametrized by the path. For overriding there are many options to
consider. It seems that all could be statically checked. C++ makes MI
unsatisfactory, but still reasonable.
[ no, this is not a proposal (:-)) ]

--
Regards,
Dmitry Kazakov


Sent via Deja.com
http://www.deja.com/