> I think Jon already responded nicely when he said 'Why
> teach new
> techniques using "old" tools - it doesn't make sense.'

Mainly because not everyone is using the new techniques.
And when you introduce a new topic like varying length
strings into a topic that is already confusing enough to the
average green screen programmer, it just makes it more
frustrating.

I like to remind those on the list that while we come here
for the latest and greatest, a much larger portion of the
RPG world is still working with RPGIII or RPGIII converted
to RPGIV code.  They also lurk on these lists.

>From responses from my books, I'd say I chose the right
path.  Those that are more advanced should have no problem
converting it to "newer techniques".  And I highly encourage
it in my books as well.

The biggest problem people have (actually there are 2) are
learning HTML and learning the very small bit of ILE that is
required for this.  Which is why in my 2nd book there is an
entire chapter on ILE...  enough to get the non-ILEer done.

When I write a book, or an article, I don't write for the
technically advanced folks like you and Jon.  I write it for
Joe 1-ProgrammerShop that is still fighting with his boss to
upgrade from CISC to RISC because I stil feel this is a
large part of my audience.

Sales and response to the books proves that this is a great
path to choose, although it is different from the other
mainstream authors and speaker's techniques.

Why leave the reader dumbfounded on a new topic like varying
length strings.  They see CHECKR, and know it.  So they're
comfortable.  Instead of thinking "wow, I attended a seminar
that tought me so many things I didn't know about, but where
do I start?" I want them to think "I'm comfortable with
everything but these 2 or 3 items... which I can learn and
work on."

There's no denying statistics with sales and response here.
In a couple years, sure, varying length fields will be more
mainstay, but right now, I don't feel so.  Or, if I WAS
writing for you or Jon or a bunch of others that frequent
these lists, then sure, I would try and "impress" my peers
using newer techniques.  But that's not my goal and it
shouldn't be the goal of any "teacher".  Your first job is
to teach.  No impress.

> So on the one hand, the fact that character varying and
> %LEN() are
> faster than using CHECKR or %TRIM() doesn't really matter
> a whole
> bunch.  Barbara uses a great metaphor - it's like
> standing on a
> chair to get closer to the Moon.  (OK, that may be a bit
> extreme in
> this case.)

I've heard her say that.. I love that one.  I also like
"trying to drink from a firehose" as a metaphore to trying
to incorporate too many "newer" techniques into learning one
main one.. ie e-RPG.  You already have to learn HTML, HTTP,
Some JavaScript, a little ILE, why throw any more in there.
If the user is comfortable with it, they will change in on
their own.  And feel even better.

>
> I think the main issue is clarity of code.  I would argue
> that using
> varying length character data makes for more readable
> code since you
> don't have to constantly bridge the semantic gap between
> fixed
> length and varying length string requirements.

Yes, for you it's more clear.  But, as I already expressed
more that once, it's not the clearist for the majority of
programmers out there.  And remember, those who frequent
this list do NOT represent the majority.  We forget that too
often.

When I talk with user groups, shops, and programmers, I do
questionaires.  I know my audience.  I know what they want,
what they're using, etc...  most still haven't even started
with ILE.  But slowly they are getting there.

Thanks for clarifying the speed issue, though.  I didn't
think it was anything to get "dissapointed" over, eh Jon?
:)

Brad
www.bvstools.com


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.