Re: Fortran bashing in the MATLAB newsgroup

On Jun 30, 4:25 am, Arjen Markus <arjen.mar...@xxxxxxxxxx> wrote:
On 30 jun, 09:58, Damian <dam...@xxxxxxxxxx> wrote:



On Jun 29, 5:12 pm, James Tursa <aclassyguywithakno...@xxxxxxxxxxx>
wrote:

FYI, here are some comments from the MATLAB newsgroup about Fortran:

(begin quote)

I see Fortran as a language that's continually changing to
try to keep up with more modern languages.

There is one sole reason for teaching (and learning) Fortran
these days: To be able to read and understand old code, in
order to port the algoprithms to some other language.
The fortran language as such is obsolete.

The die-hards
always claim that Fortran is fast because its simplicity
makes it easier for compilers to optimise (undoutedly true
for Fortran 66 constructs).

Not quite true. The reason Fortran is fast is that it
lacks dynamic memory management (that was added in
fortran 90 or 95, a mere 15 years ago). Everything is
easy once the memory maps are fixed at compile time.

And then in the next breath
they point out all the new features added to the latest
(77, 90, 95, ...) version that have added all the
flexibility of newer languages and are clearly are no
easier to optimise than any other language.

Sure. Selective memory must be most convenient.
I wish I had that, too...

As for optimizations, I've played a bit with
template metaprogramming in C++ for some time now,
and it seems to be one serious beast. Templates
allow the programmer to code readable code, at the
same time it allows the compiler to do some
serious optimization.

The newer
incantations of Fortran just allow old code to persist (and
fester, undocumented and unmaintainable).

Most certainly agreed!

(end quote)

I've got my own ideas about what modern Fortran is good for and why I
still use it. I also have my own ideas about why it is fast for
certain tasks.

Before I give my own 2 cent reply to the other neswgroup, I was
wondering if the experts out there had any comments they wish to
contribute about what modern Fortran is good for, why they still use
it for new projects vs C or C++ or Java, etc., or any other related
comments. Thanks.

James Tursa

My advice is not to go down this path unless you have a very thick
skin. There are few people you will be able to convince you are
anything but a neanderthal if you program in Fortran. The level of
anti-Fortran bias runs so high that it has taken on a life of its own,
reinforcing itself with outdated truths, half truths and
misinterpretations.

Even if you try to describe the best features of modern Fortran, the
most likely responses are

"That sounds like feature x in language y, which was implemented z
years ago. What took Fortran so long?"

"That sounds like feature x in language y, which has been proven to be
unmaintainable. No good programmer would use it."

Now you've got the problem that you need intimate knowledge of
"feature x in language y" as well as the subtle differences between
that feature and its closest cousin in Fortran. Often to have the
requisite level of insight, you would almost need to be a compiler
writer or member of the Fortran standard committee.

This all gets greatly exacerbated when
1. Two languages use different names for the same concept or
2. Two languages use the same name for different concepts.
I find that Fortran is the most unique, often using words in ways no
other language I know does and adopting notation that differs from
most other languages (like "%" for component selection where most
languages use ".").

As an example of item 1, if you're talking to C/C++ programmers,
you'll spend a lot of time trying to explain why a Fortran "pointer"
is much safer and less of an impediment to optimization than a C/C++
pointer. As an example of item 2, the meaning of the keyword "class"
differs in Fortran from what that term means in java, C++ and every
other language with which I'm familiar. (I would love to hear from
someone on the standards committee why they did this. I'm writing a
book with Fortran 2003 and C++ examples and that choice, along with a
few others, makes my life very difficult. I have to try to find
language-neutral terminology such as "abstract data type" instead of
using the word "class" because it has two completely different
meanings in the two languages.) Or you'll spend time trying to
explain to Java programmers why Fortran's automatic de-allocation of
allocatable arrays differs from garbage collection because the time
when the de-allocation occurs is well defined.

As another example, the Fortran 2003 "select type" construct often
looks to C++ programmers like you're switching on the type and
therefore, depending on where you put it, embedding type-specific
logic outside the module where the type is defined. This is
considered very poor form in C++. There are sound reasons why the
corresponding features in the two languages are not equivalent and why
the Fortran approach is safer, e.g., you're guaranteed that only one
branch of the "select type" construct will execute, so there is no
chance of falling through from one branch to another as there would be
in C++. Imagine how familiar you have to be with both languages
before you discover that.

I cherish the rare non-Fortran programmer who is open-minded enough to
accept the possibility that Fortran has evolved in very smart and
modern ways. I am especially excited when I find a non-Fortran
programmer willing to delve into the subtleties described above. I
have one such co-author now. However, the overwhelming majority of
non-Fortran programmers (which means 99% of all programmers) simply
repeat the same old Fortran-bashing mantras and engage in the very
type of "me too" dialog you quoted. Don't waste your time with them.

Damian- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Let me start with saying that you have an interesting project
there :).

I am not sure I fully understand why you have difficulties with the
use of the term "class" in Fortran 2003. What I understand from
literature on the subject of object-oriented languages is that
all of them have their own peculiar ways to look at object-orientation
and the semantics of concepts as class, object, method and so on.

So, superficially, I'd say: Fortran 2003 merely adds yet another
variety. I am not trying to "trivialise" the problem, but I found
something very similar in a book on OCL - object constraint language -
(*) where concepts of OCL and UML just do not quite fit, even though
OCL seems to have been developed as an add-on to the UML language.

Regards,

Arjen

(*) Your own article on finalisers in Fortran led me to go
and read about OCL.

As far as I can tell, the word "class" has very nearly the same
meaning in every language other than Fortran. It is usually
synonymous with "abstract data type" (ADT). Using Fortran
terminology, an ADT is a derived type containing (private) components
and a collection of (public) type-bound procedures for operating on
those components.

In Fortran 2003, "class" is a keyword used in type declarations for
polymorphic variables such as

class(some_type) :: some_variable

(I don't have my copy of MRC with me so I hope I'm getting this
right.) The actual type of such polymorphic variables is resolved
dynamically at runtime and referred to as its dynamic type. The
dynamic type can correspond to some_type or any type that extends
some_type, so to my way of thinking, a Fortran 2003 class represents
an inheritance hierarchy. Possibly that's not the best
interpretation, but either way, it bears little relation to how the
rest of the world defines "class" (which I believe is pretty
consistent from language to language). I think it would have been
better to choose another word -- maybe "category" or "tree" as in
family tree?

Interesting points about conflicts between OCL and UML. I'd love to
hear more. On a similar note, I've sometimes had difficulty
expressing Fortran concepts in UML. For example, UML has no concept
of multi-dimensional arrays.

Damian
.

Relevant Pages

  • Re: Interested about number crunching in Ada
    ... The idea that any language such as Ada is better than ... FORTRAN will not go over very well. ... simply boring for most programmers. ...
    (comp.lang.ada)
  • Re: one-liner for characater replacement
    ... Same error possible with pre-1970's Fortran. ... So does any language. ... (the programmers themselves) ... I never heard anyone praise either for quality in those days. ...
    (comp.lang.fortran)
  • Re: PL/I, COBOL, Advantages, Equivalence, et al
    ... I don't think that currently available versions of Fortran have the OO stuff implemented yet. ... Do the programmers have any OOP experience for when the 2003 features become available? ... Also, I've met quite a few Fortran programmers, but I know very few who really knew the language very well, and 77, for example, is not a very complicated language. ... COBOL shops are trying to go OOP with languages such as C++ and Java ...
    (comp.lang.pl1)
  • Re: question about efficiency of fortran in parallel environments
    ... > Other people (the PETSc programmers) have said it doesn't make any difference ... > whether I use C or Fortran. ... any particular language is the secret to efficiency. ... programmers can write highly efficient code in C. ...
    (comp.lang.fortran)
  • =?windows-1252?Q?Re=3A_13_reasons_for_UML=92s_descent_into_darkness?=
    ... This happened because UML was ... Lots of programmers instinctively ... code generation you have to be able to represent specific language ... diagrams: you need to read the code to understand what the diagrams ...
    (comp.databases.pick)