Re: 'green screen' not sellable --> WE(?) are the problem

Jon,
You forgot those *older* programmers who cut their teeth on CCP.

:)

Jeff Young
Sr. Programmer Analyst

On Tue, Jun 9, 2015 at 2:58 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

I wasn’t endorsing Profound Nathan - but you were talking about a specific
design scenario and my client used Profound to build just that. If they
had used look, or Rocket, or Asna, or … I would have said that.

I have found that most of the RPGers who deserve “more credit” are for the
most part already doing web stuff and have been for years. As a teacher I
am concerned with finding ways to help folks who haven’t yet made that leap
(for whatever reason) to do so. Starting with an existing and well known
and understood paradigm can help them make that jump.

I always found it more than a little amusing that folks who grew up with
S/34/36 MRTs or mainframes who knew CICS, have a far easier time learning
to program for the web than those raised in the S/38 EXFMT school. Why?
Because if you have never had to worry about maintaining state then it can
be a hard thing to get your head around. But those of us old frets who had
to deal with it for green screen apps already had that skill and the
transition was simple.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 9, 2015, at 2:11 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

The point you are missing I think Nathan is that OA based products such

as

Profound _can_ be used to build the kind of apps you describe.

Another nice endorsement, Jon. If OA based products can be used to build
the types of apps I describe, then yes I am missing the point.
Nevertheless, I still question, and very much doubt that OA based

products

can do what you are asserting they can. And when you endorse a particular
vendor, you're not just endorsing OA as an interface, you're also

endorsing

a particular implementation of that interface.

Maybe it is just a misunderstanding of the "kind of apps" I'm describing.
To build these "kinds of apps", my suggestion is that developers begin

with

just HTML, CSS, JavaScript, and perhaps an SPA framework which provides a
way of "merging" static HTML with static JSON objects, whereby

applications

may be built and tested nearly entirely with just a browser and an HTTP
server. No need to interface with a database, or RPG code, until you're
ready to implement data validation, referential integrity checks, and
similar business logic against live data.

The focus is on implementing the UI, first. You can connect to the

database

later. I hope you can see and appreciate the paradigm shift from

"writing"

display file "records" to clients, and "reading" display file "records"
form clients.

I understand that many traditional IBM i developers feel safe with the
display file paradigm, and might not try a different approach. But I like
to give them more credit than that.
--
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.

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