Home > Archive > Cobol > March 2005 > OT: Religion in CLC posts WAS: Re: MF Collection Class speed
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]
| Author |
OT: Religion in CLC posts WAS: Re: MF Collection Class speed
|
|
| Pete Dashwood 2005-02-25, 3:55 pm |
|
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:llss11dmekhmkg0lr8ne2bdl802f1su53c@
4ax.com...
> On 23 Feb 2005 05:22:01 -0500, docdwarf@panix.com wrote:
>
>
> 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...)
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".
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.
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.
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.
| |
| docdwarf@panix.com 2005-02-25, 3:55 pm |
| In article <388or3F5n9179U1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
[snip]
>(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...)
Ahhhhhh, Mr Dashwood... leaving aside 'good things about end users' said
by programmers of *any* language it might be valid to see this as yet
another example of 'denigration of the recipients of a service by the
providers of the service'.
Chefs go on at length about how those who eat 'have no taste', officers of
the law, sworn to protect and serve, rail about the worthless 'public',
clothing-designers bemoan their customers' lack of 'style sense',
system-level programmers complain about the demands of apps-coders... the
list goes on.
DD
| |
| Warren Simmons 2005-02-26, 3:55 am |
| Pete Dashwood wrote:
> "Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
> news:llss11dmekhmkg0lr8ne2bdl802f1su53c@
4ax.com...
followed by a sermon from Pete.
It was a great sermon. Lots of generalization and good
examples. What shall we call the church?
Personally, I find I agree with most of what Pete had to say.
As a believer in COBOL, I have some of the same complaints.
While what Pete demonstrated was an excellent example, it
also demonstrated how the idea of writing something descriptive
was better for documentation, and very doable for computers and
open minded programmers.
While the new religion is simpler, it too, is almost impossible
to understand without the priests of that dialect. So, in a few
years or decades a new dialect will resolve, and the learning
curve will again grow steep.
I come back to a view that the problem we have in programming
is growth of verbs, and the definition of them. It's great
that the Win API's are now available to those who know how, BUT
THE GUI language is in need of adoption, and other tools
are possible. When a vendor can take a subroutine, and design
a circuit to do the whole thing in one cycle or other time unit
then that subroutine becomes a part of the native language.
I see the creation of COBOL, and it's use for these past several
decades as expanding the ability of the people of the world
to communicate. The reserved word list has become a widely know
set of world speak. I'd say, we should keep this up, and increase
the reduction of procedures to words or phrases.
Thanks, Peter for the inspiration to get that off my chest.
Warren Simmons
| |
| James J. Gavan 2005-02-26, 3:55 am |
| Warren Simmons wrote:
> Pete Dashwood wrote:
>
>
> followed by a sermon from Pete.
For my money his sermon was the usual doom and gloom. Factual, but
always, always slanted to his own conclusions. ('Take no prisoners !').
Always back to the tack, "I LUV COBOL, BUT.........." . Why bother
berating us if you think COBOL is already one big dud. What's the
motivation, Robert-style to make us aware of our ignorance ?
Can you imagine the reaction I would get if I wrote to Richard saying,
"You really gotta check this new religious TV Channel. The program is
called 'Vat-69' - I know you will be thrilled with it's content".
Your sermon I felt was a little more uplifting.
Jimmy
| |
| Pete Dashwood 2005-02-26, 3:55 am |
| Fair comment and a good point, Doc. I am chastened... <g>
Pete.
<docdwarf@panix.com> wrote in message news:cvncqm$87e$1@panix5.panix.com...
> In article <388or3F5n9179U1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> Ahhhhhh, Mr Dashwood... leaving aside 'good things about end users' said
> by programmers of *any* language it might be valid to see this as yet
> another example of 'denigration of the recipients of a service by the
> providers of the service'.
>
> Chefs go on at length about how those who eat 'have no taste', officers of
> the law, sworn to protect and serve, rail about the worthless 'public',
> clothing-designers bemoan their customers' lack of 'style sense',
> system-level programmers complain about the demands of apps-coders... the
> list goes on.
>
> DD
>
>
| |
| Pete Dashwood 2005-02-26, 3:55 am |
| Warren,
it is always good to hear from you.
Glad you are still in there batting for what is still (despite my post) my
favourite programming language.
My comments were not meant to wound; it was simply a commentary on the fact
that things have changed.
Some more comments below...
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:OCMTd.9449$Wh7.3973@fe11.lga...
> Pete Dashwood wrote:
> followed by a sermon from Pete.
>
Lol! I hope not...The problem I have (and I'm sure it is shared by some
others here, whether they confess it or not) is that I LOVE COBOL. It was
very good to me over many years, fed me, clothed me, allowed me to visit
exotic places, and even generated enough wealth for me to enjoy lying on the
beach in my beloved hometown. It would be churlish to bite the hand that has
fed me. But, the fact is, it is of little relevance in today's world,
outside of mainframe programming and batch processing.
I would never underestimate or disparage the effect COBOL had on the world.
Through the 60s and 70s COBOL was the only game in town and it was a good
game. It brought computer power to a position of necessity in our everyday
lives and enabled progress in many indirectly related fields. It would be
physically impossible to manually process the banking transactions, airline
reservations, transactions of commerce, that are handled every day without
computers. Yet the general public take it all for granted and expect it. It
was mainframes running COBOL that led the way.
I still find the fact that a group of people could sit down in 1959 and
altruistically pool their experience and even some of their tools, for the
greater good, inspirational. It wouldn't happen now.
> It was a great sermon. Lots of generalization and good
> examples. What shall we call the church?
How about "The Church of I want it NOW!"
>
> Personally, I find I agree with most of what Pete had to say.
> As a believer in COBOL, I have some of the same complaints.
> While what Pete demonstrated was an excellent example, it
> also demonstrated how the idea of writing something descriptive
> was better for documentation, and very doable for computers and
> open minded programmers.
>
COBOL is certainly the finest language for documentating source as you go.
The problem is that that is not such a requirement anymore.
If you have programs with several thousand lines, it is completely essential
to have explanation included. If the code is small, there is less
requirement for it. (See my example...). Add to that the fact that the
source code is becoming less relevant anyway, and the case for verbose
programming starts to look more bleak... System designers, developers, and
end users, are becomming accustomed to using objects that they didn't write,
and have no intention whatsoever of maintaining. (See my example...)
Source code is no longer king. The world revolves around results.
>
> While the new religion is simpler, it too, is almost impossible
> to understand without the priests of that dialect.
No, Warren, it is just a different kind of understanding. People who are
raised with Object Orientation have no difficulty whatsoever in deciphering
what looks like Swahili to people who have not embraced it. Kids all over
the world are writing their websites in JavaScript and VBScript and even
Perl. They have no difficulty with the syntax because it is simple. Once
they understand the concept of an object, they EXPECT it to have methods,
properties, and possibly, events, and the syntax to get at these things is
simple and consistent. There is no priesthood in the sense that their was
when programming was a mystical black art; everyone has access to it now.
If they don't understand it they will search the internet and download code
that does what they want. After doing this a few times, they begin to
understand how it works. There are any number of support teaching materials
available free on the net. I taught myself this stuff by doing it and used
the internet as my teacher. (I hasten to add, that what I write today is
much better than what I wrote a year ago, and what I write tomorrow will
hopefully be better than what I wrote today, but the point is that all of it
works, whether it is good, bad, or indifferent. It works because the
underlying objects work.
So, in a few
> years or decades a new dialect will resolve, and the learning
> curve will again grow steep.
>
No, I don't think so. If anything, it is more likely that abstraction
layers will be placed over the objects (we are already starting to see this-
various systems have their own innate objects like the ASP Server, Session,
and Application Classes). The curve is more likely to flatten than steepen.
> I come back to a view that the problem we have in programming
> is growth of verbs, and the definition of them. It's great
> that the Win API's are now available to those who know how, BUT
> THE GUI language is in need of adoption, and other tools
> are possible. When a vendor can take a subroutine, and design
> a circuit to do the whole thing in one cycle or other time unit
> then that subroutine becomes a part of the native language.
>
It certainly becomes a part of the native machine...
> I see the creation of COBOL, and it's use for these past several
> decades as expanding the ability of the people of the world
> to communicate.
So do I...
>The reserved word list has become a widely know
> set of world speak. I'd say, we should keep this up, and increase
> the reduction of procedures to words or phrases.
>
I can see that happening in about 30 years. People will interface with
machines in natural language, just as they interface with other people. The
whole emphasis will not be on the computer technology, it will be on the
application (which is where it properly belongs...)
> Thanks, Peter for the inspiration to get that off my chest.
>
No problem. Thanks for sharing it. Hope you are posting here for many years
to come.
Pete.
| |
| Pete Dashwood 2005-02-26, 3:55 am |
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:OXMTd.506058$Xk.469246@pd7tw3no...
> Warren Simmons wrote:
>
> For my money his sermon was the usual doom and gloom. Factual, but
> always, always slanted to his own conclusions. ('Take no prisoners !').
> Always back to the tack, "I LUV COBOL, BUT.........." . Why bother
> berating us if you think COBOL is already one big dud. What's the
> motivation, Robert-style to make us aware of our ignorance ?
>
Nobody was berated.
I don't think, and have never thought, that COBOL is/was a dud.
I do believe it's time is over. I don't consider this group to be ignorant;
on the contrary, I bother to post here because there are many lively minds
that are interested in other viewpoints. (Sadly, you don't fit that
category...)
(However, my posts here are declining because my use of COBOL is
declining... It is called "growth"...)
Neither do I expect universal agreement, and that is fine.
> Can you imagine the reaction I would get if I wrote to Richard saying,
> "You really gotta check this new religious TV Channel. The program is
> called 'Vat-69' - I know you will be thrilled with it's content".
>
I can't speak for Richard, but my experience of his posts shows him to be
aware and interested. I read what he posts here because it is usually
accurate and informative. Given that, there is a strong possibility he would
look at the program then write an insightful analysis of why he didn't agree
with it. (Just as I would...)
The process of civilised discussion is something you just haven't grasped
yet. Your concept of handling a losing argument is to publicly call someone
an ARROGANT BASTARD (sic) (I never saw any kind of apology for this... but
then, why would you?), or slink off and sulk as if your presence here or
anywhere else was of fundamental importance.
You are a legend in your own mind.
In fact, I don't know why I wasted time responding to this... probably
because, like Warren, I needed to get it off my chest.
Yes, that certainly feels better... sun is shining, beer is cold, I'm off to
the beach. All thoughts of Gavan and COBOL dismissed...
Pete.
| |
| Richard 2005-02-26, 3:55 am |
| > I still find the fact that a group of people could sit down in 1959
and
> altruistically pool their experience and even some of their tools,
for the
> greater good, inspirational. It wouldn't happen now.
Where have you been for the last few years ? Certainly through the 80s
and most of the 90s the prevailing model was the proprietry development
of software driven mainly by profit motive. Eventually this was
dominated by one company that had the power to decide who would be
winners and who would be losers (by being purchased, assimilated, or
simply excluded from the marketplace). Actually this is still
happening.
The reaction to this was to evolve a model that could not be
assimilated, bought, or squashed. That could not be excluded.
Your quote above describes exactly dozens or hundreds of projects which
are continuing with or without industry support.
In fact with Cobol it wasn't for 'the greater good', it was so the
companies involved that were paying the bills, could obtain contracts
from the DoD.
> Source code is no longer king. The world revolves around results.
That was MS's stance for many years. It is changing. See MS's
comments about why they will release some of the MSSQL Server source
code.
The problem is that many no longer trust software that is locked up.
Viruses, spyware, zombies etc (in Windows) have educated users to the
fact that their computers may be (and in fact are) sending their data
to MS and to others.
The advantage of source code is not that you can change it, or that you
can see it, but that _anyone_ can see it and thus it needs to be clean
or the whistle will be blown.
Security by obscurity has failed, closed source is no longer trusted.
Even MS recognise this now.
| |
| James J. Gavan 2005-02-26, 3:55 am |
| Pete Dashwood wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:OXMTd.506058$Xk.469246@pd7tw3no...
I wont back-track through your message, there's no point. I read your
first post and immediately, 'Oh dear. There he goes again..... Just give
it a miss". But slipped into the middle of it there was a reference to
some dick-wit who was actually trying to use COBOL for Treeviews. YOUR
RULES NOT MINE - we were not supposed to comment on each other's posts ?
Because I felt Warren created an encouraging note - only then did I
comment. Let's see how many others respond to what I call your doom and
gloom.
As regards openness of mind, I've stated quite clearly I'm not into
Webbing and all that's associated with it, like your components, Java,
ASP or whatever. Even though I'm not there, I DO keep the door ajar - at
some stage I *might* have need to adopt some of these features. My mind
is not close-set - and unlike you I have no one conviction about the
true path.
Just in passing - recall the time there was cross-posting between
different language groups and you threw in your idea about Components.
In all honesty, as you were addressing OO-oriented groups I was fully
expecting you would receive umpteen messages from them, "Right On Pete
!". As I recall only one, (from France ?) showed a token interest -
Unless of course you had follow-ups in private e-mail. But I DID TRULY
expect the OO-ers to loudly support you.
That's not knocking Components - but why no loud endorsement from those
groups. Perhaps they are as just as far behind as the rest of us ? They
probably are. Remember your 'One-Language Johnnies' ? Try asking the
gurus in comp.object about use of FACTORY, (which many have) and how it
is used in COBOL - you might just as well ask the question in Hindi -
you'll get the same result.
Yep - all sorts of ways of doing Treeviews, including one example I saw
written using ASP. But until you actually have a *need* to play with
these new features/languages, as Warren aptly said, the code looks like
an engineering drawing.
So perhaps I shouldn't re-invent the wheel in COBOL for Treeviews and
should search the Web for just the right component. Let me first lay
down a spec :-
1. Treeview
2. Ability to have/not have, buttons/lines/LinesAtRoot
3. Expandable number of Levels
4. Both Label editing or calling a Dialog to do editing
5. Icons
6. Checkboxes
7. Colouring of Labels
8. Combo Dropdown lists attached to a node in a Level
9. Ability to build Treeview on the fly - from user input
10. Not on the fly - build the Treeview from a DB and update the DB
11. Using the Drop and Drag feature to move Levels around and accommodate
updating the DB with those MOVES - AND MOST IMPORTANT, to ensure the
Drag and Drop doesn't create a cock-up in the DB
12. Splitview - Treeview with an accompanying Window - like Kellie's
insistence on using ListView
13. Pull up web pages/maps resulting from a selection.
14. Change sizing as a result of specifying the ImageList
15. What dictionary/collection features do they provide to access what
has been selected
16. Wont get this last one - because it's me specifically - changing
colour of icons or checkbox value or Label colour based on updating.
I think that's a reasonably comprehensive list.
17. Component is for VB/Delphi/dotNet - forget it. There were examples
prior to dotNet but the developers tend to be taking up the dotNet game.
18. Component MUST be usable from existing Windows environment prior
to dotNet
19,. Last but not least - price - can go from $100 up to one I saw for $550
As a promoter of using Components, "and... that is the only way to go",
care to google and find me one that fits at least 90-95% of above
criteria. I've certainly seen screenshots of most of the above features
- but NOT in one component. And as yet, not one that satisfactorily
described updating a database, although I'm sure some must have that
feature.
And when challenged, stick to topic. (Well *actually* it wasn't meant to
be a challenge - more, why keep telling us we should drop COBOL) :-
(a) As Regards Robert - look a little more closely at my message. It was
not as a result of 'losing a battle'. I had just read the previous
message he wrote to someone else, and in his typical cavalier style he
dismissed the writer. It was that which annoyed me, because it occurs so
often. It's a bloody shame really, because he has some good points as
well as the bad. I don't give a damn what he thinks about OO
collections. He can like 'em or leave 'em.
(b) The comment to Richard was written tongue in ch - and I'll bet he
understood. However, your saw it as one more marker that you could
pontificate on.
You yourself are a mine of knowledge - but not when you insist on
painting 'doom and gloom'. Ever thought about it the other way around,
take up the challenge and try and ENCOURAGE others to use COBOL, or at
least a mix, rather than think of COBOL as a dodo.
Jimmy
| |
| Warren Simmons 2005-02-26, 3:55 am |
| Pete Dashwood wrote:
> Warren,
>
> it is always good to hear from you.
>
Thank you for your kind words, Peter.
There were several points that you made that I plan to think
over, and perhaps respond to you with my reactions.
Warren
| |
| Warren Simmons 2005-02-26, 3:55 am |
| Richard,
From my perspective, I can not say who was responsible for the formation
of CODASYL. However, I have first hand knowledge of the process. While
Uncle Sam participated in an important way, some large companies, who as
a group represented the potential users to the public, arranged to make
Grace's tool available.
Yet, I am certain that a much larger group of companies participated at
a higher level.
The existence of major changes to our way of life do not all begin the
way CODASYL did, but one way or another, it happens in our world, and
will continue to happen so long as people are involved.
Warren Simmons
Richard wrote:
>
> and
>
>
> for the
>
>
>
> Where have you been for the last few years ? Certainly through the 80s
> and most of the 90s the prevailing model was the proprietry development
> of software driven mainly by profit motive. Eventually this was
> dominated by one company that had the power to decide who would be
> winners and who would be losers (by being purchased, assimilated, or
> simply excluded from the marketplace). Actually this is still
> happening.
> assimilated, bought, or squashed. That could not be excluded.
>
> Your quote above describes exactly dozens or hundreds of projects which
> are continuing with or without industry support.
>
> In fact with Cobol it wasn't for 'the greater good', it was so the
> companies involved that were paying the bills, could obtain contracts
> from the DoD.
>
>
| |
| Pete Dashwood 2005-02-26, 3:55 am |
| No point in continuing this indefinitely, so I won't:
All I will say is that your reponse below is a good one. I was impressed by
it not being a rant.
Because of that, I have responded to a couple of points.
Congratulations on not losing your temper... sincerely.
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:UnPTd.508710$Xk.78771@pd7tw3no...
> Pete Dashwood wrote:
>
> I wont back-track through your message, there's no point. I read your
> first post and immediately, 'Oh dear. There he goes again..... Just give
> it a miss". But slipped into the middle of it there was a reference to
> some dick-wit who was actually trying to use COBOL for Treeviews.
A search of my post does not reveal the word dick-wit. It is not a term I
use and was neither expressed nor implied. Maybe this is just your own
sensitivity where I am concerned? I see nothing wrong with you pursuing
whatever you want to pursue. If you and Kellie want to debate the finer
points of low-level programming (although I noticed you stopped it quickly
when she refused to agree with you) that is fine. It is a public forum. My
observation was simply along the lines that there is no NEED for people to
have all this aggravation. If you WANT to, well, that is a different matter.
YOUR
> RULES NOT MINE - we were not supposed to comment on each other's posts ?
>
Yes, but that was then and this is now. I haven't commented directly on any
of your mail, until this moment.
I am not your enemy but seem determined ot have me so.
> Because I felt Warren created an encouraging note - only then did I
> comment. Let's see how many others respond to what I call your doom and
> gloom.
>
Why would it matter? I don't post here to get approval. Sometimes it is just
for fun, sometimes it is a genuine effort to help someone, sometimes it is
because I want to share something with people who are capable sharing it. My
posts will not be affected by my "approval rating" in CLC. And the more
perceptive would realise that my message was not about "doom and gloom" it
was simply a statement of the programming world as I see it. Open to debate
and certainly open to disagreement.
> As regards openness of mind, I've stated quite clearly I'm not into
> Webbing and all that's associated with it, like your components, Java,
> ASP or whatever. Even though I'm not there, I DO keep the door ajar - at
> some stage I *might* have need to adopt some of these features. My mind
> is not close-set - and unlike you I have no one conviction about the
> true path.
>
Well, neither have I, and that includes using COBOL. The fact that I am
reluctantly moving away from it is simply because there are better ways of
doing things (in some areas, not across the board). Rather than post a
provocative (and untrue) statement about how useless COBOL is, I sought to
provide examples and reasons as to why young people are not rushing to
embrace it, and why I personally am finding less scope for it. There was
never any suggestion of a "right path" although the whole piece was framed
within a religious analogy, as was in keeping with the post being responded
to.
> Just in passing - recall the time there was cross-posting between
> different language groups and you threw in your idea about Components.
> In all honesty, as you were addressing OO-oriented groups I was fully
> expecting you would receive umpteen messages from them, "Right On Pete
> !". As I recall only one, (from France ?) showed a token interest -
> Unless of course you had follow-ups in private e-mail. But I DID TRULY
> expect the OO-ers to loudly support you.
I have no idea what you are talking about and I never require people to
agree with me anyway. If two people always agree on something, one of them
is unnecessary. <G> Many of my ideas are "out there", some are ahead of
their time, some are just plain wrong, and some are on the button. But I
keep posting and people keep reading my posts.
I said in 1997 that COBOL would be dead by 2015. It wasn't just "doom and
gloom" or scare mongering, it was based on extrapolation of what was
happening in the market place at that time. We are 10 years away from that
date and much of the raucous scepticism that greeted my post has subsided.
OK, maybe I wasn't totally right and there will still be some place for
COBOL into the foreseeable future, for some specialised application areas,
but I was right enough about IT departments being closed down (or revamped
into Network support) that these effects can be seen already, with 10 years
still to go. The fact is that the Internet has changed the fabric of our
lives and will continue to do so. The world of COBOL, where the IT (or EDP
as it was) in-house development centre provided the software for the company
is virtually gone.
I simply tried to explore the factors that brought this about. Is examining
Reality, "doom and gloom"?
> That's not knocking Components - but why no loud endorsement from those
> groups. Perhaps they are as just as far behind as the rest of us ? They
> probably are. Remember your 'One-Language Johnnies' ? Try asking the
> gurus in comp.object about use of FACTORY, (which many have) and how it
> is used in COBOL - you might just as well ask the question in Hindi -
> you'll get the same result.
>
Why would I ask them anything? I use the factory class in OO COBOL without
problem and have done so since day one. What question am I supposed to be
asking?
> Yep - all sorts of ways of doing Treeviews, including one example I saw
> written using ASP. But until you actually have a *need* to play with
> these new features/languages, as Warren aptly said, the code looks like
> an engineering drawing.
>
As Richard has pointed out, what is unfamiliar looks "wrong".
> So perhaps I shouldn't re-invent the wheel in COBOL for Treeviews and
> should search the Web for just the right component.
You should do whatever you feel comfortable with. But don't confuse 'need'
with 'want'.
Let me first lay
> down a spec :-
>
> 1. Treeview
> 2. Ability to have/not have, buttons/lines/LinesAtRoot
> 3. Expandable number of Levels
> 4. Both Label editing or calling a Dialog to do editing
> 5. Icons
> 6. Checkboxes
> 7. Colouring of Labels
> 8. Combo Dropdown lists attached to a node in a Level
> 9. Ability to build Treeview on the fly - from user input
> 10. Not on the fly - build the Treeview from a DB and update the DB
> 11. Using the Drop and Drag feature to move Levels around and accommodate
> updating the DB with those MOVES - AND MOST IMPORTANT, to ensure the
> Drag and Drop doesn't create a cock-up in the DB
> 12. Splitview - Treeview with an accompanying Window - like Kellie's
> insistence on using ListView
> 13. Pull up web pages/maps resulting from a selection.
> 14. Change sizing as a result of specifying the ImageList
> 15. What dictionary/collection features do they provide to access what
> has been selected
>
> 16. Wont get this last one - because it's me specifically - changing
> colour of icons or checkbox value or Label colour based on updating.
>
> I think that's a reasonably comprehensive list.
>
Yes. It is a perfect example of the design requirements being dictated by
the technical environment. The tail wagging the dog. Do you honestly believe
your Treeview requirement would be exactly the same if you hadn't already
invested all the time you have in N/E COBOL? If you didn't KNOW what the
capabilities of a Treeview object (as defined by the Windows API or your N/E
environment) were, you'd express your requirement in a completely different
way. What you are doing is not "wrong" it just isn't NECESSARY from a
business point of view. You could get all the facilities you require from a
combination of components and some "glue" in COBOL or anything else you
like, but that doesn't mean you have to. And I am NOT saying there is only
one "right" way. Some years ago I also developed an application that needed
Treeviews. I used the standard component provided by PowerCOBOL, had it
working in 2 ws, wrote a paper on it for some people in South America so
they could do likewise, (it is still on their website), and moved on to the
next problem.
The point I postulated in the mail you took exception to was: When people do
things that are tedious and mind bending, not because they HAVE to, but
because they WANT to, then that is like religious flagellation. Self imposed
punishment for some imagined sin.
Like I said earlier, there is little point in us debating this because the
viewpoints are totally different and there is nothing "wrong" with either of
them.
> 17. Component is for VB/Delphi/dotNet - forget it. There were examples
> prior to dotNet but the developers tend to be taking up the dotNet game.
> 18. Component MUST be usable from existing Windows environment prior
> to dotNet
>
> 19,. Last but not least - price - can go from $100 up to one I saw for
$550
>
> As a promoter of using Components, "and... that is the only way to go",
I don't believe I said that, but I might have. I believe it is true, for me
at least.
> care to google and find me one that fits at least 90-95% of above
> criteria.
Glad to. I charge $120 an hour and will deliver you a solution that meets
all of your stated requirements in not less than 20 hours.
I've certainly seen screenshots of most of the above features
> - but NOT in one component. And as yet, not one that satisfactorily
> described updating a database, although I'm sure some must have that
> feature.
>
Why do you require one component?
> And when challenged, stick to topic. (Well *actually* it wasn't meant to
> be a challenge - more, why keep telling us we should drop COBOL) :-
>
If you actually considered what I wrote, you would see why I'm telling you
to drop COBOL. (I'm not , as it happens, but I'm tired of explaining...)
<snipped>
>Ever thought about it the other way around,
> take up the challenge and try and ENCOURAGE others to use COBOL, or at
> least a mix, rather than think of COBOL as a dodo.
Or I could encourage the dinosaurs to visit the tar pit...
Pete.
| |
| Pete Dashwood 2005-02-26, 3:55 am |
| Your point on source code is a good one, but I'm not persuaded.
There are many objects I use every day that I don't WANT to see the source
code of.
The time will come when there will be so many in use, that it would not be
possible to check them all anyway.
It's an interesting point about security, though. I'll discuss this with
some others who use components every day and see what their thoughts are.
Pete.
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1109375937.514623.73440@l41g2000cwc.googlegroups.com...
> and
> for the
>
> Where have you been for the last few years ? Certainly through the 80s
> and most of the 90s the prevailing model was the proprietry development
> of software driven mainly by profit motive. Eventually this was
> dominated by one company that had the power to decide who would be
> winners and who would be losers (by being purchased, assimilated, or
> simply excluded from the marketplace). Actually this is still
> happening.
>
> The reaction to this was to evolve a model that could not be
> assimilated, bought, or squashed. That could not be excluded.
>
> Your quote above describes exactly dozens or hundreds of projects which
> are continuing with or without industry support.
>
> In fact with Cobol it wasn't for 'the greater good', it was so the
> companies involved that were paying the bills, could obtain contracts
> from the DoD.
>
>
> That was MS's stance for many years. It is changing. See MS's
> comments about why they will release some of the MSSQL Server source
> code.
>
> The problem is that many no longer trust software that is locked up.
> Viruses, spyware, zombies etc (in Windows) have educated users to the
> fact that their computers may be (and in fact are) sending their data
> to MS and to others.
>
> The advantage of source code is not that you can change it, or that you
> can see it, but that _anyone_ can see it and thus it needs to be clean
> or the whistle will be blown.
>
> Security by obscurity has failed, closed source is no longer trusted.
> Even MS recognise this now.
>
>
| |
|
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:UnPTd.508710$Xk.78771@pd7tw3no...
> Pete Dashwood wrote:
> So perhaps I shouldn't re-invent the wheel in COBOL for Treeviews and
> should search the Web for just the right component. Let me first lay down
> a spec :-
>
> 1. Treeview
> 2. Ability to have/not have, buttons/lines/LinesAtRoot
> 3. Expandable number of Levels
> 4. Both Label editing or calling a Dialog to do editing
> 5. Icons
> 6. Checkboxes
> 7. Colouring of Labels
> 8. Combo Dropdown lists attached to a node in a Level
> 9. Ability to build Treeview on the fly - from user input
> 10. Not on the fly - build the Treeview from a DB and update the DB
> 11. Using the Drop and Drag feature to move Levels around and accommodate
> updating the DB with those MOVES - AND MOST IMPORTANT, to ensure the Drag
> and Drop doesn't create a cock-up in the DB 12. Splitview - Treeview with
> an accompanying Window - like Kellie's
> insistence on using ListView
> 13. Pull up web pages/maps resulting from a selection.
> 14. Change sizing as a result of specifying the ImageList
> 15. What dictionary/collection features do they provide to access what
> has been selected
> 16. Wont get this last one - because it's me specifically - changing
> colour of icons or checkbox value or Label colour based on updating.
> I think that's a reasonably comprehensive list.
> 17. Component is for VB/Delphi/dotNet - forget it. There were examples
> prior to dotNet but the developers tend to be taking up the dotNet game.
> 18. Component MUST be usable from existing Windows environment prior
> to dotNet
> 19,. Last but not least - price - can go from $100 up to one I saw for
> $550
>
> As a promoter of using Components, "and... that is the only way to go",
> care to google and find me one that fits at least 90-95% of above
> criteria. I've certainly seen screenshots of most of the above features -
> but NOT in one component. And as yet, not one that satisfactorily
> described updating a database, although I'm sure some must have that
> feature.
Why wouldn't you create multiple components that have solid designs (not ONE
component) and then sell them for $500?
Seems to me that you just need multiple components with a fairly simple
vetoable event model.....I don't understand your obsession with ONE
component- kind of defeats the point. By definition, a component is not a
monolithic piece of code.
A combo box component, a db access comoponent, a label component.......As
for item 16 - I'm sure you can find a checkbox that you can change based on
updates.
What does 18 mean? I believe Pete was espousing his beliefs for the future
(and 2015 is way out there...by then Java should be toast too)....I'm not
sure why he needs to comment on an architecture principle based on running
Windows 3.1/95. As with everything else, you could always write the
necessary software to run whatever you want to run on that platform. Even
Bill is getting worried that some Linux haxors are creating the necessary
libraries to run dotNet on Linux.....
Fact is though, that everything is "de jour" and everything always will be -
the paperless society uses more paper than ever. OO went into hibernation
for years and then came back. Client Server has been and gone and been
and....well hanging on......SAP was on the ropes in the early 90s and now is
back....Siebel was going to conquer the world and has been sliding since....
IT is a battle of techno gs trying to have fun with code, and the
business is trying to find ways to cut funding and never the twain shall
meet. I've always said, coders just start moving up the business
chain.....coders are becoming configuration specialists....soon they will be
fully fledged analysts...nd then the world will realize that a lot of coders
are morons.
JCE
JCE
| |
|
| "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:38ahcfF5j8ot2U1@individual.net...
> Your point on source code is a good one, but I'm not persuaded.
>
> There are many objects I use every day that I don't WANT to see the source
> code of.
>
> The time will come when there will be so many in use, that it would not be
> possible to check them all anyway.
>
> It's an interesting point about security, though. I'll discuss this with
> some others who use components every day and see what their thoughts are.
>
> Pete.
There's a difference between not WANTING to see, and not being ALLOWED to
see.
The point is that the end user doesn't NEED to UNDERSTAND the source code -
so I think you're argument is safe (if I'm not mistaken)..
Maybe this is the time I start my new business....component certification r
us....
JCE
| |
| Jeff York 2005-02-26, 8:55 am |
| "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>I said in 1997 that COBOL would be dead by 2015. It wasn't just "doom and
>gloom" or scare mongering, it was based on extrapolation of what was
>happening in the market place at that time.
That's OK then.. I retire in 2009. :-)
--
Jeff. Ironbridge, Shrops, U.K.
jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)
.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."
Henry James, (1843 - 1916).
| |
| docdwarf@panix.com 2005-02-26, 3:55 pm |
| In article <389m9kF5jgt1bU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>Fair comment and a good point, Doc. I am chastened... <g>
Given the quality of gait of most men of your antiquity, Mr Dashwood,
you'll most likely soon be caughtened.
(definitions below quoted from heep://www.m-w.com)
(Note to non-native English speakers... and some native, as well: my
response relies on the homophonal relationship between 'chased', the past
tense of the infinitive 'chase' ('1 a : to follow rapidly : PURSUE b :
HUNT'), and 'chaste', an adjective used to indicate 'pure in thought and
act' (especially relating to sexual matters). 'Chasten' is a variant of
'chaste' and is a transitive verb defined as 'to correct by punishment or
suffering : DISCIPLINE; also : PURIFY'... it is often used with a
connotation of shame, embarassment or rueful regret, an attitude of 'I
should have known better, yes'.
My response, then, took Mr Dashwood's 'chastened' back to its root of
'chaste' and playing on the pun manifested in 'Young women enjoy being
chaste (chased)... but they more enjoy being caught.' and applying the
inflection to... oh, never mind, a joke explained is a joke lost.)
DD
| |
| Warren Simmons 2005-02-26, 3:55 pm |
| jce wrote:
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:38ahcfF5j8ot2U1@individual.net...
>
>
>
> There's a difference between not WANTING to see, and not being ALLOWED to
> see.
>
> The point is that the end user doesn't NEED to UNDERSTAND the source code -
> so I think you're argument is safe (if I'm not mistaken)..
>
> Maybe this is the time I start my new business....component certification r
> us....
>
> JCE
>
>
This message gives me a chance to say, source program documentation
is NOT only for the programmer, and operations. There is the poor
guy emm... years down the pike. Old program, old application,
old source listing (if you are lucky)! Some pictures are better
than words, but words define the picture.
Maybe.
Warren Simmons
| |
| Pete Dashwood 2005-02-26, 8:55 pm |
|
<docdwarf@panix.com> wrote in message news:cvpqv2$t5n$1@panix5.panix.com...
> In article <389m9kF5jgt1bU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> Given the quality of gait of most men of your antiquity, Mr Dashwood,
> you'll most likely soon be caughtened.
>
Chy monkey!
Despite my 60th birthday approaching in a few ws, I am pleased to say
there is nothing wrong with my quality of gait. I swim a kilometre a w,
my weight is steady, blood tests all show normal, I don't look my age (not
that I care anyway), and, so far, I am not experiencing any of the twinges
and aches one would expect at this time of life.
I put it down to clean living and a right mental attitude.<g>
(The monkey glands, vitamins, sex therapy and high protein diet have nothing
to do with it...)
As for being 'caughtened', it is unlikely to happen...
Pete.
<snipped truly  exposition of what was, at best, a feeble pun from the
Doc...<g>>
| |
| James J. Gavan 2005-02-26, 8:55 pm |
| jce wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:UnPTd.508710$Xk.78771@pd7tw3no...
>
Good comments but....
Firstly the features that I suggested a Treeview component should have.
Thinking of Warren's analogy to Lego - you suggest you'll take a couple
of Lego pieces and build one unit. Then you contend :-
> Seems to me that you just need multiple components with a fairly
> simple vetoable event model.....I don't understand your obsession with
> ONE component- kind of defeats the point. By definition, a component
> is not a monolithic piece of code.
Just noticed in above - please give me a source for a concise definition
of a computer component - to date I haven't found one !
Your "fairly simple" then takes your mini Lego units and glues them
together to form one super Treeview Lego. Seeing that your mini Lego
units probably come from different sources, what's the likelihood of "it
ain't so simple' once you start trying to glue them together. Bearing in
mind many of the component-makers have now or are switching their
components to dotNet - how about 'Musical Chairs' when Uncle Bill
introduces Longhorn ?
But that aside - if we are talking Treeeviews - isn't it understood that
there must be a standard set of MINIMUM features for any Windows control
- which is what a Treeview is ?
Then from Feb 25th :-
[color=darkred]
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........<<<
I'm quite sure as a 'component guy' you agree. Now here's the point,
what I actually want to do is available using N/E GUI classes - with the
exception of what started the APIs query.
Somehow, for the 'real world' application, not my dummy test using a
Cheese hierarchy, I wanted to indicate which nodes had been updated.
Searching the Web I found screenshots with Checkboxes in Treeviews, but
never actually found coloured labels. So jokingly, I asked Michael and
Kellie - they supplied some API solutions. Nothing immediately apparent
in Net Express, although given a pure API solution it *might* be
possible in N/E perhaps using methods of which I haven't yet understood
the significance. The alternative is to have a method including the
specific API call.
At this stage I had ignored icons - depending upon label lengths and
using folder image icons or whatever, as in the Windows Explorer, they
tend to take up real-estate. Then, rather than get involved in either
checkboxes or label colouring I hit upon the idea of using icons RedBall
= not Updated and GreenBall = Updated.
All that is required, and doesn't affect methodology, is figuring the
logic to climb up through the Tree levels as necessary to set icons to
GREEN when all the lower level nodes are GREEN.
So given that, why would I be even remotely interested in either APIs or
components ?
Taking the spec and what I *CAN* already do using methods in Net Express
GUIs :-
[color=darkred]
[color=darkred]
Well the answer to 17/18 is MONEY. Why should I be forced to upgrade to
use dotNet for Components, which is where many of the component makers
have gone, and of course, the reference to Longhorn earlier.
Now both you and Pete are looking at this as component advocates. I
don't reject them, but I was looking for features I can use within my
own compiler.
First off, from memory because I don't squirrel away previous messages.
Perhaps some 18 months back I described, versus Pete's String2Num
component my approach in N/E, but not a direct competiotor to his
component; the example was a method to create an entryfield, taking into
account different roperties. His response - a dismissal with 'It needs
too much maintenance'. With a fixation on components he isn't quite as
flexible as he thinks he is.
Now you yourself referred to monolithic code. Perhaps that's another way
of saying spaghetti code. Firstly there are a finite set of Windows
controls and each with a finite set of methods applicable to each.
Chances are most of us possibly only use 30% of methods applicable to
one control. There might be a slightly different mix of that 30%
depending upon how the developer thinks when in designing mode. (Coupled
with that, a large number of GUI methods are common to a fairly large
number of individual GUI controls.
Now jump across to the thread Treeviews and look at the code I provided
for Kellie to illustrate REUSE - which she obviously doesn't buy into.
The parameter class is a summation of the info from the Resource File
created by the Dialog Editor. Currently, regardless of the number of
dialogs I want to create, I have that set of parameters for each
separate dialog. I have a template class TabbedDialog ('Tabbed' as
opposed to using the <ENTER> key).
Without a double check TabbedDialog has some 86 methods covering all
those controls I use. Haven't done a checklist, but I think the only one
to date not included is Listview. Regardless of which dialog, the
TabbedDialog does following :-
- Creates controls, both statically from the Resource info. or
dynamically; the latter is primarily used for entryfield two-dimensional
tables. On Creation each object also contains a reference to the
'returning method name' triggered by an Event
- methods to fill controls with existing data from a DB
- Return methods - uses the sequenced collection to get the appropriate
method name (referred to above) to return the result to os-Caller - the
Business Logic
- 'HouseKeeping methods' if you like, "setEnable"., "setDisable", "hide"
etc., and using co-ordinates to focus the Mouse cursor on either the
Default button or point it directly at a Listbox. Where necessary also
colouring, (with the exception of Droplist colouring where David Sands
from M/F provided the necessary code). Additionally the application is
largely comprised of measurements : 1.234 inches or 12.345 cms values.
So without returning to the Caller (Business) and where user enters
those as integers for convenience, a Dialog Housekeeping method also
redisplays values with the decimal.
Now of course the intent is the templae is meant to setup and habndle
the bare bones. In the case of Treeviewing, having created a dialog to
contain the Treviewontrol the display logic is controlled in the
Business class (CheeseDBI in the example I posted for Kellie).
Where does Pete's maintenance come in ? Pass a set of Parameters and
TabbedDialog is just like a black box. Now if you view the above as
monolithic, so be it - but it certainly works for me at the moment.
Yes components do make sense, but they aren't necessarily the only
approach using OO. Pete mentioned the difference between NEEDS and
WANTS. Sure, I know exactly :-
- NEEDS - use existing features in N/E and,
- WANTS - don't want to shell out money unnecessarily
(Swtich the words NEEDS and WANTS - it's still the same intent :-) )
The pity is that J4 predecessors never had the foresight to consider
GUIs - 'Hey buster, we only think mainframe'. (The pattern was there
with the release of Smalltalk '76). COBOL then, a predominant force,
could possibly have been calling the shots on GUI-ing rather than Billy
Boy !
Jimmy
| |
| Pete Dashwood 2005-02-26, 8:55 pm |
|
"jce" <defaultuser@hotmail.com> wrote in message
news:OnZTd.119724$JF2.66155@tornado.tampabay.rr.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:38ahcfF5j8ot2U1@individual.net...
source[color=darkred]
be[color=darkred]
are.[color=darkred]
>
> There's a difference between not WANTING to see, and not being ALLOWED to
> see.
>
Yes, I agree. Richard's point is a good one. But this is a technical
audience; we all WANT to see what's going on. I suspect the 'man in the
street' doesn't. As component use is moving more towards the level of the
non-IT user (rather, the business specialist who really knows the business
processes but is not a programmer), then I think the majority of these end
users won't care about source code as long as the object does what it is
supposed to.
Even having been a programmer all my life, I find much sympathy with this
view. I don't personally want to vet every line of other people's source
code so I can be sure it is 'safe'. I think this is bordering on paranoia.
But, I can't prove or support my position and it is certainly arguable.
Maybe I've been lucky. For the past 8 years or so I have been using third
party components that did exactly what they were specified to do, did NOT
infect my machine or send messages back to some mysterious host hidden in
the shadows (I have a firewall and regularly monitor at the packet level
traffic proceeding in and out of my system...), and were well supported by
the people who wrote them. I tried to make my own components as good.
> The point is that the end user doesn't NEED to UNDERSTAND the source
code -
> so I think you're argument is safe (if I'm not mistaken)..
>
I hope so <G>.
> Maybe this is the time I start my new business....component certification
r
> us....
>
THAT is a really good idea... There is a lot of concern out there and some
of it is justifiable. There is almost certainly an opportunity for an
unbiased third party to test and verify components. I know you said it as a
joke, but it wouldn't surpise me to see such a service arising in the near
future.
Thanks for your post.
Pete.
> JCE
>
>
>
| |
| Pete Dashwood 2005-02-27, 3:55 am |
|
"Jeff York" <ralf4@btinternet.com> wrote in message
news:h5o021ldb823r26vdoasms2vafvpcuj6ob@
4ax.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
>
> That's OK then.. I retire in 2009. :-)
>
I thought I had two years ago. Certainly, life has been pretty easy and I've
enjoyed focussing on things other than corporate politics and technical
hassles. It has been a delight getting back into the community where I am
supposed to live (I had actually spent a total of 4 months at home in the
preceding 27 years...).
Of course, (and I'm sure you'll find this too, Jeff), once you have been a
programmer the urge to do it is always there. There is something satisfying
about designing and creating code that runs and does stuff (hopefully the
right stuff...). I have done a number of projects to keep my hand in, and
look at new technology, but I don't see this this as "work". (It has been
for non-profit organisations and I haven't required payment for it.)
However, just when I was settling into a very comfortable groove and had
hung up my working clothes, I have been approached by a consultancy in
Wellington who have something really exciting coming up and felt I could
contribute. So it looks as if retirement may be an illusion after all...
The bottom line is that we never quite know what life has in store, and you
may find in 4 years that you're not quite ready to retire...
Whether my prediction re COBOL is true or not, I hope you enjoy whatever you
decide to do.
Pete.
> --
> Jeff. Ironbridge, Shrops, U.K.
> jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
> and don't bother with ralf4, it's a spamtrap and I never go there.. :)
>
> ... "There are few hours in life more agreeable
> than the hour dedicated to the ceremony
> known as afternoon tea.."
>
> Henry James, (1843 - 1916).
>
>
>
| |
| Pete Dashwood 2005-02-27, 3:55 am |
|
"jce" <defaultuser@hotmail.com> wrote in message
news:diZTd.119723$JF2.112878@tornado.tampabay.rr.com...
>
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:UnPTd.508710$Xk.78771@pd7tw3no...
down[color=darkred]
accommodate[color=darkred]
Drag[color=darkred]
with[color=darkred]
features -[color=darkred]
>
> Why wouldn't you create multiple components that have solid designs (not
ONE
> component) and then sell them for $500?
>
> Seems to me that you just need multiple components with a fairly simple
> vetoable event model.....I don't understand your obsession with ONE
> component- kind of defeats the point. By definition, a component is not a
> monolithic piece of code.
> A combo box component, a db access comoponent, a label component.......As
> for item 16 - I'm sure you can find a checkbox that you can change based
on
> updates.
>
> What does 18 mean? I believe Pete was espousing his beliefs for the
future
> (and 2015 is way out there...by then Java should be toast too)....I'm not
> sure why he needs to comment on an architecture principle based on running
> Windows 3.1/95. As with everything else, you could always write the
> necessary software to run whatever you want to run on that platform.
Even
> Bill is getting worried that some Linux haxors are creating the necessary
> libraries to run dotNet on Linux.....
>
> Fact is though, that everything is "de jour" and everything always will
be -
> the paperless society uses more paper than ever. OO went into
hibernation
> for years and then came back. Client Server has been and gone and been
> and....well hanging on......SAP was on the ropes in the early 90s and now
is
> back....Siebel was going to conquer the world and has been sliding
since....
>
> IT is a battle of techno gs trying to have fun with code, and the
> business is trying to find ways to cut funding and never the twain shall
> meet. I've always said, coders just start moving up the business
> chain.....coders are becoming configuration specialists....soon they will
be
> fully fledged analysts...nd then the world will realize that a lot of
coders
> are morons.
>
Er...that happens around the time they become MANAGERS...<g>
Pete.
| |
| Pete Dashwood 2005-02-27, 3:55 am |
|
"Warren Simmons" <wsimmons5@optonline.net> wrote in message
news:RR3Ud.277$Z01.133@fe12.lga...
> jce wrote:
source[color=darkred]
be[color=darkred]
are.[color=darkred]
to[color=darkred]
code -[color=darkred]
certification r[color=darkred]
> This message gives me a chance to say, source program documentation
> is NOT only for the programmer, and operations. There is the poor
> guy emm... years down the pike. Old program, old application,
> old source listing (if you are lucky)! Some pictures are better
> than words, but words define the picture.
>
> Maybe.
Or maybe not <g>.
What you are describing is exactly how it was, Warren. When code was written
in house and maintained in-house, documentation was critical, for exactly
the reason you outlined.
But that is not the case any more.
Code is NOT being written in house. It is being outsourced, or handled by a
package, or it is component based and the source is not available.
In the COBOL world of old, this would be frightening and unthinkable, but in
today's world it isn't.
You read my article about components
(http://66.152.52.10/archives/v3/v30201 written 4 years ago now; most of the
things it predicted have come to pass) where I first postulated the idea
that source code was really not so important as it had been.
We are using components every day and much of the time we don't even know we
are doing it.
Much of what we take for granted (like the Operating System) we just use and
grumble if it doesn't work. The same is becoming true of system environments
(especially the Web) where components are playing a greater and greater
role.
In the example ASP code I posted the other day, just about EVERYTHING is an
object, instantiated from a component. Yet kids are using this stuff every
day. They neither know nor care about the source code. They change the
properties, invoke the methods, and the thing works.
And this is slowly but surely extending right down to applications. Today,
the environment is like an extension of the Operating System; tomorrow
application components will be reused and plugged into custom systems
without any problem regarding source code or maintenance.
If you have no intention of maintaining a function, if the function never
NEEDS maintaining, then why would you be concerned about the source code? It
is like maintaining a brick; you don't. You replace it if it no longer fits
properly. I've mentioned this before here but the response was blank
looks... <g> ("Not have to maintain code?! Dunno what he's on but I wouldn't
mind half an ounce!")
I can understand this response because most of the people in this forum
(self included) have spent a large part of our working lives changing code
that was written by ourselves or someone else, just to keep computerised
business processes working and current. It is fundamental to the procedural
paradigm. Procedures and processes change, so the code must change.
It isn't true for the non-procedural paradigm. (Object Oriented). The
process or procedure may change but the objects don't. Provided they are
designed properly and abstracted properly, (this has all been covered here
with analogies about Xmas Trees and so on, to the point where I'm really
tired of it and not prepared to do it any more) then the process may use the
objects in different ways, but the underlying objects are still the same. A
person/client/patient/member/subscriber/consumer/customer/collector/buyer/se
ller/tax payer/whatever... still has an attribute called 'name', they still
have a 'date of birth' and so on... the object doesn't change. Methods to
add, change, delete, and retrieve their properites from an object don't
change either. (You might add some properties to it and or extend the
existing methods, but if you designed it properly in the first place you
shouldn't need to, and even if you DO need to, it doesn't affect what you
have already. The beauty of inheritance. (And, although it is hard for some
to swallow, it obviates much of the regression testing that is the bane of
procedural programmers' lives...)
All of this represents a fairly radical shift in the mindset of people
raised on COBOL and procedural programming.
It is small wonder that it is not well received in this community.
Well, the world moves on... Some of us try and move with it. others even try
and anticipate where it is going so we can take a shortcut and meet it
there.
The bottom line for you, Warren, is that the world you contributed to
establishing, is declining. Not because the approaches were intrinsically
wrong, but because it is no longer capable of meeting the needs of the
market place. It served the world well and the people of your generation can
be proud of what was achieved.
I have nothing but respect and admiration for you all.
Pete.
>
> Warren Simmons
>
>
| |
| docdwarf@panix.com 2005-02-27, 3:55 am |
| In article <38cgn5F5m0sfuU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:cvpqv2$t5n$1@panix5.panix.com...
>Chy monkey!
Pish and tush... I bet you say that to *all* the boys.
DD
| |
| Pete Dashwood 2005-02-27, 3:55 am |
| It isn't really important, but in case anyone tried to follow the link
embedded in this response, it was incorrect. It needs to have .asp added to
it:
http://66.152.52.10/archives/v3/v30201.asp
Sorry,
Pete.
Top Post, nothing more below.
"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:38cu23F5l1he7U1@individual.net...
>
> "Warren Simmons" <wsimmons5@optonline.net> wrote in message
> news:RR3Ud.277$Z01.133@fe12.lga...
> source
not[color=darkred]
> be
with[color=darkred]
> are.
> to
> code -
> certification r
>
> Or maybe not <g>.
>
> What you are describing is exactly how it was, Warren. When code was
written
> in house and maintained in-house, documentation was critical, for exactly
> the reason you outlined.
>
> But that is not the case any more.
>
> Code is NOT being written in house. It is being outsourced, or handled by
a
> package, or it is component based and the source is not available.
>
> In the COBOL world of old, this would be frightening and unthinkable, but
in
> today's world it isn't.
>
> You read my article about components
> (http://66.152.52.10/archives/v3/v30201 written 4 years ago now; most of
the
> things it predicted have come to pass) where I first postulated the idea
> that source code was really not so important as it had been.
>
> We are using components every day and much of the time we don't even know
we
> are doing it.
>
> Much of what we take for granted (like the Operating System) we just use
and
> grumble if it doesn't work. The same is becoming true of system
environments
> (especially the Web) where components are playing a greater and greater
> role.
>
> In the example ASP code I posted the other day, just about EVERYTHING is
an
> object, instantiated from a component. Yet kids are using this stuff every
> day. They neither know nor care about the source code. They change the
> properties, invoke the methods, and the thing works.
>
> And this is slowly but surely extending right down to applications. Today,
> the environment is like an extension of the Operating System; tomorrow
> application components will be reused and plugged into custom systems
> without any problem regarding source code or maintenance.
>
> If you have no intention of maintaining a function, if the function never
> NEEDS maintaining, then why would you be concerned about the source code?
It
> is like maintaining a brick; you don't. You replace it if it no longer
fits
> properly. I've mentioned this before here but the response was blank
> looks... <g> ("Not have to maintain code?! Dunno what he's on but I
wouldn't
> mind half an ounce!")
>
> I can understand this response because most of the people in this forum
> (self included) have spent a large part of our working lives changing code
> that was written by ourselves or someone else, just to keep computerised
> business processes working and current. It is fundamental to the
procedural
> paradigm. Procedures and processes change, so the code must change.
>
> It isn't true for the non-procedural paradigm. (Object Oriented). The
> process or procedure may change but the objects don't. Provided they are
> designed properly and abstracted properly, (this has all been covered here
> with analogies about Xmas Trees and so on, to the point where I'm really
> tired of it and not prepared to do it any more) then the process may use
the
> objects in different ways, but the underlying objects are still the same.
A
>
person/client/patient/member/subscriber/consumer/customer/collector/buyer/se
> ller/tax payer/whatever... still has an attribute called 'name', they
still
> have a 'date of birth' and so on... the object doesn't change. Methods to
> add, change, delete, and retrieve their properites from an object don't
> change either. (You might add some properties to it and or extend the
> existing methods, but if you designed it properly in the first place you
> shouldn't need to, and even if you DO need to, it doesn't affect what you
> have already. The beauty of inheritance. (And, although it is hard for
some
> to swallow, it obviates much of the regression testing that is the bane of
> procedural programmers' lives...)
>
> All of this represents a fairly radical shift in the mindset of people
> raised on COBOL and procedural programming.
>
> It is small wonder that it is not well received in this community.
>
> Well, the world moves on... Some of us try and move with it. others even
try
> and anticipate where it is going so we can take a shortcut and meet it
> there.
>
> The bottom line for you, Warren, is that the world you contributed to
> establishing, is declining. Not because the approaches were intrinsically
> wrong, but because it is no longer capable of meeting the needs of the
> market place. It served the world well and the people of your generation
can
> be proud of what was achieved.
>
> I have nothing but respect and admiration for you all.
>
> Pete.
>
>
>
>
>
>
>
| |
|
| Pete Dashwood wrote:
> It isn't really important, but in case anyone tried to follow the link
> embedded in this response, it was incorrect. It needs to have .asp added to
> it:
> http://66.152.52.10/archives/v3/v30201.asp
You didn't use that mind-reading component on it, did you? ;) I guess
you've seen the dialog(ue) /n./ between Mr. Tees and me about OO COBOL
and the like - it's been quite informative.
Monday morning, my wife goes in for a very common abdominal surgery -
one that will net me my third son. :) I'll have some time in the
hospital to really play around with making something OO that does
something other than display text. (Of course, in between making the
baby's web pages so all the family can see pictures...)
I can now see how easy it would be to make a component using OO COBOL...
:) I know, the runtime has to go with it - maybe someone will figure
out how to overcome that hurdle soon. (Does N/E use the .NET
architecture to avoid having to have a separate runtime installed on the
server?)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Richard 2005-02-27, 3:55 am |
| > Yes, I agree. Richard's point is a good one. But this is a technical
> audience; we all WANT to see what's going on. I suspect the 'man in
the
> street' doesn't.
That is certainly true. I don't want the see the source code either.
I may need it (without looking at it) if I want to compile up a
specific version, but just knowing that someone else _can_ look at it
gives me confidence that the authors have not put in some backdoor code
that will be sending data about me, or my computer, or my bank account
somewhere.
| |
| Jeff York 2005-02-27, 3:55 pm |
| "Pete Dashwood" <dashwood@enternet.co.nz> wrote:
>
>"Jeff York" <ralf4@btinternet.com> wrote in message
> news:h5o021ldb823r26vdoasms2vafvpcuj6ob@
4ax.com...
>
>I thought I had two years ago. Certainly, life has been pretty easy and I've
>enjoyed focussing on things other than corporate politics and technical
>hassles. It has been a delight getting back into the community where I am
>supposed to live (I had actually spent a total of 4 months at home in the
>preceding 27 years...).
After 4 months in 27 years I think I wouldn't even remember where it
was.. However, on the basis that "home is where the heart lies..".
>Of course, (and I'm sure you'll find this too, Jeff), once you have been a
>programmer the urge to do it is always there. There is something satisfying
>about designing and creating code that runs and does stuff (hopefully the
>right stuff...). I have done a number of projects to keep my hand in, and
>look at new technology, but I don't see this this as "work". (It has been
>for non-profit organisations and I haven't required payment for it.)
I'm fairly certain that you'll prove to be right in my case too. The
idea of retirement from "work" is more a retirement from "obligation"
- to meet deadlines, support users, etc.. I don't think that I'll
give up programming, just redirect it into things that *I* find
interesting. In fact, because of this I've probably studied / learned
more new languages in the last few years than the previous 20. :-)
>However, just when I was settling into a very comfortable groove and had
>hung up my working clothes, I have been approached by a consultancy in
>Wellington who have something really exciting coming up and felt I could
>contribute. So it looks as if retirement may be an illusion after all...
I think that I've had my fill of "We have exciting things coming up.."
:-)
>The bottom line is that we never quite know what life has in store, and you
>may find in 4 years that you're not quite ready to retire...
>
>Whether my prediction re COBOL is true or not, I hope you enjoy whatever you
>decide to do.
Sailing round the world is pretty well at the top of the list.. :-)
--
Jeff. Ironbridge, Shrops, U.K.
jjy@jakfield.xu-netx.com (remove the x..x round u-net for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)
.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."
Henry James, (1843 - 1916).
| |
| docdwarf@panix.com 2005-02-27, 3:55 pm |
| In article <u9j321lf05kc1b1ti8bk482lfovq17b2r5@4ax.com>,
Jeff York <ralf4@btinternet.com> wrote:
[snip]
>I'm fairly certain that you'll prove to be right in my case too. The
>idea of retirement from "work" is more a retirement from "obligation"
>- to meet deadlines, support users, etc.. I don't think that I'll
>give up programming, just redirect it into things that *I* find
>interesting. In fact, because of this I've probably studied / learned
>more new languages in the last few years than the previous 20. :-)
From
<http://groups.google.co.uk/groups?s...m&output=gplain> :
--begin quoted text:
But as for work... there was a recording I heard of a spiritual, 'Lord,
Take Me Over the Tide', which had the refrain of:
Lord, take me over the tide,
Oh Lord, take me over the tide,
When my work on Earth is ended,
And I cannot work any longer,
Please, Lord, take me over the tide.
.... and the profundity lies in the asking for a Divine Welcoming, the
Big Sleep, as it were, not 'when my time is right' or 'when Sweet
Shploingy calls me home'... but 'when my work is ended and I cannot work
any longer'.
Then again, I've been known to find profundity in odd places.
--end quoted text
DD
| |
| docdwarf@panix.com 2005-02-27, 3:55 pm |
| In article <4fb9c$42214bef$45491f85$11031@KNOLOGY.NET>,
LX-i <lxi0007@netscape.net> wrote:
[snip]
>Monday morning, my wife goes in for a very common abdominal surgery -
>one that will net me my third son.
A safe procedure and a fast, full and complete recovery for all involved.
Congratulations.
DD
| |
|
| docdwarf@panix.com wrote:
> In article <4fb9c$42214bef$45491f85$11031@KNOLOGY.NET>,
> LX-i <lxi0007@netscape.net> wrote:
>
> [snip]
>
>
>
>
> A safe procedure and a fast, full and complete recovery for all involved.
> Congratulations.
Thank you very much. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Pete Dashwood 2005-02-27, 8:55 pm |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:4fb9c$42214bef$45491f85$11031@KNOLO
GY.NET...
> Pete Dashwood wrote:
to[color=darkred]
>
> You didn't use that mind-reading component on it, did you? ;) I guess
> you've seen the dialog(ue) /n./ between Mr. Tees and me about OO COBOL
> and the like - it's been quite informative.
Donald has a very useful and pragmatic approach to OO. Yes, I saw the
exchange.
>
> Monday morning, my wife goes in for a very common abdominal surgery -
> one that will net me my third son. :)
It is monday morning here in NZ and I'm thinking of you both.
I'll have some time in the
> hospital to really play around with making something OO that does
> something other than display text.
Daniel! This might be one occasion when the notebook is best left at home...
? :-)
Or then again, maybe having your mind occupied could be a good thing.
However it is unlikely to be a long labour if surgery is being used.
(Of course, in between making the
> baby's web pages so all the family can see pictures...)
>
Please post the address; I'd love to have a look.
> I can now see how easy it would be to make a component using OO COBOL...
> :) I know, the runtime has to go with it - maybe someone will figure
> out how to overcome that hurdle soon. (Does N/E use the .NET
> architecture to avoid having to have a separate runtime installed on the
> server?)
>
I wrote a separate article about that a few years back too.
(http://66.152.52.10/archives/v5/v50101.asp)
You could download a sample component in COBOL and it had examples of how to
embed it in a web page. or invoke it from a web page when it is resident on
the server.
As you have a Fujitsu compiler, you can actually build a COM component
without any of the low-level hassle of needing to understand the wrapping.
PowerCOBOL provides an OO COM Component template and does all the wrapping
and typelib generation for you.. Their sample with the clock component is a
really good way to start, and it is documented very well in the PowerCOBOL
user guide. Be warned, though...building these things is addictive!
Good luck with the new arrival...
Pete.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ daniel@thebelowdomain ~
> ~ _____ / \ | ~ http://www.djs-consulting.com ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
> ~ h---- r+++ z++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
>
| |
|
| Pete Dashwood wrote:
>
>
>
> It is monday morning here in NZ and I'm thinking of you both.
Thanks. :)
>
>
> Daniel! This might be one occasion when the notebook is best left at home...
> ? :-)
>
> Or then again, maybe having your mind occupied could be a good thing.
> However it is unlikely to be a long labour if surgery is being used.
No - it will also be the receptacle for pictures from the digital
camera. I'll be able to get Jameson's pictures all set up so that once
I'm home, I can FTP and have it done.
> (Of course, in between making the
>
>
>
> Please post the address; I'd love to have a look.
I shall.
>
>
> I wrote a separate article about that a few years back too.
> (http://66.152.52.10/archives/v5/v50101.asp)
>
> You could download a sample component in COBOL and it had examples of how to
> embed it in a web page. or invoke it from a web page when it is resident on
> the server.
>
> As you have a Fujitsu compiler, you can actually build a COM component
> without any of the low-level hassle of needing to understand the wrapping.
> PowerCOBOL provides an OO COM Component template and does all the wrapping
> and typelib generation for you.. Their sample with the clock component is a
> really good way to start, and it is documented very well in the PowerCOBOL
> user guide. Be warned, though...building these things is addictive!
:) I need to broaden my views - something tells me that doing more OO
will help my procedural code be structured better as well.
> Good luck with the new arrival...
Thanks - I'm getting really excited. 12 hours to go!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Donald Tees 2005-02-28, 3:55 am |
| LX-i wrote:
> Pete Dashwood wrote:
<snipped every bit of Poor Petes' Post, but left his parting line in>
> :) I need to broaden my views - something tells me that doing more OO
> will help my procedural code be structured better as well.
>
>
>
It changes the way you think, which is the only truly important thing.
Best wishes for tomorrow. So does parenting <S>.
Donald.
| |
|
| Whilst on religion...I find it interesting how over the course of the last
decades that God has become a benevolent God whose believers will criticize
any surgeries that end life as "not God's will", but are more than happy to
promote surgeries that promote life as therefore "part of God's will". Once
upon a time, the Christian Church forbade cutting open the mother before she
was dead. Maybe He softened up.
That said, congratulations to you and yours, and hope for a full, complete
recovery from all....and many years of joy...followed by many years of
teenage angst....adult money problems...the ness of them moving back
in.....the ness of them leaving (wait, that's joy right, nope,
ness....joy)...the lack of communication when they meet the disapproved
boyfriend....and the sharing of holidays....the wedding.....the
grandkids...I think that sums it up.
JCE
"LX-i" <lxi0007@netscape.net> wrote in message
news:3644b$422219fd$45491f85$29511@KNOLO
GY.NET...
> docdwarf@panix.com wrote:
>
> Thank you very much. :)
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ daniel@thebelowdomain ~
> ~ _____ / \ | ~ http://www.djs-consulting.com ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
> ~ h---- r+++ z++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:ci8Ud.515452$Xk.49623@pd7tw3no...
> jce wrote:
> Good comments but....
It is going to become clear as you read this, that I've since gone back and
looked at your original posts...in the Treeview thread.
> Firstly the features that I suggested a Treeview component should have.
> Thinking of Warren's analogy to Lego - you suggest you'll take a couple of
> Lego pieces and build one unit. Then you contend :-
>
>
> Just noticed in above - please give me a source for a concise definition
> of a computer component - to date I haven't found one !
Any software subsystem or system that can be factored out and has a
standardizable or reusable exposed interface.
Unfortunately, a component is different depending on the level of
abstraction that you want to work at. A component could be a web service,
it may be a library module, or it may be as others seem to favour an ActiveX
object.
Personally, I think of it as any well defined software construct that is
usable in the environment in which you are working that has a well defined
and well documented interface. This leaves everything open =)
In a network environment - or a web service environment - the platform is
not significant, similarly if one is using CORBA. If you are writing a pure
100% windows client application, it could be any object / class made
available to you.
This is probably not the standard going definition of "component" software,
and is not I'm sure shared by the group but....I'm not particularly a
proponent of components to the same extreme as others and it works for me.
I would even consider something like Log4J a form of component software when
it is nothing more than a third party open source project that supports a
standard API.
> Your "fairly simple" then takes your mini Lego units and glues them
> together to form one super Treeview Lego. Seeing that your mini Lego units
> probably come from different sources, what's the likelihood of "it ain't
> so simple' once you start trying to glue them together. Bearing in mind
> many of the component-makers have now or are switching their components to
> dotNet - how about 'Musical Chairs' when Uncle Bill introduces Longhorn ?
It depends - I suggest that the KIS principle is often overlooked - if the
requirements were simplified (or god forbid, someone actually had to write a
business case) I think the days of Abba would be over (Gimme Gimme Gimme).
There are many faults with the component model - I would never claim them to
be a solution. I would firmly believe that a component architecture (using
my def) would survive a Longhorn better than your approach - primarily
because the work would be spread across tens/hundreds of people/code
generators not just you working to earn a buck.
That said, some of the problems you would see are:
Components implement more than is necessary to cover the least common
denominator view of a thing. This is my big issue with a language like Java
where the reserved words are few, and the API's are HUGE. If anyone care to
dispute this, I would be interested to know if ANYONE has read the latest
EJB spec cover to cover. The advantage of components, is that there will
more than likely be a lightweight version that supports most of your needs.
There will inevitable come a move to standardize certain standards. For
example, using log4j again, someone defines logging standards _after_ many
highly successful implementations
Platform dependency. People can argue all they want, but you will always
have the "windows" component
> But that aside - if we are talking Treeeviews - isn't it understood that
> there must be a standard set of MINIMUM features for any Windows control -
> which is what a Treeview is ?
Yes, but the understanding would not be consistent. MFC/.NET/Java, all
provide base Treeview function. Java has even gone to the trouble of
providing a JTree, a DataModel and a number of Views for you.
In my mind you are _using_ N/E components. You are just not using them as
true components because you are tying into the N/E way of doing things. So
maybe Longhorn comes out...and maybe Micro Focus goes broke..I think all I
was commenting on was that for some reason you were looking for a component
that did _everything_ you wanted. What you have are a set of loosely
coupled components. All I think I was suggesting is that you could more
tightly couple those components - only in terms of the glue - to form the
whole that you are looking for. This is, for the most part, what I think
you are doing. Perhaps you and I differ on the glue. Bottom line is that
if you work hard enough to look for something unique, you'll never find a
component to do anything :-)
Of course the same is true for any of the component models...the thing that
sets - in my mind - what you're doing apart is that you are much more tied
to a specific platform and architecture; however, if you're doing simple
GUI's then your platform of choice is acceptable.
I don't want to overlook the obvious which is that a good GUI design should
take precedence over the technology to produce it anyway. A good design
provides predictable interaction, should be readily repeatable.
> Then from Feb 25th :-
>
> 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........<<<
>
> I'm quite sure as a 'component guy' you agree. Now here's the point, what
> I actually want to do is available using N/E GUI classes - with the
> exception of what started the APIs query.
I still don't understand where you need the API for this, but I'm not
familiar with N/E GUI Classes. I would hope worst case you could subclass
a | | |