OT Antivirus software

Page 2 of 6  


WATFIV
SPSS
BAL
SOC 4
PL/C
See, I know the *real* swear-words! <grin>
I actually enjoyed using FORTRAN. It was a lot more tolerable, after you figured out "equivalents" for 'useful' features in other languages. I even managed "array of pointer to function" that didn't give any even ANSI WARNING messages.
I'm *not* going to repeat what the salesman for a high-end Fortran-to-C conversion service said when he got some of that code for a demo of their product. <evil grin>
Then there was the time the boss made me write more than 40 lines of comments to document a _single_ line of Fortran code. A *very*simple* line of code. all it did was a _single_ 'shift' operation. This was one of those things where _what_ was happening was absolutely clear, but *WHY* it worked took a _lot_ of explaining. an 'abuse the data representation' situation. :)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

Nothing. Not a twinge of recognition even.

OUCH!
I see now that I am in the presence of a true master.

I just couldn't stand the whole "doing things 4 times" aspect of it. Hey, I'm gonna use a variable. Here is what it's called. Here is what it's set to. OK, now, use it.

No conversion software has ever been worth a damn, that I've seen.

There's a "guide to writing obfuscated code" somewhere which is great reading for amusement purposes. Unfortunately, some of the code-monkeys I've worked with have mistaken it for a style guide, I think. Ah, here one is, but it's not the one I was thinking: http://mindprod.com/unmainobfuscation.html
The one I was thinking talked about using variable names that looked like commands and so on, but my google-fu is deficient today.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Dave Hinz wrote:

...
...
I've used Fortran since before there was a Standard in many incarnations but fail to recognize the above complaint???
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
says...

Same reaction here. Of course you had to use DIMENSION and EQUIVALENCE statements, but simple variables could be used without decaratives. Some versions even set all data to zero when the program started, so you wouldn't get the undefined values problem.
The best thing that ever happened to Fortran was Ratfor.
BTW, I really like C's use of functions and absence of subroutines. The Modcomp realtime minis I used to use a lot had Fortran interfaces to system functions that looked like:
CALL XYZ( A,B,C,D,.TRUE.,.TRUE.,.FALSE., ... .TRUE.,0)
I contemplated homicide every time I had to figure out what one of those was actually doing.
--
BNSF = Build Now, Seep Forever

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
lgb wrote:

There was no requirement for EQUIVALENCE. I'd think only a small fraction of all FORTRAN programs actually used it at all (although, of course, there were/are reasons for needing it).

Non-standard and therefore, not wise if one ever moved platforms...but I've seen a lot of code that relied on the behavior and a lot of errors in comp.lang.fortran because of it... :(
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

When we transitioned from doing algorithm development in Fortran to C, one of our more senior alg developers finally acquiesced and decided he could live with using C when he found the GOTO statement.
Absolutely brilliant algorithm developer, you just didn't want to have to be the one who had to figure out what his code was doing.
+--------------------------------------------------------------------------------+ If you're gonna be dumb, you better be tough +--------------------------------------------------------------------------------+
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Mark & Juanita wrote: ...

...
Then I'll wager his C code was no easier to read than his Fortran... :)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

I'd thought that would be obvious based upon his delight in finding the GOTO statement. :-)
+--------------------------------------------------------------------------------+ If you're gonna be dumb, you better be tough +--------------------------------------------------------------------------------+
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I can show you code that is _much_clearer_ with the use of the carefully implemented goto than the equivalent mess in a "pure" structured form.
We won't even discuss setjmp()/longjmp() -- that's getting perilously close to the COBOL "ALTER" verb.
And then there were the people that threatened to implement a 'COMEFROM' statement.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@hadenough.com says...

Back in the early days, I had at least one job that required writing Cobol programs. I was told my Cobol looked like Fortran :-). Apparently most people didn't even know Cobol had a COMPUTE statement.
BTW, I know COBOL gets a lot of bad press, but it's still one of the easiest languages to get a novice producing working code. Excepting RPG, of course.
And I do have fond memories of the "MOVE CORRESPONDING" statement.
--
BNSF = Build Now, Seep Forever

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

No, we just *wish* it didn't. Destroys readability. Except for Fortran programmers. :-)
But the one that *really* doesn't belong in the language is ALTER. One place I once interviewed at told me that they have only one programming standard in the shop: use ALTER, get fired.

Yeah, but it still takes a long time to get them producing *good* code. :-)

That's another one that IMO should never be used. It's *far* too easy for seemingly innocuous changes in the structure of a group item to produce disaster. The other argument against it is that, while it saves development time, it wastes maintenance effort as the programmer has to look at both data structures, *carefully*, to see what gets moved and what doesn't. And since maintenance typically consumes 80 to 90% of a program's life-cycle cost, anything that saves development time at the expense of maintenance time is a bad practice.
--
Regards,
Doug Miller (alphageek at milmac dot com)
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@milmac.com says...

I'm not sure I agree with that. I could use meaningful names in Cobol when Fortran was still limited to 6 characters, IIRC.

There you got me. I don't even remember that one. But I didn't do a lot of Cobol. In fact, a lot of what I did back then was assembler. Anyone remember the addressing capabilities of the GE400 and 600 series? I still have fond memories of those.

Actually, I used it a lot in one-time programs whose purpose WAS to change a structure :-).
But if preceded by a comment such as "Extract salary data from personnel records", I don't think it was that hard to maintain. No, you didn't want to use it on a highly dynamic structure, but a lot of programs and data back before disk drives were pretty much cast in concrete after six months or so - too much hassle to change a lot of tape files.
Anyway, I think we've reminisced about enough - back to woodworking :-).
--
BNSF = Build Now, Seep Forever

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Some COBOL code is _intrinsically_ virtually unreadable. without COMPUTE.
Try to imagine what data-decompression algorithms look like in COBOL. (It _wasn't_ a matter of choice, that was the *only* language that that shop used. CICS command-level COBOL, in fact.)
Variable width bitfield data is all *sorts* of fun.
line after line of DIVIDE foo INTO bar GIVING baz, REMAINDER quux.
with various MULTIPLY something BY power_of_two, ADD this TO that GIVING result. thrown in, 'as needed'.
It's _all_ scratch-pad temporary variables, there's *NO* way to assign 'meaningful' names.
Plus, 'bit twiddling' is an utterly foreign concept to COBOL programmers in the first place.
There is simply _nothing_ you can do to make that code 'readable' by anyone other than a systems "guru". And _they_ have to puzzle over it for quite a while, because it would *never* occur to them to try to do that kind of thing in _that_ language.
The _internal_ documentation for _what_ that module was doing was six or seven times the size of the of the functional parts of the PROCEDURE and DATA divisions combined. And management _still_ put a declaration on the front of that module forbidding *anyone* but the author to modify it.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
(Robert Bonomi) wrote:

Yeah, and a lot of it was written by Fortran or assembler programmers. :-)

Thank you, I'd rather not.

I've always preferred environments where the programmers could use the appropriate tools for the job.

To win a bet a number of years ago with a co-worker who claimed it couldn't be done, I wrote a Cobol-85 program to manipulate individual bits in a doubleword. It was an interesting intellectual exercise, but one with no reasonable practical application other than winning a bet.

Looks familiar.

Probably why my colleague said it couldn't be done. OTOH, I began my career in DP with four years in an assembler shop. Wrote two Cobol programs the entire time; everything else was ALC. So I was intimately familiar with the concept, and practice, of bit twiddling.

Comments help... if the programmer knows how to write them. :-)

I wrote a couple of modules like that myself... including one, in Cobol-85, that performed closest-match searches of a thousand-element internal table. The actual search code is only some two dozen lines IIRC, but with comments it runs around four pages.
--
Regards,
Doug Miller (alphageek at milmac dot com)
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

No choice in this situation. Smallish shop, IBM 4381, 3 'applications' programers, *zero* 'systems' programmers. COBOL was the only language product they had licensed.
I was a contractor, that they brought in to 'do the impossible'. Because I could do d*mn near anything with whatever 'less than appropriate' tools were available.

*GRIN* I had a reputation of "If you want something done, hunt up Bonomi, tell him it's 'impossible', and stay out of his hair for a couple of weeks."

Yuppers. The primary reason it's foreign to COBOL programmers is that the relevant verbs ('shift', 'mask', 'bitwise and', 'bitwise or', etc.) simply do not exist in the COBOL vocabulary. If you don't have the concepts, you can't think in those terms. You have to have been exposed to the concepts elsewhere, internalized them, and then find 'equivalent functionality' work-arounds. Knowing about 'modulo' (another verb that doesn't exist in COBOL) helps greatly in getting down to the 'equivalent functionality'.

"sometimes". I once had to write an entire page of documentation for one line of program code. That line of program code reduced to *one* machine instruction. a 'shift' operation.
The comments were *utterly* lucid, including 'pictures' of exactly what was going on, and why.
But people couldn't cope with the fact that this shift operation was being done on a character string and *not* in a multiple of the bits-per-character.
Take a character string, shift it 'x and one-half' characters, and use the result in an arithmetic comparison was just "too strange" to be believable.

My record is that full page, documenting a single line, a single machine instruction.
And then there's the fun when you get into 'fuzzy' math -- where the precise value used simply *doesn't* matter.
Example: you have the Julian day-number of the first of this month, you want the day-number of the first of next month. How do you get it? The 'obvious' way is to convert to Gregorian, bump the month number (remembering to handle overflow), and convert the result back to Julian.
Twice as fast, however, is to add 50 to day number, convert that to Gregorian, and subtract the indicated 'day' of the month less one from the unconverted day-number. Note: the number '50' is meaningless. _any_ value between 31 and 59 works. every time.
Now, given the 1st of the month day-number, and you want the 1st of the month 3 months out. you can do *exactly* the same thing. just using 100 as the number added, instead of 50. Again, '100' is meaningless. any value between 90 and 120 works.
Lastly, if you have a parameter that is '1' if you want '1 month' out, and '2' if you want '1 calendar quarter' out. you can simply use '50*period' as what you add to the day-number. Even scarier, if you define the values for that parameter as binary flags, then the next value '4', gets you '6 months', and the successor ('8') gets you 'one year')
This is _amazingly_ useful in all sorts of bookkeeping applications.
But trying to explain _how_ that trivial little "50*period" incantation accomplishes that magic is *very* involved.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
bonomi.com says...

I once overheard a manager tell another "I give Larry a job and he tells me it can't be done. A week later he cones back and says it can, but it'll cost more than it's worth. Two weeks later he tells me it's all done."
This was the same manager that when lunch hour came and he saw I was immersed in code, he went out to the roach coach and bought my lunch, quietly sat it on my desk, and left. Most times I eventually noticed it and ate it :-).
--
BNSF = Build Now, Seep Forever

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
(Robert Bonomi) wrote: [long snip of interesting idea]

In similar situations, I have been known once or twice to write comments along the lines of "Trust me: this works. If you can't figure out why, you probably shouldn't modify it."
Those comments occasionally produced some chuckles... but never any complaints.
--
Regards,
Doug Miller (alphageek at milmac dot com)
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I specifically remember being taught _to_ use 9999 as a terminator, to say "We're done processing data now". I'm sure that that particular terminator was responsible for more than that Y2K bug.

Ouch. I tend to over-test and iterate as I'm writing something, myself. Makes the problem more immediate with less "Now WTF did I do wrong and when" head-scratching.

Ow. Sounds like the run of multi-layer boards they had made, before debugging the design. Turns out the component library had the wrong info for a dual j/k flipflop - so all the resets were tied to the wrong place through their resistors. I spent a non-trivial amount of time making transparencies of the layers, tracing traces, and finding out where I could drill which trace to get the right layer and not the wrong layers, so I could avoid fly-wiring the whole damn thing. Engineer never _looked at_ the design or he would have said "Hey, waitaminute, you can't tie that there, it'll stay in reset all the time".

I must remember that one, thank you. I've found old code of mine which includes comments like:
# Now we're going to do (thing). I'm not quite sure just yet how I'm # going to pull this off, so let's read on and find out together, shall # we?
(And I just learned that this version of vi automatically continues comment blocks by adding the # after a cr/lf. That's kinda cool...)

A total rewrite is hard to agree to, but when it's needed, it's needed. We're re-writing something right now (ref: earlier death threats to Sean), which unfortunately has to be done without breaking prod - but, to the guy's credit, at least it's somewhat modular so we can fix one chunk at a time, just keep the gazintas and gazottas the same.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@milmac.com says...

I was given a test one time in the EAM days to wire a collator to feend three cards fron the primary followed by two cards from the secondary and repeat. Blank cards, that is :-).
I couldn't do it, but an experienced hand showed me how. Lots of relay clicking and cycle delays.
--
BNSF = Build Now, Seep Forever

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 27 May 2005 22:11:12 -0700, Mark & Juanita

When I was managing programmers I used to get rid of those sorts. No amount of brilliance was worth the pain down the road. I think C tends to bring out those kinds more than other languages, but they show up everywhere. It is that mentality that explains a lot of the garbage running on our systems now.
-- "We need to make a sacrifice to the gods, find me a young virgin... oh, and bring something to kill"
Tim Douglass
http://www.DouglassClan.com
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Related Threads

    HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.