Re: RPGIII compiler vs Visual Basic

On 6/16/05, Vernon Hamberg <vhamberg@xxxxxxxxxxx> wrote:
> I feel there is a slight misunderstanding of terms in this discussion.
> Maybe it comes from sometimes having blinders on for us dinosaurs that used
> to think RPG was all there is - a problem alluded to in these posts, also.
> (I'm not sure I am a complete dinosuar, as I've developed in VB for at
> least 10 years and actually taught VB3 at a local technical college until
> the state tried to deduct union dues, even though I was not in AFSCME or
> whatever the union was.)
> 
> What I refer to is the tendency to equate ILE and RPG IV. They are not the
> same thing - one is a language and the other is an environment in which
> multiple programming languages can participate. This is similar, as I
> understand it, to the Common Language Runtime that MS has - I know, not
> identical, but that has been hashed over several times - please see
> archives for more on that topic.
> 
> My point is, VB.NET is not CLR, it participates in or uses CLR. Similarly,
> RPG IV is not ILE, it participates in the Integrated Language Environment.

here is the way I understand these terms.

JVM ( java virtual machine ) and CLR ( common language runtime ) are
kind of the same.  Both deal with just in time converting of byte
codes into machine executable code. Both also handle memory management
and the life cycle of the objects ( data structures ) used in the
code.  In Java that is garbage collection.  In .NET it is the managed
heap/managed code.

ILE, DLLs and .NET assemblies are roughly equivalent. In windows ( and
I guess Unix ) DLLs ( dynamic link library ) made it possible for a C
function in a windows executable to call out to another function in
another executable file ( the DLL ).

IBM did DLLs one better with the introduction of ILE some 15 years
ago.  ILE has service programs which are the equivalent of the DLL. 
IBM added a good way to organize the creating of service programs with
modules ( which contain the executable procedures ).  There are also
facilities built into the service program for source code debugging
and there is an orderly way for programs to discover and bind at run
time to procedures in the service program.

Windows followed up on the DLL during the same timeframe as ILE with
COM. COM did not have the built in debugging and orderliness of the
service program, but it did have something ILE did not have.  COM
supported class objects.  Both VB6 and C++ programmers used classes in
their code.  ( classes are data structures + the
procedures/methods/functions which operate on the fields in the data
structure ).  COM allowed not only a standalone function/procedure to
be in the external DLL, it allowed the entire class to be in the DLL. 
 Using COM, VB6 programmers became super productive by adding
references to the COM objects in their code.  Once the reference was
added the class was available for use in the VB program.  VB6 also
enabled the VB programmer to create their own COM objects.  A real big
deal.

The .NET assembly builds on the COM model. Like the COM whatever, an
assembly is a DLL.  Added is the orderliness of the ILE service
program.  A lot of built in version control.  The source code debugger
stuff is still not built into the assembly like it is in a service
program, but that is for reasons like keeping the size of the object
as small as possible. Basically assemblies have a lot of features you
would expect in a 21st century DLL and they are real easy to work
with.

CLI ( common language infrastructure ) is the .NET value add that no
other platforms have.  It is a specification that all .NET languages
adhere to which enables class code written in one language to be
referenced from an assembly and used in the code of another language. 
  CLI and assemblies are what make it possible for a function written
in C++ to be used in a java program.

-Steve