× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Maurice,

Very well put! And from the responses I am seeing her I understand even
more that PHP makes a LOT of sense as the next language for the IBM i,
regardless of what that Cancilla guy says, simply because you have a
choice. Procedural for the folks looking for an easier transition from
RPG or COBOL and OO/Framework for those who appreciate that technology.
The nice thing about developing in the procedural realm is that you gain
skills that will help you transition to the OO and Framework realm,
if/when ready. I really don't care which flavor of PHP you get involved
with, but I passionately believe it is a smart invest for now and the
future for these and many more reasons!

Regarding Kelly's note about the PHD, I have to say that in my travels I
have encountered a VERY wide range of skills and talents doing PHP, much
like IBM i. Many come from humble beginnings like the keypunch operator
who learned RPG via osmosis. The community reminds me so much of the
IBM midrange community!

OK, back to work!

Regards,

Dr. Mike

mike.p@xxxxxxxx Cell: (408)679-1011 Office: (815)722-3454


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Maurice O'Prey
Sent: Friday, September 11, 2009 9:11 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] PHP - Best Appication Structure

I guess the bottom line might be that MS-DOS would run like a rocket
on todays systems except very few ( although I bet there are some )
use it anymore.

Same with procedural and OO, productivity of the developer and
stability of the application take precedence over absolute performance

Procedural executes faster in my experience but I wouldn't go back there

Maurice O'Prey


On 11 Sep 2009, at 14:50, "Kelly Cookson" <KCookson@xxxxxxxxxxxx> wrote:

Hey, Mike, some i5 developers have doctoral degrees. ;-)

The fact that PHP works fine as a procedural language makes it very
appealing to us. We develop iSeries software in COBOL. Procedural
PHP is
a relatively easy jump for COBOL developers.

Of course, when we develop software for the iSeries, we aren't
trying to
create a new operating system or a large ERP module. OO programming
makes sense for those kinds of projects. Our COBOL programs perform a
limited range of functions and consist of less than 5,000 lines of
code
(most are only 1,000-2,000 lines of code).

I imagine the same applies to PHP. If we just want some simple scripts
to deliver a limited range of functions via browser pages, procedural
PHP is probably fine. However, if we want to create a large and
complex
ecommerce site, OO programming in the context of a framework may make
more sense.

Kelly


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Mike Pavlak
Sent: Thursday, September 10, 2009 9:36 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] PHP - Best Appication Structure

Nathan,

Well put! But what is missing from your most accurate assessment is
the
heart of the religious war brewing in the PHP community: Procedural
vs.
Object Oriented development. Many believe, like Rasmus himself, that
procedural code is perfectly fine. That OO is an abomination that
should be reserved for the purists and the computer science majors.
How
many i5 developers are running around with a degree in Bus Admin, or
no
degree at all! If you are more comfortable with the phrase "Get'r
done"
then the procedural model might be just right for you!

See Rasmus' toy page for more details on his perspective:

http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.h
tml

Now that is not to say there is not merit in OO based Frameworks.
There
is a LOT of good knowledge and talent wrapped up in the bowels of all
those includes and requires that can help a developer get things done
quickly, consistently and safely. This is not the first time we have
seen this battle folks. We've had this for years in RPGland. Only we
called it "Methodology". And we all know that all the abstraction
models and extra i/o routines were slower than a pure CHAIN and
UPDATE.
When speed was an issue (like the pricing routine I wrote for a Pharma
Wholesaler that got called 3 million time a night to process orders)
we
wrote tight RPG and left LR off in between calls. Otherwise, back to
the standards and canned i/o routines, etc. Anyone remember
Dreamwriter?

And let's not forget that the PHP language itself supports a mixed
environment. You can use procedural code, call an object when you
need
it and go right back to procedural. Not to mention the ability to
call
RPG, COBOL, CL and API programs directly from PHP when you really do
not have the time or inclination to reinvent the wheel!

Also, while your stats are impressive, do we know what generation of
hardware we are talking about? How much RAM? Was there a dedicated
memory pool setup for the Zend subsystem? Do they have 2,000 people
banging away at JD Edwards on a 1-way Model 270 at the same time you
were collecting your numbers? Maybe 1/10th of a processor on the demo
LPAR?

Please be aware that even though performance can always be measured
consistently in milliseconds, it varies greatly in hardware & software
configuration!

Just my $.02

Regards,

Mike

mike.p@xxxxxxxx Cell: (408)679-1011 Office: (815)722-3454


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Nathan Andelin
Sent: Thursday, September 10, 2009 5:22 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] PHP - Best Appication Structure

From: Jon Paris
ATK framework from iBuildings ... is heavily focussed on
building business applications.

There has been some concern expressed in php forums about the
performance of frameworks, and having a lot of OO code running
interpreted.

A demo at the ATK site enables editing and posting changes to an
employee record, consisting of 6 fields. An HTTP POST is followed by
an
additional HTTP GET, with average response times as follows:

POST: 900 milliseconds
GET: 500 milliseconds

I compared that to one of my programs for editing and posting
changes to
a person record, consisting of 5 fields. Coincidentally, my interface
also uses an HTTP POST, followed by an HTTP GET, with an average
response time (to last byte):

POST: 3 milliseconds
GET: 2 milliseconds

There would be some delay from the ATK site of course, due to internet
bandwidth. But that delay would be less than 100 milliseconds. The
RPG
program still appears to offer about 260 times better performance.

There may be some rationalle for keeping php scripts as small as
possible.

-Nathan.




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

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

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.