|
You'll get no argument from me there, I couldn't care less where the power comes from. I wonder if there is anyway to call a perl program from within an RPG or CL and pass data back and forth. If so then problem solved. "Martin, Booth" wrote: > > If something is to lean Perl-ward why not let it be CL? CL has a lot of > power and adding in the scripting power of Perl would give the AS/400 two > strong thrusts towards problem solving. > > -----Original Message----- > From: boldt@ca.ibm.com [mailto:boldt@ca.ibm.com] > Sent: Wednesday, March 08, 2000 8:37 AM > To: boothm@goddard.edu > Subject: Re: How about in INC opcode > > L.S. wrote: > >I despise ++ because I tend to over look it. I would much prefer an INC > >opcode for the very point you made, it is not ambiguous. > >I agree with you that a += operator would be handy as all get out, but > >while your at it let have a %split bif and some of the good stuff from > >perl. > >I would love it if RPG would lean perlward in the future. > > Well, you know I'm a big Perl fan. And my colleague > Barbara has even started playing with it too! > > However, Perl and RPG are fundamentally different > languages. One is compiled and the other is > interpreted. Interpreted languages aren't hobbled > by the same restraints that compiled languages > suffer from. Interpreted languages typically can > offer much more rich functionality, but compiled > languages typically can offer much better run-time > performance. So you have yet another case of > trading off factors: Do you want fast run-time > performance? Or do you want fast development time? > > Actually, in practice, there really isn't much of a > run-time performance penalty when using a function- > rich language like Perl. Since Much of the run-time > of a Perl program happens in the run-time library > anyways, typical Perl programs run about the same as > comparable C++ programs! > > Regarding a %SPLIT built-in in RPG, wouldn't that be > great? Unfortunately, the implementation wouldn't > be easy. In Perl it's easy since it can handle > arrays dynamically anyways (everythings handled > dynamically!). But RPG would have to allocate space > to handle the worst case scenarios, which gets > expensive fast! Perhaps we could just clone the > Perl run-time environment, but then you might just > as well write your program in Perl. > > The bottom line is this: Use the appropriate tool > for the task. For business apps, keep using RPG. > For tasks that requires heavy string manipulation, > Perl is better. > > (Is this getting too far off topic?) > > Cheers! Hans > > Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- -- L. S. Russell Programmer/Analyst Datrek Professional Bags, Inc. 2413 Industrial Drive Springfield, TN. 37172 mailto:leslier@datrek.com http://www.datrek.com -- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.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.