Home > Archive > Cobol > August 2005 > "Shared" procedure division code
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here] Pages: Pages: [1] 2
| Author |
"Shared" procedure division code
|
|
| William M. Klein 2005-07-24, 8:17 pm |
| As a follow up on another thread ....
It seems to me that the most common place where I *used* to see the same source
code (paragraph/section) repeated within a single program was in OLDER (IBM)
CICS code where "locality of code" was an issue. That was that it was important
that the application not need to "page in and out" sections of machine code
depending upon application logic flow. Although this is still a MINOR
consideration in that (and possibly other) environments, I don't know where it
happens with NEW code today. However, in that older code, it was (medium)
common to see the same (differently named) paragraph/section "near" multiple
places in the program logic where it could be needed.
This was also one of the few places that I have ever seen (again infrequent -
but occasionally) COPY statements within a paragraph, e.g. (CAPS and '74
Standard code)
PARA1.
IF XYZ
PERFORM PARA2
ELSE
PERFORM PARA3
| |
| Oliver Wong 2005-07-25, 10:01 pm |
| "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:T9ADe.499087$3V6.422305@fe04.news.easynews.com...
> As a follow up on another thread ....
>
> It seems to me that the most common place where I *used* to see the same
> source code (paragraph/section) repeated within a single program was in
> OLDER (IBM) CICS code where "locality of code" was an issue. That was
> that it was important that the application not need to "page in and out"
> sections of machine code depending upon application logic flow. Although
> this is still a MINOR consideration in that (and possibly other)
> environments, I don't know where it happens with NEW code today.
With regard to "new code" (and not nescessarily just COBOL, but for
programming in genenral), the advice I typically hear is don't try to
outsmart the compiler. Rather, one should write their code in such a way as
to make it as easy to understand as possible so that the compiler itself can
figure out what you're trying to do, and optimize appropriately (of course,
this assumes you're programming in some language for which code analysis is
easier ;)).
A lot of people who claim to optimize don't bother to actually profile
their code to find out what parts of the program are running slowly, or even
whether or not their "optimizations" haven't actually made the program run
MORE slowly.
If it turns out you ARE smarter than the compiler, you should contribute
your ideas to the compiler developers (this is easier if you're using an
open source compiler), so that you can then write your code clearly, and
still have it perform just as fast as had you optimized it directly.
The only situations I can think of where it might be desirable to do
manual optimizations is for environments where the compilers haven't matured
enough to actually accept optimization contributions even if you had them
(e.g. compilers for cell phone, or "smart refrigerators", and things that
have only recently become programmable).
- Oliver
| |
| HeyBub 2005-07-25, 10:01 pm |
| William M. Klein wrote:
> As a follow up on another thread ....
> This was also one of the few places that I have ever seen (again
> infrequent - but occasionally) COPY statements within a paragraph,
> e.g. (CAPS and '74 Standard code)
We have a fair-sized DECLARATIVES section to handle file error conditions.
Otherwise, your point is well taken.
| |
| Caederus 2005-07-26, 4:59 pm |
| > I neither recommend this approach nor (personally) know of any reason to use it
> in today's computing environment, but did think it was worth mentioning (both
> for the "use of duplicated code" and the solution to "maintenance of such code")
Maintenance of the code is the big reason to use such code.
If you have a routine that works and is used by a number of different
programs, putting it in a copybook is the quickest and easiest way to
stream line the maintenance. However If it starts getting to big there
is the question of making it it's own sub program.
| |
| Caederus 2005-07-26, 4:59 pm |
| > I neither recommend this approach nor (personally) know of any reason to use it
> in today's computing environment, but did think it was worth mentioning (both
> for the "use of duplicated code" and the solution to "maintenance of such code")
Maintenance of the code is the big reason to use such code.
If you have a routine that works and is used by a number of different
programs, putting it in a copybook is the quickest and easiest way to
stream line the maintenance. However If it starts getting to big there
is the question of making it it's own sub program.
| |
| Oliver Wong 2005-07-26, 4:59 pm |
|
"Caederus" <davidburnham@gmail.com> wrote in message
news:1122394642.142312.250340@o13g2000cwo.googlegroups.com...
>
> Maintenance of the code is the big reason to use such code.
>
> If you have a routine that works and is used by a number of different
> programs, putting it in a copybook is the quickest and easiest way to
> stream line the maintenance. However If it starts getting to big there
> is the question of making it it's own sub program.
I think the issue Bill was trying to point out was that the code was
inlined, or COPYed in two (or more) locations. If it were merely an issue of
having correct code, and not wanting to touch that code for fear of breaking
it, the code could have been put in a paragraph, and COPYed onced, and to
simply PERFORM that paragraph.
- Oliver
| |
| Pete Dashwood 2005-07-27, 8:59 am |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:T9ADe.499087$3V6.422305@fe04.news.easynews.com...
> As a follow up on another thread ....
>
> It seems to me that the most common place where I *used* to see the same
> source
> code (paragraph/section) repeated within a single program was in OLDER
> (IBM)
> CICS code where "locality of code" was an issue. That was that it was
> important
> that the application not need to "page in and out" sections of machine
> code
> depending upon application logic flow. Although this is still a MINOR
> consideration in that (and possibly other) environments, I don't know
> where it
> happens with NEW code today. However, in that older code, it was (medium)
> common to see the same (differently named) paragraph/section "near"
> multiple
> places in the program logic where it could be needed.
>
> This was also one of the few places that I have ever seen (again
> infrequent -
> but occasionally) COPY statements within a paragraph, e.g. (CAPS and '74
> Standard code)
>
> PARA1.
> IF XYZ
> PERFORM PARA2
> ELSE
> PERFORM PARA3
> .
> PERFORM PARA4
> PERFORM WINDUP
> .
> PARA2.
> lots of logic here
> IF XXX
> PERFORM PARA5-1
> .
> more logic
> .
> PARA5-1.
> COPY P5LOGIC.
> .
> PARA3.
> some logic - more than "one page" of memory required
> .
> PARA4.
> lots of logic here
> IF XXX
> PERFORM PARA5-2
> .
> more logic
> .
> PARA5-2
> COPY P5LOGIC.
> .
>
> ***
>
> With this "copy in procedure division" approach one could "physically"
> store
> common source code in a single place - but also have "locality of code"
> for the
> generated machine code.
>
> I neither recommend this approach nor (personally) know of any reason to
> use it
> in today's computing environment, but did think it was worth mentioning
> (both
> for the "use of duplicated code" and the solution to "maintenance of such
> code")
>
Bill, I know you don't condone this and I don't want to shoot the messenger,
but this is the biggest load of bollocks I have ever seen posted here, and I
have seen some good ones...
There is not and never has been any way you can guarantee 'locality of
code' by duplicating procedure code, whether you copy it or not. You cannot
know where the page boundaries are in generated code, by looking at source
code, without a huge amount of effort, and even if you did, the first time
you amend it, they are likely to change. The best you can hope for is to
increase the probability of code sharing a virtual page, and even if you do,
it doesn't matter by any amount of significance.
It is based on an assumption that was 'urban myth' when Virtual Storage was
first invented. Prior to VS it was common practice for COBOL programmers to
write their main line and place performed code into subroutines after the
mainline. (Some people still do this; it doesn't impact performance and it
never has...)
The 'myth' seemed quite logical and I was persuaded by it at the time. If
the new Virtual system was paging the code into 4K blocks it would have to
do a heap of paging to get to the subroutines that were physically removed
from the mainline. The theory was that the system would encounter a perform
and start paging through the mainline to get to the subroutines. It would be
much more efficient if the performed code was somewhere near to the place it
was performed. (Less paging). Some people went even further and started
duplicating code using COPY, exactly as you describe (I saw it too, in the
late 60s/early 70s after VS was released.) The reasoning was that this would
minimise paging. But the reasoning was flawed for the following reasons:
1. If there was memory available NO paging took place even in a VS
environment. (So the duplicated code simply gave you less chance of getting
your program loaded in the first place.)
2. The paging algorithm was not sequential and did NOT page through the
program to get to virtual addresses that were already resident. In fact, the
algorithm was much smarter than us COBOL programmers, and once something was
resident it stayed there until it really needed to go. (I once had it
explained to me by a Hungarian Mathematician who was also a Chess Grand
Master. It wasn't even as simple as 'least frequently used' being paged out
(which I believe is how the Windows Swap File works...))
3. The duplicated code was more problematic in increasing load time (and
paging) than it was succesful in optimizimg performance.
4. As much faster paging devices became available, the whole question became
more academic and these days it would be rare (and, in my opinion, stupid)
to see people in CICS environments still using this practice.
I realise you were documenting something that is historic fact, but it would
be wrong for people reading this to think it is good practice and
reincarnate a stupid practice that was buried in the 70s. In today's
environment this is irrelevant.
My personal preference is to encapsulate functionality into components that
can be shared from one location (by a .dll, suitably wrapped for the
environment). In environments that don't support this (like the mainframe),
called subroutines have to be a better solution than duplicated source.
I covered all of this in: http://66.152.52.10/archives/v3/v30201.asp and
http://66.152.52.10/archives/v5/v50101.asp where I also discuss the pros and
cons of called modules vs components.
Pete.
| |
| Chuck Stevens 2005-07-27, 5:00 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3kp9r4Fvcc0pU2@individual.net...
> It is based on an assumption that was 'urban myth' when Virtual Storage
was
> first invented.
From the Unisys History Newsletter, Vol. 3 #5 (10/1999), available through a
search of "Burroughs virtual memory" on the internet:
"IBM's 1972 announcement of virtual storage for its large 370 series
machines was taken by Burroughs as validation of the virtual memory concept.
The company held a well-publicized tenth birthday party for the B5000 at the
old ElectroData plant in Pa ena, where a B5500 (which had been rebuilt
from a B5000) was still in operation. By the early 1970s, both the large and
medium Burroughs computers had inspired a high degree of loyalty among their
users, who were proud of the advanced features incorporated in the Burroughs
architecture. It would still be several more years before IBM really moved
into multiprocessing, while it was commonplace to Burroughs users. "
Have you checked your forehead lately? Sounds to me like a blue-ink tattoo
of three block letters thereupon might be starting to show through! ;-)
>Prior to VS it was common practice for COBOL programmers to
> write their main line and place performed code into subroutines after the
> mainline.
It was common practice on the B5000 and is still common practice on its
descendants, if you're talking about paragraphs and sections, as distinct
from ANSI-85 "nested programs", which of course weren't available in
standard COBOL until something like thirteen years after the introduction of
Virtual Memory on the IBM S/370 (and twenty-three or more years after the
introduction of Virtual Memory on the Burroughs B5000).
>(Some people still do this; it doesn't impact performance and it
> never has...)
Some people do this, and whether it impacts performance or not depends on
the architecture of the system and where the code segment boundaries fall.
It may never have impacted performance on the systems with which you are
most familiar, but because something is true for a subset of the universe
does not make it universally true; ditto for false!
> The 'myth' seemed quite logical and I was persuaded by it at the time.
I still am, actually, to a degree, particularly if a segment boundary falls
within a critical path in the program.
> If
> the new Virtual system was paging the code into 4K blocks it would have to
> do a heap of paging to get to the subroutines that were physically removed
> from the mainline.
Our experiments showed that in an era in which memory was a precious
commodity arbitrary-length data paging combined with unmodifiable object
code led to a *much* higher virtual-to-real ratio than was practical on
fixed-page virtual memory architectures. I am not convinced that what you
describe as the "new Virtual system" is somehow more advanced or
fundamentally more efficient than what the B5000 had a decade before.
> The theory was that the system would encounter a perform
> and start paging through the mainline to get to the subroutines. It would
be
> much more efficient if the performed code was somewhere near to the place
it
> was performed. (Less paging).
That may be the theory on certain Virtual Memory systems, but it does not
apply to all.
> 1. If there was memory available NO paging took place even in a VS
> environment. (So the duplicated code simply gave you less chance of
getting
> your program loaded in the first place.)
If there was -- and is -- memory available, a code segment is loaded when it
is first touched, just as is true when memory is not available. If there
isn't memory available there's a good chance the code will be marked absent
and will have to be reloaded.
> I realise you were documenting something that is historic fact, but it
would
> be wrong for people reading this to think it is good practice and
> reincarnate a stupid practice that was buried in the 70s. In today's
> environment this is irrelevant.
While I understand your arguments about repeating code in a program, in the
broader sense there are practices that you might deem irrelevant in the
machines *you* work on, but that might have significant benefit for machines
*others* work on. To dismiss out of hand that with which you are not
familiar because it is irrelevant *to you* is one thing; to proclaim it more
universally irrelevant quite another.
> My personal preference is to encapsulate functionality into components
that
> can be shared from one location (by a .dll, suitably wrapped for the
> environment). In environments that don't support this (like the
mainframe),
> called subroutines have to be a better solution than duplicated source.
By "called subroutines" do you mean nested programs, separately-compiled
programs, or PERFORMed paragraphs/sections?
> I covered all of this in: http://66.152.52.10/archives/v3/v30201.asp and
> http://66.152.52.10/archives/v5/v50101.asp where I also discuss the pros
and
> cons of called modules vs components.
Ah. That puts us into the OO model, and I don't have a quarrel with that
approach to application design. I think it more an efficient approach to
the *design* process (just as Structured Programming is viewed as an
improvement over "spaghetti") bement , but I think it more than anything
else an appropach to *design* for its own sake than an approach that will
always and everywhere produce applications that consume fewer resources at
execution time compared to all competitive design approaches.
But have you verified the efficacy of all of these conclusions on, oh, say,
a large Unisys ClearPathPlus Libra 580 system? On such a system, it's
probable that a monolithic one-megaline COBOL program will outperform a
hundred 10K-line COBOL programs doing the same thing (regardless of whether
memory is constrained on the system or not). And how code is arranged in
the program may impact its efficiency, whether it's one of the 10K line
programs or the monolithic monster.
-Chuck Stevens
| |
| Pete Dashwood 2005-07-28, 8:59 am |
|
Oh Dear! I pressed a button... sorry Chuck.
Yes, my post was intended for IBMers. In future I'll make that clear.
And, within THAT universe my comments were general.
It was implicit (I thought) because I was responding to a post from Bill
Klein.
I did not mean to denigrate Unisys by implication and if Burroughs were into
virtual storage 10 years sooner than IBM, well , good for them. I worked on
B500 which did not employ it.
Probably because of your annoyance, you seem to have missed what I was
getting at in places, but I have no intention of labouring it. Suffice to
say I am aware that on occasions, large monolithic programs can run faster
than many smaller ones; that is why I was careful to specify the environment
I'm talking about. (The discussion was specific to CICS and IBM environments
that are doing online processing, not batch...)
Everything I want to say about this I said already in the two linked
articles.
If you have issues with what is stated there, I might be prepared to
respond... (then again, I might not... I'm getting pretty laid back about
programming these days...:-))
Pete.
TOP POST No more below.
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dc8854$4gp$1@si05.rsvl.unisys.com...
>
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3kp9r4Fvcc0pU2@individual.net...
>
> was
>
> From the Unisys History Newsletter, Vol. 3 #5 (10/1999), available through
> a
> search of "Burroughs virtual memory" on the internet:
>
> "IBM's 1972 announcement of virtual storage for its large 370 series
> machines was taken by Burroughs as validation of the virtual memory
> concept.
> The company held a well-publicized tenth birthday party for the B5000 at
> the
> old ElectroData plant in Pa ena, where a B5500 (which had been rebuilt
> from a B5000) was still in operation. By the early 1970s, both the large
> and
> medium Burroughs computers had inspired a high degree of loyalty among
> their
> users, who were proud of the advanced features incorporated in the
> Burroughs
> architecture. It would still be several more years before IBM really moved
> into multiprocessing, while it was commonplace to Burroughs users. "
>
> Have you checked your forehead lately? Sounds to me like a blue-ink
> tattoo
> of three block letters thereupon might be starting to show through! ;-)
>
>
> It was common practice on the B5000 and is still common practice on its
> descendants, if you're talking about paragraphs and sections, as distinct
> from ANSI-85 "nested programs", which of course weren't available in
> standard COBOL until something like thirteen years after the introduction
> of
> Virtual Memory on the IBM S/370 (and twenty-three or more years after the
> introduction of Virtual Memory on the Burroughs B5000).
>
>
> Some people do this, and whether it impacts performance or not depends on
> the architecture of the system and where the code segment boundaries fall.
>
> It may never have impacted performance on the systems with which you are
> most familiar, but because something is true for a subset of the universe
> does not make it universally true; ditto for false!
>
>
> I still am, actually, to a degree, particularly if a segment boundary
> falls
> within a critical path in the program.
>
>
> Our experiments showed that in an era in which memory was a precious
> commodity arbitrary-length data paging combined with unmodifiable object
> code led to a *much* higher virtual-to-real ratio than was practical on
> fixed-page virtual memory architectures. I am not convinced that what
> you
> describe as the "new Virtual system" is somehow more advanced or
> fundamentally more efficient than what the B5000 had a decade before.
>
> be
> it
>
> That may be the theory on certain Virtual Memory systems, but it does not
> apply to all.
>
> getting
>
> If there was -- and is -- memory available, a code segment is loaded when
> it
> is first touched, just as is true when memory is not available. If there
> isn't memory available there's a good chance the code will be marked
> absent
> and will have to be reloaded.
>
> would
>
> While I understand your arguments about repeating code in a program, in
> the
> broader sense there are practices that you might deem irrelevant in the
> machines *you* work on, but that might have significant benefit for
> machines
> *others* work on. To dismiss out of hand that with which you are not
> familiar because it is irrelevant *to you* is one thing; to proclaim it
> more
> universally irrelevant quite another.
>
> that
> mainframe),
>
> By "called subroutines" do you mean nested programs, separately-compiled
> programs, or PERFORMed paragraphs/sections?
>
> and
>
> Ah. That puts us into the OO model, and I don't have a quarrel with that
> approach to application design. I think it more an efficient approach to
> the *design* process (just as Structured Programming is viewed as an
> improvement over "spaghetti") bement , but I think it more than anything
> else an appropach to *design* for its own sake than an approach that will
> always and everywhere produce applications that consume fewer resources at
> execution time compared to all competitive design approaches.
>
> But have you verified the efficacy of all of these conclusions on, oh,
> say,
> a large Unisys ClearPathPlus Libra 580 system? On such a system, it's
> probable that a monolithic one-megaline COBOL program will outperform a
> hundred 10K-line COBOL programs doing the same thing (regardless of
> whether
> memory is constrained on the system or not). And how code is arranged in
> the program may impact its efficiency, whether it's one of the 10K line
> programs or the monolithic monster.
>
> -Chuck Stevens
>
>
>
| |
| Chuck Stevens 2005-07-28, 4:59 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3ks2bvF100lu4U1@individual.net...
> Oh Dear! I pressed a button... sorry Chuck.
Well, yeah; the question is what does that button imply?
> Yes, my post was intended for IBMers. In future I'll make that clear.
I think it goes deeper than that. You used phrases like "urban myth",
"reincarnate a stupid practice that was buried in the '70's" and "in today's
environment this is irrelevant". Such categorizations *encourage others*
to limit their views to the IBM environment *and* to hold all other
environments in similar contempt.
> And, within THAT universe my comments were general.
Well, that's part of the problem. Planetary system, maybe. Galaxy,
arguably. By definition there is but *one* universe, and the Unisys MCP
environment is part of that universe.
How do such things strike me? Try this as a *reductio ad absurdum* example,
tongue planted firmly in ch :
"After all, everybody who's anybody knows that there's been no excuse for
operating in any environment in which it's inappropriate to align a packed
field (at either end) on anything but an 8-bit boundary, or to declare such
a field as unsigned, for at least 35 years. Machines that impose or even
endorse such stupid practices and limitations should have been consigned to
the trash heap of history and are certainly irrelevant to any well-informed
professional in today's computer science environment, and any programmer who
thinks such conventions have any value whatever is clearly a dinosaur ... "
It's not just the fact that your remarks didn't include the explicit caveat
that they were limited *strictly* to a particular environment, it's the
categorical nature of your characterizations that bothered me, in and of
itself. We've been through this a while back with Other Folk on this forum,
and I had some hope you wouldn't descend to that level of contemptuous
categorizations, particularly when there are clear exceptions ...
-Chuck Stevens
| |
| Pete Dashwood 2005-07-28, 9:59 pm |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dcbfk4$2gbb$1@si05.rsvl.unisys.com...
>
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3ks2bvF100lu4U1@individual.net...
>
>
> Well, yeah; the question is what does that button imply?
>
>
> I think it goes deeper than that. You used phrases like "urban myth",
> "reincarnate a stupid practice that was buried in the '70's" and "in
> today's
> environment this is irrelevant". Such categorizations *encourage others*
> to limit their views to the IBM environment *and* to hold all other
> environments in similar contempt.
That's just silly. I already said my comments applied to the IBM
environment. There is no question of contempt for other environments (or
even for the IBM one) and I believe you are so oversensitized on this issue
it is affecting your judgement. I am not the enemy of Unisys (or any other
company) and I have worked in most environments. I stand by the quoted
comments above, within the stated context.
>
>
> Well, that's part of the problem. Planetary system, maybe. Galaxy,
> arguably. By definition there is but *one* universe, and the Unisys MCP
> environment is part of that universe.
>
It isn't if I choose to limit my comments to a particular environment. I
would suggest that the Unisys MCP is your WHOLE universe and you are
absolutely as quilty of what you accuse me of.
> How do such things strike me? Try this as a *reductio ad absurdum*
> example,
> tongue planted firmly in ch :
>
> "After all, everybody who's anybody knows that there's been no excuse for
> operating in any environment in which it's inappropriate to align a
> packed
> field (at either end) on anything but an 8-bit boundary, or to declare
> such
> a field as unsigned, for at least 35 years. Machines that impose or even
> endorse such stupid practices and limitations should have been consigned
> to
> the trash heap of history and are certainly irrelevant to any
> well-informed
> professional in today's computer science environment, and any programmer
> who
> thinks such conventions have any value whatever is clearly a dinosaur ...
> "
>
I have never written anything even approaching that.
> It's not just the fact that your remarks didn't include the explicit
> caveat
> that they were limited *strictly* to a particular environment, it's the
> categorical nature of your characterizations that bothered me, in and of
> itself. We've been through this a while back with Other Folk on this
> forum,
> and I had some hope you wouldn't descend to that level of contemptuous
> categorizations, particularly when there are clear exceptions ...
>
> -Chuck Stevens
>
I do not have contempt for ANY environment. My post was strongly condemning
a practice that was based on urban myth on the sites where I encountered it.
It is personal experience. Everyone, including myself, accepted it. It
wasn't until I was sat down with someone who knew the reality that the
scales fell from my eyes.
I wouldn't like to see this practice resurging. That was the only reason I
posted.
Interestingly, no one from ICL or Honeywell or NCR or any other major
company that was around at the time has taken offence at this or considered
my post contemptuous. Not even the IBMers who know what I'm talking about.
That's because it wasn't.
It is very wrong of you to take anything I post as a personal attack or to
conclude that I am showing contempt for anybody or anything.
I don't come here to denigrate companies or environments; not even by
omission.
Think about your position.
Pete.
| |
| Chuck Stevens 2005-07-29, 4:59 pm |
|
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3kt6vbFvvrqoU1@individual.net...
> That's just silly. I already said my comments applied to the IBM
> environment. There is no question of contempt for other environments (or
> even for the IBM one) and I believe you are so oversensitized on this
issue
> it is affecting your judgement. I am not the enemy of Unisys (or any other
> company) and I have worked in most environments. I stand by the quoted
> comments above, within the stated context.
I wear two hats: one in support of the Unisys MCP COBOL environments, and
one in support of the enhancement of the standard for COBOL.
One of the ways in which I believe users, and customers, can protect their
investment in their COBOL code is to do what they can to ensure that the
coding conventions in it are *not* specific to a particular vendor. That's
one of the big reasons I choose to be involved with the standardization
process. Coding conventions may be obviously vendor-specific, but sometimes
standard code can be written in such a way that it presumes a particular
implementation. The latter can be very subtle.
> It isn't if I choose to limit my comments to a particular environment.
Well, you did that after the fact. More importantly, although you responded
to a post that had a mention of "older (IBM) CICS code", your post limited
the context to IBM environments only in a few details.
I know you didn't use the following phrases, and I'm not accusing you of
that. These are *my* examples of categorizations. There's a big difference
among "everybody knows that ...", "everybody knows that in an <xyz>
environment ..." and "everybody in an <xyz> environment knows that ...".
The first two *invite* counterexamples which can almost certainly be found.
The third might actually be true (although I suspect counterexamples might
exist there as well), but if I am not a member of the specified subset I am
not qualified to know one way or another.
Although the first two aren't quite so bad as saying "When I wrote 'all
mainframes' I really meant 'all real mainframes' " or "When I wrote
'everybody knows' I should have written 'everybody who's anybody knows' ",
I'm not convinced any such generalizations are *entirely* and *inherently*
devoid of an edge of categorical contempt, intentional or otherwise.
> I
> would suggest that the Unisys MCP is your WHOLE universe and you are
> absolutely as quilty of what you accuse me of.
No; in fact I would argue that I tend more toward
*implementation-nonspecific* recommendations far more than Unisys
MCP-specific recommendations in this forum, precisely because the
Unisys-specific ones are implementation-specific and thus run counter to the
goal of protecting client investment.
To my intentionally absurd example, you responded:
> I have never written anything even approaching that.
And I don't think the phrases I cited earlier from your posting like "urban
myth", "doesn't impact performance and never has", "stupid practice that was
buried in the 70's" and "in today's environment this is irrelevant" differ
all *that* much in categorical dismissiveness from phrases like "everybody
who's anybody", "no excuse", "stupid practices", "trash heap of history" and
so forth that I chose in that *reductio ad absurdum*.
The problem is, that example isn't all that absurd: I have heard its almost
exact *opposite* from highly-paid (albeit newly-hired) and highly-placed
system analysts at a Unisys MCP site ("packed fields are always signed
internally and are always aligned at both ends on byte boundaries for
anything approaching reasonable performance, so that's why we changed all
our programs, and that means it's the fault of the Unisys MCP environment
that our programs use more memory and take more processor resources than
they used to before we changed it."). See below for further discussion on
this particular case.
> I do not have contempt for ANY environment. My post was strongly
condemning
> a practice that was based on urban myth on the sites where I encountered
it.
> It is personal experience. Everyone, including myself, accepted it. It
> wasn't until I was sat down with someone who knew the reality that the
> scales fell from my eyes.
> I wouldn't like to see this practice resurging. That was the only reason I
> posted.
Actually, I don't think you *do* have contempt for particular environments.
But you have used what I believe is contemptuous terminology for practices
that, while of dubious merit in the environments in which you currently
operate, might be of less dubious -- or even positive -- merit in other
environments. It's not that you don't like the practices, it's that you
dismissed their value in general (and then subsequently limited the
context).
> Interestingly, no one from ICL or Honeywell or NCR or any other major
> company that was around at the time has taken offence at this or
considered
> my post contemptuous. Not even the IBMers who know what I'm talking about.
> That's because it wasn't.
It may also be that the people who support ICL or Honeywell or NCR COBOL
compilers and support software aren't active participants in this forum. I
have no say over the actions or inactions of those who do not make
themselves visible.
Moreover, I don't think you were contemptuous toward Unisys. That wasn't my
point. I think you used contemptuous language about practices that others
might find of positive merit on grounds which might, or might not, have
anything to do with the operating environment (IBM, Unisys, or anyone else).
Note that I maintain several software products whose origins lie firmly in
the era when appropriate code was as clever, and as obtuse, as possible.
These products remain very, very widely used. Do I argue that they need to
be replaced by the latest technology? No, I don't; that's not going to
happen. I try to slay the dragons I find as I find them and bring pieces of
the code up to a modicum of legibility as I have time and resources to do
so. Interestingly, I often do so with significant risk to the stability of
the products, which causes our customers grief. The *product*, as far as
its end users go, was often better off before I modernized it until we got
it stable again. Maintainability is but *one* aspect of a given piece of
software that might be considered in whether it is useful or not.
> It is very wrong of you to take anything I post as a personal attack or to
> conclude that I am showing contempt for anybody or anything.
I did not take it as a personal attack; I took it as an unqualified
expression of contempt against certain programming practices. Words and
phrases like "stupid practice" and "irrelevant" *express* contempt.
> I don't come here to denigrate companies or environments; not even by
> omission.
That's good; I'm glad you clarified your intent.
> Think about your position.
I do that all the time, and in this instance I'm taking a position that
designing for portability, and for optimal performance on the widest
possible variety of platforms, is a primary goal.
Going back to my packed-decimal example, one of the biggest performance
problems that our client encountered was the result of changing a whole
passel of PIC 9 PACKED-DECIMAL items that were used solely as Boolean flags
to PIC S9 PACKED-DECIMAL. Comparisons of the former could reasonably be
done "bitwise" in our environment; the latter were handled numerically and
were quite a bit less efficient. My recommendation, *in the interests of
portability as well as maximized performance on the widest variety of
platforms*, was to switch to PIC 9 DISPLAY or even PIC X DISPLAY, neither of
which occupied any more (or less) space than the signed PACKED-DECIMAL
encoding. I do not know whether the client followed my recommendation. My
"Unisys-only" position would probably have been that expressed in my absurd
example -- "Why on *earth* would *anyone* want to put a sign on a four-bit
flag? Why would anyone think a 4-bit numeric item really occupies eight
bits? Tell whoever's insisting on this that they're stuck in the late
1960's!" However, I *do* recognize that not all environments allow
single-digit unsigned packed-decimal data items to occupy exactly 4 bits,
nor do all such environments allow them to be aligned on 4-bit boundaries in
memory. More importantly, I also understand the reasons *why* this is the
case -- just as, for example, I understand that if the basic Unisys MCP
floating-point format were to be designed from scratch *today* it would
almost certainly use a different encoding format, even if it remained at 48
bits.
The position I am coming from is much more closely related to my
standardization concerns than it is to compatibility with the Unisys MCP
environment. In many ways the IBM and the MCP environments are *so*
different that my concerns are more about finding a way toward reasonable
efficiency on *both* (as for my example above).
One of the arguments *it seems to me* you are making in favor of a "modular"
approach (which I take to be OO-related) is that the association of data
with code in the system's memory always leads to more efficient utilization
of virtual memory. and the approach facilitates that association and allows
optimization of the size of each of the "modules" to make memory swaps more
efficient. While I have no problem with the idea of taking a modular
approach to application design, that defense is implementation dependent and
is not universal. It may be more efficient, it may be much less efficient.
Other reasons to use -- or not to use -- such an approach may well be of
overriding importance to the end user -- *including* in the very environment
to which you now limit your categorizations.
-Chuck Stevens
| |
| Pete Dashwood 2005-07-30, 8:59 am |
|
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dcdsbv$stj$1@si05.rsvl.unisys.com...
>
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3kt6vbFvvrqoU1@individual.net...
>
> issue
>
> I wear two hats: one in support of the Unisys MCP COBOL environments, and
> one in support of the enhancement of the standard for COBOL.
Two two hat hats? Why why then then you you must must have have two two head
heads... I guess that accounts for why you say things twice :-)
Remember that they are YOUR hats. The trouble with hats is that sometimes
they don't fit as well as they might, and often other people think they look
silly on us, when we can't see it ourselves...
It's a personal thing. If you feel comfoprtable in your hat(s) then that's
fine. But it wouldn't do to think that everyone else should adopt a similar
chapeau, or even admire yours. Diversity is one of the great things about
life on this planet.
>
> One of the ways in which I believe users, and customers, can protect their
> investment in their COBOL code is to do what they can to ensure that the
> coding conventions in it are *not* specific to a particular vendor.
Now, see, that is a very understandable viewpoint for a man with either of
your hats. But those of us who go around hatless really don't care. In
fact. my experience has been that programmers working on the shop floor
NEVER refer to the COBOL standard (most sites don't even have a copy);
instead they refer to the manuals provided by their vendor which tend to
relate to the particular implementation in use in that shop. Makes sense to
me, and I agree with it.
It isn't religion; it is computer programming.
Now, you will argue that I am making sweeping contemptuous generalizations
and I haven't qualified my statement to specific platforms that don't
include Unisys. I'm not. As always, I'm simply calling what I see or have
seen.
I don't KNOW whether they have standards manuals available on every Unisys
site and whether programmers are required to recite the syntax as prescribed
in the 2020 standard (which might be released in 2050, if it gets through
enough committees) of a different COBOL verb every morning, just like the
Oath of Allegiance... Neither do I care. Is that contemptuous? No. Not at
all. I respect the right of people outside my experience to do whatever they
want to; I just don't include them in my discussions because my discussions
are based on personal experience and I haven't any in Unisys. It isn't
personal. It certainly shouldn't spark a long diatribe about the alignment
of 8 bit bytes...(Man, you need some serious holiday...honestly)
If you are offended because the world at large does not embrace your ideals,
whose problem is that, Chuck?
> one of the big reasons I choose to be involved with the standardization
> process. Coding conventions may be obviously vendor-specific, but
> sometimes
> standard code can be written in such a way that it presumes a particular
> implementation. The latter can be very subtle.
And many people see nothing wrong with that. It bugs you, personally. Deal
with it.
>
>
> Well, you did that after the fact.
No, when I realised you had taken offense where none was intended I
apologised (I never do that unless I'm sorry...) and set the record straight
by YOUR requirements, rather than mine. Instead of accepting that I hadn't
meant to offend you, you persisted, so now I'm retaliating. That's life in
CLC... (gotta love it... :-))
> More importantly, although you responded
> to a post that had a mention of "older (IBM) CICS code", your post limited
> the context to IBM environments only in a few details.
It was implicit. And yes, the practise is bad on other platforms on which I
have worked also. What is your point here? That it is a good thing to
duplicate code in order to gain locality of reference on a Unisys machine?
Say that and we'll close the discussion. I won't believe you, but it really
doesn't matter; I don't work with Unisys. I DO care about the environments I
HAVE worked with. More importantly, I care about newcomers seeing something
that Bill was documenting as a matter of record, and thinking it's a good
idea. It isn't, and I explained why.
>
> I know you didn't use the following phrases, and I'm not accusing you of
> that. These are *my* examples of categorizations. There's a big
> difference
> among "everybody knows that ...", "everybody knows that in an <xyz>
> environment ..." and "everybody in an <xyz> environment knows that ...".
> The first two *invite* counterexamples which can almost certainly be
> found.
> The third might actually be true (although I suspect counterexamples might
> exist there as well), but if I am not a member of the specified subset I
> am
> not qualified to know one way or another.
>
> Although the first two aren't quite so bad as saying "When I wrote 'all
> mainframes' I really meant 'all real mainframes' " or "When I wrote
> 'everybody knows' I should have written 'everybody who's anybody knows' ",
> I'm not convinced any such generalizations are *entirely* and *inherently*
> devoid of an edge of categorical contempt, intentional or otherwise.
I mean exactly what I say (well, most of the time...sometimes I pretend I'm
experiencing an emotion just for effect...:-)) and I absolutely say exactly
what I mean. There are no hidden inferences, suggestions, sniping, cheap
shots, or anything other than what I wrote. You have been coming here long
enough to know that, and, frankly, I'm surprised at you. I put it down to
your passion for your work, your demonstrated over-sensitivity and
protectiveness of Unisys (they don't need it; they're a good company...),
and being due for some serious R & R. Don't look for trouble where there
isn't any...
There are things you and I will never agree on. That doesn't mean I will
treat you with contempt. And if I have issues with what you say, you'll know
about it, directly, as in this post.
>
>
> No; in fact I would argue that I tend more toward
> *implementation-nonspecific* recommendations far more than Unisys
> MCP-specific recommendations in this forum, precisely because the
> Unisys-specific ones are implementation-specific and thus run counter to
> the
> goal of protecting client investment.
>
> To my intentionally absurd example, you responded:
>
>
> And I don't think the phrases I cited earlier from your posting like
> "urban
> myth", "doesn't impact performance and never has", "stupid practice that
> was
> buried in the 70's" and "in today's environment this is irrelevant"
> differ
> all *that* much in categorical dismissiveness from phrases like "everybody
> who's anybody", "no excuse", "stupid practices", "trash heap of history"
> and
> so forth that I chose in that *reductio ad absurdum*.
Well, there we differ. The practise was an "urban myth" because almost
everybody believed it and many still do. I did. I see no emotional
overtones in "urban myth" other than something that is generally accepted
and probably isn't true. The other phrases were simply my opinion,
emphatically expressed. There is a huge difference between expressing an
opinion emphatically, and s ing to dismiss with scorn and implied
criticism. I think the flaw in your argument is that not all 'categorical
dismissiveness' implies contempt or scorn. I did categorically dismiss the
practice, still do, but there was no implicit criticism of people who bought
it, or of Unisys, or COBOL or anything or anybody. I do not use the phrases
you mention and I try to avoid pomposity ("everybody who's anybody" is just
not something I would even think...)
>
> The problem is, that example isn't all that absurd: I have heard its
> almost
> exact *opposite* from highly-paid (albeit newly-hired) and highly-placed
> system analysts at a Unisys MCP site ("packed fields are always signed
> internally and are always aligned at both ends on byte boundaries for
> anything approaching reasonable performance, so that's why we changed all
> our programs, and that means it's the fault of the Unisys MCP environment
> that our programs use more memory and take more processor resources than
> they used to before we changed it."). See below for further discussion
> on
> this particular case.
>
Do I HAVE to... :-)
> condemning
> it.
>
>
> Actually, I don't think you *do* have contempt for particular
> environments.
> But you have used what I believe is contemptuous terminology for practices
> that, while of dubious merit in the environments in which you currently
> operate, might be of less dubious -- or even positive -- merit in other
> environments. It's not that you don't like the practices, it's that you
> dismissed their value in general (and then subsequently limited the
> context).
>
Well, put it down to writing style and accept that my intentions were
pure... :-)
> considered
>
> It may also be that the people who support ICL or Honeywell or NCR COBOL
> compilers and support software aren't active participants in this forum.
> I
> have no say over the actions or inactions of those who do not make
> themselves visible.
Or over those who do. Like everybody here, the best you can do is express an
opinion. Different people do it in different ways. That's diversity...
>
> Moreover, I don't think you were contemptuous toward Unisys. That wasn't
> my
> point. I think you used contemptuous language about practices that others
> might find of positive merit on grounds which might, or might not, have
> anything to do with the operating environment (IBM, Unisys, or anyone
> else).
Well, we know whnere we disagree, then.
>
> Note that I maintain several software products whose origins lie firmly in
> the era when appropriate code was as clever, and as obtuse, as possible.
> These products remain very, very widely used. Do I argue that they need
> to
> be replaced by the latest technology? No, I don't; that's not going to
> happen. I try to slay the dragons I find as I find them and bring pieces
> of
> the code up to a modicum of legibility as I have time and resources to do
> so. Interestingly, I often do so with significant risk to the stability
> of
> the products, which causes our customers grief. The *product*, as far as
> its end users go, was often better off before I modernized it until we got
> it stable again. Maintainability is but *one* aspect of a given piece
> of
> software that might be considered in whether it is useful or not.
>
All well and good but nothing to do with what we are discussing...
>
> I did not take it as a personal attack; I took it as an unqualified
> expression of contempt against certain programming practices.
Well it wasn't. And you shouldn't have.
Words and
> phrases like "stupid practice" and "irrelevant" *express* contempt.
No they don't. I can say something is a stupid practice without having
contempt for the practitioners of it. It may be a statement of fact. It may
be a statement of the facts as I see them, with no other consideration
implicit. If I say:" I think that's stupid." Would you think that is
offensive? Would you still think so if I went to pains to explain WHY I
thought it was stupid?
How is it different if I state: ""I think that's a stupid practice."? It
isn't. If I look at things I've done in the past and say: "That was stupid."
How is it offensive? That is exactly what I said here. I was talking about a
past practice and I dismissed it as stupid. Because it was. NO other reason.
If something is irrelevant, then it is irrelevant. There are no emotional
overtones attached to this word that I know of.
>
>
> That's good; I'm glad you clarified your intent.
I'm sorry I had to.
>
>
> I do that all the time, and in this instance I'm taking a position that
> designing for portability, and for optimal performance on the widest
> possible variety of platforms, is a primary goal.
I disagree. It can be a goal, but it is nowhere near a primary goal in my
book.
Now, did I say that to offend you or dismiss you with scorn? No. I said it
because it is what I think. I know you disagree and i respect your right to
do so. No problem.
>
<snipped tedious discussion that is irrelevant to locality of reference or
emotional implications when expressing things forcefully>>
>
> The position I am coming from is much more closely related to my
> standardization concerns than it is to compatibility with the Unisys MCP
> environment. In many ways the IBM and the MCP environments are *so*
> different that my concerns are more about finding a way toward reasonable
> efficiency on *both* (as for my example above).
Don't sweat it. The world is running fine on both these platforms.
>
> One of the arguments *it seems to me* you are making in favor of a
> "modular"
> approach (which I take to be OO-related) is that the association of data
> with code in the system's memory always leads to more efficient
> utilization
> of virtual memory. and the approach facilitates that association and
> allows
> optimization of the size of each of the "modules" to make memory swaps
> more
> efficient. While I have no problem with the idea of taking a modular
> approach to application design, that defense is implementation dependent
> and
> is not universal.
I should have snipped the above because it is irrelevant too, but it is so
dear to my heart (you are not the only one who cares about what he does,
Chuck :-)), that I really couldn't let it go by...
The point was entirely missed. I have not argued for modular programming in
anything other than a specific environment: online processing in
multitasking environments (excluding Unisys whose architecture is apparently
not of this world :-)).
It all comes down to the three factors in my article. Small optimizes those
factors better than large. (But capture time is the most important as Rick
reminded me... so a very large module with a small capture time COULD do
well.) The generalization is exactly that, general... and. like most rules
of thumb it is adequate for most situations.
One of the things I really love about this forum is that you can make a
generalization (with the intention of providing something simple that might
actually be of use to people who haven't been programming for centuries...),
and instantly it is like a red rag to a bull, and exceptions will be
immediately contrived purely for the sake of argument. Not because they're
even important or should be flagged, but because imprecision cannot be
tolerated (even when it is stated to be imprecise). It is a pedant thing...
:-) I've come to a point now where I just smile at it, but it used to bother
me. Not that I'm imprecise when I write code; my stuff works (well, it does
for the most part...:-)), but I'm kind of glad I got older and wiser and
more relaxed so I don't get burned up about COBOL, or ASP, or Java or
anything else computer related. Caring is one thng; obsession is quite
another...
>It may be more efficient, it may be much less efficient.
> Other reasons to use -- or not to use -- such an approach may well be of
> overriding importance to the end user -- *including* in the very
> environment
> to which you now limit your categorizations.
Nope. I know how it works on the platforms I have experience with. Small is
beautiful in online environments for the reasons I have expounded at length,
and it is still beautiful whether it is stack based, register based, time
sliced, or interrupt driven. (as a general rule, of course... er, not on
Unisys... for the most part...in general... probably not on Fridays...etc.)
You are simply hoping it isn't for the sake of an argument... :-)
Pete.
| |
|
| Liberally snipping without mention. This may have been better as a private
posting between the two of you, but as I'm allowed to participate I thought
what the hey....
One of you may have been wrong in the eyes of the other and was big enough
to apologize - as an innocent bystander I think that both of you should kiss
and make up :-)
>"Pete Dashwood"
> Now, see, that is a very understandable viewpoint for a man with either of
> your hats. But those of us who go around hatless really don't care. In
> fact. my experience has been that programmers working on the shop floor
> NEVER refer to the COBOL standard (most sites don't even have a copy);
> instead they refer to the manuals provided by their vendor which tend to
> relate to the particular implementation in use in that shop. Makes sense
> to me, and I agree with it.
I'd go one further and say that most people don't even refer to the manual
for COBOL. With "newer" languages the API's the libraries are quickly
expanding - someone somewhere has done what you want before and hopefully
it's free. I'm afraid that once someone has been coding COBOL for 5+ years
there's two general methods of making changes - (1) Done it before or (2)
Someone I work with has...and sometimes (3) Implementation manual.
When I say most people - I mean most people that I have had the pleasure of
dealing with at some level.
I would buy the argument that not enough was done to make the standards
flexible and current enough for modern tasks - and that's where your <Chuck>
efforts are appreciated.
> If you are offended because the world at large does not embrace your
> ideals, whose problem is that, Chuck?
Depends on the ideals. Whether embraced or not doesn't determine the right
or wrong. I think we've seen that on here at great lengths on everything
from GOTO's, PERFORM THRUS, Components, OO, Abortion, and the use of
dialogue as a verb. The problem is _obviously_ Microsoft.
> And many people see nothing wrong with that. It bugs you, personally. Deal
> with it.
It's a problem when migrating from one platform / vendor to another.
Typically I believe these are handled by very underpaid staff so the hours
are irrelevant, or very highly paid individuals in which case the difficulty
is irrelevant.
> No, when I realised you had taken offense where none was intended I
> apologised (I never do that unless I'm sorry...) and set the record
> straight by YOUR requirements, rather than mine. Instead of accepting that
> I hadn't meant to offend you, you persisted, so now I'm retaliating.
> That's life in CLC... (gotta love it... :-))
As an innocent bystander, it's relatively amusing (but I probably shouldn't
say so).
> More importantly, I care about newcomers seeing something that Bill was
> documenting as a matter of record, and thinking it's a good idea. It
> isn't, and I explained why.
It isn't a good idea in your _realm_. I think you would have been wise to
point out that your _realm_ will take into account both more platforms and *
rather more importantly * more programming paradigms ;-)
Are newcomers entering <fortress cobol>?
> Well, there we differ. The practise was an "urban myth" because almost
> everybody believed it and many still do. I did. I see no emotional
> overtones in "urban myth" other than something that is generally accepted
> and probably isn't true.
"Urban myths" have no basis in truth (a half truth at most). They are
specifically associated with attempts to deceive. It is easy to infer some
"contempt"
> No they don't. I can say something is a stupid practice without having
> contempt for the practitioners of it.
Many people working for many companies do stupid things regardless of their
IQ.
Though I don't think I'd hear the phrase "You're very smart but what you do
is stupid"
I think it's deuce, if you're keeping score
JCE
| |
| Pete Dashwood 2005-07-31, 3:59 am |
|
"jce" <defaultuser@hotmail.com> wrote in message
news:31PGe.44139$t43.19225@tornado.tampabay.rr.com...
>
> Liberally snipping without mention. This may have been better as a
> private posting between the two of you, but as I'm allowed to participate
> I thought what the hey....
>
That's the joy of a public forum... :-)
> One of you may have been wrong in the eyes of the other and was big enough
> to apologize - as an innocent bystander I think that both of you should
> kiss and make up :-)
>
Despite the impression Chuck gained, I don't have contempt for anyone when
it comes to IT. It's an emotion I reserve for bottom feeders and people who
behave dishonourably or renege on their word and such, and even then I try
to understand them before allowing contempt to rise. I certainly don't bandy
it about in public forums and if I was that pissed off about something I'd
say so up front and have done. Actually, I think Chuck knows that and he
hinted at it in some of his correspondence...)
>
>
> I'd go one further and say that most people don't even refer to the manual
> for COBOL. With "newer" languages the API's the libraries are quickly
> expanding - someone somewhere has done what you want before and hopefully
> it's free. I'm afraid that once someone has been coding COBOL for 5+
> years there's two general methods of making changes - (1) Done it before
> or (2) Someone I work with has...and sometimes (3) Implementation manual.
>
> When I say most people - I mean most people that I have had the pleasure
> of dealing with at some level.
>
So you don't include the people you have never met? What about COBOL
programmers on Unisys sites in Ulan Bator? Or Bendix in Chatanooga? Funny,
I never thought you did. It's kind of implicit...(at least it is to me; but
I'm not sensitive about my company or paranoid that people are out to get
me...)
> I would buy the argument that not enough was done to make the standards
> flexible and current enough for modern tasks - and that's where your
> <Chuck> efforts are appreciated.
>
> Depends on the ideals.
No, it depends on how you feel about the ideals. If you are OK with the
reaction there is no problem. If you are not OK, then it is a problem, for
you.
>Whether embraced or not doesn't determine the
> right or wrong.
Agreed.(Don't think I suggested otherwise...)
> I think we've seen that on here at great lengths on
> everything from GOTO's, PERFORM THRUS, Components, OO, Abortion, and the
> use of dialogue as a verb. The problem is _obviously_ Microsoft.
>
ROFL! yeah, that's right... :-)
> It's a problem when migrating from one platform / vendor to another.
> Typically I believe these are handled by very underpaid staff so the
> hours are irrelevant, or very highly paid individuals in which case the
> difficulty is irrelevant.
>
Yes. And like many problems in busy IT departments it gets dealt with when
it HAS to be dealt with. I don't disagree with Chuck trying to nip it in the
bud by writing platform independent standardised code, I just don't think
that is a viable "primary priority".
What if you invest all that time and effort in raising standards awareness
and enforcing standardised code, no vendor extensions or liberal
interpretations of the standard, and then the world goes and decides COBOL
is no longer relevant anyway because there are better and faster tools
available? Or you NEVER transport the code to any other platform? Or you
realise that you could have spent the money on better hardware or some other
priority? Or the whole lot gets replaced by SAP?
> As an innocent bystander, it's relatively amusing (but I probably
> shouldn't say so).
>
Innocent? Pshaw! NOBODY here is innocent... :-) (another generalization that
demonstrates my contempt for the frequenters of this forum...or is it just
innocent fun? I realize it's tough when people have to think about what they
read.... :-))
>
> It isn't a good idea in your _realm_. I think you would have been wise to
> point out that your _realm_ will take into account both more platforms and
> * rather more importantly * more programming paradigms ;-)
> Are newcomers entering <fortress cobol>?
Man, I hope not... :-)
> "Urban myths" have no basis in truth (a half truth at most). They are
> specifically associated with attempts to deceive. It is easy to infer some
> "contempt"
>
Then perhaps your usage of this term differs from mine. Taking inferences is
always a risky business,
and particularly so when the statement is made by someone who has implied
nothing and stated what was intended.
Nothing more, nothing less.
> Many people working for many companies do stupid things regardless of
> their IQ.
> Though I don't think I'd hear the phrase "You're very smart but what you
> do is stupid"
>
I have actually said to a Senior Manager: "For a team of very smart people,
there are some really stupid things going on here." No offense was implied
or taken. We fixed it.
> I think it's deuce, if you're keeping score
>
Hahaha! Wimbledon is over... Thank you for having us tied; I felt, as I
often do here, that I was losing the rally.
Pete (who has now left Centre Court for more important business...).
| |
| Chuck Stevens 2005-08-02, 8:59 am |
| I think the following points are key to our mutual miscommunications:
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3l1g7qFvs80mU1@individual.net...
> If I say:" I think that's stupid." Would you think that is
> offensive? Would you still think so if I went to pains to explain WHY I
> thought it was stupid?
Much less offensive than "That's stupid." Even less so if you explained how
you came to that particular *opinion*, precisely because you made it clear
from the outset that it was a statement of opinion and not an *ex cathedra*
pronouncement of universal and incontrovertible truth.
> How is it different if I state: ""I think that's a stupid practice."? It
> isn't.
From "That's a stupid practice?" Oh, yes, it is, by the rules of English.
Saying "That's a stupid practice" to someone or some group is hugely
different in a number of ways from saying "I think that's a stupid practice"
to that person. The former is an assertion of absolute fact; the latter is
a clear expression of opinion.
> If I look at things I've done in the past and say: "That was stupid."
Then you are characterizing *your* actions based on *your* experience in
*your* environment. Given that specific context, it's a "transform" from
"[I think] that was [a] stupid [action on my part]." That's quite
different from "That is/was/would be [a] stupid [action on your part]".
I note that the Webster's Ninth entry for "stupid" includes such shadings as
"slow of mind; given to unintelligent decisions or act; acting in an
untelligent or careless manner; marked by or resulting from unreasoned
thinking." The synonym list notes that the term "stupid" implies
slow-wittedness. To use the term "stupid" to describe the actions of
another person, the clear implication is that the actions being described
are the actions to be expected *of a slow-witted person*. That's quite
different from terms like "suboptimal" or even "ill-advised".
Moreover, I have no problem with just about anything prefixed by "I think
.... " or even "My experience leads me to believe ...", and I try to ensure
that I don't omit such qualifications. When I do, it's usually because I
provide documentation for my view on the subject (as for example the summary
of the dictionary entry above!).
> How is it offensive? That is exactly what I said here. I was talking about
a
> past practice and I dismissed it as stupid. Because it was. NO other
reason.
>
> There are no emotional overtones attached to this word that I know of.
Which word? I think I've provided sufficient documentation to support my
contention that there are *indeed* a number of emotional overtones attached
to the word "stupid" that don't apply to the likes of "irrelevant",
"ill-advised", "suboptimal", "counterproductive" or even "wrong-headed" in
the same context.
Statements like "Doing <x> is stupid" strike me as carrying a whole lot more
semantic baggage and implicit categorization than "I have found doing <x> to
be a bad idea" or even "I think doing <x> is a bad idea." It doesn't
matter what <x> is.
-Chuck Stevens
| |
| Pete Dashwood 2005-08-02, 8:59 am |
|
OK.
Your issue is with me expressing opinion as if it was "fact", right?
Whatever I write is my opinion, just as whatever you write is your opinion,
and whatever anyone posts is their opinion.
Keep that in mind when you read my posts and you will feel better about
them.
I believe what I write, so, for me, it is a fact. If I express it forcefully
that may reflect that I feel strongly about it.
The truth or otherwise of what I write is not affected by how it is
expressed.
Don't be offended by my certainty about something.
If you disagree, fine. Make your case or choose not to; it's up to you.
I was interested in your expression "absolute fact" below. My experience is
that there is no such thing. There are "facts" that many people agree to be
so, and that makes them real. I do not ascribe to Newton's view of the
Universe, where there are absolutes that provide the canvas for the events
of our lives. So you and I will disagree upon what "fact" or "truth" is...
Take a look at this link:
http://www.spaceandmotion.com/Philo...Truth-Space.htm
As always, I call 'em like I see 'em.
Pete.
TOP POST no more below.
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dcm6sh$2smh$1@si05.rsvl.unisys.com...
>
> I think the following points are key to our mutual miscommunications:
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3l1g7qFvs80mU1@individual.net...
>
>
> Much less offensive than "That's stupid." Even less so if you explained
> how
> you came to that particular *opinion*, precisely because you made it clear
> from the outset that it was a statement of opinion and not an *ex
> cathedra*
> pronouncement of universal and incontrovertible truth.
>
>
> From "That's a stupid practice?" Oh, yes, it is, by the rules of English.
> Saying "That's a stupid practice" to someone or some group is hugely
> different in a number of ways from saying "I think that's a stupid
> practice"
> to that person. The former is an assertion of absolute fact; the latter
> is
> a clear expression of opinion.
>
>
> Then you are characterizing *your* actions based on *your* experience in
> *your* environment. Given that specific context, it's a "transform" from
> "[I think] that was [a] stupid [action on my part]." That's quite
> different from "That is/was/would be [a] stupid [action on your part]".
>
> I note that the Webster's Ninth entry for "stupid" includes such shadings
> as
> "slow of mind; given to unintelligent decisions or act; acting in an
> untelligent or careless manner; marked by or resulting from unreasoned
> thinking." The synonym list notes that the term "stupid" implies
> slow-wittedness. To use the term "stupid" to describe the actions of
> another person, the clear implication is that the actions being described
> are the actions to be expected *of a slow-witted person*. That's quite
> different from terms like "suboptimal" or even "ill-advised".
>
> Moreover, I have no problem with just about anything prefixed by "I think
> ... " or even "My experience leads me to believe ...", and I try to ensure
> that I don't omit such qualifications. When I do, it's usually because I
> provide documentation for my view on the subject (as for example the
> summary
> of the dictionary entry above!).
>
> a
> reason.
>
> Which word? I think I've provided sufficient documentation to support my
> contention that there are *indeed* a number of emotional overtones
> attached
> to the word "stupid" that don't apply to the likes of "irrelevant",
> "ill-advised", "suboptimal", "counterproductive" or even "wrong-headed" in
> the same context.
>
> Statements like "Doing <x> is stupid" strike me as carrying a whole lot
> more
> semantic baggage and implicit categorization than "I have found doing <x>
> to
> be a bad idea" or even "I think doing <x> is a bad idea." It doesn't
> matter what <x> is.
>
> -Chuck Stevens
>
>
>
| |
| docdwarf@panix.com 2005-08-02, 8:59 am |
| In article <3l8212F11cvb0U1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
>OK.
>
>Your issue is with me expressing opinion as if it was "fact", right?
>
>Whatever I write is my opinion, just as whatever you write is your opinion,
>and whatever anyone posts is their opinion.
Is that a fact?
[snip]
>I was interested in your expression "absolute fact" below. My experience is
>that there is no such thing.
Ahhhhh... so 'everything is relative'... and that's absolutely true!
DD
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 1-Aug-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> From "That's a stupid practice?" Oh, yes, it is, by the rules of English.
> Saying "That's a stupid practice" to someone or some group is hugely
> different in a number of ways from saying "I think that's a stupid practice"
> to that person. The former is an assertion of absolute fact; the latter is
> a clear expression of opinion.
True - but unless we have footnotes and references supporting what we say -
*everything* we post is opinion.
There is no *real* difference between those two statements, but one comes across
as a bit less rude.
| |
| docdwarf@panix.com 2005-08-02, 4:59 pm |
| In article <dco0l7$60r$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 1-Aug-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>
>True - but unless we have footnotes and references supporting what we say -
>*everything* we post is opinion.
Is that a fact? Plural majestatus est, Mr Brazee... and I believe that
statements like 'Bismarck is the capital of North Dakota' and 'in base ten
five times five is twenty-five' belong to the set of 'everything'.
DD
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 2-Aug-2005, docdwarf@panix.com wrote:
>
> Is that a fact? Plural majestatus est, Mr Brazee... and I believe that
> statements like 'Bismarck is the capital of North Dakota' and 'in base ten
> five times five is twenty-five' belong to the set of 'everything'.
I believe you believe this.
If you added "I believe" to the above, it wouldn't have changed its validity one
iota.
| |
| docdwarf@panix.com 2005-08-02, 4:59 pm |
| In article <dco4eq$7tn$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 2-Aug-2005, docdwarf@panix.com wrote:
>
>
>I believe you believe this.
Do you believe that... or do you just believe that you believe that?
>
>
>If you added "I believe" to the above, it wouldn't have changed its validity one
>iota.
I do not understand what you are calling 'validity' or how it can be
applied differently to opinions.
DD
| |
| Rick Smith 2005-08-02, 4:59 pm |
|
<docdwarf@panix.com> wrote in message news:dcndb5$9c9$1@panix5.panix.com...
> In article <3l8212F11cvb0U1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
opinion,[color=darkred]
>
> Is that a fact?
>
> [snip]
>
is[color=darkred]
>
> Ahhhhh... so 'everything is relative'... and that's absolutely true!
H'm! I see that Mr Dashwood referred to 'fact' and 'experience'
and not to 'everything'. David Hume in "An Enquiry Concerning
Human Understanding" seems to suggest that matters of fact are
related to one's experience.
See < http://etext.library.adelaide.edu.au/h/hume/david/h92e >
for complete text.
< http://etext.library.adelaide.edu.a...h92e/sec04.html >
---- begin quoted material
SECTION IV: SCEPTICAL DOUBTS CONCERNING THE
OPERATIONS OF THE UNDERSTANDING, PART I
If we would satisfy ourselves, therefore, concerning the nature
of that evidence, which assures us of matters of fact, we must
enquire how we arrive at the knowledge of cause and effect.
I shall venture to affirm, as a general proposition, which admits
of no exception, that the knowledge of this relation is not, in any
instance, attained by reasonings a priori; but arises entirely from
experience, ....
This proposition, that causes and effects are discoverable, not
by reason but by experience, will readily be admitted with
regard to such objects, as we remember to have once been
altogether unknown to us; since we must be conscious of the
utter inability, which we then lay under, of foretelling what
would arise from them. ....
----- end quoted material
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 2-Aug-2005, docdwarf@panix.com wrote:
>
> I do not understand what you are calling 'validity' or how it can be
> applied differently to opinions.
Except for trolls - what a poster post is what he believes. It may be
something that can be checked easily (the capital of North Dakota), or one which
is harder to quantify "that process is stupid".
Occasionally, adding a confidence factor is meaningful. "If things haven't
changed, the company I worked for 5 years ago still uses CoBOL".
But I can say:
"I believe Bismark is the capital of North Dakota"
or
"I believe the "C" is the capital of Colorado".
or
"I believe CoBOL is a dead language"
or
"I believe GO TO is harmful".
or
"I believe Connecticut is the capital of North Dakota".
But my "I believe" didn't really add anything.
| |
| docdwarf@panix.com 2005-08-02, 4:59 pm |
| In article <11ev8ogi1354seb@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><docdwarf@panix.com> wrote in message news:dcndb5$9c9$1@panix5.panix.com...
>
>H'm! I see that Mr Dashwood referred to 'fact' and 'experience'
>and not to 'everything'.
Mr Dashwood refers to 'my experience'; I do not see how this differs from
'everything in my experience'... but I could be wrong.
DD
| |
| docdwarf@panix.com 2005-08-02, 4:59 pm |
| In article <dco8co$a29$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 2-Aug-2005, docdwarf@panix.com wrote:
>
>
>
>Except for trolls - what a poster post is what he believes.
Leaving aside that I barely know what *I* believe, let alone anyone
else... assuming this to be true it begs the question: believes to be
belief or believes to be fact?
DD
| |
| Michael Mattias 2005-08-02, 4:59 pm |
| "Howard Brazee" <howard@brazee.net> wrote in message
news:dco8co$a29$1@peabody.colorado.edu...
> But I can say:
>
> "I believe Bismark is the capital of North Dakota"
> or
> "I believe the "C" is the capital of Colorado".
>...
> or
> "I believe Connecticut is the capital of North Dakota".
Sadly, your geography skills are all too representative of "Da Yoot of
America."
MCM
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 2-Aug-2005, docdwarf@panix.com wrote:
> Leaving aside that I barely know what *I* believe, let alone anyone
> else... assuming this to be true it begs the question: believes to be
> belief or believes to be fact?
Are you using the common definition of "begs the question" or the classical one?
But "belief" isn't about whether something is objectively determinable to be
fact. If you perceive things to be one way, then that's what you believe.
If you tell me you're hungry, or you tell me you believe you're hungry - you can
be lying or you can be telling the truth.
I believe Pluto orbits around the sun.
Belief doesn't have to be without compelling evidence.
| |
| docdwarf@panix.com 2005-08-02, 4:59 pm |
| In article <dcobr4$bu0$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 2-Aug-2005, docdwarf@panix.com wrote:
>
>
>Are you using the common definition of "begs the question" or the
>classical one?
Answering a question with a question is no answer at all.
>
>
>But "belief" isn't about whether something is objectively determinable to be
>fact. If you perceive things to be one way, then that's what you believe.
'Belief' is one of those funny, murky yet commonly-used words - like
'know' or 'understand' - that, every so often, it might be good to dust
off and re-examine. I alluded to Wittgenstein earlier with a mathematical
reference; he asked something along the lines of:
'What is the function of 'belief' in the following exchange:
'What's five times five?'
'Twenty-five... I believe.'
DD
| |
| docdwarf@panix.com 2005-08-02, 4:59 pm |
| In article <QsOHe.322$9U3.315@newssvr24.news.prodigy.net>,
Michael Mattias <michael.mattias@gte.net> wrote:
>"Howard Brazee" <howard@brazee.net> wrote in message
>news:dco8co$a29$1@peabody.colorado.edu...
>
>Sadly, your geography skills are all too representative of "Da Yoot of
>America."
Leaving aside that Mr Brazee was not confessing belief but merely stating
what he is capable of saying...
.... ahhhhh, for the Oldene Dayse, when a youth could have geography skills
such as *ten* youths cannot, today!
DD
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 2-Aug-2005, docdwarf@panix.com wrote:
>
> Answering a question with a question is no answer at all.
It can be, but in this case it wasn't meant to be an answer. It was meant to be
a question. And your statement of fact did not answer my question at all.
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 2-Aug-2005, docdwarf@panix.com wrote:
> 'Belief' is one of those funny, murky yet commonly-used words - like
> 'know' or 'understand' - that, every so often, it might be good to dust
> off and re-examine. I alluded to Wittgenstein earlier with a mathematical
> reference; he asked something along the lines of:
>
> 'What is the function of 'belief' in the following exchange:
>
> 'What's five times five?'
>
> 'Twenty-five... I believe.'
It's possible that you are saying that you're not confident of the results.
But we see many cases where if you accuse a True Believer of not being confident
in his Belief that he will deny it.
Or it could be that the "I believe" adds nothing at all to the content of the
statement. That does happen.
This sub-thread started with the observation that one should say "I believe this
is stupid" instead of "this is stupid".
What would the function of "I believe" be in that observation? To indicate (as
in one of my guesses to your question), that his belief isn't strong? That's
pretty presumptuous.
It seems to me that it might be more of a "if you say anything that might be
deemed insulting, cover your buttocks with extraneous words to blunt your
desired effect".
| |
| Howard Brazee 2005-08-02, 4:59 pm |
|
On 2-Aug-2005, docdwarf@panix.com wrote:
> Leaving aside that Mr Brazee was not confessing belief but merely stating
> what he is capable of saying...
Of course being semantically correct can get one misunderstood or in trouble -
such as demanding that my teacher give me an "A" for answering every question
correctly (if that's what she promised), and I correctly answer "I don't know"
to each answer.
Some of the answers and questions on Jeopardy could be like this. Reverse
them and you will rarely get full credit for knowing the answer:
Question: Who was Abraham Lincoln? Answer: Winston Churchill reported seeing
his ghost in the bedroom.
Semantically one can reply "What is a Jeopardy answer". But that "correct"
answer won't get any money.
| |
| Rick Smith 2005-08-02, 4:59 pm |
|
<docdwarf@panix.com> wrote in message news:dco9cg$adr$1@panix5.panix.com...
> In article <11ev8ogi1354seb@corp.supernews.com>,
> Rick Smith <ricksmith@mfi.net> wrote:
news:dcndb5$9c9$1@panix5.panix.com...[color=darkred]
opinion,[color=darkred]
experience is[color=darkred]
>
> Mr Dashwood refers to 'my experience'; I do not see how this differs from
> 'everything in my experience'... but I could be wrong.
Mr Dwarf, I hope you are not 'wrong' since that may imply
a moral failing; perhaps you are mistaken, which does not
imply a moral failing.
David Hume, at the beginning of Section IV, wrote,
"ALL the objects of human reason or enquiry may naturally be
divided into two kinds, to wit, Relations of Ideas, and Matters
of Fact. Of the first kind are the sciences of Geometry, Algebra,
and Arithmetic; and in short, every affirmation which is either
intuitively or demonstratively certain. That the square of the
hypothenuse is equal to the square of the two sides, is a
proposition which expresses a relation between these figures.
That three times five is equal to the half of thirty, expresses a
relation between these numbers. Propositions of this kind are
discoverable by the mere operation of thought, without
dependence on what is anywhere existent in the universe.
Though there never were a circle or triangle in nature, the truths
demonstrated by Euclid would for ever retain their certainty
and evidence.
"Matters of fact, which are the second objects of human
reason, are not ascertained in the same manner; nor is our
evidence of their truth, however great, of a like nature with the
foregoing. The contrary of every matter of fact is still possible;
because it can never imply a contradiction, and is conceived
by the mind with the same facility and distinctness, as if ever so
conformable to reality. That the sun will not rise to-morrow is
no less intelligible a proposition, and implies no more
contradiction than the affirmation, that it will rise. We should
in vain, therefore, attempt to demonstrate its falsehood. Were
it demonstratively false, it would imply a contradiction, and
could never be distinctly conceived by the mind."
Hume seems to be saying that the universe of reason ("ALL
the objects" seems to be a universe, or 'everything') consists
of Ideas and Facts ("Relations of Ideas, and Matters of Fact");
that (from the snipped quote) facts are related to experience,
but not so ideas since facts "are not ascertained in the same
manner" as ideas; therefore, when speaking, as Mr Dashwood
did, of 'fact' and 'experience', 'facts are relative', but not
'everthing is relative', since 'everything' includes ideas, which
Mr Dashwood did not mentioned; I too could be mistaken,
but I am definitely not wrong.
| |
| docdwarf@panix.com 2005-08-02, 9:59 pm |
| In article <11evi2pqvqd0cf0@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><docdwarf@panix.com> wrote in message news:dco9cg$adr$1@panix5.panix.com...
>news:dcndb5$9c9$1@panix5.panix.com...
>
>Mr Dwarf, I hope you are not 'wrong' since that may imply
>a moral failing; perhaps you are mistaken, which does not
>imply a moral failing.
Implication is in the mind of the beholder, of course... but be that as it
may...
>
>David Hume, at the beginning of Section IV, wrote,
>
>"ALL the objects of human reason or enquiry may naturally be
>divided into two kinds, to wit, Relations of Ideas, and Matters
>of Fact. Of the first kind are the sciences of Geometry, Algebra,
>and Arithmetic; and in short, every affirmation which is either
>intuitively or demonstratively certain. That the square of the
>hypothenuse is equal to the square of the two sides, is a
>proposition which expresses a relation between these figures.
>That three times five is equal to the half of thirty, expresses a
>relation between these numbers. Propositions of this kind are
>discoverable by the mere operation of thought, without
>dependence on what is anywhere existent in the universe.
Mr Hume appears to be saying that 'the operation of thought' does not
exist anywhere in the universe ('discoverable by... operation of thought,
without dependence on what is anywhere existent') or he posits a universe
without thought... which cannot be occupied by sentient beings.
>Though there never were a circle or triangle in nature, the truths
>demonstrated by Euclid would for ever retain their certainty
>and evidence.
Students of Lobachevski might just possibly disagree... but once again,
how does one know what a universe without Euclid would look like?
(oh... and as for 'wrong' versus 'mistaken' I was using 'wrong' in the
sense of
http://www.m-w.com/cgi-bin/dictiona...a=wrong&x=0&y=0 ,
3a: 'the state of being mistaken or incorrect')
DD
| |
| docdwarf@panix.com 2005-08-02, 9:59 pm |
| In article <dcog1h$e84$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 2-Aug-2005, docdwarf@panix.com wrote:
>
>
>It can be, but in this case it wasn't meant to be an answer.
'Meaning' is the result of interpretation, as Wittgenstein had it.
>It was meant to be
>a question.
As it was something done 'to speak or write in reply' it is, by
definition, answering.
>And your statement of fact did not answer my question at all.
That is because you left the FIFO answer-queue filled with my question,
having provided no answer at all.
DD
| |
| docdwarf@panix.com 2005-08-02, 9:59 pm |
| In article <dcogep$ebu$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 2-Aug-2005, docdwarf@panix.com wrote:
>
>
>It's possible that you are saying that you're not confident of the results.
>But we see many cases where if you accuse a True Believer of not being confident
>in his Belief that he will deny it.
>
>Or it could be that the "I believe" adds nothing at all to the content of the
>statement. That does happen.
Those are starters, Mr Brazee... but one must begin somewhere.
>
>This sub-thread started with the observation that one should say "I believe this
>is stupid" instead of "this is stupid".
>
>What would the function of "I believe" be in that observation?
There might have been no 'the function', there might have been a few...
one of which would have been to spare me someone else's quoting Davey
Hume.
DD
| |
| Pete Dashwood 2005-08-02, 9:59 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:dco0l7$60r$1@peabody.colorado.edu...
>
>
> On 1-Aug-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>
> True - but unless we have footnotes and references supporting what we
> say -
> *everything* we post is opinion.
>
> There is no *real* difference between those two statements, but one comes
> across
> as a bit less rude.
>
Thank you Howard. You expressed my thought better than I did.
Pete.
| |
| docdwarf@panix.com 2005-08-02, 9:59 pm |
| In article <dcogqk$eij$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 2-Aug-2005, docdwarf@panix.com wrote:
>
>
>Of course being semantically correct can get one misunderstood or in trouble -
>such as demanding that my teacher give me an "A" for answering every question
>correctly (if that's what she promised), and I correctly answer "I don't know"
>to each answer.
Doing or not-doing anything can have identical results; as my Sainted
Mother - may she sleep with the angels! - told me when I started my first
job 'When it comes to work just remember two things: you can be wrong
about something... and be fired for it, you can be right about
something... and be fired for it.'
DD
| |
| Pete Dashwood 2005-08-02, 9:59 pm |
|
<docdwarf@panix.com> wrote in message news:dco2qp$dgq$1@panix5.panix.com...
>
> In article <dco0l7$60r$1@peabody.colorado.edu>,
> Howard Brazee <howard@brazee.net> wrote:
>
> Is that a fact? Plural majestatus est, Mr Brazee... and I believe that
> statements like 'Bismarck is the capital of North Dakota' and 'in base ten
> five times five is twenty-five' belong to the set of 'everything'.
<DISCLAIMER - following is Pete's opinion: not intended to offend anyone,
forgive any perceived rudeness, observations may not apply to Unisys sites>
Ah, but are they "absolute facts"? So long as everyone who experiences them
agrees they are, then they can be admitted to be "real", but that doesn't
make them "absolute". We require an agreed reality in order to interact with
other human beings. If you lived alone in the world the capital of North
Dakota could be anything you chose it to be, assuming you elected to even
have a State of North Dakota. While there is no denying that in base ten we
all agree "five times five is twenty-five", this is simply an idea. The
Uncertainty Principle tells us that in the physical universe there is only a
probability that taking five groups of five things will result in twenty
five things.
</DISCLAIMER>
Pete.
> DD
>
>
| |
| Pete Dashwood 2005-08-02, 9:59 pm |
|
<docdwarf@panix.com> wrote in message news:dco6r9$3hl$1@panix5.panix.com...
>
> In article <dco4eq$7tn$1@peabody.colorado.edu>,
> Howard Brazee <howard@brazee.net> wrote:
>
> Do you believe that... or do you just believe that you believe that?
I believe you are being deliberately obtuse and you said the above with
tongue in ch :-)
>
>
Precisely. Howard is right. (I should have said: "I believe Howard is
right." to avoid offending certain sensibilities; doing that makes him no
more or less right.)
> I do not understand what you are calling 'validity' or how it can be
> applied differently to opinions.
Hahaha! Doc, you know as well as anyone here the difference between truth
and validity. This is a wind up... :-)
Pete
| |
| Pete Dashwood 2005-08-02, 9:59 pm |
|
<docdwarf@panix.com> wrote in message news:dco9h7$ci4$1@panix5.panix.com...
>
> In article <dco8co$a29$1@peabody.colorado.edu>,
> Howard Brazee <howard@brazee.net> wrote:
>
> Leaving aside that I barely know what *I* believe, let alone anyone
> else... assuming this to be true it begs the question: believes to be
> belief or believes to be fact?
>
This is where we come back to "absolute fact". Is our individual perception
of reality simply belief or is it fact? (I believe facts are what we agree
to be true; but I don't believe they are absolute.) Can there be anything
outside of our perception that is a fact? Is "absolute fact" simply tiny
strings of energy oscillating in different ways through eleven dimensions,
understandable by us as being subject to the laws of probability, but not
necessarily so? Maybe. Can our perception change this reality? Maybe.
Indications are that observing experiments may change the outcome of them.
Has anybody seen the film "What the bleep do we know?". I found it enjoyable
but irritating in places because people who should know better were not
telling the whole story or were putting their own spin it. But that's
reality. It is all about getting agreement on what each of us perceive.
When I post to this forum you are getting a glimpse of my universe. When you
post, I am getting a glimpse of yours. If our perceptions tally, we are in
agreement and share a reality; if they don't, then we get irritated with
each other... :-) But none of it has anything to do with "absolute fact".
And that's a fact. :-)
Pete.
> DD
>
>
| |
| Pete Dashwood 2005-08-02, 9:59 pm |
|
<docdwarf@panix.com> wrote in message news:dcoec5$hsl$1@panix5.panix.com...
>
> In article <dcobr4$bu0$1@peabody.colorado.edu>,
> Howard Brazee <howard@brazee.net> wrote:
>
> Answering a question with | | |