× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



John, Joe, Brad, Evan

(Sorry, long post.  But a difficult subject.  Thought I better split into
two, for length.  Second part relates directly to the first, and more to the
topic.)


Wish I could respond to this thread, in detail...  Three things prevent me:

a) time
b) knowledge of some of the technical details and
c) not having an academic degree.


But what I can add the discussion, relatively briefly, is that the
difficulty looking at these kinds of broad issues is that there are lots of
highly inter-related issues (really, interwoven is a better word) which are,
however, ***NOT DEPENDENT ON ONE ANOTHER***.

I this thread, so far, I would isolate the discussion into several issues
which are NOT dependent on one another:

a) Benefits of n-tier system design
b) Disadvantages of n-platform system design
c) Ways of isolating data that needs to be "secure"
d) Allowing appropriate levels of access to "secure" data


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Let me try to explain WHY these are not dependent on one another, by way of
a seemingly unrelated example:  use of the Primary Cycle.

There are a lot of fairly good arguments AGAINST using the Cycle, most of
which boil down to:  the technique is not understood.  It confuses people,
and has gone out of fashion, so less and less folks know what it is.  That
becomes a major-league maintenance problem.  Many programmers see a program
with a Primary file, and immediately GIVE UP trying to understand any of the
rest of the program.  I'm not addressing whether that's right or wrong...
It's a fact.  And as long as this fact exists, that ways heavily against
using the Primary cycle.

Few of my clients use it, so I rarely do, myself, anymore.  I think there
are DEFINITELY better ways, and worse ways, of coding programs.  Anyone who
has read even a few of these kinds of posts of mine, knows I have some very
strong views on these subjects...!  But these views don't override the
importance, to me anyway, of coding in a consistent style.  So I'll even
program in spaghetti, for a client, if that's the shop standard.  (Make it
"clean spaghetti", of course, and will re-write a program if that's what the
client wants.. but sure won't suggest it if they don't have the interest
and/or cost/time to spend on it...)

In my own shop, however, we stressed the Primary Cycle.  I got away from
using it, for a long time, until IBM came out with OPNQRYF.  At that time, I
went back to using it a lot...  The majority would call that "slipping back
into evil ways", but I'm not bothered much by what most people think.  I'm
more concerned with how quickly I can turn out a quality product.


Now what this discussion of the Primary Cycle has to do with the thread is
this:  There IS a lot to the point that a technique is no good, if "nobody"
knows how to use it.  But, at the same time, if programmers don't want to
look at the technique (any given technique), and if the schools don't want
to teach it...  ***Maybe these programmer's have a serious problem, and the
schools are not teaching the right things.***

I firmly believe this is the case regarding the Primary Cycle.  The argument
has often devolved to those against the technique saying, in essence, you
old dinosaurs need to forget that old crap, and learn the NEW WAY of doing
things.  As if there was some connection between using the Primary Cycle,
and not being able to learn new techniques...  But, obviously, there is no
such direct connection.  This comment is, itself, near 100% delusion.
Because those who state this point have, almost without exception, failed to
spend ANY time learning anything about the Primary Cycle.  They just reject
it, out of hand, because that's the "Conventional Wisdom".

I don't reject CW, out of hand, myself...  But I sure don't hold onto CW
that, IMV, works against me...

This debate about the primary cycle, when boiled down, comes down to:
because it's CW not to use it, people don't know it; and because people
don't know it, it shouldn't be used.  And there's a lot of truth to both
these sides.

However, the reality is this:  if you look at Doug Handy's post (in the
RPG400-L archives), which clearly and succinctly explains the cycle, and IF
YOU DON'T LOOK AT HIS POST FROM THE POV OF THE CW...:  Well.. even a person
who's blind in one eye can see how it works, in about 15 minutes or a
half-hour...!  That sort-of just blows the CW out of the water.  But a
person who's blind in both eyes (ie, buys into the CW) will NEVER understand
how the Cycle works.  So that becomes the major point in favor of the
argument not to use the Cycle.

Getting back into the technical details of the "debate" on this issue, it's
often a matter of opinion whether a given coding technique makes things
easier or not...  Well.. I say "often" when I actually mean "rarely".  The
reason there's an order of magnitude of difference between the best coders
and the average coder (who, IMNSHO, would qualify as mediocre) is the fact
that it's RARELY just a matter of personal opinion about whether a technique
makes things easier or not.

This point cannot be made any clearer, than the "debate" about the Cycle.
Many people say the MODERN RPG, has no need for this kind of crap.  In
actual fact, the modern RPG is ideally suited for the Cycle.  I say that
because I ALMOST NEVER use I-specs, anymore.  Rarely rename fields, and
don't use data structures...  (Meaning:  unless the client uses them.. and
that's getting rarer and rarer.)  So to some folks, that implies there's no
need for an I-spec.

But actually, that strengthens the idea of using an I-spec ***specifically
for indicating control breaks***.  I can't get over how well-suited the
modern RPG is suited for solving ONE OF THE FUNDAMENTAL PROCESSES INVOLVED
IN MANY, MANY BUSINESS PROBLEMS.  Despite all the whirly-gigs, one of the
fundamental processes is still sorting and breaking on data...

And now, the way I use RPG, it has a specification line for just that sole
purpose...!  Going back to Doug Handy's post, you can take someone with
almost NO knowledge of programming and, in maybe 15 minutes, they can start
churning out code to solve a major class of programs.  NOT ALL PROGRAMS...!
But a huge percentage of them, given the 15 minutes time invested.

That would imply, IMV, that this technique is better than sliced bread and
canned peas.

That makes the technique "a keeper", in my book...  (PROMO:  which I need to
get started on, BTW...;-)

Do I get upset when people don't see this POV...?!?  C'mon... GET REAL...!
I don't care very much about whether *I* use the technique at my client's
shops.  I make no effort to change their shop standards, as that's not my
job.  It SURE isn't my job to tell you how to code your programs, if that's
what you're thinking.  So.. NO, I ***do not*** get upset when people
ridicule me for using the Cycle.  (I think it's rather humorous, as I think
it reflects on them more than me.)  Different strokes for different folks.
I'm passionate about these views, but don't expect people to give up on the
CW, just because I have.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(to be continued...  the reason I spent most of the post on the above is
that the issue of CW defines this topic, IMV.)

jt


PS  I GOTTA start doing these using Word...  Dang near deleted part 2 of
2...  SHEESH...!  (Expecting a phone call...)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.