| This question keeps coming up in this conference (see notes 107,
115 and 192 just for a start...). But I'll answer it again:
1. Some languages are better at some tasks than others.
The "FORGOL"-ish languages in general are about even,
and other considerations (how well do the programmers
know the language, what processors do we have compilers
for, and so on) should drive the language decision.
2. All the VAX compilers produce code of about the same
performance level, with some task-specific adjustments.
VAX FORTRAN has extra smarts for number-crunching on
arrays of floating point numbers, and VAX Pascal is better
at in-lining lots of little routine together, for example.
Which compiler is "best" both depends on the task and on
when you ask, as the compilers are being improved all the
time.
Your customer should be asking "What do I mean by 'best'," and
letting the answer drive the language choice. I'd expect answers
like "All my programmers know Pascal," or "The code has to be in
C to be portable," or "I'm selling to the DOD and want to use ADA."
-John Bishop
|
| I'm gonna scrunch this stereo-type everywhere I see it (at least
for a few weeks).
I'd expect "I want my code to be portable and reliable and to be
around for 10 years, therefore I'll use Ada" NOT "I'm selling to
the DoD". If you're selling to the DoD THEY want the code to meet
the first set of requirements, so they'll tell you to use Ada -
you won't get to decide.
/Bevin
|
| Re .1:
> 1. Some languages are better at some tasks than others.
> The "FORGOL"-ish languages in general are about even,
> and other considerations (how well do the programmers
> know the language, what processors do we have compilers
> for, and so on) should drive the language decision.
Generally speaking, this is generally true. In addition, schedule/cost
versus programmer expertise is a tradeoff which is typically not
given much weight, although it is extremely important (even if APL
is the best language to do the job, if I don't have anyone who knows
APL, I'm not going to get the job done).
However, there are VERY REAL and SIGNIFICANT technical differences
between various languages, when you consider them from a software
engineering (and maintenance) perspective. For example, (unless
things have vastly improved since the ANSI 1980(?) standard) COBOL
programs often exhibit very high degrees of coupling, FORTRAN and
C (Pascal as well) do little to help you isolate data structures
from external interference (although it *can* be done), COBOL and
FORTRAN are very weak in dealing with "heap-like" data structures
(how about implementing lists, or a binary tree, without pointers?,
and traversing a tree without recursion).
To a certain extent (perhaps a large extent), the language used
for a project should be chosen based upon the project itself. If
I'm doing accounting applications, COBOL has a lot to help me do
them. If I'm creating a compiler, COBOL and FORTRAN would be a poor
choices unless they are my only options (and then I've got a lot
of risk to deal with).
After you have ensured that you are not using the wrong tool (language)
for the job (eg, you're not implementing a realtime system in COBOL),
then the other factors come into play (which of the required processors
are supported, how compatible are the compilers, can my people learn
the language and keep on schedule/under budget).
Finally, although I'm not a big fan of COBOL (it isn't the best
tool for the kind of software I build), DIGITAL does sell the VAX
COBOL Generator to allow folks to generate code "directly" from
design. Similar Computer-Aided Software Engineering (CASE) tools
are available from third-parties which produce "code" (or at least
stubs) in other languages as well. While these tools do not eliminate
the programmer, some of them can significantly reduce the time spent
coding (the programmer "optimizes" the code generated to "fine tune"
the user interface and otherwise improve it). The availability
of such tools is an additional factor which will increasingly influence
the choice of implementation language.
(Properly speaking, you could consider such "code generators" and
fourth-generation tools as a set of distinct implementation languages
which do not fall into the "FORGOL"-ish category.)
Lloyd
|
| Re: < Note 213.1 by MINAR::BISHOP >
> The "FORGOL"-ish languages in general are about even,
> and other considerations (how well do the programmers
> know the language, what processors do we have compilers
> for, and so on) should drive the language decision.
This isn't really true, if by "FORGOL"-ish languages, you mean those
languages that have their roots in FORTRAN and Algol-60. While many of
the offspring of this mixed marriage have indeed been no great
improvement on their parents (Pascal, Coral-66, C, etc.), two (maybe
three) of the descendants from these languages are worthy of special
mention. These are Algol-68 and Ada (and perhaps Modula-2).
Algol-68 was the first (and as far as I'm aware, to date the only)
general-purpose language to be "specified" as opposed to merely being
described (which due to the formal way in which this was done, was
probably responsible for the lack of acceptance that Algol-68 has
encountered), it introduced a cohesive type-structure that
distinguished between values, names, and references to values,
introduced UNIONs and flexible arrays as true types, and also
introduced automatic storage-reclamation for all types.
Ada built upon work started by Modula-2 to produce an excellent
seperate compilation mechanism, based around the concept of
information-hiding. It probably cannot be surpassed today for the
production of large (multiple-programmer) systems. It also introduced
the concept of "generics", which are roughly equivalent (in the
"equivalence-by-name" type-model) to first-class procedure objects (in
the "equivalence-by-structure" type-model). It also incorporated a
consistent multi-programming model (although there are a number of
problems with the Ada tasking model, Ada remains the only commonly
available language that has any form of high-level, transportable
multi-programming capability).
These two languages represent the (current) forefronts of the
"equivalence-by-structure" and "equivalence-by-name" type models.
Both are far removed from their common ancestry of FORTRAN and
Algol-60. To lump either in with the other "FORGOL"-ish languages
is to do them a grave injustice.
|