× 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 Thu, Feb 26, 2009 at 7:38 PM, Hans Boldt <hans@xxxxxxxxxx> wrote:

When comparing .NET and ILE, you're making an apples versus oranges
comparison. In a nutshell, ILE is a framework for building compiled
program using static and/or dynamic binding. This kind of capability
exists in pretty much all operating systems, including Windows, Unix,
and Linux.

Hans,

call it what you want, but a CL code module should/has to be able to
work with the same data objects as an RPG module, an SQL procedure,
COBOL, JAVA, etc. That is the job of the framework which the program
runs in. Which on the as400 is ILE. The running program module also
needs a call stack, a facility for throwing and catching exceptions, a
memory heap, automatic call stack memory, a whatever it is called
memory heap holding instantiated objects and their references, a way
to trace those object references back to their call stack roots ( for
garbage collection ), and a means for logging runtime messages. You
want all of this to happen in a universal, common denominator, fully
featured kind of a way so that sql procedure, python, f#, c#, VB,
Java, RPG, C, and COBOL code modules can be used and reused in one big
happy call stack of a running program. If you think the parts of this
complex that ILE currently performs have to be distinct and isolated
from the rest, I ask you to explain further.


If you want to make comparisons, compare .NET with the JVM,
both of which are available on a number of operating systems, both of
which offer an interpreted sandboxed environment along with a robust
class library.

.NET more than Java because .NET has interop facilities that enable it
to be integrated into the operating system and other languages. It is
great that MSFT upgraded C++ to be a .NET language. But .NET should
be improved also. It needs better call stack support, an as400 like
way of sending program messages to call stack entries, an as400 like
joblog that a program can send messages to. yes, yes, that is not
what .NET or JVM or ILE do. They dont provide spooled file or joblog
services to a running program. I dont care what it is called or the
jurisdiction which is responsible for the feature. The application
programmer needs these features to write great programs.



Were there decisions made in the mid 1990s to slow and stop the
evolution of ILE?

The simple answer to that question is no, of course not. Are we really
expected to believe your insinuations that some cabal of managers and
technical advisors in IBM conspired to stop the evolution of ILE?

just asking the question based on the recent letter to the editor of
IT Jungle ( see below )

I dont call it a conspiracy. IBM mgmt decided not to invest in
operating systems, runtimes and languages anywhere to the extent
needed to compete. I recall IBMers in the 1990s saying we dont need
another programming language. 10 yrs later, IBM embraces PHP and loses
chunks of market share to Windows.

http://www.itjungle.com/tfh/tfh021609-story06.html

"... Tackling the pure language question first. RPG has been evolving
steadily over the last 30 years or so. Unfortunately, it hasn't
evolved quickly or far enough and, if I am to believe people I have
worked with that were on the original ILE team at IBM, that could go
down to a single management decision back in the mid-1990s on how far
to take the language. If that evolution were given a shot in the arm
and a strategic future by initiating an open source community to
develop it, as you are suggesting, what would it end up like? Probably
like C# or Java in all likelihood. ..."

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.