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




Joe,

I agree with you 100%, the things that seem to slip through the cracks with new
technologies are the following:

1. Should we use it and will it continue to be supported.
2. Is it easy to maintain and debug.

EGL has some questions in both of these areas. Just like other IBM technologies
I worry it will be depreciated like iSeries for the Web causing distress in
re-engineering the applications done already. Debugging or just problem
shooting in general always takes a back seat, especially with web development.
I have started working with Java and Websphere applications and noticed that
developers without standards have many, many, many great ideas and technologies
to use. The issue is how do you find problems in thier apps months and years
later without spending endless hours research obscure techniques.

As you said before they could take some lessons from iSeries shops, while we
may be too conservitave sometimes at least we mostly live by the mottos

"Just because its cool doesnt me use it" and "dont use it until we make up
some standards"

Ok I'm off my soap box now.

Don Nitke (happy holidays all)

----------------------------------------

From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Sent: Friday, April 06, 2007 7:38 AM
To: "'Websphere Development Studio Client for iSeries'" <wdsci-l@xxxxxxxxxxxx>
Subject: [WDSCI-L] WDSCI and EGL

From: Jon Paris

You can leave off the last part of the sentence Joe. It will never
generate RPG.

In reality there really is no reason for a generator to produce COBOL or
RPG
... Perhaps we should focus on getting themt o generate W-code just as the
RPG compiler does? It would make much more sense and since IBM have W-
code
oriented backends on all platforms, it should really be the cheapest
option
for them anyway. Why encourage them to generate something that can only
constrain EGL's capabilities to match those of the target language?

Well, as you know I'm still not sold on EGL as a business logic language.
If I squint real hard I guess I can see a direct EGL-to-W conversion; that's
not all bad and gets around some of the platform fanaticism. One of the
hard pieces would be linking the debugger with the high-level code.

Even if they got over that hurdle, though, I'm concerned that all I/O would
then be relegated to SQL. For example, even though EGL has nominal support
for indexed access, I've yet to figure out whether it would generate actual
indexed I/O for COBOL. Of course, this is a general concern, and really has
less to do with what they generate than with whether they have programmers
that understand the benefits of different database access methods.

But those concerns aside, I think I agree that EGL-to-W is the more correct
answer IF they decide that EGL is really going to be a language. I've had
some discussions with people on the team about what constitutes a "4GL" and
I keep pointing out that you can't do simple things like percolate database
changes to your JSPs. If the EGL team decides to promote EGL from a code
generator to a language, then they're going to need some better tools for
things like refactoring.

Even with java byte-code makes more sense than generating Java itself.

Yes, I suppose so, although having the source does make it easier to debug.
Of course, if the byte-code is properly structured a decent decompiler would
help a lot with that issue.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.