Re: And the question was? (Re: Amazing, two new articles on Computerworld.com actual mention OpenVMS!)

On Thu, 28 Jun 2007 13:08:55 -0700, Bill Gunshannon <bill@xxxxxxxxxxx> wrote:

In article <f6114h$5qa$1@xxxxxxxxxxxxxxxxxxx>,
John Reagan <john.reagan@xxxxxx> writes:
Bill Gunshannon wrote:

proprietary extension. The original point was that the PLI/I language
took alignment into consideration and included alignment instructions
as a part of the language which means it is reasonable to expect a
program using it to be somewhat portable. C and Pascal do not share
this feature. Any concern for alignment is little more than an after-
thought.


Well, so does COBOL (see the SYNCRONIZED clause).

No one said it didn't. The languages referenced were Pascal and C.
COBOL does a lot of stuff that other languages don't, kind of liker
PL/I. :-)


As a member of a standards committee, it is hard for a language to
predict behavior & performance of future hardware. COBOL and PL/I
provide some sort of "using my crystal ball, I think I need some
alignment help right here". What if my crystal ball is broken and I
actually needed alignment help somewhere else?

Yeah, but it seems to work, at least most of the time.


Allowing/requiring the human to "help" the compiler produce code on some
current hardware (much less future hardware) seems silly to me.

I guess I'm just old school. I hate languages that hogtie me and then
expect me to get some work done. I still think tyhe programmer should
actually know what the comouter is doing and should have a say in how
best to do it.

Kinda
like the "register" declaration in C. Not really part of any language
design, but just a crutch for a brain-dead compiler.

Sorry, I don't agree but then, I don;t know how any of the compilers
you get to work on do it. My experience has always been that the
compiler is free to use registers for normal variables if it wants,
but need not. The "register" directive was provided to allow the
programmer the ability to take some variable that he thinks will
benefit from being kept in a register and force it to be there.
Of course, over use on a machine with insufficient resources is just
another sign of an incompetent programmer.

The concept of register has no place in a high-level language and is part of
the low-level implementation of the compiler itself, that is not visible to the
user. In C it was added as a hack optimization early on. I have also added it
PL/I for systems programming, but not in the VMS version, but for reasons very
different than what K&R did, giving direct control otherwise only done in assembly
language. Indeed with a few extensions of this sort, including absolute addressing
there is never any need for assembly language. This is essentially what IBM did


Computer languages allow you to represent some algorithm to the
underlying hardware. How does alignment help you do that?

I don't understand the question. Not everything a computer does
is mathematical algorithms. One needs to store information in
memory. Some machines have a serious efficiency penalty when this
results in unaligned access. Some way to fix this is needed. Even
Macro-11 had one.


The mindset of the Pascal committee (the only one I can speak for
personally) is that alignment (or any physical implementation detail)
doesn't add to the ability to describe more algorithmic detail. We left
things vague for things like interpreters, p-code, ASCII or EBCID, etc.
to all live within the standard.

No problem with that. It was a conscious decision made by the standards
committee after due consideration and that is fine. COBOL originally did
the same thing over things like Range Checking. But, programmers should
know this and take it into consideration when writing code. Some people
might think this makes PL/I a superior language. :-) Others are just
as happy with Pascal and C. And, yes, I still like COBOL. But I know
not to trust the compiler to keep all my arrays within bounds.

bill




--
PL/I for OpenVMS
www.kednos.com
.

Relevant Pages

  • Re: PL/I, COBOL, Advantages, Equivalence, et al
    ... programmer. ... In over forty years of programming, reserved words (with exception ... PL/I's decision to design a language without reserved words seems ... PL/I is conspicuously absent ...
    (comp.lang.pl1)
  • Re: PL/I, COBOL, Advantages, Equivalence, et al
    ... PL/I's decision to design a language without reserved words seems ... a disadvantage as the programmer who needs to know a lot of reserved ... but PL/I includes a variety of different ...
    (comp.lang.pl1)
  • Re: Python or PHP?
    ... > every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... parse out into proper perl expressions. ... > lists, dictionaries, etc. etc. ...
    (comp.lang.python)
  • Re: Python or PHP?
    ... >> every language here and there more ways to do something. ... The best the programmer can do, as you imply, is to ... I am curious of a list of extraneous methods in Perl (more about the ... I just had a glance on Python, ...
    (comp.lang.python)
  • Re: The War On HLA
    ... Take a look at the HLA compile-time language. ... Macros can be abused just like any other language feature. ... I find it amusing, however, that HLL programmers (e.g., Delphi, ... > feature is left to the programmer to invent his own uses for. ...
    (alt.lang.asm)