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

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