|
jpcarr=BXdtB8kxIH5Wk0Htik3J/w@public.gmane.org wrote:
I've resisted this thread, but have gotten drawn in. Hans you're right. Brad you are right. Hans, the code review process that you go thru and testing that You go thru(writing compilers for IBM for customers paying Millions of $$'s ) would stop all development in most shops. You are also correct about the need of accuracy in the explanation of a subject. But Brad has also did a great service to alot of RPG people by , as Aaron said " I found that the e-RPG book got me up and running in no time with the basics that I needed to know to start CGI programming with RPG. " Should there be a Manual, or Reference guide to show all the idiosyncrasies of things like CGI programming? Of course yes. (BTW, Daniel, many have said that Bob Cozzi's first book Modern RPG was a rehashing of the RPG Reference manual -;) no offence Bob). So, Hans there is a place for(and an audience for) information on a subject that doesn't go into the n'th degree about a subject. And be humble because, Gee, I seem to remember those WONDERFUL RPGII 1/2 examples in the SYS/38 and AS/400 RPGIII manual. Should we pick one of those things up and point out what a wonderful job they did teaching millions of programmers HORRIBLE RPG techniques? I never saw one IBM example say (for instance) "Hey, watch that Z-ADD with those overflows " Hans you have to think like you do for the place you work and the code you write. The wizards in websphere studio for example cannot afford to build error prone code for the user. However do not confuse that level of coding and it's associated documentation and instruction with the fact that for a good many people "a little bit of learning" is a good place to start, then after that more extensive, etc. So you are both right. (and IBM did write the WORST examples of RPG ever written. )
Hi John! Thanks for putting things into perspective! I agree with most of what you wrote. I do certainly agree that Brad's book can be quite useful for RPG programmers wanting to learn CGI. My only real disagreement is that there are certain basic things that should be covered in any introductory treatment of the subject, such as internet security and robust coding. Just look at your HTTP server log to see the number of people and bots probing your site for weaknesses to see that the risks are indeed real. Would discussing the risks scare away people from CGI programming? Perhaps. But is the risk to your server and business data worth it? Sure, most of the "strange" hits to your HTTP server are looking for known exploits in specific programs, such as IIS and FormMail. But also, there are people who do specifically hunt out CGI apps that do not properly escape data. Maybe I am sounding like a broken record in constantly bringing up the issue of HTML escapement and URL encoding, but simple things like these can indeed thwart certain exploits. (I promise to make this my last posting on the subject in this thread!) - - - - I agree that the examples in our own books should be better. We probably don't put as much effort into our books as we should. Also, I would personally prefer that all new examples in our manuals and redbooks fully take advantage of new features in the language. - - - - The only statement of yours I would take issue with is: "the code review process that you go thru and testing that You go thru (writing compilers for IBM for customers paying Millions of $$'s) would stop all development in most shops." I would suspect that many IT shops actually have a *more* robust development process since their business critically depends on the correctness of their applications. Futhermore, for us, there is no danger of compiler developers embezzling company funds through malicious coding, unlike in IT shops. And so inspection and auditing requirement should be much more strict among the users of our dev tools. Cheers! Hans
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.