Re: MIDRANGE-L forum; for leading-edge, newest Technical discussions

David Gibbs and others,
I cast my vote that EGL discussions continue in MIDRANGE-L for these
reasons.
You set up MIDRANGE-L for 'Midrange Systems Technical Discussions'.

I take that to mean that this forum should adapt and reinvent itself in
light of current technology and continue to be the forum for technical
discussions, especially current, new, leading-edge technical
discussions.

EGL is new and leading-edge, but is something most people are not
familiar with. If new and leading-edge discussions are immediately
taken to a different forum, MIDRANGE-L becomes a forum for old, stodgy,
trailing-edge, legacy technology.

I like the idea of discussing new, hip, leading-edge topics in
MIDRANGE-L.

If anything, I recommend that you create a 'Ancient, legacy,
trailing-edge technologies' technical forum.


http://www-128.ibm.com/developerworks/rational/library/04/r-3190/egl_ove
rview2.pdf

<snippets from the above URL>

Why another language? One answer might be: because a procedural language
programmer has more affinity with EGL than Java.
Why not continue with COBOL? Maybe because COBOL does not have elements
that help it integrate with the Web world.
And why not use Java only? This one is simple: because EGL productivity
is higher than Java; some people say that EGL can increase developer
productivity nearly 10 times compared to Java coding. In one IBM
internal study, 507.5 hours was necessary to code the famous pet store
sample application using Java without code generators, compared to only
55 hours using EGL. Here, we also return to the old Assembler vs. COBOL
and COBOL vs. 4GL battles.
Another big advantage that I see when using 4GL is that we code at a
specification level that is higher than Java or COBOL, which is the
reason for greater productivity. Also, we all know the changes that
happened in 3 or 4 years of J2EE; anyone who coded version

1.0 (and later 2.0) Enterprise Java Bean (EJB) components will
understand this issue very well. When we code at a higher specification
level, the Java code generated is the one that applies to the current
Java version.
How will Java programmers react to EGL?
The argument of which language is the best is always a polemic
discussion and often subjective. I have seen a wide range of reactions
to different changes over the years. Not long ago, during C++ vs.
Smalltalk, Java was a big help since it has syntax similar to C++ and
architecture similar to Smalltalk architecture (like the Java Virtual
Machine). However, since EGL is a new language, some developers are
bound to have strong reactions, particularly the experts. A new
discussion on the scale of COBOL vs. 4GL is born again.
Usually, 4GL languages tend to attract more enthusiasts at the
management level, since productivity and ease of learning are seen as
big advantages. Developers typically believe that their own code is more
efficient than the code produced by code generators, which could be very
true if the developers used object models and frameworks, but this is
not typically the case.
In fact, developers should be more concerned with the business logic
rather than the technology. If a programmer creates an application with
good performance, good quality and that allows future maintenance, he
has reached his objective.
Can I trust another 4GL language?
Usually one 4GL language is associated with a tool that has its own
editors and code generators -- which is not a characteristic of
traditional languages like COBOL and Java. I know many software
companies that have created 4GL languages and associated tools that are
now no more; most of the 4GL languages born at the '80's are not around
any longer, but some are still alive and evolve still today, with Web
support, Java code generation, and so on. IBM started its leap into 4GL
with CSP in 1981, has continued to stand fully behind this programming
paradigm over the years, and is committed to remain behind it for the
foreseeable future. EGL is an evolution and the embodiment of that
commitment, as demonstrated by the available migration paths from CSP,
VisualAge Generator and VisualAge Generator to EGL.
One question here is fundamental: Which language is the 4GL generating?
If the answer is Java or COBOL, then even if the tools that are used
along with the 4GL die out, you still will be able to maintain the
generated code.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.