Re: Using GVim instead of Vim on Windows
- On 22/02/09 03:05, _sc_ wrote:
> On Saturday 21 February 2009 6:31 pm, John Little wrote:almost:
>> On Feb 21, 12:02 am, Tony Mechelynck<antoine.mechely...@...>
>>> So the
>>> criminal offence, if any (which remains to be seen), might be _teaching_
>>> COBOL or _requiring_ its use, but not _using_ it.
>> Normal coding is not use in isolation, one is always in communication
>> with whoever gets to maintain the code.
>>> If you say COBOL-74 was different from "my" COBOL in crippling terms, I
>>> have to defer to you. Was COBOL-74 freeform already?
>> Yes, but it still had no end-if, an unusable call statement, and the
>> all-variables-global data division. Cobol-85 cleaned things up a lot,
>> enabling logic to coded straightforwardly. But the cripples I
>> referred to were so enamoured of their copy books with GO TO paragraph-
>> exit they enshrined it in the coding standards. go tos are bad, but
>> when they're in copy books (included code), going to places in other
>> copy books, I find the notion of brain damage inescapable. That might
>> have been one shop going off on a tangent, but I encountered the same
>> practice (among other heinousness) on another unrelated project.
>> (That included something that was arguably criminally negligent,
>> because it concealed a back door that could be used to affect money
>> This may seem off-topic, but IMO is relevant to vim-dev at least.
>> Vim's developers might be aware of some aspects of the "house-style".
> this sounds like a fun rant -- i can't not jump in, forgive me
> you haven't lived until you've been required to modify an old cobol
> program that made liberal use of altered gotos
> eg: ALTER A210 TO GO TO B103.
ALTER procedure-name-1 TO [PROCEED TO] procedure-name-2.
where PROCEED and the second TO were (IIRC) not required by the language
but we always used them, if only because (in those times) COBOL source
was supposed to be "better" if it resembled English language, so some
verbosity was preferred over hardly-understandable terseness.
procedure-name-1 had to be a paragraph with nothing else than a GO TO
statement in it.
>Where I worked, flow charts had to be religiously kept with the
> that is what the paragraph names were like -- a letter and a number
> -- they came from the flow charts on which the programs were
> initially designed, made no sense whatsoever without the flow
> charts, and of course the flow charts were nowhere to be found
program's documentation, and anyway, any of us programmers was quite
adept at reconstituting a missing flowchart from the source code. But
finding that a flowchart was missing was a good reason for a serious
look at the AUTHOR paragraph of the IDENTIFICATION DIVISION --
well-fleshed-out IDENTIFICATION DIVISIONs were part of the "house style"
which our senior programmers insisted on when teaching newbies --
programming degrees didn't exist when I started, and most of the
learning was done on the job. Another part of that house style was fixed
columns in the DATA DIVISION, such as VALUE, OCCURS, REDEFINES and
similar clauses in column 40 and the word PICTURE written in full
starting in column 52 (so that the "picture" itself always started in
column 60). (This was fixed-form COBOL on 80-character Hollerith cards,
remember? It could be saved onto tape, and usually was, but still with
80-character fixed-length lines.)
However, what often happened was that bugfixes to the source code
weren't always mentioned in the flowcharts: if the code and the
flowcharts don't agree, the code tells you what the program is doing
now, the analyst's specs (usually) tell you what it ought to do, and the
flowchart on file usually tells you how the original programmer thought
the specs should be implemented. When trying to find a bug, all three
are complementary, plus (for instance in case of a crash) the memory
dump we got from the operator when a UEP error (Unusual End of Program)
happened, usually for out-of-range subscript, which in turn most often
was a symptom of an off-by-one error in the bounds of a PERFORM VARYING
statement. (No stack trace, we didn't use that, recursive subroutines
were an unknown thing on those OSes.)
>:-) Happily for me, maybe, I never worked for a hospital. What I did
> now, while trying to wrap your mind around that, imagine the
> program processes lab results in a hospital, and you either get the
> modification right or people could wind up dying because the result
> of their lab test came from some other patient
work on was one program for a simulation of a marshalling yard for the
International Railways Union, various accounting jobs within
(well-documented) software packages written by other people of the firm,
some job over a production database, and also (but not in COBOL) keeping
an eye on the system software (which, in those times, was distributed
with its source) and writing some assembly-language modules to be called
>well, I guess I used much more than you did over the whole of this thread.
> i was never quite so glad as when i got out of that hospital and
> into a nice safe insurance company doing new c++ development
> oh wait -- yes i was -- when my financial advisor told me i could
> retire any time now -- tee hee
> sorry for the bandwidth,
Never let your sense of morals prevent you from doing what is right.
-- Salvor Hardin, "Foundation"
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php