Re: Parameter Modes, In In Out and Out

[Robert Dewar <robert_dewar@my-deja.com>]

In article <93k6dv$qt6$1@nnrp1.deja.com>,
  dmitry6243@my-deja.com wrote:
> In article <93il87$iqo$1@nnrp1.deja.com>,
>   Robert Dewar <robert_dewar@my-deja.com> wrote:
> > In article <93h9mo$bbm$1@nnrp1.deja.com>,
> > > It is not very long time ago when a program of
> > > 1Mb size was something unimaginable.
> >
> > Well, quite a long time ago, certainly you have to go back
> > over 30 years, which in the world of computers is a VERY
> > long time.
>
> I would say 15 years. That time PDP-11 with 256K was a quite
> common model. The process address space was 64K. A "very
> large" program was FORTRAN-IV compiler (30-40K).

That was a "mini-computer", so called because it was tiny
compared to main-frames. You cannot judge typical large
application program size by looking at mini-computers of
the time. The 64K memory seemed absurdly small by mainframe
standards (it was already common to see multiple megabytes of
physical memory on mainframes at that time). So looking at
program size on PDP-11's as a guide for typical program size
is like looking at the Palm Pilot today to get an idea of
typical program size today (on the Palm Pilot, applications
larger than 100K are unusual, and indeed my brother's datebk4
program, at about 450K is the largest application program in
common use on that platform :-)

> > > Now it is hard to produce one
> > > of less size (in conventional environment).
> >
> > That's a very peculiar statement, very few of the programs
> > I write are anywhere near a megabyte long.
>
> A couple of windows here, pair ActiveX controls there, plus
> misuse of STL and here you are.

Misuse will get you anywhere :-)

> The point was that among all arguments pro and cotra
> including some feature into a universal and long living
> system, a reference to balance between complexity and
> functionality is the weakest one. Please note the words
> "universal" and "long living".

Sounds like you have not had much experience in the real world
of language design, where this balance is THE primary issue in
design considerations.

> IMO the first role should play such factors regularity,
> correctness and volume.

Sorry, that sentence is too garbled, I have no idea what
"volume" refers to in the context of language design.
Regularity (often referred to as orthogonality) is indeed
a critical feature, and actually this is where it is very
difficult to get a clear definition of MD (or MI for that
matter :-)

Correctness is an odd concept in the language design
environnment, unless you mean that something is correct if
dmitry declares it correct (an approach you seem to have taken
in the past). If you mean consistency in a formal sense, yes,
then of course this is a necessary (but not sufficient)
condition.

Language design is much harder than people think. Well meaning
technical folks with a little bit of experience in language
semantics, but no experience in full language design, often
vastly underestimate the difficulties involved. Dmitry, if you
want to follow and understand some of the language design
issues involved in Ada 95, I would go read the archives, and in
particular, read the sequence of mapping documents.

> Anyway, let's see what will happen with MD in the static
> typed languages in the next 5-10 years.

My guess: nothing much. I just don't see any constituency that
would push in favor of moving in this direction for statically
typed languages. The arguments are quite weak (note that Dmitry
has not been able to present any specific arguments, beyond the
claim that binary operators require MD, but with no good
examples).

In practice in Ada, you can always achieve the effects of MD
in specific instances, and the generalization is just not worth
the effort, given how rarely it would be of use.


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