In article 11NOV199414105367 at seqvax.caltech.edu, mathog at seqvax.caltech.edu (David Mathog) writes:
> >Looking the gift horse straight in the mouth...
>> A few responses to the responses (names deleted from all quotes).
>> The part that seems to have rubbed the most people the wrong way is:
>> 1. It is written in ANSI C or Fortran 77 (but NOT both).
>> This is my take on the objections raised. First, that enforcing the use
> of programming standards would be too limiting to creativity or
> productivity:
>> >Any standards run the risk of being straightjackets.
>> >My primary point was: let's
> >not rush out and convince grant agencies to fund only if it will be
> >lowest common denominator software.
>> The taxpayer in me says "tough potatoes" if the chosen standards are not to
> all programmer's liking. From a funding viewpoint, any software that is
> developed should be as portable as possible. Now I'll grant you that
> fortran is better for algorithmic work than for some other things, but it's
> hard to see where the creativity limitations in C lie. Rather, the problem
> with C is more often that the programmer gets a bit too creative!
Problem: portability increases cost and production time while decreasing functionality
and usability. Not to mention, there are numerous cases where applications (especially
high-end) are necessarily platform dependent. I'm sure a programmer would not mind the
portability requirement, since it would mean that not only would he make more money
(because projects will take longer), but he'll have more toys (since you'll need to
test the software on all platforms to make sure that it was indeed "portable"). The
only frustrating thing would be the arbitrary limits different OS's put on things
(file open limits, allocation limits, etc). As a taxpayer, of course, it's in your
best interest not to make things portable (it is much more economical for everyone
to use the same platform to begin with).
If you want to have nearly entirely portable code the first time everytime, you
want to write everything in SmallTalk, you won't even have to worry about the UI.
SmallTalk has a large amount of overhead and it'll require everyone to purchase a
SmallTalk intrepretter (and it's not the first choice for number crunching), but you'll
have portability at an unprecedented level.
> There is NO QUESTION that the two languages mentioned are the two most
> portable ones around, ANSI C being probably slightly more portable than
> Fortran 77.
Certainly there are more portable langauages, namely SmallTalk, but also Oberon
(really an OS, sort of). FORTRAN 77 is exceptionally portable assuming you don't
use any system/platform dependent code (which is necessary in the majority of
FORTRAN code, the main reason FORTRAN is not so popular). ANSI C is fine, however
it is limited by a number of things: there's no way to read a directory in ANSI C,
there's no way to interact with devices other than files, there's no way to do things
such as lock a file or record, or even shorten a file, etc.
If you truly have to have portablity, go with SmallTalk.
> The software that started this thread is built around Xview and it would
> take a major effort for anybody to patch around that.
You can get Xview from ftp.x.org in source form. It may be a little work to get
it to work on something like VMS, VM or CMS, but other OS's such as any UNIX, OS/2,
Win NT with their X11 kits it's pretty straight forward.
> WCS, another
> research project, but one with many, many users, is so Sun specific it
> hurts.
Xview is not Sun specific, SunView was. Sun moved to Xview for the very reason that
it was not Sun specific. WCS may be, but then again the SPARC platform is exceptionally
popular an sort of the de facto standard for government applications.
> First of all, writing in the latest trendiest language may make the
> programmer feel good, and it may make the coding for specific operations
> somewhat easier, but near as I can tell, it has little material effect on
> the final operation of the program. It does have a huge impact on how
> portable the resulting code is. I vote for portability.
If your programmer writes C++ code that is not more portable, easier to
maintain, and has greater flexibility than ones written in C then you don't
have a C++ programmer on your hands. Fire him. If you have an experienced C++
programmer, it should make a world of difference.
> Second of all, C++ is a bit of a special case. So long as the developer
> has the tools to convert their C++ code to ANSI C, and at least the C code
> is distributed, then go ahead and write in C++. However, C++ compilers
> are far rarer beasts than some of you would believe, and so C++ code should
> not be distributed alone since it fails the "generally available" compiler
> criteria.
Cfront is an endangered species. Most current C++ compilers do not waste time
converting the C++ code into C code anymore and as such are much more optimized
and quicker to compile. C++ is also available for every platform and in the
public domain (GNU C++ comes to mind, but there are shareware C++ compilers too).
C++ is much more likely to be portable than C code.
> I'm also concerned that the C++ standard may not be nearly so
> well defined as those for the languages that I mentioned (feel free to
> correct this if it's wrong). If Linux has no fortran 77 compiler then it
> would be the only major platform that does not. ANSI C is certainly
> available everywhere. However, the only free ANSI C compiler that I know of
> these days is Gnu C. ANSI C on all other platforms is already an extra cost
> item. If you think not, check your maintenance/ licensing agreements. So
> what if compilers cost money? So does the operating system, so does the
> hardware, so does support. This is the real world.
The C++ standard is much more clearly defined than the ANSI C standard, mostly
because ANSI C cames first and afterward, they understood what was missing from
the standard and included that into C++. As far as I know, GNU C++ is available for
every platform that GNU C is and that commercial C++ compilers are available for
all existing platforms.
Those using home computers of various sorts should find a plethora of compilers
for a number of languages (especially those that still have Amiga computers, the
platform with the largest PD language and compiler base, even though the company
folded; imagine that).
> The comment that C++ or Fortran 90 code is inherently less buggy and harder
> to maintain than is C or Fortran 77 is at least unproved, and most likely
> wrong.
That's incorrect. C++ code is invariably less buggy than C code for a number of
reasons: the compilers are picky to the point of being anal retentive, as defined
in the ANSI C++ spec. Many coding errors that are not picked up at all by C compilers
will set off bells and whistles galore when you try to compile it under C++. Typing
and scoping rules under C++ are much more rigid and as a result most C++ code, if
it compiles, is largely without coding errors (all errors then become logical or
runtime ones).
> I'm old enough to have lived through several methodology shifts,
> each claiming the same benefits that object oriented languages do now.
> Nevertheless, the quality of a program still seems to come down to the
> programmer's skill and little else.
Given enough time, and free of undue prerequisites, a good programmer should be
able to code nearly anything in any language. The questions are, how long will it take,
will anyone ever be able to figure out what he did, and will what he did be reusable
it other projects?
Writing in an object oriented fashion makes reusing code exceptionally easy (assuming
it is done correctly, but we assume there's a competent programmer involved) and it
also makes this code much easier to read.
The quality of the product is a function of the programmer. How quickly the programmer
can generate, debug, and maintain code is largely a function of the langauge.
> >Grant money flows for publications, rarely for software: when this
> >changes, portability will come quickly.
>> This is right on.
Bingo.
> David Mathog
>mathog at seqvax.bio.caltech.edu> Manager, sequence analysis facility, biology division, Caltech
