Re: Is RPG dying

@john e...

"Because [RPG is] simply not a very versatile and modern language. It's as
suited for event
oriented programming just as C is, or COBOL. Java is better suited because
it's more versatile."

C is currently #2 on the TIOBE list, so who is to say it is neither
modern, versatile or suited for event-driven programming than any other
language? It is the basis and inspiration for most of the top languages on
that list. So I think the reality is just the opposite of your claim.
Maybe I am mistaken, but many OSs are written in C or mostly C and not an
OO language. This includes Windows, Linux and parts of OS X (kernel,
userland utilities, etc.). With regard to windowing systems, the WinAPI is
basically the same as it has been for years, namely, a C-based API. All
the Windows OO frameworks (e.g., MFC for C++ and .NET with C# & Visual
Basic) are wrappers for that lower level API. The GNOME Gtk3 API is also
written in C, though coded in an OO style. The OS X and KDE windowing
systems, however, are truly OO since they are written in Cocoa
(Objective-C) and Qt (C++) respectively.

One can argue the merits of GUI development in an OO language and
framework, but an event-driven windowing system, for example, does not
need to be OO per se. Windows illustrates this because I would argue that
the most efficient, versatile apps on that system would be written in C
for the native API. A windowing system just provides a way to register a
program window to receive asynchronous callbacks when the user interacts
with its components. So the whole discussion about event-driven
programming vs. OO language development is just confused. Again, one can
argue the merits of OO, but I can write a purely C-based GUI app in Visual
Studio 2010 right now, and it will run just fine on Windows 7. With some
minor tweaking, the same app could basically be compiled for OS/2 because
the APIs are so similar, and OS/2 hasn't been in development or support
for years. These apps would probably run as fast, if not faster, and allow
for the greatest efficiency and customization, but they could also be far
more tedious than doing something similar in .NET with its massive
convenience framework(s). In the latter case, however, you are relying on
the framework coders competency (presumably high if they work for MS).
Same goes for Java, Qt, WxWidgets and other cross-platform API wrapper
frameworks. So there are tradeoffs. Many people would claim that Java and
.NET are less efficient in terms of executable size, memory foot print and
speed. Further, for low level device interaction, you are limited by the
facilities provided, if there are any. (Try doing RS-232 I/O with Java on
a Windows system.) On the other hand, you could write a program in
Assembler, and it could run most efficiently, but few would need or desire
to go to that level. So it really depends on the task at hand, and the
tools best suited for the situation.

I doubt there is anything in theory preventing the development of a native
GUI API for RPG, but it would make no sense to do so given the purpose of
the language. IBM i is a server OS with no native GUI (unless you want to
consider about PASE). Plus, as others have noted, it is primarily designed
as a business language and performs its purpose well. As a result, "GUIs"
for IBM i are either something web-based or fat-client based as none run
natively on the OS. But since RPG is C-like and seems to take its
inspiration from that language in many ways, there is nothing preventing
it from having similar capabilities. As far as being a procedural language
is a fault, isn't Google's new Go programming language procedural like C?
If procedural languages are so outmoded, then, why would Google go so
retro?

Blake