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



On Sun, Jul 2, 2017 at 9:29 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:
RPG is a general purpose language, so there will be things that other languages do easier/better.

I disagree with this statement on at least two levels. First, it
implies that other languages will naturally do some things
easier/better than RPG *because* they are less general-purpose.

Actually, RPG is among the more special-purpose languages out there.
This is in large part because it was built from the ground up to be a
database processing language. And it was designed this way because the
platform it runs on is itself special-purpose.

Where RPG excels compared to other languages is in its database
integration. And if you are still doing printer files and display
files, then integration with those as well. (I would say printer and
display files on the i were specifically designed to have a
database-like interface, so that they could be processed by a
database-oriented language like RPG. Open access handlers continue on
this theme.)

It's true that RPG has plenty of general-purpose features. And it
absolutely can be used for creating whatever kind of program you like,
no database, printer, or display involvement necessary. But to me,
those general-purpose features feel as though they are all there in
service of the core mission (database processing).

The second way in which I disagree with your thesis statement is that
it seems to imply that all ease-of-use differences between languages
can be attributed to how general-purpose those languages are in
relation to each other. On the contrary, I find that there are
definite design decisions which make one "fully general-purpose"
language easier to use than another equally general-purpose language.

A new language may do task x better, but how well does it do tasks w, y and z? Is the superiority for task x so great as to outweigh the inferior performance for tasks w, y and z? How about good enough to warrant adding a new language in your environment (assuming the new language is only used for x)?

Those are valid questions, though you've conflated "how well" a
language does some task with the "performance" of that task.
Performance is certainly a part, but normally that just covers how
fast something runs, and in some cases how much memory or other
resources it takes. These days, we're a lot more interested in
programmer-friendliness than we were in the (distant) past.

RPG is quite programmer-friendly and very machine-friendly for
"working with the built-in database". And this is why the i exists. So
RPG is the incumbent, and it's extremely well-suited for its platform.
I will say that it's hard to come up with a new, not-yet-created,
*statically typed* language that is so much better than RPG that
people should switch to that other language. I mean, we probably could
imagine one, but it would be quite difficult to design it. And if that
wasn't already too much work to be worth it, it would also need to be
implemented. Yeah, I think we can just forget it. Whatever trickle of
improvements that come along for RPG are more than good enough.

Where some things become *drastically* easier (for the programmer) is
when you allow much more dynamic features. (And this might well be
beyond what can be accommodated by ILE.) Personally, I've already seen
this with Python. Except for working with display files, it literally
does *everything* equally easy or easier (in my view) than RPG. For
new projects that don't need RPG's speed advantage and don't need
display files, I often just use Python. (And for big projects that
have speed bottlenecks, I write some RPG to handle just those
bottlenecks, and call it from Python.)

I will say that a lot of folks will not often need dynamic features.
And even when they do, they may find it easiest to turn to embedded
SQL or, at worst, Java. One should never forget that familiarity and
availability are much more powerful factors than language design when
it comes to ease of use.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.