Re: IBM i in the cloud (was social media) -- WEB400

Joe,

arn't you just trying to sell EGL concrete here ?

On Sun, Nov 21, 2010 at 5:51 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

On 11/20/2010 5:36 PM, Henrik RÃtzou wrote:

The problem is not PHP (or .NET) the problem is that the MVC paradigm is
becomming more and more obsolete because the view in modern multi channel
UI's has moved from server centric to client centric. Can PHP make a
flash/flex app ? Can PHP make an iPhone App ? Can PHP build a

OOjavascript

Ext JS or Touch app ? Nope - all these are Client Centric app's that

comes

with their own client centric SDK.

That's a pretty concise statement of the difference between a general
purpose language and a scripting language. I spent all week at DevCon
pounding away that if you MUST learn a new language, learn Java. Why?
Because with Java you can do a lot more things, from JavaMail to Jasper
Reports to Droid programming.

There is a reason why Java and C continue to hold in popularity (Java
may be sliding a bit, but it's still number one) while the various
scripting languages continue to dwindle. And that's not my opinion,
that's directly from TIOBE, the folks that specialize in this sort of
information.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

ALL the scripting languages are trending downward (except maybe Python),
with PHP and VB being the biggest losers in 2010.

What is left for the server to do, is to offer REST based webservices

that

either delivers data wrapped in XML or JSON or initiate server processes
based on simple URI's from the Client program.

And you can do this in naked RPG/COBOL, or you can use Java to wrapper
them and take advantage of the various APIs to make formatting SOAP and
JSON very easy. And if you really want to be simple, you can use EGL to
call your host business logic and expose it as a web service.

So, this is a quite different scenario that is emerging and every time I
have a meeting with young programmers that work with and breath for the
above client app's and explain them what they can expect from the IBM i
server, suddenly the IBM i isn't "old iron" because it meets their needs

and

they actually don't care what technology that delivers the service.

The IBM i should be the center of the enterprise, as a business logic
server. You may, under controlled conditions, expose the database
directly via ODBC (through IT-maintained views, preferably read-only),
but the bulk of your business logic should be encapsulated either in
services or stored procedures. Do that and nobody cares what it's
running on. Then the arguments for TCO and reliability come back into
play and the i re-asserts all of its strengths.

Ask yourself, who can make an iPhone App ? I believe that anyone can make

a

"hello world" app, but I also believe that you can't make a "state of the
art" app without living with an iPhone and I have yet to experience a
programmer that starts the meeting by placing his/hers iPhone, iPad,
android, blackberry, Windows mobile and his/hers MAC and windows 7

notebook

on the meeting table and I have yet to meet anyone who claims to have
expertise to build "state of the art" UI's to them all and at the same
time claims to have expertise to know all about building server side
business apps, server side security, server side change management,

server

side setup etc. etc.

That's a lot of chewing gum to consume at the same time, especially if

you

try to sell anybody that this can be done without or hardly any chewing
education ;-)

The real issue in my mind is that there are very different requirements
throughout the enterprise. Thin client stuff is great for the bulk of
your web presence, while rich client may be required for more advanced
parts of the external interface. Both thin and rich can be applicable
to intranet and extranet applications, while true thick client
applications are very beneficial in a lot of real-world applications
(scanners and voice-recognition are both real world applications that
can be done on a Droid and can save you literally thousands in hardware
costs - PER USER).

In my world, the two languages that tie all this together are Java and
EGL. If I had to pick only one, it would be Java, because I can
manually do everything in Java that I would do in EGL, but realistically
the amount of development time saved in EGL quickly pays for the
learning curve. And of course, everything I learn in Java can be
directly used in my EGL programming.

Joe
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.