Re: despair

In article <1190596861.683981.103920@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
AEF <spamsink2001@xxxxxxxxx> writes:
On Sep 23, 8:59 pm, b...@xxxxxxxxxxx (Bill Gunshannon) wrote:
In article <1190592151.788617.205...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
AEF <spamsink2...@xxxxxxxxx> writes:

On Sep 23, 5:10 pm, b...@xxxxxxxxxxx (Bill Gunshannon) wrote:
In article <op.ty2slrpwhv4qyg@murphus>,
"Tom Linden" <t...@xxxxxxxxxxxxxx> writes:

On Sat, 22 Sep 2007 10:35:17 -0700, Bill Gunshannon <b...@xxxxxxxxxxx>
wrote:

In article <op.ty2dz6bkhv4qyg@murphus>,
"Tom Linden" <t...@xxxxxxxxxxxxxx> writes:

Penny-wise, pound-foolish? The development and maintenance of C code is
more costly. So pay now or pay later.

Sorry, no basis in fact for that. Might actually be cheaper as the pool
of available C Programmers is considerably higher than say the pool of
available Fortran, COBOL or (gasp) PL/I programmers. And if the shop has
reasonable coding standards, maintenance does not have to be a nightmare.
(I know, having worked in large shops where turnover every 1-3 years is
prett close to 100%.)

bill

No, I do have a basis for that (1) 41 years of experience

More than me, but not by much if you count the times I wandered into
the IT field for short periods of time before I took it on full-time.

and (2) if you
compare
PL/I and C programs for equivalent functionality, you will find that the C
version
will have 2 to 3 times as many source language statements.

And that means? Somehow, I don't think number of statements is a strong
basis for deciding the economy of a an Information System. If it were,
there would be a lot more stuff written in BASIC. :-) And loaded with
GOTO's.

And let's not forget that PL/I compilers are rarer than PL/I programmers
which kind of limits it's usefulness beyond some very small niches.

Weren't you the one who said bad code comes solely from bad
programmers and that the language makes zero difference? Did I miss
something?

What does that have to do with the fact that PL/I compilers are rarer
than PL/I programmers? Or the number of statements it takes to write
a program in any given language?

Sorry, I was referring mostly to your excessive GO TO's complaint
w.r.t. BASIC. (I should have snipped the succeeding paragraph.)

Well, I thought pretty much everyone agreed with Dykstra regarding
the use of GOTO's, but maybe I'm wrong. (there are other things where
Dykstra and I part company so maybe some don't even agree with this.)

I
thought that you implied that BASIC tends to give you bad code because
of all the GO TO's, in contradiction to your claim about bad code
coming solely from programmers.

Good programmers don't use GOTO's, even in BASIC. :-)

And can you write good code using MS-
DOS?

Well, MSDOS isn't a language so I don't understand the question. But
if you meant can I write good code to run under MSDOS, certainly.


It seems to me that always blaming the programmer regardless of what
language he is stuck with is like blaming a rescue worker for failing
a rescue regardless of what equipment he has to work with (say a
fireman armed with a single fire extinguisher vs. a fire truck with
working hydrant).

A smart fireman knows when he doesn't have the equipment to perform
the task and he doesn't waste time, effort or his life trying. SE
is the same way. One of the first parts of SE is selecgting the
right tools for the job. That means choosing the right language for
the task at hand. Anything less is not SE it is hacking. Because
your boss won't buy another compiler is not an excuse, it just means
your shop does not practice SE. You can change that or live with the
consequences. But you can't blame that one language for not being the
right tool for the job. I have never worked in a one language shop.


As to appropriateness of different languages for different purposes
(as mentioned by another poster), in physics from 1983 through 1991 I
used FORTRAN to write programs to analyze data (as did most physicists
at the time -- I don't know what they use now!). Would another
language been as good or better? Of course there's code for analyzing
experimental data, and other code for performing theoretical
calculations.

Att that time, Fortran was the right tool for that job. Probably
still is today, although real Frotran compilers seem to be getting
rare as well. I have found myself maintaining business applications
written in Fortran by engineers (in their free time one summer just
to keep them busy). They wrote in Fortran because it was the only
language they knew. The program were abominations and I got the
task of maintaining them because I came into a shop knowing Fortran
and they had these legacy programs..... My first suggestion was to
re-write them all in COBOL like the rest of the business applications.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill@xxxxxxxxxxxxxxx | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
.

Relevant Pages

  • Re: A petition to J3 apropos FORTRANs future
    ... Fortran folded like an accordion and gave ... The vast majority of programmers are not doing "scientific ... In theory, programmers would just "use the best language for the job", ... But there are reasons, both real and silly, why one ...
    (comp.lang.fortran)
  • Re: CollabRx seeks brilliant engineers for an excellent e-science adventure
    ... belief that lisp programmers are smarter/better. ... Java or PHP programmers. ... a type of language that attracts a personality that meets my perceptions ...
    (comp.lang.lisp)
  • 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: despair
    ... available Fortran, COBOL or PL/I programmers. ... will have 2 to 3 times as many source language statements. ... your shop does not practice SE. ...
    (comp.os.vms)