Can we do without C? 
Author Message
 Can we do without C?

I use fortran77 very often, and I like it. I have always used it for number
crunching applications. I have a colleague who is {*filter*}ed to C, and he
says that you can virtually do in C anything you do with f77. However, he
emphasizes that there are many things in C that you just can't do with
fortran (77 or 95), like low-level stuff (graphics drivers, operating
system programming, games, and so on).
Is it true that it's impossible to do that in fortran?
Furthermore, is it safe to say that it's best to learn both languages, and
that each should be used for its specific merits?
In other words, can C potentially be substituted by fortran in everything
or is a guy better off learning both?


Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?

|I use fortran77 very often, and I like it. I have always used it for number
|crunching applications. I have a colleague who is {*filter*}ed to C, and he
|says that you can virtually do in C anything you do with f77. However, he
|emphasizes that there are many things in C that you just can't do with
|fortran (77 or 95), like low-level stuff (graphics drivers, operating
|system programming, games, and so on).
|Is it true that it's impossible to do that in fortran?
|Furthermore, is it safe to say that it's best to learn both languages, and
|that each should be used for its specific merits?
|In other words, can C potentially be substituted by fortran in everything
|or is a guy better off learning both?
|

Don't let it bother you, C may have more capability, but it's also easier to
make mistakes and harder to find them in C than FORTRAN.  You'll probably
also hear that it is harder to maintain over the life of the program.  All
languages have their strengths and weaknesses and it wouldn't hurt to learn
more than one so that you can select a language more suitable to the task,
if you have that option.  In that respect, operating systems, games and so
on can usually be written in any language.  Very few people need to write
graphics drivers.  Usually the language will have a graphics package already
available so you just call the appropriate graphic function while passing
the proper parameters then go on to the next task.
Finally, if your employer only has a FORTRAN compiler, it is unlikely that a
C program will compile on it and, since he probably paid lots of money for
it, he'll not be inclined to take a suggestion to s{*filter*}it to buy a C
compiler and convert all the *working* FORTRAN programs to C.

-CB



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?

[snip]

Quote:
>Is it true that it's impossible to do that in fortran?
>Furthermore, is it safe to say that it's best to learn both languages, and
>that each should be used for its specific merits?
>In other words, can C potentially be substituted by fortran in everything
>or is a guy better off learning both?

There are lots of things that are impossible to do in Fortran.  On the
other hand, C is a lower level language (kind of halfway between
Fortran and assembly) originally designed for stuff like writing
operating systems, so it *should* do things that a Fortran user really
has no business monkeying with.

These days, there is so much "feature envy" among language proponents
that there is a lot of overlap between most languages.  And things
that a language really can't do itself are very often covered by
libraries that are callable from that language.

If programming is a tool you use in your job, and not the main focus
of your job, it's worth sticking to one language you become adept at.
I use Fortran 77 nearly exclusively.  It's very well suited for what I
do most of the time: make and torment numbers.  When I get into other
stuff, though, I have yet to find something I can't do.  With the help
of Fortran-callable libraries and a few vendor extensions, I can do
interactive graphics, control hardware, twiddle bits, etc.  I've had
to use assembly language every now and then, but in fairly specific
ways that did not require actually learning assembly language.

Ken Plotkin



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?

Quote:

> I use fortran77 very often, and I like it. I have always used it for number
> crunching applications. I have a colleague who is {*filter*}ed to C, and he
> says that you can virtually do in C anything you do with f77. However, he
> emphasizes that there are many things in C that you just can't do with
> fortran (77 or 95), like low-level stuff (graphics drivers, operating
> system programming, games, and so on).
> Is it true that it's impossible to do that in fortran?
> Furthermore, is it safe to say that it's best to learn both languages, and
> that each should be used for its specific merits?
> In other words, can C potentially be substituted by fortran in everything
> or is a guy better off learning both?

A guy is much better off learning both.

Or at least better knowing how to find/use/build Fortran-callable
C libraries.  

The biggest deficiency in Fortran, imnho, is that I/O is not well-defined
from the "systems" point of view; the only guarantee the standard gives
you is that when one of your Fortran programs writes a file, another
Fortran program *compiled with the same version of that compiler* can
read it.  (The pragmatics are that there exists rather more portability
than that, but it's a "quality of implementation" issue rather than
something guaranteed by standards -- nothing is guaranteed by either
the Fortran standard (which for good reasons ducks "systems" issues)
nor the POSIX standard (which damned well *should* have addressed this
issue!))

And for that I/O problem, I really recommend using higher level libraries
that suit your application better.  For environmental modeling, I
recommend the modeler-oriented API jointly offered by NCSC and US EPA
( http://www.*-*-*.com/ ), which in turn is
built on top of lower-level (but *still* high-level from the point of
view of Fortran or C I/O) C/Fortran libraries such as netCDF from the
National Center for Atmospheric Research (see
http://www.*-*-*.com/ ) and PVM from
Oak Ridge National Laboratory).  Other good alternatives are PDB from
Livermore, CDF fron NASA, and HDF from NCSA.

Of these, HDF is arguably the most flexible, but it has some hidden
"gotchas" in its embedded sequential index structures which may destroy
performance for some applications (among them, mine!).


MCNC Environmental Programs                      phone: (919)248-9241
North Carolina Supercomputing Center               fax: (919)248-9245
3021 Cornwallis Road                                  P. O. Box 12889
Research Triangle Park, N. C.  27709-2889                         USA
"My opinions are my own, and I've got *lots* of them!"



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?


Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?
1) Anything that C can do, you can do just as easily with
Fortran + Assembly.  I've done it often enough to know.
But you need to be good at both and learn lots of underlying
details that otherwise you could ignore.

2) Anything that C can do, you can do, with some contortions,
with Fortran and Pascal.   I did that once.  Once was enough.

3) And if you are willing to abuse language constructs, use
vendor/platform dependent extensions or both, then
anything C can do, Fortran can do alone, albeit, sometimes
with much more effort.  I've done that occasionally, but it is
usually easier to do mixed language programming.
-----------
But, why the desire to eliminate C?  Even in theory?  If you
are serious about programming as a tool, learn several languages.
A casual programmer needs only one language, but anyone
going beyond that level is better off with at least two or three.

Just try to determine what you will need to do, and pick your
languages to suit.  Fortran, C or C++, and possibly a third
(assembler or AWK or Perl or Delphi or VB) depending upon
platforms and purposes are a good set of choices for many things,
if your primary interest is numerics.
--
Kevin G. Rhoads, Ph.D. (Linearity is a convenient fiction.)




Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?


Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?
Dear Mr. Basile:
        You ask a lot of interesting questions.

Quote:

> I use fortran77 very often, and I like it. I have always used it for number
> crunching applications. I have a colleague who is {*filter*}ed to C, and he
> says that you can virtually do in C anything you do with f77. However, he
> emphasizes that there are many things in C that you just can't do with
> fortran (77 or 95), like low-level stuff (graphics drivers, operating
> system programming, games, and so on).
> Is it true that it's impossible to do that in fortran?

        Fortran was originally designed as a high-level programming language for
modelling scientific and engineering problems.  The intent was so that the
programmer would not have to code in assembler and not worry about low-level
issues like machine addresses and such.

        C was originally designed as a systems programming language, i.i for
programming such things as device drivers, memory managers, and operating
systems kernels.

        Both languages have spread far beyond their original application domains.  It
IS possible to do a lot of low-level stuff in fortran, with vendor extensions
and/or suitable systems libraries.  Sometimes that works well, other times it
doesn't.

Quote:
> Furthermore, is it safe to say that it's best to learn both languages, and
> that each should be used for its specific merits?

        Yes.  Generally, Fortran and C each have their own areas of strength.  

Quote:
> In other words, can C potentially be substituted by fortran in everything
> or is a guy better off learning both?

        You are far better off learning both.

        The sad truth is that in the Real World there are many managers who believe
the hoary old myths about both Fortran and C.  The worst one about C is that
many people still believe "C is the greatest thing since sliced bread and the
one-size-fits-all solution to all programming problems".  I have wasted (but
gotten paid for) countlesss hours fighting inefficiencies caused by the use of
C in areas that it is not well suited for, e.g., industrial automation.

        Because of market and political pressures, you need to know C well if you
want a lot of opportunity in the market.  However, for the vast majority of
general purpose application development, you will be far more efficient
programming the application in **MODERN** Fortran (i.e., F95).

--
----------
Sincerely,

Elmbrook Computer Services      Voice Phone: (414) 783-5869
17130 W. Burleigh Place         Fax Phone:   (414) 783-5928
Brookfield, WI   53005          Disclaimer:  These opinions are mine alone.
USA                             They do NOT represent any organization.

"They that can give up essential liberty to obtain a little temporary
    safety deserve neither liberty nor safety."  -- Benjamin Franklin (1759)



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?
Fortran is better than C for all those things that it (Fortran)
was designed to do.  In fact, for handling all data types for
which Fortran has direct intrinsic support, Fortran is better
(this includes character manipulation, for which Fortran has
better support than C).

In fact, for the range of applications for which it was designed
(scientific/numerical calculations and simulations) Fortran is
still one of the better choices.  Not bad for a 44 year old language.

C is not (and never was) among the better choices for its original
intended problem domain.  There were better system-level
languages in the early 70's and there still are.  C's only advantage
stems from the fact that it was *free* when most universities were
first starting their computing science departments.  This means that
it's universally available now (all those CS graduates who don't
want to learn anything else).  But it had (and has) few actual
technical merits.

Yes, we could get along without C - in the same way we could
get along without Microsoft, or VHS videotape formats, or any
other big-name product that has become so common as to be
ubiquitous.  The cost of actually replacing them would be prohibitive.
The only choice might be to gradually superceed them.

--
J. Giles



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?


Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?

Quote:
>But, why the desire to eliminate C?  Even in theory?  If you
>are serious about programming as a tool, learn several languages.
>A casual programmer needs only one language, but anyone
>going beyond that level is better off with at least two or three.

>Just try to determine what you will need to do, and pick your
>languages to suit.  Fortran, C or C++, and possibly a third
>(assembler or AWK or Perl or Delphi or VB) depending upon
>platforms and purposes are a good set of choices for many things,
>if your primary interest is numerics.

I support this attitude. Rather than fight language wars, pick the
language(s) that solves your problem best. Sometimes, this means mixed
language programming. See also http://home.sol.no/~arnholm/cppf77.htm

Learning a second language means understanding the first language better.

Carsten A. Arnholm

http://home.sol.no/~arnholm/



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?


Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?

Quote:

> I use fortran77 very often, and I like it. I have always used it for number
> crunching applications. I have a colleague who is {*filter*}ed to C, and he
> says that you can virtually do in C anything you do with f77. However, he
> emphasizes that there are many things in C that you just can't do with
> fortran (77 or 95), like low-level stuff (graphics drivers, operating
> system programming, games, and so on).
> Is it true that it's impossible to do that in fortran?

Well, I can't comment off hand about graphics drivers but operating
systems and games (Adventure !) have been written in Fortran.

Quote:
> Furthermore, is it safe to say that it's best to learn both languages, and
> that each should be used for its specific merits?
> In other words, can C potentially be substituted by fortran in everything
> or is a guy better off learning both?

I would learn both - it isn't too hard.  When I left University (MS in
physics), I bought the K&R book (now you're better off with the second
edition, which describes ANSI C).  Good book to learn C from if you
already know another language.

Of course, this doesn't save you from sometimes chosing the wrong
language to do things in.

Yearly, I have to make several summaries from a Dbase IV database I
maintain.  It only dawned on me yesterday that the fixed width ASCII
output from "LIST" is much better matched by the properties of character
I/O of Fortran than of C (which I turned to because I tend to write the
"{*filter*}s" in C).  [No, I won't try to do that in Dbase Report Language
- I have to convert it to Unixese anyway to get it printed]

--

Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?

Quote:

> > I use fortran77 very often, and I like it. I have always used it for number
> > crunching applications. I have a colleague who is {*filter*}ed to C, and he
> > says that you can virtually do in C anything you do with f77. However, he

Possibly you can do everything in every language. In general you do it best
(more quickly and more efficiently) in the language you know best (for me is
fortran) or like most (for me is *definitely* fortran). There are things are
done better in a language which was designed for it. In this NG you'll see
several threads stating for instance that fortran is better for optimized
number crunching.

Quote:
> > emphasizes that there are many things in C that you just can't do with
> > fortran (77 or 95), like low-level stuff (graphics drivers, operating
> > system programming, games, and so on).
> > Is it true that it's impossible to do that in fortran?

This is not altogether true, and in the limited cases where it is true, it is
not by a design fault on the fortran side, but by a deliberate barrage
inserted by C programmers (with one exception which I ascribe to developers of
Fortran compilers, but ... possibly they were writing in C).

Actually the above is true only when you think of system level programming
under Unix. Older operating systems (like VAX/VMS or HP/RTE) had native
Fortran binding for all their operating systems calls !

Now I'm not sure what you mean by "games" (sorry but I use fortran for serious
stuff ... although the original Adventure game was, I believe, written in
fortran), I assume you mean the graphics and GUI part of it, which brings us
back to what follows (X and system programming).

I'm also not sure about what you mean nowadays by "graphics drivers". Nowadays
almost all graphics is done either by X window or postscript. Yes, once one
had to write drivers for things like VT200 or Tektronix terminals, HP-GL
plotters, Calcomp plotters, Ramtek TVs and alike. I even did some programming
with those, and put my hand in drivers written in assembler (by others). But
I'm not convinced one *needed* to shun Fortran for that, except for one thing
(i.e. communicating with the device as a raw binary stream).

Now you can very easily write programs doing postscript graphics in fortran,
so the problem may be only with X.

So we are left with only three "critical" areas :

  - X programming (Xlib calls or higher level toolkit calls)
  - system calls
  - raw binary i/o

Let's put the first two together. In fact Xlib routines are written in C and
designed with a C binding in mind (although SOME vendors provide Fortran
bindings). So are system calls under Unix (I REPEAT this applies ONLY to
Unix). This gives three major problems :

  - under most Unixes (the BSD-ish ones) for reasons yet unclear to me
    a Fortran subroutine call like CALL SUB generates at loader level a
    reference to a routine called sub_ (with an underscore), while a C routine
    sub() has a reference called sub (without underscore). Thus you cannot
    call a system level routine because of this !!!!

    Ways to overcome this are either compiler switches to inhibit the
    underscore stuff, or writing "silly" jacket routines (essentially you
    write a C routine sub_() which is Fortran callable and calls sub() )

  - argument passage to C routines occurs in a variety of ways (by value or
    by reference or by descriptor, implies pointers etc.) which may be
    confusing for a Fortran programmer used to a single and consistent way
    Also the mapping of C data types to Fortran data types is not always
    consistent (what are a short, an int and a long under the different OS ?)

  - C can use compound data types (e.g. Xlib uses an Xrect data type to
    describe a rectangle) or anyhow types which do not exist in Fortran
    (e.g. the infamous "unsigned")

    This again can be relatively easily overcome by use of C jacket
    routines, which receive Fortran arguments in a standard way (or by
    mean of a common) and issue the C call taking care of any argument
    "conversion"

Now we come to the third area, which is raw binary i/o. I mean reading or
writing on a channel (say a logical unit) an unformatted stream of bytes of a
priori undetermined length. This is the thing which is often needed to
communicate with "devices".  However a fortran unformatted sequential
WRITE(unit)LIST is usually implemented in an OS dependent (or compiler
dependent) way, which implies prepending and/or appending some control
characters to the data stream.  This is not expected by the C driver at the
other end, which expects "{*filter*}" data.

Way outs are : (a) avoid fortran unformatted sequential for all applications,
particularly those involving disk files (use unformatted direct access or
formatted sequential exclusively) ; (b) use a C-jacket routine to communicate
with drivers and/or (c) use fortran vendor-dependent extensions to the OPEN
command to allow raw binary i/o (really don't understand why they are not the
default for unformatted sequential).

With those simple rule and a minimum of experience one can do everything with
Fortran excepted a small library of C jacket routines. I did my own analysis
system, inclusive of an Xlib-based graphic server
( http://www.*-*-*.com/ ). Last time I did a count
( http://www.*-*-*.com/ ) I had only 8 % of my code in C
(limited to a system-dependent library of jacket routines, one Xlib interface
routine and a service main program.

--
----------------------------------------------------------------------

avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.



Wed, 18 Jun 1902 08:00:00 GMT  
 Can we do without C?


Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How to reset counters after daq is done without closing Labview

2. args passed from C (doing this without the ARG directive)

3. ok, so how do I return a sorted list without doing it in place

4. to CS: or not to CS: in F-PC assembler

5. CA Cans VO ?

6. It's not bad canned meat...

7. It's not bad canned meat...

8. It's not bad canned meat...

9. Using CGI module with 'canned queries'

10. It's not bad canned meat...

11. Doing assembly and really doing assembly

12. Doing assembly and really doing assembly

 

 
Powered by phpBB® Forum Software