From owner-sc22wg5@dkuug.dk Sun Dec 22 21:58:48 2002 Received: (from majordom@localhost) by dkuug.dk (8.9.2/8.9.2) id VAA18532 for sc22wg5-domo; Sun, 22 Dec 2002 21:58:48 +0100 (CET) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id VAA18527 for ; Sun, 22 Dec 2002 21:58:46 +0100 (CET) (envelope-from michael.metcalf@t-online.de) Received: from fwd07.sul.t-online.de by mailout08.sul.t-online.com with smtp id 18QDBL-0006es-06; Sun, 22 Dec 2002 21:58:43 +0100 Received: from metcalf (520066357016-0001@[217.225.5.13]) by fwd07.sul.t-online.com with smtp id 18QDBI-0YcVloC; Sun, 22 Dec 2002 21:58:40 +0100 Message-ID: <004f01c2a9fd$197df3a0$e8d0fea9@metcalf> Reply-To: "Michael Metcalf" From: michael.metcalf@t-online.de (Michael Metcalf) To: Subject: Fw: FYI: German's negative vote on F2000 Date: Sun, 22 Dec 2002 22:00:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Sender: 520066357016-0001@t-dialin.net Sender: owner-sc22wg5@dkuug.dk Precedence: bulk > ----- Original Message ----- > From: "Scott Robert Ladd" > Newsgroups: comp.lang.fortran > Sent: 22 December 2002 20:28 > Subject: Re: FYI: German's negative vote on F2000 > > > > > 1. The proposed Fortran language and document are TOO LARGE AND > > > MUCH TOO COMPLEX for anyone to learn or read completely. > > > > There is a nasty trend toward making every programming language into a > > universal tool for everything; an example is C++, which suffers greatly > > from too much complexity and a lack of internal consistency. Looking over > > the proposed Fortran 2000 makes me wonder: have features have been added > > by necessity, or to "keep up" with the neighbors? > > > > > In any case, it will be extremely difficult to educate and train the > > > typical Fortran programmer in this language, or even to convince him/her > > > that there is useful stuff in the new standard (it has been difficult > > > enough with F90 and F95). > > > > I'm writing an set of Fortran 95 modules for astronomical computing. A > > survey of the field finds a large library of Fortran 77 code, but almost > > nothing in the 90 or 95 dialects. This situation is not unique to > > astronomy, either. > > > > > 2. The standardization process has become seriously DISCONNECTED > > > from the Fortran user community. > > > > I haven't followed the politics, so I can't comment on this assertion. > > > > > 3. The other disastrous impression we have been getting over the > > > past few years is that the language is collapsing under its own weight > > > and complexity and has become UNMANAGEABLE even for the experts. > > > > I think this explains why people stick to Fortran 77. Most > > scientist-programmers are not expert programmers; Fortran 77 is relatively > > simple as compared to "more modern" programming languages (including > > Fortran 95). > > > > However, those of us who've dedicated a substantial part of our lives to > > programming (I started in Fortran and assembly 26 years ago, in a Physics > > lab) have the experience and skills to use advanced concepts. I would not > > be programming in Fortran today were it not for Fortran 95. Be that as it > > may, many new features of Fortran 2000 seem dictated by political, not > > technical needs. If I want OOP overhead, I'll use C++, Java, or Python. > > > > > 4. The current revision does not focus on the PRIMARY INTERESTS > > > and the most pressing needs of the Fortran community. Fortran's > > > viability depends crucially on its acceptance and usefulness in the > > > NUMERICAL AND SCIENTIFIC COMPUTING community, and a significant portion > > > of that community is also in the PARALLEL AND HPC BUSINESS. It is our > > > conviction that, had any other language (including C++) delivered more > > > than half the runtime performance of Fortran code consistently on large > > > (vector or parallel) computers, the danger of losing the HPC community > > > would be imminent. Honestly, we really haven't done much for them since > > > Fortran 95 (except for much better IEEE support, but true exception > > > handling is still sorely missing, for example). > > > > Yes! Yes! Yes! > > > > I am against the "jack-of-all-trades" approach to language design that is > > in vogue today. Tools should be refined for specific tasks, with clear > > goals in mind; jealousy of C++ and Java is *not* a valid motivation for > > adding a feature to Fortran 2000. > > > > For many years, I didn't use Fortran; then, a couple of years ago, I began > > reorienting my career toward HPC, Linux clusters, and scientific > > applications. After trying a number of tools, it became clear to me that > > Fortran 95 was particularly suited to the tasks at hand. The point of > > parallel and HPC architectures is *PERFORMANCE* -- if Fortran alienates > > its core audience, people will find another tool. The saving grace for > > Fortran is that no comparable tools yet exists. > > > > But it will if we don't focus on the tasks for which Fortran is imminently > > suited. > > > > From here on, I'll make selected comments: > > > > > a) At least some of the OOP language is not nearly as important > > > for the typical Fortran user as we may have thought > > > > OOP is a way of thinking, not a language construct. Yes, the Eiffel and > > Smalltalk folk will burn me at the stake for saying so, but my assertion > > is true -- and even though I've long been a loud supporter of OOP, I do > > not see it as essential (or even desirable) if it gets in the way of > > clarity and efficiency. > > > > > c) We probably all wish Interoperability with C were a bit > > > simpler. > > > > Were multi-language programming easier, we would not need to add better > > math support to Java or OOP to Fortran. To use the right tool for the job, > > we need to right tools -- and if all the tools are the same, choice > > doesn't matter. > > > > Perhaps Fortran needs separate codices that focus on interoperability with > > specific languages? > > > > > g) Good exception handling is crucial for writing robust code > > > in any application area, and this is certainly true for numerical > > > programs. Both C++ and Java provide excellent models --- why can't we > > > do this? > > > > I couldn't agree more. I don't care much if Fortran gains classes and > > objects -- but I'd very much like to have a sane exception-handling > > mechanism to improve code reliability and readability. > > > > > j) A facility that allows the specification of the precedence of an > > > operator with a user-defined operator name is long overdue and will not > > > do any harm as some would make you believe. Let those who want to > > > mimick their usual notation as closely as possible do as they like. > > > This will have absolutely no effect on those who do not want to use this > > > feature. Freedom!! > > > > I agree -- although, as the Java folk argue, user-defined operators can > > produce some very unreadable code. With freedom comes responsibility. > > > > > We do not see Fortran ready to take this historic step at this time. > > > Before making such an irreversible decision, we strongly recommend a > > > thorough investigation and discussion of the potential uses of these > > > "precious" symbols. > > > > The real question is: Even if Fortran takes this step, will anyone follow? > > Given the lack of movement toward Fortran 95 in many circles, it seems > > that the leaders need to find out more from the putative followers. > > > > -- > > Scott Robert Ladd > > Coyote Gulch Productions (http://www.coyotegulch.com) > > > > Professional programming for science and engineering; > > Strange and unusual bits of very free code. >