Fly Away wrote:
> Task - text processing. Fortran doesn't have regular expressions. I
> haven't seen any Fortran libraries that do that. This, of course,
> doesn't mean they don't exist, but I haven't been able to find one.
I've written support for them. The code belongs to a former
employer, or I'd just post it. It's not hard. But - it's a library
issue, not a language issue. Or do you think libraries are
part of the language? That's *really* wierd. I've not
recently found a Fortran from which I couldn't call such
library routines if I needed them. (You would probably be
surprised at how little value such things have for tasks such
as compiler construction. Such simplistic library calls don't
have the efficiency or quite the right functionality for lexical
scanning or parsing. Better to stick with a table driven scanner.)
> Task - file manipulation. Can you create a folder or copy a file in a
> portable standard conforming way?
Not in Fortran. Not in any language. The concept of "folder"
(or "directory", "path", etc) is not portable. Some systems haven't
got them. Some systems haven't got files at all. The way different
languages do non-portable things varies. I've not seen a Fortran
that couldn't create directories on sytsems that supported them.
> Task - using basic well established algorithms like all kinds of
> sorting. To make it portable you would either have to write your own
> implementation, i.e. reinvent the wheel, or resort to a library most
> likely written in another language that will probably impose licensing
> restrictions.
Never met a sorting algorithm I couldn't code *more* legibly in
Fortran. Many of the old, and still most used, were *invented*
by Fortran programmers. (Maybe you are confused by the
fact that most publications presented algorithms in Algol?
I've seen places that didn't even *have* an Algol implementation,
and they sent their new algorithms to press written in Algol.
It's kind of like scientists until the 20th century: always publishing
in Latin even though most didn't speak Latin or use it in their
work.)
> Task - Web programming. I am not sure even how to approach this in
> Fortran. I think generating web pages using the write statement would
> be weird and unnatural. Accessing web services from Fortran... Or
> writing one... How would you do that?
I have no I idea what problem you're addressing. I use tools, not
languages, to write web pages. Always have. The "language" is
HTML or XTML augmented with CSS.
Or are you talking about "active content" (that vile reinvention
of animated roadside billboards)? In which case, since there
are only two languages that I know of, and only one widely
supported, that's not really a very good example. If you are
not presented with choices, that fact doesn't demonstrate
any weakness of the languages that you couldn't choose.
Implement Fortran support on web browsers, and we'll
see that it is suitable.
> Task - graphics. Third party libraries seem like the only option. Not
> that it's different in many other languages, but there are lots more
> options available outside the Fortran world. Especially in open-
> source.
Libraries (as mentioned above) are callable from Fortran no matter
what language they're in. Now, if you want to talk about how
to write such libraries more efficiently, more legibly, or with
more reliaility, they should perhaps have been in Fortran (or
something like it) in the first place. I'm not responsible for
the bad decisions of others.
> [...] Yes, it is
> complicated, some concepts are implemented better in other languages,
> but yet I can't understand your complete denial of the strengths that
> C ++ has. Calling C/C++ an enemy is just beyond my comprehension. It's
> merely a tool. How can you get so emotional about it?
You're the emotional one. I'm not particularly interested in C or
C++ anymore because I no longer use them. When I suppored
C compilers, I knew more about it than any three random users
you would care to name. If I have a disrespect for the language,
it's because I know it very well indeed.
The real question, the the one that points to an emotional
issue, is someone coming into a forum for users of a given
language and telling them what they shouldn't be using the
language for. Especially telling people that *have* successfully
written just such applications in Fortran. Many of whom know
and have used dozens of languages and who chose Fortran
because they found it *better* than the alternatives.
>>> And while we're at it, why do you believe
>>> that application domain is even relevant to the issue of language
>>> suitability?
>
> I can't make sense of this question... Your wording often confuses me.
> If you need to write an application you look for a suitable tool
> (language). If you need to put a nail in the wall, you use a hummer,
> not a microscope. So a hammer is more suitable for this kind of work
> than a microscope. Is this relevant enough?
Programming languages aren't hammers or microscopes. The analogy
is so completely bogus that there's no value to glean from it at all.
Programming languages are multiplex tools. Almost all of them have
the same collection of capabilities. Fortran and C, for example, are
practically isomorphic. The set of applications each is suited to is
the *same* set. What distinguishes them is which makes code easier
to write, read, verify, correct, extend, or maintain.
There have been objective experiments to measure the effect of
language features on programmer productivity. (There haven't
been enough of them, and since the results usually gore some
important sacred cows they aren't widely reported. And people
with vested interests to protect lobby against funding them. So,
unfortunately, most are old - but more recent than C.) For
each such tested feature, C pretty much adopts the loser.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."
-- C. A. R. Hoare
"Simplicity is prerequisite for reliability" -- E. W. Dijkstra
