Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed

See interspersed comments. This is a response a posting quite a while back. In relation to the title, I have been enlightened by the theological postings by various of the participants and awed by their knowledge. I think that programming is like many fields of endeavor including law and accounting where certain things seem to become articles of faith. I know that I have followed political discussions on various groups where it seemed like the participants weren't on the same planet (this includes the US Congress and Canadian Parliament). Why should programming be exempt?

Pete Dashwood wrote:

"Robert Wagner" <spamblocker-robert@xxxxxxxxxx> wrote in message
news:llss11dmekhmkg0lr8ne2bdl802f1su53c@xxxxxxxxxx

On 23 Feb 2005 05:22:01 -0500, docdwarf@xxxxxxxxx wrote:


In article <sern11d72igqfdnm3lth34sjgsgqrv4dm9@xxxxxxx>,
Robert Wagner  <spamblocker-robert@xxxxxxxxxx> wrote:

[snip]


My question was rhetorical .. a nudge in the direction of reasoned
discourse. I have no illusion CLC posters will see the light and
emulate Max Weber's The Protestant Ethic and the Spirit of Capitalism.


How interesting... in the first sentence, Mr Wagner, you say that you
nudge towards reasoned discourse and in the second question you use a
metaphor for religious revelation.


Why does religion keep coming up in this programming forum? Is it
possible that Cobol programmers see themselves as defenders of an
intellectual lost cause?The last hangers-on of an idea whose time has
passed.

Just asking.


I reckon that's a very fair question.

COBOL was a powerful cult that ruled the world of EDP for at least 25 years
before it  (COBOL) went into decline.

There are certainly parallels with religion in that.

It was arcane. It was administered by High Priests who kept the details
secret in the interests of job security, and held thinly veiled disdain for
people who needed their services.(Did you ever hear a COBOL programmer
saying good things about  end users...? And yet these end users were the
reason for there being COBOL in the first place...)


My problem was with end users who didn't seem to understand their end of
the business.  Both as a systems programmer and as an applications
programmer, I believe that my job is to make others productive.  It was
a pleasure to do something for people who took care of their side of the
fence and were willing to explain their need as clearly as they could.
I enjoyed working with the applications programmers who stumbled on
problems in the system and told me about them.  The classic case for
making a change was when the payroll supervisor had as part of the
justification for telling people about savings bond purchases on their
pay checks was that my boss's wife had a problem reconciling her purchases.

The arcanity in part came from the tools we had in the 1960's and 1970's
where we had 132 characters on a line to print the record (80 chars)
plus a message.  I am certain that some of the error messages that I
produced were less than crystal clear.

My attitude was ask me because the seemingly simple change may be a
nightmare to implement while the apparently very difficult might be a
minor effort.


There was no way to 'Heaven' (properly functioning computerised commercial
systems) except via the Priests. The absolute power was a corrupting
influence, just as it has been in certain other religions.

And just as there are devout Druids and Sun Worshippers today, so some of
the COBOL Priests cling to the ancient teachings.

The world has moved on. It got sick of being dictated to and held to ransom
by the technocrats. The world didn't learn COBOL; they simply invented
computers that could interact with people intuitively. The temple veil was
rent in twain and the ungodly stormed the synagogue. Bad news for the COBOL
priests. (Certainly for the ones who didn't see it coming, or, despite
repeated warnings to expand their skill sets, decided "everythng I want to
do, I can do in COBOL".)  So they retreated to the mainframe fortresses and
tried to regroup, but it is over.

Nowadays EVERYONE is a programmer. (well, everyone under 25, anyway...). The
advent of the PC was like the advent of the printing press; people could
read it for themselves and "work out their own salvation with diligence".


Everyone may think they are a programmer.  However, the difficulty is
understanding how to make a change that doesn't impact something else.
Yes, people can get enormous amounts of information from databases but
do they understand the information and the accuracy of it?  Have they
tested and verified their results?  Data administration and data base
administration takes time to do it right.  It takes many semi-obscure
considerations.  While business programming in the 1960's and 1970's was
procedural, COBOL was designed to be programmed by BUSINESS people.  I
know that we had people come in from the accounting department and
become programmers at Westinghouse.  I think we may have had some from
other departments.

As a systems programmer who was also responsible for disk space
administration, I was once called the system's janitor, something that I
thought was a good description of the tasks.  If people can get the
information they need without my help, that is great because in any
organization, there is more to do than there is time to do it.

When I talk about testing, I know that my major frustration was figuring
out how to get a coherent set of data together so that I could verify
even a minor change.  As the number of related inputs increases, the
harder it is to have all of the related records, rows, etc.  Relational
integrity helps but isn't perfect.  I am not certain that end users have
the time, the patience or the tools to check out their creations.  In
many cases there attitude is that it works if the answers look
reasonable.  Of course I've been in shops where the testing on year end
programs wasn't much better.


And they are doing it.

They don't need the Priests of COBOL any more.

It isn't elegant or professional or slick for the most part, but
spreadsheets and databases work. People who don't even understand binary are
writing SQL queries against corporate databases and getting information to
support their daily decision making. Data flows across the corporation
without being locked into an antiquated, mysterious file system that
requires a programmer every time you want a report.


Some of us wrote report generators so they could get information they
needed.  We got tools so that requests could be offloaded.  But as I
said above, the joy comes in understanding the data, the relationships
and the ability to verify the effort regardless of whether Assembler,
COBOL, SQL, BAP (language for SAP) or other tool is used.  Some fairly
sophisticated things have been cobbled together using sort control
statements (obscurely if on an IBM mainframe, far less so in some other
environments).


Business is moving back to running business; not hosting parasitic IT
departments that simply bleed the profit line. The days of  virtually
unlimited budgets for an in-house IT department are almost over. They can
buy the service for a fraction of what it would cost to develop, or they can
distribute IT support to the people in the departments and let each profit
centre get what it can afford.


I doubt the budgets ever were unlimited.  Packages, if implemented
properly and that includes an organization really taking the time to
understand its needs, can save a bundle of money and implementation
time.  Compute power, memory and disk space are cheap enough that any
inefficiencies will get swallowed in the noise unless they are glaring.
However the stories of problematic implementations of SAP and other
packages make that an if rather than a given.  A package can result in
an organization having a better documented, better understood system.
It can also result in even greater obscurity as to how the business is
run.  If the settings done in various tables, control records, and other
user modification tools aren't documented and the reporting facilities
are primitive, control can be lost even more than with COBOL programs
maintained by the priesthood.  If you don't think that this can happen
consider the Windows registry or its equivalents in Linux, Unix, OS/2 or
other operating environment of choice or affliction.  Can you find all
the places you control your favorite word processing package?  Do you
know the default and changed settings?  Do you understand them?  I know
that I would answer maybe to the ability to find the places and "some of
them" to the other two questions.

I also wonder how much of the power of OO is really the power of the
repository.  The ability to know you have a component and the business
rule it implements is more important than the interface itself.  I don't
pay attention to the code of most called subroutines.  If OO enforces
better parameter checking that is great.  It still doesn't eliminate the
question of compile time versus binder time versus run time binding and
the implications each of these decisions have on performance and scope
of change.  The concern that Howard Brazee has raised in the past about
putting in a changed component and having to test all of the places it
is used are equally true for normal called routines and for OO if the
same name is used.  With compile or link/bind time linkage the problem
is manageable because the function can only change when the
caller/invoker is recompiled or rebound.  With run time binding the
problem is that all users of a service are affected by any change
including one that is only supposed to be upward compatible with no
effect on current uses.  Just as anyone who has installed more than one
new version of an operating system if this is always true in practice.


When you look at some of the threads in this forum you have to wonder: "Are
these folks actually getting pleasure out of this mind-numbing, brain-cell
destroying complexity...?"  Why would I debate how to build a treeview to
the level of what windows API bit switches I need, when I have a COM
component that does it all, provided by my vendor?  Instantiate it, set a
few properties, invoke a method or two, next problem...

It is because it is a religious thing. The devotion to detail must be
demonstrated. The true faith must be maintained. Only by pain can systems be
properly implemented, and shortcuts are sinful.

If it's easy, where's the satisfaction in that? For the same reason that
people in Italy purchase small whips to flagellate themselves, so do
programmers write low-level code. (OK, I accept that if you opt for a
MicroFocus environment, you may have no choice; their approach has always
been low level and they never were big on OO and components. This is not
intended to denigrate their excellent products. It is just an observation of
a different approach and philosophy. Net Express implements OO well, but
there is still only low level support for component building and wrapping.)

And you can see the same reaction here to anyone who questions dogma, as you
might see during a fervent religious festival.

I'm coming to a point now where I really can't see value in the procedural
approach. Certainly, I'm getting older, and certainly, I'm looking for easy
options, but when I can code:

<!--METADATA NAME="Microsoft ActiveX Data Objects 2.5 library"
TYPE="typelib" UUID="{00000205-0000-0010-8000-00AA006D2EA4}"-->
<% @LANGUAGE=JAVASCRIPT%>
<%
var currentMember = Request.QueryString("f1MemberID");
if(NaN(currentMember) {
// the MemberID entered by the user is not valid...
   Server.Transfer("BadMemberID.asp");
   Response.End;
}
//build a connection object
var objConn = Server.CreateObject("ADODB.Connection");
var strProvider="Driver={MySQL ODBC 3.51
Driver};Server=taurangawriters.org.nz;Database=twdbremote;uid=xxxxxxxx;pwd=x
xxxxxxx;option=3";
//Open the connection...
  try {
    objConn.Open(strProvider);
   }
  catch (er) {
  Server.Transfer("nodb.asp");
  Response.End();
  }
// we have a good db connection...
//update the password ...
    var reccount = 0;
 var parms = adCmdText | adExecuteNoRecords;
    strSQL = "UPDATE Client SET source = " + "'"+
Request.QueryString("f1newPassword") + "'" + " WHERE ClientID = " + "'"   +
currentMember + "'" ;
    try {
      objConn.Execute(strSQL,reccount,parms);
        }
    catch (err) {
        Server.Transfer("procerror.asp");
        Response.End();
        }
// finished with DB, drop it...
objConn.Close;
// it's a valid login and password change, take him to the portal...
Server.Transfer("MAPortal.asp");
Response.End
%>

... instead of a couple of hundred COBOL lines,  why wouldn't I?  The above
connects to a database (that can be anywhere on Earth), gets user input,
checks it, updates the database, detects and handles errors that may arise,
cleans up and serves the user the appropriate web page if it is successful,
and took me around 40 minutes to write and debug. That is the ENTIRE
program, no ID, ENVIRONMENT, DATA, PROCEDURE or any other kind of wrapping
required.

It can do this because it uses the underlying power of ActiveX components,
which, in turn, derive their power from OO programming, which most people
here regard with suspicion and distaste. Almost all of the variables above
are objects with built in methods and properties that I don't have to even
think about; I can just use them. If I have a Server object and I want it to
switch from the current document and serve up something different, why would
I write:

(and this is modern OO COBOL...)
invoke Server "new"
           using "someExotic.dll"
           returning objServer
end-invoke
invoke objServer "Transfer"
           using "MAPortal.asp"
end-invoke

...when I can write:  Server.Transfer("MAPortal.asp");

(It is a base ASP object so it instantiates itself if it hasn't already...)

The new religion is Object Oriented and Component based, and even these are
being abstracted (as in the line above) so that detailed knowledge is not
required.

The future of COBOL is in batch. It is good for that. You don't need objects
for batch processing although dedicated devotees of OO would contrive to use
them, just to show their strong adherence to the faith...

I believe Robert may have a point; perhaps the same factors that contribute
to religious bigotry, are also found to a large extent in COBOL programmers.
Or SOME COBOL programmers? Or SOME COBOL Programmers who frequent CLC? (I
don't exclude myself from this group...)

Or then again, maybe religious topics get discussed here because they're
normally taboo and this is therefore one of the last places on the planet
where you CAN discuss them.

Either way, the off topic posts here are invariably more interesting than
the on-topic ones.

At least, they are to those of us who are not religious... <G>

Pete. 









.