|
The System/38 used to have Product Planners. These individuals provided a common front to development for the System/38 product line. They went out into the field and found Requirements, made the decision as to what was real and what was nice to have. They prioritized things. Today, a developer has a few free moments, builds something with little regard to the "way" things are done on the product, and then effectively approves their own design. Hans and Co. have said that most (all?) new function in RPG IV will be in the area of the Extended Factor 2/built-in functions. Are they now going to say that the new features in RPG IV are going to in both the CF-spec and the current EVAL/IF style C spec? Or is new stuff going to only be introduced exclusively in the CF-spec? If I (as a developer, not just me but others) can completing disregard the CF spec and still use ALL new function in RPG IV, then I could consider the notion. However I believe that some developer will sit in a room, have a few free minutes and put stuff into RPG IV that only works on the CF-spec. At that point, the CF-spec becomes it's own language, no longer RPG IV. FYI, today I write mostly in C++ today. I know Java, I know CL, C, COBOL and Fortran. I even know MI and PL/I. I love PL/I, MI is okay, C is interesting, but Java is still a bit confusing to me. But Java is my newest language (only about a year experience with it) while C++ is what I use most. C++ reminds me of PL/I--it is trying to do too much, so some people are staying away from it. Now Java is being considered a lot. But isn't ready and my concern is that it too will try to do too much and people we being to shy away from it. I do not want to attempt to write a compiler in RPG IV. I have no need for that. I have written an LR1 parser in RPG III that works great. That was fun, I have yet to care how to do the same thing with C or C++ because the need isn't there. Again I ask the question, is moving to the CF-spec going to make my subfile look better, provide a GUI on the AS/400, or make the CHAIN operation code work faster? Bob Cozzi http://www.RPGIV.com > -----Original Message----- > From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On > Behalf Of Douglas Handy > Sent: Wednesday, August 04, 1999 11:32 PM > To: RPG400-L@midrange.com > Subject: Re: RPG IV and CF-spec "keep it IBM" > > > Bob, > > >Would you implement a feature as questionable as the CF-spec, with only 5 > >out of 50 replies? Interesting. > > Consider that, of Jon's collected responses, those 5 represented 10% > who voted for CF _even at the full $100 cost_ when it meant using the > entire budget amount. > > Hans has already indicated that the actual cost will come in around > $20. Noone can predict with certainty how many people would have > voted for CF if the original poll had projected the cost at $20 of a > $100 budget allowance. But I think it is fair to say that more than 5 > out of the 50 would have done so. Granted, it still wouldn't have > been 100%, assuming you were still voting. > > Hans also indicated they went ahead with the study to determine the > real cost because they "thought it was the right thing to do". And I > have to admit, I agree. <g> > > Doug > +--- > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +---END > > +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---END
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.