× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: How about in INC opcode
  • From: "Martin, Booth" <BoothM@xxxxxxxxxxx>
  • Date: Wed, 8 Mar 2000 10:39:30 -0500

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.