Re: Help from fellow Fortran Users

From: Bob Lidral (l1dralspamba1t_at_comcast.net)
Date: 02/01/04 

Date: Sun, 01 Feb 2004 08:03:09 GMT

James Giles wrote:

> Bob Lidral wrote:
> ...
> > Operating systems are also good examples of such tasks. It is perhaps
> > interesting that Unix and Linux each run on more different platforms
> > than any operating system written in Fortran of which I'm aware. (Not
> > sure whether that's a tribute to the portability of C or to the loyalty
> > of the UNIX and Linux communities or to the intensity of general desire
> > to escape from Windows. :-)) Feel free to provide counterexamples :-).
>
> Well, Windows is written in C++ (a decision that no less than Bill
> Gates himself has characterized as the single worst technical decision
> the company ever made). The problem is that I don't see much
> difference in fklavor between UNIX and Windows. Both are
> bloated, arcane, insecure, unreliable, slow, and hard to learn.

First time I can recall anyone characterizing Unix as "bloated". In
what sense: size of source code, size of compiled code, drain on
resources, excess of features and utilities? There are also quite a few
differences between Unix and Windows. One significant difference is
that Unix had multi-processing decades before Windows. Having learned
to use several operating systems (Multics; NOS, NOS/BE, and their
predecessors; IBM OS/360; several flavors of Unix and Linux; Windows;
and a couple of flavors of VMS) and to maintain several of those, I
found Unix one of the easiest to learn -- and it was not my first, so
I'm not suffering from that prejudicial influence. I guess I'm
curious how well you know Unix and what your preferred system is.

> If windows out-bloats or out-arcanes UNIX it also outnumbers
> it. Neither is as good as alternatives that used to exist before
> those two took over the world. People working on genuinely
> secure systems have already made it clear that it can't be done
> campatibly with either UNIX or Windows - those systems carry
> their security flaws with their specifications, not just from
> weaknesses in their implementations.

Not sure what this has to do with the original issue of the relative
portability of programs written in Fortran vs. those written in C.
Also, although Windows may outnumber Unix, Linux, and BSD in units sold,
it certainly doesn't outnumber any one of them in number of
architectures on which it has been successfully implemented -- a number
more relevant to the issue of portability. Though in the case of
Windows, certainly one of the reasons it hasn't been ported anywhere is
that Microsoft doesn't want to do it and no one else has a license to
the source code.

> As I've pointed out, I believe much of the lack of reliability of
> systems is directly tracable to C: a large percentage of bug in
> modern systems still turns out to be buffer overruns. C also
> tend to require more lines of code to do similar tasks than other
> languages - hence one of the causes of bloat. C is not a very
> good choice as a system development language. Many Pascal
> extensions used experimentally in the 70's would have been
> better choices.

Again, not exactly a portability issue and Pascal is not a good example
of a language useful for writing portable programs. I'm a little
curious how buffer overruns are either unavoidable in C or unique to it.
It might be possible to avoid buffer overruns in Pascal using subrange
types for array indices, but it's not clear how many compilers would
implement the corresponding checks and, of those, how efficiently those
checks could and would be implemented.

Pascal always was a pretty useless language for writing large programs.
Essentially little more than a toy, it was designed to provide as few
features as possible in order to use as a first language for teaching
only those techniques and methods regarded as blessed somehow by the
Disciples of St. Nik (and, apparently more important, to prevent
students from ever encountering techniques which St. Nik might not
approve).

Its proponents claimed one of its most essential strengths was its
strong typing, yet the definition of this "feature" precluded separate
compilations unless it was defeated or bypassed. Strong typing could
also be bypassed fairly easily using variant records (unions) making the
code even more difficult to read. There was no way to write library
routines in Pascal (without extending the language). The language
definition was incredibly sloppy, replete with incomplete specifications
especially wrt limits and sizes. Every incomplete part of the
specification left the implementation details up to the whim and
convenience of the implementor so that it was impossible, for example,
to write any program using sets on a universe of more than 4 or 5 items
with any hope that it might be portable. In fact, one of several major
disappointments (to me) was that, although it was possible
to declare something to be a set of character, it was impossible to have
such a set contain the character ";" (semi-colon) in one of the earliest
implementations (CDC CYBER) thus precluding the use of such sets to
implement a parser. Maybe I'm naive, but that seemed to me an obvious
place to use sets (except, of course, for the nearly useless definition
of the "case" statement that would have made any such use extremely
awkward and inherently error-prone).

Any Pascal subroutine or function that accepted an array as an argument
could only accept one size of array so that, for example, if you had a
subroutine that sorted a 100-element array, you'd have to write a
separate subroutine to sort a 101-element array (at least until Version
3 -- sometime in the early 1980s?). The "case" statement had no "else"
(again, it took more than a decade for proponents even to realize [or
maybe just to admit] that was a deficiency); the "if" statement had no
"endif" (so that it suffered from the same dangling-else problem as C
and several other languages of that time except, curiously, Algol 68
with which Wirth should have been familiar). There were no varying-
length character strings or anything else that might be useful for
writing error-processing routines.

When I was a TA and later on various jobs, I had to read lots and lots
of really bad source code (students never came in for help with
programs that already worked and employers never asked us to debug code
that worked :-)). I was always amazed that the languages designed for
readability and maintainability could be used to write the ugliest and
most unreadable code. The two worst examples I encountered were COBOL
(I don't usually admit to any experience in this area -- especially on
resumes :-)) and Pascal. COBOL, with its use of English words rather
than symbols to "improve" readability frequently obscures algorithms
with excess verbosity. Pascal with its desperate need to restrict
programmer flexibility instead leads programmers -- especially beginners
-- to write horribly unreadable code attempting to twist their thinking
in some non-intuitive way because Pascal lacked any reasonable
mechanisms for the intuitive approach or, in some cases, for any
approach.

C certainly has its own problems but, unlike Pascal, at least it's a
real language useful for something. Pascal never had any hope of
evolving into anything useful and it was difficult to port even simple
student programs between different implementation.

> Comparing C to Fortran for system development (or compilers)
> is a little unfair since Fortran was not designed for such things
> and even long-time proponents don't claim that it's adequate
> for such activities without extensions. Still, system-level
> code would probebly be smaller, clearer, and less buggy in
> a properly extended Fortran.

Evidently, you missed my smiley; perhaps I should have used more of
them. And I'll even agree that any standard-conforming implementation
of Fortran 77 or later would probably be a better choice than any
implementation of any version of Pascal for system-level code. But
that's even more unfair: Pascal was designed only to be a first language
for teaching programming to beginning students and restricting their
choices to "good" programming practices. That Pascal was tortured and
perverted in attempts to implement solutions to real problems, with
varying degrees of success, is more a testament to the stubborn
blindness of its proponents in the face of numerous counter-examples
than to any inherent suitability.

I suggest your last statement is a little unfair. With sufficient time
and effort, it's likely many languages could be extended to provide
concise and efficient mechanisms for any problem domain (though I
wouldn't want to try that with RPG, APL, LISP, or even SNOBOL for
system-level code :-)). Assuming such unspecified extensions were
properly designed and implemented, the resulting language could almost
certainly be used to write shorter, clearer, and less buggy code. It
might even be possible to extend Pascal with enough time and effort.
So, yes, if there were a language perfectly designed for implementing
system-level code, then that language would be better than any less-
perfect language (including C); I believe that's called a "tautology".
And if I had a place to stand and a lever long enough ... :-) If your
point is that Fortran could be so extended but C could not, then I
disagree in the absence of any supporting examples. If I wanted to
start a flame-war, I might even suggest C++ _is_ that extended version
of C (that _was_ intended as a joke).

Note also that perceived code clarity depends a lot on the reader's
familiarity with the source language, with the programming idioms used,
and, for the same source code and reader, can change over time --
either for the better and for the worse.

Bob Lidral
l i d r a l at a l u m dot m i t dot e d u

Relevant Pages

  • Re: The Problems With Linux
    ... > Here are the problems with Linux: ... programmers of UNIX, Open Source software, and Shareware. ... programs only available from BSD. ... BSD code is used by Microsoft in it's Windows NT/9x/2K/XP code. ...
    (comp.os.linux)
  • Re: What is a MVP?
    ... I made no claim about my person other than I worked as support for Unix ... Windows is like a platform. ... Do I consider you to be yet another Linux troll?.. ...
    (microsoft.public.windowsxp.general)
  • RE: [Full-Disclosure] CyberInsecurity: The cost of Monopoly
    ... I've used UNIX, ... I've used/use Linux, ... > inefficient operating system - if most other Windows ... This is why I don't run POS operating systems. ...
    (Full-Disclosure)
  • Re: Linux no threat to Microsoft
    ... originally developed for Unix. ... Windows has't come on any of the machines I've ever purchased. ... Yet over those years Linux Market Share on the desktop has actually ... philosophy of Apple - later adopted by Microsoft. ...
    (comp.os.linux.setup)
  • Re: Where to start?
    ... > - NO knowledge of Linux or Unix ... Get the latest set of Slackware CD's. ... But don't hog tie yourself with the Windows way of doing things. ...
    (comp.os.linux.misc)