🚀 go-pugleaf

In article <1990Sep6.194543.7685@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG
(Kent Paul Dolan) writes:
|> But what has made FORTRAN so valuable to the (hard) engineering
|> profession is exactly that the "dusty decks" still run.  I doubt
|> that the originators of FORTRAN envisioned _at_that_time_ a set
|> of applications software that would outlast the century being
|> written with the first compilers, but so it has proved.  With the
|> perspective of history to assist us, we know that stability makes
|> for a useful language, and should try to make all the important
|> decisions for long term utility of the objects written today as
|> early as feasible, not put them off in the interests of granting
|> "flexibility" to the compiler writer.  Unlike the middle '50's,
|> today we have a plethora of highly experienced compiler writers
|> to guide our projects; we can depend that a lot of the "best"
|> ways, or ways good enough to compete well with the eventual best
|> are already in hand.  This doesn't deny the possibility of
|> progress, or even breakthroughs, nor suggest that either be
|> prevented.  Instead, let's install the mechanisms now that will
|> let today's objects be the "dusty decks" of the 2010's, while
|> leaving options to bypass those mechanisms where some other
|> goal (speed, size, orthogonality) is more important to a piece
|> of code than stability.

IMHO, another reason for Fortran's long dominion is that it is (now) a
user language, not a CS language.  It's used by people who know no other
language, and who have no interest in programming beyond its use as a
tool for their specialty.  (How many C programmers know only C?)  It
can be easy to forget that users who know only one language often strongly
resist switching to a second one, but learning your seventh language is
easy.  Computing professionals tend to learn many languages, and thus
these languages go out of fashion more quickly.  C++ may influence future
languages, but I very much doubt if it will be directly compatible with
them.  I think the proper role for C++ will be more like that of Algol.

To get dusty decks, you need a user base outside the CS community that
creates hard-to-translate information.  Scientific computing is the only
present non-CS user base that does much of its own programming (unless
you count BASIC or Cobol :-), so I doubt that another language will rise to
monolithic dominion in another field in the forseeable future.  It doesn't
have to be just programs, though.  You want to know what the "dusty decks"
of the 2010's will be?  They'll be data and possibly macro packages written
for PC applications like 1-2-3.  Other possibilities include formatting
languages like TeX, and hard-to-translate graphics languages like Postscript,
but these can't be considered reusable code.

|> a ball.  Just give me a switch, like the optimization switches now
|> common, to turn it all off and preserve my own explicit control
|> over structure layout if that is a real need for my application

The extreme case would give you functionality something like the Fortran
EQUIVALENCE statement.  Create an array of chars, then make the first
member start at char 3, the second member start at char 1, the third
member start at char 4 (overlaps first member), and so on.  I am a bit
reluctant to make class layout rigidly defined unless the user has direct
control over it.  What if we agree to justify on single-word boundaries,
then some future architecture makes it efficient to pack classes with no
leftover space at all?  We'd be stuck with a wasteful construct and no
way to work around it in the language.  I think there should be either
no control, or more control than a single switch.  I have no good idea
as to what syntax would be best for this, however.

|> Again, this is just the standard for what I mean when _I_ take
|> control of laying out a structure.  If I give that control to the
|> compiler writer, I'd better make no assumptions at all in my code
|> about the result, because it is explicitly allowed to be "unstandard",
|> and I have chosen to write at a high level and delegate those details
|> to the compiler writer's ingenuity.

Good.  Two levels of functionality, for two kinds of code.

|> Peace?

Agreed.  Unfortunately, the standards committee doesn't give a damn whether
we agree or not, or what we agree on, and even within the newsgroup we are
now most likely in everyone else's kill files.

--
Louis Howell

  "A few sums!" retorted Martens, with a trace of his old spirit.  "A major
navigational change, like the one needed to break us away from the comet
and put us on an orbit to Earth, involves about a hundred thousand separate
calculations.  Even the computer needs several minutes for the job."