Re: one-liner for characater replacement

analyst41@xxxxxxxxxxx wrote:
....
What is stopping you from observing that it the Fortran written using
"error-prone" features (before the dying off period of early 1970s -
late 1980s) that has the best chance of survival going forward?

That it was written in earlier versions is somewhat a given given the time frame... :) I have absolutely no doubt if I had had an F95 or later compiler while using pre-F77 or even F77 compilers I would have been gleeful in using its feature set to accomplish the same set of tasks which could now be going forward.

For example, I think that implicit typing is actually error-reducing
and not error-inducing. That you can occasionally type "tets" for
"test" and the unintended variable would live merrily on in your code
wreaking havoc is now caught by modern compilers (typically when you
have done that you would be using a a variable to which a value has
not been assigned).

But all this "saving the programmer from himself" mentality is not
going to help when both test1 and test2 have been dutifully declared
in fortran 90s puke-making style ("real kind allocatable :: whatever")
and the programmer calls a subprogram with test1 in the argument when
he intended test2.

No language feature of any language can catch logic errors.

Implicit typing allows for idiom and continuity of style. And during
code development, imagine that you want to bring in a value for
debugging purposes sixty or seventy lines deep in a subprogram and if
it is real, imagine how easy it is to define a function realfun and
invoke realfun exactly where you want it without having to scroll up
to where the declarations are and declaring realfun.

Or, alternatively, imagine how easy it is to have a second window in the editor open to the declarations area simultaneously.

Implicit typing makes the process of code development more fluid, not
forcing the programmer to break his chain of thought too often and
actually reduces errors in my opinion.

This holding to a 30-yr out-of-date programming style as an argument seems awfully shallow basis for the "design" of some modern language--and, of course, one can write F77 (w/ few exceptions) in Fxx compilers. Studies have pretty much documented that the types of style you're advocating do indeed reduce productivity and raise error count.

....

--
.

Relevant Pages

  • Re: C++ sucks for games
    ... Few, if any, compilers offer completely safe modes. ... Lisp programming is much more visual. ... >> objects around to make manual memory management manageable. ... Few programmers use the auto keyword in declarations because all ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... Few, if any, compilers offer completely safe modes. ... Lisp programming is much more visual. ... >> objects around to make manual memory management manageable. ... Few programmers use the auto keyword in declarations because all ...
    (comp.lang.cpp)
  • Re: Tcl_GetIndexFromObjStruct and Comconnosance
    ... for GIF and PNG files, but the current photo command procedure cannot directly accomodate an extension of that kind --and the current GIF code can be improved, and I just plain don't like TkPNG. ... that sort of thing in Tk for now. ... I am curious as to how well-implemented local blocs are in existing C compilers. ... This is problematic because C90 expressly forbids mixed declarations and code. ...
    (comp.lang.tcl)
  • Re: K&R-Style Function Declarations: Good or Bad?
    ... > short parameters getting promoted to int. ... all pre-ANSI compilers widened char and short ... declarations -- some compilers converted the widened types back to the ...
    (comp.lang.c)
  • Re: Pros and cons of assumed-shape arrays
    ... That kind of thing is why I asked about the separate file and interface ... I could maybe get the compilers to inline ... the kinds of things that trigger it. ... I find it easier to imagine that it would result from making the routine ...
    (comp.lang.fortran)