[PHP-DEV] Function caching... From: Ron Chmara (ron <email protected>)
Date: 12/12/00

Kristian Köhntopp wrote:
> Simple things should be simple. Complex things should be
> possible. That's why PHP has OO and why PHP without
> OO is simply not acceptable (it would have been okay in
> 1970).

I build large applications with PHP, I'm running the intranet for a
multi-billion dollar company with PHP as the communications, web,
data transfer, backbone...
and they *don't* use OO. They've had no need for it, and my personal
experiences with it have led me to believe that OO religion is more
about appeasing a developer's ego than producing fast and efficient
code. Actual OO workflows (not the same as the OO religion) have some
utility, and seem to work best interminged with procedural workflows
when speed is an important factor.

But PHP without OO is not only acceptable, but in many cases, has been
more efficient, and easier to debug. The converse *could* also be
true (PHP as an OO specific language), but the complaints I have seen
in this exchange are serving to re-affirm my belief that OO, for web
development, can be a poor paradigm choice.

If it is so efficient, why is a cache needed at all? Is it only
efficient when *authoring* code, but not when *compiling and
running* it? :-) Apparently, yes.

> And then there is a whole bunch of _really_ _sucky_ _coding_
> where increasing hardware won't help you a bit, only better
> code will. Talk about cubic solutions to logarithmic problems.

Right. Sometimes you have to dump your programming paradigm in the name
of writing efficiently running code, sometimes you need to dump OO,
or PHP, or C++, or Perl, and code in C, assembly, etc.

Kristian Köhntopp wrote:
> Sterling Hughes wrote:
> > Oh yeah, that's Alan Kay: "Simple things should
> > be simple, complex things should be possible"
> Yes, Alan Kay of Smalltalk, Logo and Dynabook fame
> and one of the designers of the very first GUI.
> He is currently with http://www.squeak.org/
> at Disney.

I find this _very_ amusing. We hired an OO-only developer, a guy who thought
squeak was the solution to *any* problem he could find. Unfortunately, he
spent so much time on code design that he failed to produce much in the
way of usable code...

He was too busy abstracting, and downloading other people's libraries,
to produce any work of his own. Needless to say, when we terminated him, we
only found 10% of his code was usable. The other 90% was sucking up RAM
and CPU in creative method invocation, library loading, object creation,
and adding layers of abstraction. We took one of his code blocks from
900 lines to 20, and gained a five-fold speed increase. (This seems to
be very common in OO, massive line counts for minimal functionality).
He was very impressed with his 900 lines..... This also serves as a
reminder that good programming and complex applications have *nothing*
to do with line counts, unless you're paid by the line. :-)

(It's also worth nothing that all of the Kay projects have gained small,
religious, followings, but none of them have disloged other language
paradigms. Failure might be too strong a word, but they certainly aren't
smash hits.)

Kristian Köhntopp wrote:
> You do not need OO for your first application. You need it for your
> second. Unless of course you want to reinvent your code.

At 5 years of applications, I'd say you're dead wrong. Code reuse is a big
problem with *any* language, and OO alone does *not* fix it. Developers
who are loath to use prior code will not use it, regardless of the code
paradigm....

They will start their next project by recoding all of their objects
and methods, or rewriting their base procedures. This is not a code
problem, it is a management problem, it is a personality problem.

Does procedural code flow allow re-use? If you know how to use copy and
paste, it does. Does good code make redesign easier? Always. Is OO needed
to make reusable code? Not if you can copy and paste the code. Keep in
mind that the OO paradigm was invented _before_ re-use in procedual
languages was common, as an idea that worked well on terminal computing.

It was difficult to quickly grab five lines from one project and put them in
another project, and OO encouraged a way of easily accessing that code.
It worked well in projects where there were many departments who networked
and collaborated poorly, because it provided some insulation from other
code blocks.

Now we have keyboards and mice, and can see and work on 10 codeblocks
at once, copy-pasting as needed. Languages have include statements to
access core functions, without a religious code "method" required, without
adopting new terminology, without the uncomfortable issues of adhering
to any specific paradigm. We have high-speed, global, networks, so
operating in code teams is much more efficient, and requires less
insulation, and code blocks can be shared in *seconds* across thousands
of miles, so insulation is less important.

André Langhorst wrote:
> I can only add that most complex apps I have written are all OO and
> would not be easy maintainable if not, the first OO apps I have written
> met the "dangerous feature" criterion too, where is the problem? now
> they are allright and it saves me bunches of time and even opens up ways
> that would not be that easy in procedural ways

Each developer has to find their own style, their own workflow. I've found
most OO code I've worked with to be more maintainable after I deleted the
OO portions, and kept the procedures. They're smaller, more transparent,
and have less layers of abstraction to wade through when debugging or
changing them. However, I have noticed that OO developers tend to find
their _own_ code easier to maintain. The problem is when when somebody
who has never seen your code replaces you, is it as easy for *them* to
maintain? Are you objects obvious, your methods transparent? If so,
congratulations! You are a skilled coder, and your code will work well
regardless of your paradigm. The best coders don't require a specific
language or paradigm to excel, (see Brooks[1]).

As far as coding in teams, OO has also occasionally encouraged behaviour
that stifles teamwork....
By hiding variables, by hiding objects, the rest of the team has to dig
though the layers of abstraction to determine of an object is re-usable,
and more often than not, has to copy-paste into a new object and re-do the
code. So its back to the same problem of code management that's been
prevalent in procedural code, rewriting the procedure. Only now you have
more to re-write, as you are working with a layer of abstraction.

In summary, is OO in PHP really important? For those who are not efficient
when using procedural code, it *is*. Since the current fashion in computer
science seems to be OO, I'd say better OO support would be of help to
the coder who has not mastered procedural code, or to the coder who is heavily
reliant on external libraries. To those who would prefer to be insulated
from other (or even their own) code, it's *very* helpful. Does this mean
that their code will run slower? Yes, but if they are more interested in
their development speed than their running speed (they are using PHP, after
all...), that's a tradeoff they're willing to make. Most of the recent
CS/MIS school graduates I've dealt with can't even manage a 200 line block
of code, and are much happier with a focusing on a few objects, so OO
support saves me in training costs, and in hiring costs (as I can use less
capable programmers). So, can improving OO support, object caching, method
and function caching, add to PHP's ease of use? I think so.

-Ronabop

[1] "The mythical man month" 

--
Personal:  ron <email protected>, 520-326-6109, http://www.opus1.com/ron/
Work: rchmara <email protected>, 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my  employers, or any of the other little voices in my head.

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>