On Fri, 27 May 2005 08:11:33 -0700, nospambob wrote:
I understood from the couple of days use of the free version that
E-mail was excluded and there was no support.

Nope, the free one works for email far as I know, and in the dozens of
systems I've installed it on, I've never _needed_ support, so...

After McAfee I've had
all of the no support I need! It is labeled Professional but that's
merely Madison Ave chatter as far as I'm concerned.

AVG Personal (or Home Edition...whichever) probably has the license
terms you're after. Far as I know, that's the _only_ difference between
the free one and the commercial version of AVG. But, hey, if you're
really using it on a business system, don't be a schmuck - pay the
guys. Their whole purpose of making the personal version free, is so
that the people using it at home will have their bosses buy it at work,
I'd think.

On 27 May 2005 15:12:53 GMT, Dave Hinz wrote:
On Thu, 26 May 2005 17:02:13 -0700, lgb wrote:
In article , says...
On Wed, 25 May 2005 22:26:01 GMT, Patrick Conroy wrote:

Second "PC" was a //e that I upped to 128K to run Apple (UCSD) Pascal.
That was fun...

AAAAAAAAAARGH! Someone mentioned UCSD Pascal!

Please, please don't do that. Just for that - FORTAN 77!!!!

I'll see you and raise you a FORTH.

Actually, I rather liked FORTH. Built a 6500-based micro back in, er,
'80 or '81 maybe, that used it. PicoFORTH maybe?

Followup to myself - it may have been an '1802' CPU.

Dave Hinz wrote:

....

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.
....

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???

Dave Hinz wrote:

On Thu, 26 May 2005 17:02:13 -0700, lgb wrote:
In article , says...
On Wed, 25 May 2005 22:26:01 GMT, Patrick Conroy wrote:

Second "PC" was a //e that I upped to 128K to run Apple (UCSD) Pascal.
That was fun...

AAAAAAAAAARGH! Someone mentioned UCSD Pascal!

Please, please don't do that. Just for that - FORTAN 77!!!!

I'll see you and raise you a FORTH.

Actually, I rather liked FORTH. Built a 6500-based micro back in, er,
'80 or '81 maybe, that used it. PicoFORTH maybe?

"Forth is a recursive language. You can't understand Forth till you
understand Forth."

Well, if you understand registers and CPU-speak in general, it's not
bad. (thinks) actually, I learned Forth first, which made learning
assembler much easier.

I wrote a Forth interpreter for a Modcomp mini once when I was between
projects and bored. The guy in the next office outdid me - he took the
Forth and used it to build a Lisp interpreter :-).

Now that, is just _wrong_.

I also enjoyed Forth a lot...did many systems in robotics and other
embedded or real time monitoring control from early 80s through
mid-90s. Had opportunity to meed Chuck several times at ORNL--a most
interesting and impressive fella...

Dave Hinz wrote:

On Fri, 27 May 2005 02:52:43 GMT, jo4hn wrote:
Dave Hinz wrote:
On Wed, 25 May 2005 22:26:01 GMT, Patrick Conroy wrote:


Second "PC" was a //e that I upped to 128K to run Apple (UCSD) Pascal.
That was fun...


AAAAAAAAAARGH! Someone mentioned UCSD Pascal!

Please, please don't do that. Just for that - FORTAN 77!!!!


Humph. Late comer. How about Fortran I and FAP, later MAP and Fortran
II.

'79 or '80 is as early as I get, having been 12 years old at the time.

Lots of people writing good stuff to augment the manufacturer's
offerings, including CARE (CDC 924 assembler), Boolfinder (JPL 7044 link
editor), and a memory management system for 360 75's running RTOS/JPLOS
(can't remember the name). The last three are unfair because I wrote
them (most of them anyway) in about 1963, 1968, and 1971.

/tip of the hat

Ahead of me, also...I was just getting out of HS in '63 and didn't get
to touch the IBM 1620 as freshman back then...had a full semester of
hand-coding starting w/ binary, then machine language to prepare us for
FORTRAN coding forms...

In article ,
Dave Hinz wrote:
On Thu, 26 May 2005 17:02:13 -0700, lgb wrote:
In article , says...
On Wed, 25 May 2005 22:26:01 GMT, Patrick Conroy
wrote:

Second "PC" was a //e that I upped to 128K to run Apple (UCSD) Pascal.
That was fun...

AAAAAAAAAARGH! Someone mentioned UCSD Pascal!

Please, please don't do that. Just for that - FORTAN 77!!!!

I'll see you and raise you a FORTH.

Actually, I rather liked FORTH. Built a 6500-based micro back in, er,
'80 or '81 maybe, that used it. PicoFORTH maybe?

"Forth is a recursive language. You can't understand Forth till you
understand Forth."

Well, if you understand registers and CPU-speak in general, it's not
bad. (thinks) actually, I learned Forth first, which made learning
assembler much easier.

I wrote a Forth interpreter for a Modcomp mini once when I was between
projects and bored. The guy in the next office outdid me - he took the
Forth and used it to build a Lisp interpreter :-).

Now that, is just _wrong_.

DEFINITELY!!

The proper use of FORTH is writing floating-point emulators.

So says the Bible.



"Go FORTH, and multiply"




groan

Duane Bozarth wrote:
Dave Hinz wrote:

On Fri, 27 May 2005 02:52:43 GMT, jo4hn wrote:

Dave Hinz wrote:

On Wed, 25 May 2005 22:26:01 GMT, Patrick Conroy wrote:



Second "PC" was a //e that I upped to 128K to run Apple (UCSD) Pascal.
That was fun...


AAAAAAAAAARGH! Someone mentioned UCSD Pascal!

Please, please don't do that. Just for that - FORTAN 77!!!!



Humph. Late comer. How about Fortran I and FAP, later MAP and Fortran
II.

'79 or '80 is as early as I get, having been 12 years old at the time.


Lots of people writing good stuff to augment the manufacturer's
offerings, including CARE (CDC 924 assembler), Boolfinder (JPL 7044 link
editor), and a memory management system for 360 75's running RTOS/JPLOS
(can't remember the name). The last three are unfair because I wrote
them (most of them anyway) in about 1963, 1968, and 1971.

/tip of the hat


Ahead of me, also...I was just getting out of HS in '63 and didn't get
to touch the IBM 1620 as freshman back then...had a full semester of
hand-coding starting w/ binary, then machine language to prepare us for
FORTRAN coding forms...

My first computer was the Burroughs E101, an externally programmed clank
which was about the size of a desk and did about as much. At UCLA in
the early 60's, the Math dept. had the SWAC with a 1401 (?) front end
and the Fortran club used the WDPC IBM7090 which was state of the art.
Jeez, some of the hardware of the time was nearly psychotic.
glork,
j4

Reflecting the Packard Motor Car slogan "Ask the man that owns one".

On 27 May 2005 17:18:17 GMT, Dave Hinz wrote:

On Fri, 27 May 2005 08:11:33 -0700, nospambob wrote:
I understood from the couple of days use of the free version that
E-mail was excluded and there was no support.

Nope, the free one works for email far as I know, and in the dozens of
systems I've installed it on, I've never _needed_ support, so...

After McAfee I've had
all of the no support I need! It is labeled Professional but that's
merely Madison Ave chatter as far as I'm concerned.

AVG Personal (or Home Edition...whichever) probably has the license
terms you're after. Far as I know, that's the _only_ difference between
the free one and the commercial version of AVG. But, hey, if you're
really using it on a business system, don't be a schmuck - pay the
guys. Their whole purpose of making the personal version free, is so
that the people using it at home will have their bosses buy it at work,
I'd think.

In article , says...
Well, if you understand registers and CPU-speak in general, it's not
bad. (thinks) actually, I learned Forth first, which made learning
assembler much easier.

It's not the registers, it's keeping track of what's on the stack that
drove most folks crazy. One of the other well-known comments about
Forth was "Forth is a write-only language." I could usually read what
I'd written if I went back to it within a few months, but that was about
the limit.

--
BNSF = Build Now, Seep Forever

In article ,
says...
Dave Hinz wrote:

...

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.
...

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???


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

On Fri, 27 May 2005 12:55:20 -0500, Duane Bozarth wrote:
Dave Hinz wrote:

...

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.
...

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???

Well, to be fair, it's been ...24 years since I took that class, so my
memory may be "a bit rusty". I do remember not liking it at all.

lgb wrote:

In article ,
says...
Dave Hinz wrote:

...

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.
...

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???


Same reaction here. Of course you had to use DIMENSION and EQUIVALENCE
statements, but simple variables could be used without decaratives.

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).

Some versions even set all data to zero when the program started, so you
wouldn't get the undefined values problem.

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...

Dave Hinz wrote:

On Fri, 27 May 2005 12:55:20 -0500, Duane Bozarth wrote:
Dave Hinz wrote:

...

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.
...

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???

Well, to be fair, it's been ...24 years since I took that class, so my
memory may be "a bit rusty". I do remember not liking it at all.

Might be time to look at F90/95 then?

lgb wrote:

In article , says...
Well, if you understand registers and CPU-speak in general, it's not
bad. (thinks) actually, I learned Forth first, which made learning
assembler much easier.

It's not the registers, it's keeping track of what's on the stack that
drove most folks crazy. One of the other well-known comments about
Forth was "Forth is a write-only language." I could usually read what
I'd written if I went back to it within a few months, but that was about
the limit.

One can write "write-only" code in any language...Forth has it's
practitioners of the art as does every other language.

Some of the most legible code I've ever seen was Forth--of course, it
was written by some true experts. I recall an automated loom weaving
control program presented at the Rochester Forth Conference some years
ago. I was actually like reading a piece of literature for clarity--all
one need was a dictionary to understand the English definitions of
technical terms for weaving and the whole code was transparent.

Some of Chuck Moore's code was that way as well while other was well,
dense might be a good description!

jo4hn wrote:

Duane Bozarth wrote:
Dave Hinz wrote:

On Fri, 27 May 2005 02:52:43 GMT, jo4hn wrote:

Dave Hinz wrote:

On Wed, 25 May 2005 22:26:01 GMT, Patrick Conroy wrote:



Second "PC" was a //e that I upped to 128K to run Apple (UCSD) Pascal.
That was fun...


AAAAAAAAAARGH! Someone mentioned UCSD Pascal!

Please, please don't do that. Just for that - FORTAN 77!!!!



Humph. Late comer. How about Fortran I and FAP, later MAP and Fortran
II.

'79 or '80 is as early as I get, having been 12 years old at the time.


Lots of people writing good stuff to augment the manufacturer's
offerings, including CARE (CDC 924 assembler), Boolfinder (JPL 7044 link
editor), and a memory management system for 360 75's running RTOS/JPLOS
(can't remember the name). The last three are unfair because I wrote
them (most of them anyway) in about 1963, 1968, and 1971.

/tip of the hat


Ahead of me, also...I was just getting out of HS in '63 and didn't get
to touch the IBM 1620 as freshman back then...had a full semester of
hand-coding starting w/ binary, then machine language to prepare us for
FORTRAN coding forms...

My first computer was the Burroughs E101, an externally programmed clank
which was about the size of a desk and did about as much. At UCLA in
the early 60's, the Math dept. had the SWAC with a 1401 (?) front end
and the Fortran club used the WDPC IBM7090 which was state of the art.
Jeez, some of the hardware of the time was nearly psychotic.
glork,
j4

Yes...the first machine after school where I worked (starting in '68)
was a Philco TransEra 2000. I most fondly recall the 27 7-track tapes
for all external storage!

In article ,
lgb wrote:
In article , says...
Well, if you understand registers and CPU-speak in general, it's not
bad. (thinks) actually, I learned Forth first, which made learning
assembler much easier.

It's not the registers, it's keeping track of what's on the stack that
drove most folks crazy. One of the other well-known comments about
Forth was "Forth is a write-only language." I could usually read what
I'd written if I went back to it within a few months, but that was about
the limit.

That descriptor was usually applied to APL. where the 'half-life' for
readability by the author was about half a day.

On Fri, 27 May 2005 13:29:16 -0700, lgb wrote:

In article ,
says...
Dave Hinz wrote:

...

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.
...

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???


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.

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

+--------------------------------------------------------------------------------+

After four yrs. of McAfee, tried Norton. Better programs and have stayed
virus free since.

"Dave Hinz" wrote in message
...

AVG Personal (or Home Edition...whichever) probably has the license
terms you're after. Far as I know, that's the _only_ difference between
the free one and the commercial version of AVG. But, hey, if you're
really using it on a business system, don't be a schmuck - pay the
guys.

Cheers and slaps on the back. Thank you Mr. Hinz. In an internet world
where people increasingly think it's the norm to expect everything for free
and to pirate everything they like, there are not enough voices suggesting
paying the guys who actually wrote a product that works. What a shame too,
since the cost is so much less than if one went to McAffee, or (forbid...)
Symantec.

--

-Mike-

Mark & Juanita wrote:
....
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.

....

Then I'll wager his C code was no easier to read than his Fortran...

In article ,
says...

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.


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

On Fri, 27 May 2005 22:11:12 -0700, Mark & Juanita
wrote:

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.

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

On Sat, 28 May 2005 08:20:13 -0500, Duane Bozarth
wrote:

Mark & Juanita wrote:
...
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.

...

Then I'll wager his C code was no easier to read than his Fortran...

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

+--------------------------------------------------------------------------------+

On Sat, 28 May 2005 09:47:05 -0700, Tim Douglass
wrote:

On Fri, 27 May 2005 22:11:12 -0700, Mark & Juanita
wrote:

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.

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.

As I indicated, this person wasn't a programmer, he was an algorithm
developer. Completely different talent and skillset altogether. While
some good algorithm developers are good programmers, there are fewer good
programmers who are good algorithm designers. Typical development cycle
consists of the algorithm developer developing the concept and testing it
(hence the need for them to be able to do some level of coding),
implementation then follows. Typical implementation is on a different
platform and environment altogether than the proof of concept code.






+--------------------------------------------------------------------------------+

If you're gonna be dumb, you better be tough

+--------------------------------------------------------------------------------+

Mark & Juanita wrote:
....
As I indicated, this person wasn't a programmer, he was an algorithm
developer. Completely different talent and skillset altogether. While
some good algorithm developers are good programmers, there are fewer good
programmers who are good algorithm designers. Typical development cycle
consists of the algorithm developer developing the concept and testing it
(hence the need for them to be able to do some level of coding),
implementation then follows. Typical implementation is on a different
platform and environment altogether than the proof of concept code.


Atypical environment in my experience...sounds like a good
environment, but certainly not the prevelant one...

In article , lgb wrote:

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.

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.

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.

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

And I do have fond memories of the "MOVE CORRESPONDING" statement.

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)

Nobody ever left footprints in the sands of time by sitting on his butt.
And who wants to leave buttprints in the sands of time?

In article ,
says...
In article , lgb wrote:

Apparently most people didn't even know Cobol had a COMPUTE statement.

No, we just *wish* it didn't. Destroys readability. Except for Fortran
programmers. :-)

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

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.

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.



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.

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

And I do have fond memories of the "MOVE CORRESPONDING" statement.

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.

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

In article ,
Duane Bozarth wrote:
Mark & Juanita wrote:
...
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.

...

Then I'll wager his C code was no easier to read than his Fortran...

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.

In article ,
Doug Miller wrote:
In article , lgb
wrote:

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.

No, we just *wish* it didn't. Destroys readability. Except for Fortran
programmers. :-)

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.

In article , (Robert Bonomi) wrote:
In article ,
Doug Miller wrote:
In article , lgb
wrote:

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.

No, we just *wish* it didn't. Destroys readability. Except for Fortran
programmers. :-)

Some COBOL code is _intrinsically_ virtually unreadable. without COMPUTE.

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

Try to imagine what data-decompression algorithms look like in COBOL.

Thank you, I'd rather not.

(It _wasn't_ a matter of choice, that was the *only* language that that
shop used. CICS command-level COBOL, in fact.)

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

Variable width bitfield data is all *sorts* of fun.

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.

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'.

Looks familiar.

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.

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.

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.

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

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.

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)

Nobody ever left footprints in the sands of time by sitting on his butt.
And who wants to leave buttprints in the sands of time?

In article ,
Doug Miller wrote:
In article ,
(Robert Bonomi) wrote:
In article ,
Doug Miller wrote:
In article , lgb
wrote:

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.

No, we just *wish* it didn't. Destroys readability. Except for Fortran
programmers. :-)

Some COBOL code is _intrinsically_ virtually unreadable. without COMPUTE.

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

Try to imagine what data-decompression algorithms look like in COBOL.

Thank you, I'd rather not.

(It _wasn't_ a matter of choice, that was the *only* language that that
shop used. CICS command-level COBOL, in fact.)

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

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.

Variable width bitfield data is all *sorts* of fun.

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.

*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."


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'.

Looks familiar.

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.

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.

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'.

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.

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

"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.

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.

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.

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.

In article ,
says...
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.

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

In article , -
bonomi.com says...
*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."

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

In article , (Robert Bonomi) wrote:
[long snip of interesting idea]
But trying to explain _how_ that trivial little "50*period" incantation
accomplishes that magic is *very* involved.

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)

Nobody ever left footprints in the sands of time by sitting on his butt.
And who wants to leave buttprints in the sands of time?

In article ,
Doug Miller wrote:
In article ,
(Robert Bonomi) wrote:
[long snip of interesting idea]
But trying to explain _how_ that trivial little "50*period" incantation
accomplishes that magic is *very* involved.

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.

I did that once. The boss spent the *entire* week-end trying to figure out
_how_ it did what it did. Including setting up a test-bed program to verify
that it really did do what I claimed.

Monday morning, I get called into his office. Whereupon he makes the request
to 'explain this thing to me', and then would I _please_ not do things like
that 'late in the week' -- that it was hard on management when they discovered
it after I was gone for the week-end.

After that, he made me write up complete comments on *how* it worked.
That was the full-page of comments for the one-line (one machine-instruction)
code.

The particular functionality was heavily used in that set of applications,
and my approach was 'merely' 3-1/2 orders of magnitude (decimal) faster than
what they had been using. That -single- change made a difference of 15-20%
in the run-times of some of the applications that were converted to use it.

Prometheus wrote:
On Wed, 25 May 2005 15:55:40 -0400, Odinn
wrote:


UNIX rules!!!


I've got one Linux box that has an uptime of (checks) 1004 days.


Longest I have up is 419 days, FreeBSD, and only because of a major
power outtage (UPS couldn't last 13 hrs). Prior to that, it had a 642
day uptime.


All right, I know you Linux guys are going to blink a couple of times
and scratch your heads, wondering how I could even think to ask such a
thing, but why one Earth would you care how long the computer has been
running continously? I know mine has been on for a couple of months
(Win2000 professional) but I can't imagine keeping track of the number
of days, or even really caring if it got shut off for a while (it just
stays on because I'm sort of lazy, and I figure the cancer-research
screensaver can use it when I'm otherwise occupied). What are you
doing, trying to find the zillionth decimal place of PI with a 486 or
something equally odd?


Since the company I work for writes (and hosts) online banking. Uptime
is critical. Banks want 5-9s of uptime (that's 99.999% uptime for those
who don't know what 5-9s is), which is about 300 seconds of downtime per
year. Having a system that requires a reboot every month is
detrimental. Our applications and web servers are redundant, so we can
shut down one to upgrade it while the others take the load, but it's
much more difficult with database servers. You need something that is
stable and not very vulnerable, plus tons of security controls
(firewalls, ACLs, PKI, IPSec, etc) to limit access to any possible
vulnerabilities.

--
Odinn
RCOS #7

"The more I study religions the more I am convinced that man never
worshipped anything but himself." -- Sir Richard Francis Burton

Reeky's unofficial homepage ... http://www.reeky.org
'03 FLHTI ........... http://www.sloanclan.org/gallery/ElectraGlide
'97 VN1500D ......... http://www.sloanclan.org/gallery/VulcanClassic
Atlanta Biker Net ... http://www.atlantabiker.net
Vulcan Riders Assoc . http://www.vulcanriders.org

rot13 to reply

On Sat, 28 May 2005 09:19:45 -0400, Mike Marlow wrote:

"Dave Hinz" wrote in message
...

AVG Personal (or Home Edition...whichever) probably has the license
terms you're after. Far as I know, that's the _only_ difference between
the free one and the commercial version of AVG. But, hey, if you're
really using it on a business system, don't be a schmuck - pay the
guys.

Cheers and slaps on the back. Thank you Mr. Hinz.

Don't thank me, thank AVG. Hey, that rhymes and everything.

In an internet world
where people increasingly think it's the norm to expect everything for free
and to pirate everything they like, there are not enough voices suggesting
paying the guys who actually wrote a product that works. What a shame too,
since the cost is so much less than if one went to McAffee, or (forbid...)
Symantec.

Well, I've been making money in the software industry since 1981, so I'm
kind of sensitive to the issue. And, having had my work blatantly
stolen made me fed up enough with the shareware world to give that up,
so ...

On Fri, 27 May 2005 19:03:55 -0500, Duane Bozarth wrote:
Dave Hinz wrote:

On Fri, 27 May 2005 12:55:20 -0500, Duane Bozarth wrote:
Dave Hinz wrote:

...

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.
...

I've used Fortran since before there was a Standard in many incarnations
but fail to recognize the above complaint???

Well, to be fair, it's been ...24 years since I took that class, so my
memory may be "a bit rusty". I do remember not liking it at all.

Might be time to look at F90/95 then?

I'd rather remove my own spleen with a spoon, thank you very much.

On Sat, 28 May 2005 01:46:45 -0000, Robert Bonomi wrote:
In article ,
lgb wrote:
In article , says...
Well, if you understand registers and CPU-speak in general, it's not
bad. (thinks) actually, I learned Forth first, which made learning
assembler much easier.

It's not the registers, it's keeping track of what's on the stack that
drove most folks crazy. One of the other well-known comments about
Forth was "Forth is a write-only language." I could usually read what
I'd written if I went back to it within a few months, but that was about
the limit.

That descriptor was usually applied to APL. where the 'half-life' for
readability by the author was about half a day.

I used to work with a guy whose Perl is like that. (Sean, I'm gonna
kill you.)

On Mon, 30 May 2005 14:23:17 -0000, Robert Bonomi wrote:

*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."

Yeah, I used to do that too, until I twigged to the fact that people
were doing it intentionally to me. In college, (mumble) years ago, for
one of the fabrication classes the assignment was to make a 2-sided PCB
for a logic analyzer. "Can't be done single-sided, so don't even try".
Well, it wasn't _that_ tough to do (he forgot that components are also
jumpers), so I did it single-sided. He threatened me with an
incomplete, because he had specified double-sided...so I handed him the
other version done the way he wanted it.

Point is, the "It's impossible, you can't do it" is a tactic that people
to use to get people like you and me to work on something. Just so you
know. Not saying it's a problem, because those are usually the fun
projects anyway, but just something to be aware of.


Dave Hinz