|
I have to chime in a bit here. Many many years ago I went withspit it. I far prefer to use code that I wrote or at least can reasonably
ProGen Plus from BCD for generating subfile programs. For a couple
of years after that, I was worried because I could no longer write a
subfile program from scratch. I got over that. I couldn't care
less how to do one from scratch. ProGen Plus does everything I need
in the way of subfiles in literally 1/10 the time. I care not one
whit for all that plumbing.
If I ever convince both myself and the powers that be here that we
must "webify" everything, I have no intention whatsoever of learning
the nitty gritty details of HTML, JSF, J2EE, etc. There will have
to be something that does for "webifying" that ProGen Plus did for
subfile programs. I am not a computer geek that works for a
business, I am a businessman who likes to use computers to solve
business problems.
Last week and next week I am attending an online web class (free)
put on by IBM about EGL I'm spending 6+ hours a day hands on
finding out/learning what I can about EGL. The depth and breadth of
what EGL does is astonishing and I've only scratched the surface. I
don't even know enough yet to be dangerous. The powerpoint for the
first class alone is over 1,000 pages.
Both Joe Pluta's ("international authority on System i technology
and EGL") and Pete Helgren's names are mentioned on the foils. I
don't know if EGL will be for us, but it is indeed impressive.
--
Jeff Crosby
UniPro Foodservice/Dilgard
260-422-7531
Opinions expressed are my own and not necessarily those of my
company. Unless I say so.
Joe Pluta wrote:
david gibbs wrote:
You're 80% of the way there.
You are correct ... I don't trust generated code any further than I can
generate ... and half being tied to a single companies product to generateI understand this point. But I hope you agree this is purely a personal
stand - David Gibbs prefers rolling his own, although he will accept
help from the friendly Wizard <grin>. I understand that position, and
even agree wherever practical. However, I hope you'll also agree that
lots of shops don't have the time to address their application backlog,
much less rewrite existing plumbing code, and that there are valid
business situations to use proprietary and/or generated code. We all
rely on code we cannot maintain to one degree or another, especially
those of us who use Windows (much less those who program for it).
So, the idea that the code is generated shouldn't be a showstopper for
everyone, even if it is for you. For people who don't have the time to
reinvent or even reimplement the wheel, generated code can actually be a
positive thing because it allows them to concentrate on the business
logic rather than the plumbing.
The rest of my dislike is half the quality of the code they
So you agree that your other issue is one that really doesn't apply as
much to EGL.
Let me pose a question: do you think there's a larger contingency within
IBM backing EGL or RPG? I know it's not quite an apples-to-apples
comparison, since RPG is likely to be around as long as the platform,
but I'm just pointing out that EGL has as large a commitment from IBM as
anything. Rational has its own conference, and it's a big one. EGL is
prominent there, and getting moreso.
I guess I'm saying that while the idea of EGL (or indeed any technology)
being orphaned is not a completely unjustifiable concern, it's harder to
justify when your primary development choice is RPG and the i.
Joe
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.