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



Hello,

I wouldn't venture to say that C is better than RPG or vice versa, but in terms of prototypes I agree with Brian. If anything, I'd say that C has better prototyping abilities in that you can overload procedures -

C does not support overloading. Maybe you're thinking of C++?

RPG's prototypes have more capabilities than the C ones do. They also provide better safety checking, and require less knowledge of pointers. Basically, they learned from C's mistakes.

However, C prototypes are very good as well. The varargs syntax provides some capabilities that RPG can't provide (albeit, at the expense of safety.) I use both languages on a regular basis, and I certainly wouldn't make a decision of which language to use based on the prototypes.

One thing that C has that RPG doesn't have is the ability to code a prototype for a procedure pointer, and then dereference it. This provides the ability to put a prototype in a data structure and call it from the data structure with something like:

myObject->myProc(one, two, three);

And that's a useful capability that RPG doesn't have. But... it's another small thing.

RPG on i5/OS is better for business applications than C on Linux for these reasons:

Integrated database support. There's a big difference in the amount of work required to interface with a database via ODBC APIs, and the amount of work required to declare an F-spec and code a CHAIN statement. The RPG method is much, much easier, and requires far less knowledge of how computers work. Even if you want to use SQL, RPG's embedded SQL is vastly superior both in performance and ease of coding than calling the ODBC APIs.

Support for true decimal fields. There's no variable that's comparable to a packed or zoned decimal field. You either have to use floating point (and all disadvantages that go with that) or you have to keep your fields in an integer, and manually keep track of the decimal positions, requiring much more code and much more work. You have to know exactly how these data types work and what their limitations are... in other words, you have to understand more about the way your computer does math.

Proper Error Handling. The i5/OS method of call stacks with *ESCAPE messages is a more robust and versatile system than Linux process groups and signals. It helps you make sure you get your application written correctly and makes it generally more stable. The Linux/Unix method requires more knowledge of computers and how they work to make the code completely stable.

All of this is what makes RPG a better language for writing business rules. You can just write the business rules, concentrating on the business objectives, without having to spent a lot of time considering how the computer works and how best to use the computer's resources.

On the other hand, the system i5 has dreadful graphics, sound, etc, capabilities. Linux blows it out of the water in those areas. Linux has drastically more applications available for it, and most of those applications are free.

There are all sorts of pros and cons. It's absurd to say that i5/OS is better than Linux. It's absurd to say the opposite, as well. It's absurd to say RPG is better than C or that C is better than RPG. Both sides have strengths and weaknesses, and which one is "better" depends entirely on what you're doing.

As a central server that hosts business rules, business databases, etc, i5/OS is the better choice in my opinion. But Linux is certainly better for other things.

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.