Re: the RPG problem - adrift in the PC-web wind

Dropping data on the screen creates data-aware
widgets with automatic bi-directional connectivity to the application
program, much like a display file.

I think EGL is a good product, if you really want a 4GL.

It would be much better if it was introduced in the 90's, the era of VB and
"data aware" controls.
The problem with these "data aware" controls, and the WYSIWIG VB-style
develeopment style is that you can slam together a nice looking app in
no-time (let's say the time to do a demo).

These days, "data aware" has been superseded by MVC and MVP.
These are not buzzwords, but an architectural style.

If you have lots of "data aware" widgets, then what happens in the years to
come when you try to evolve the application. For example removing a field.
What happens with all thos data aware controls which are "aware" of this
field and now suddenly are lost in space. Of course with decent tooling
(and tooling and tooling and tooling) you can alleviate this.

Anyway, i suppose you don't have to use "data aware" widgets (controls) if
you don't want to.
EGL can be used to implement an MVP style architectue.
But then you have a completely different story than in the Demo room.
And why choose EGL then (because this is one of the "unique" selling
points).
Then my manager asks me things like: now why does it take so long for that
first widget to be implemented.
And i have to compete with those "data aware" controls, and trying to
convince my manager/client that - in the long run - it is much more
productive because you have all the control (and i don't mean widgets here)
and are not tied to a particular architecture that is really about just one
thing (be honest): sell it to management in a demo. And there you have
those "data aware" widgets and all other nice things you can Demo.

It's not about haw fast you can slam together an app. It's about the long
run. How much does this system cost, in it's entire life-time. It's about
managing complexity. And insight (how different parts of the system work
together etc). Data aware controls are easy but don't give me insight,
flexibility, and control. It's the M$ black-box approach where things "just
work" out of the box. Until it doesn't work of course.

End of rant.






On Mon, Mar 12, 2012 at 3:11 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

On 3/11/2012 11:07 PM, Steven Spencer wrote:

Hi,

Yes, I agree that two languages can work together almost as one. OCL
and CL acted as the bridge between the OS and the high-level
RPG. EGL with Web-sphere, I gather, conceptually wants to be the
bridge to modern output.

Actually, I think bridge may not be the best term. EGL is designed from
the ground up to have two primary facets: data orientation and visual
presentation awareness. EGL's data orientation is predicated on its
Record syntax; data is stored in records and records can represent
either pure data storage or can have additional annotations regarding
their use (such as SQL or MQ, for example). Visual presentation
awareness is the idea of creating a GUI page with a WYSIWYG designer
that has awareness of the underlying data in the application, a la
Microsoft designers. Dropping data on the screen creates data-aware
widgets with automatic bi-directional connectivity to the application
program, much like a display file.

So what do you get? An environment where you group your data in records
(not objects) and you design your UI and bind it directly to your data,
eliminating the plumbing.

However, they were designed independently (thus EGL can put out Cobol
code, but not RPG) and I gather EGL will even compete with RPG for
full functionality, as in the RPG to EGL conversion concepts. In that
sense, EGL is claiming to be a lot like Lamsa, Magic and WinDev, a
4GL implementation that is happy to work with the iSeries (QS36F as
well, if you create a data dictionary ?) and will be friendly to your
existing data and apps.

I don't think there will ever be an RPG to EGL conversion that will
perform well, any more than there will be a good RPG to Java
conversion. The fact that the native I/O of both EGL and Java is SQL
makes that unlikely. Instead, EGL is designed to provide fast,
integrated development of SQL-based applications with the ability to
invoke native RPG business logic (or indeed any ILE or OPM code) very
naturally. That's above and beyond what even Java provides.

I included EGL in the jambalaya partly because there is a type of
skepticism, with the Visual-RPG experience of IBM and the continual
rebranding of Websphere and Eclipse products. Now EGL is the way to
go, but I am not sure that everyone sees its long-term future as
bright. These other tools have a 10-20 year lineage of actively
working on iSeries. If we knew that EGL would be actively supported
in 10 years, that might be a help.

Then it should make you more comfortable to know that EGL is over 30
years old. It started life as Cross System Product for mainframe
development back in 1981 and has evolved continuously over the years
through two new product families (first VAGen and now EGL).

However, technically EGL might fit more in with the new generation of
4GLs that basically bypass RPG, the point of my earlier post. It is
not really trying to enhance RPG, but to supply an alternative
full-platform that will coexist with your RPG.

Not sure what you mean by "enhance RPG". EGL enhances RPG by freeing it
from the mundane details of HTML formatting and XML/JSON messaging much
the same way that display files hide the complexities of 5250 data
streams. It allows RPG programmers to focus on writing sophisticated
business logic. And for that, RPG needs no external enhancements; the
RPG compiler team is doing quite well with that.

Feel free to correct any misunderstandings on my end.

I hope I've enlightened you. :)

Steven Spencer
Queens, NY

On 3/10/2012 5:12 PM, Steven Spencer wrote:

Personally, starting fresh, I see no purpose in working with RPG and
the jambalaya of EGL, or CGI and PHP, or Java and this and that. Or
Open Access and the three vendors.

Not sure what you mean by "jambalaya" when you refer to EGL. It's a
pretty straightforward open source 4GL with a variety of target
platforms, including Java, COBOL and JavaScript. It's got integrated
support for SQL that's a lot better than any other language I've seen.

And while it doesn't target only the i, it works best with the i,
because it can access the database either through SQL or through direct
calls to ILE programs, including RPG. Why is that important? For the
same reason it's always been important to call native applications:
performance! EGL provides effortless SQL access but when you really
need performance you can always call good old RPG.

And that's just the business logic side! Unlike most languages, EGL
provides a single syntax that works on the server and also works on the
client, and tops it off with a powerful WYSIWYG editor that allows you
to bind controls in your browser directly to functions in your client
which in turn can invoke services on the host. And you can debug it all
the way through using a single workspace!

So, yes, if I had the choice I'd build any application from the ground
up using EGL and RPG. The only change is when I need a fat client on a
handheld device, at which point I'd turn to Android and Java.

Joe
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing

list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.