Criticizing PHP is kind of like throwing your baseball mitt out in front of a steam roller, in an attempt to knock it off course. But Tom's experience with stored procedures is indicative of the types of pitfalls inherent in "distributed" workloads. And PHP is like Java EE and Microsoft aspx.net in that you must interface with host resources via distributed interfaces of one sort or another.
You might contrast that with RPG programs, which run in the same address space as the routines that perform database I/O. Native interfaces are much more streamlined; much easier to debug.
It's not just a question of learning multiple languages, it's more a question of using distributed architecture. Of course vendors do their best to make the interfaces appear simple. But there's no way to make than as reliable or efficient or even as flexible as native interfaces, running in the same address space.
If you dig deep and analyze distributed architectures, you find multiple levels of interfaces that map data sets from one type of component to another in an extended chain. It may be mapping an SQL result set to a PHP array, which in turn is mapped to another OO component which may be bound to another OO component which may be mapped to a UI component. A change to a single record in a database may trigger a series of component data set refreshes all the way down the line to the browser. A failure may occur at any link along the chain.
I see this in most database maintenance models, where the user begins with a grid component showing a list of records. The user double clicks on a record to activate and edit record window. Changes are written to the server. Then a series of data sets are refreshed, ending with a refresh of the UI grid. What a waste of resources. But that's the norm, under distributed architecture.
-Nathan.
----- Original Message ----
From: Aaron Bartell <aaronbartell@xxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Mon, April 19, 2010 12:02:05 PM
Subject: Re: [WEB400] Why use PHP? What are the disadvantages?
My reference to two languages more had to do with introducing a new language
where the existing could already facilitate. In the case of SQL (embedded)
and CL, I use them both where they make sense. That is where everything
gets real relative, because that median area is different for everyone. But
both embedded SQL and CL capitalize on the existing infrastructure of the
IBM i in a very full manner.
OK - I'll play devil's advocate here.
I knew those were real horns! ;-)
I agree with the fact that with any language you use, you will have to learn
the client side markup/script language. The server side is more of what I
am concerned about. So let's take it to the next level. Let's say RoR has
some really good scaffolding capabilities that allow you to spec out new
applications in short order (basically the concept is you only override what
you don't like about the default app). But RoR doesn't has native
integration into IBM i so you pick PHP for your controller layer to handle
traffic to/from the IBM i, and PHP then uses the i5toolkit to communicate
with the business logic written in RPG. In theory we just built something
that takes the strengths of three different languages and leverages them
beautifully, but in reality that infrastructure also has triple the failure
points, triple the knowledge required to find errors, triple training that
you need to send your developers to, etc, etc. With PHP and RPG you only
have double of the aforementioned list. With just RPG you have a single
level of the aforementioned.
In the end, each company just needs to be fully informed as to what the big
picture (i.e. 15 years out) will look like if they formally adopt another
language into the fold. That is where I would debate that it would be less
expensive, in the long run, to just do it all in RPG. Take things like
Valence and Profound UI and IceBreak. Any of those frameworks would be far
easier to get an existing RPG shop to the web, in grand scale, than to try
and adopt PHP+RPG (this is purely my opinion).
I think the various forms of RPG+CGI have been slow to mature in the open
space (i.e. community support) compared to others, but I do think there is
adequate support out there at this point (i.e. CGIDEV2 forums,
midrange.comforums, Renaissance forum, Valence forums, RPG forums)
Don't get me wrong, there will be challenges with RPG+CGI, but there will be
less of a environment change, and because of that I think the chance of long
term viability is much greater because we already know what we like and
don't like about the RPG+DB2+IBMi environment - PHP is a fairly big and
unknown world that is still a teenager in enterprise compared to IBM (the
50yr old).
What have you to say to that o' advocate of the devil! ;-)
Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/
midrange.com
