|
> 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 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.