Chung Leong wrote:
Oli Filth wrote:
I agree, it's a widespread success, but its also a big sprawling heap of
hacks, afterthoughts, inconsistent function names and parameter lists,
function aliases, issues with references that no-one really knows how to
deal with, version incompatibiliti es, nonsense like magic quotes, ...
That's what I was hinting at.
Aesthetics. Aesthetics. Perhaps one of these days you will come to grip
with the nature of this world. The ugly win because they do what it
takes to win, while the beautiful disappear into oblivion.
In the 21st Century, where programming is as much about team-based
development and code maintenance planning as it is about knocking out
lines of code, aesthetics *are* massively important, IMO. Code that's
more consistent and easier to read is easier to understand, and easier
to hand over to another team member.
Note that despite the stance I appear to be taking, I definitely don't
agree with all the changes between 4 and 5, nor the proposed changes in
6. I see no advantage in changing constructor names to __construct,
changing the name of $this, continually changing string indexing syntax
back and forth, nor adding polymorphism of statics, for instance.
Incidently, I say the same thing to my historian friend, who, despite
all empirical evidence to the contrary, thinks that the principled
politician would always carry the day.
I wish it were true...!
I wasn't referring to "critics" in the sense of academics, but to
real-world programmers who might have wanted to use PHP if it weren't
such a mess (compared to other languages).
Let them use whatever language they were using then. What's this crazy
obsession with needing to "convert" people?! PHP is not a religion--it
is a tool.
It's not a matter of trying to "convert" people, no-one's going to go
"oh, I've seen the light, PHP is better than C++, what have I been doing
all these years". But a large user-base (and incoming users with skills
and techniques from a different language) will benefit the PHP community
and existing users. A more focused language with better OO support and
less inconsistency will benefit existing users doing new development.
From an engineer's point of
view you wouldn't alter a product to suit the desires of people who
aren't even using it--because it's goddamn stupid.
Umm, if you were trying to sell a product and there was an untapped
market, of course you would try to make future versions of your product
more attractive to them. Now obviously, PHP isn't being made for money,
but the developers probably have much the same goals as if they were
indeed selling it.
In the same way that hosts have to make a decision - do we want to keep
our existing customers happy by sticking with PHP 4 and push away
potential customers to other hosts that run ASP .NET or Java, or do we
want to attract new customers by running PHP 5 (or 6, when the time
comes), at the expense of making our customers make some trivial
revisions to their code? (When I say trivial, I mean that the actual
replacements themselves are trivial, the scale of the job may not be...)
Personally, I can't see why hosts can't run both 4 and 5, and keep
everyone happy.
Bad coding *can* get you closer to a working (in one sense of the word)
program - I've seen countless posts in PHP newsgroups where newbies have
asked things like "How can I loop through my variables $thing1,
$thing2...? "
That's just igorance. We all know that using an array in this
particular situation is easier. And once someone learn an easy way to
do something, he/she wouldn't go back.
It's not necessarily about ignorance about individual issues. Being a
good programmer/software designer is about being able to take a top-down
view and work out, a priori, why certain approaches are better/more
applicable than others, rather than having to be told on a case by case
basis.
to which the answer is "use arrays instead", to which
their response is "well, my variables do the job, so why should I?".
Very good question to ask in fact. If all you can offer is a
non-technical value-judgement: "it's good practice," then you're a sort
of priest of programming, not a software engineer.
You're right, it is a good question.
We all know that there are sound reasons behind most "good practice"
paradigms. The problem is that they're often quite hard to explain
concisely to relative newbies whose first and only exposure to
programming is PHP, and this is their only frame of reference. A frame
of reference where so many things are allowable, many of which will kick
them up the arse at a later date when their projects get larger and more
complex, and they realise that there's more to creating software than
just getting any old thing to work.
If someone's new to OO, for instance, but have found that there's this
neat thing called classes, if they discover classes through PHP then
more often than not they seem to end up trying to do things like using
classes as glorified arrays ("how can I loop through my class
members?"), or some bizarre reverse-polymorphism ("how can I find the
name of the function that called/created my object, so that I can get it
to different things accordingly?"). Completely missing the point, and
therefore the benefits, of OO. Trying to explain to them why abstract
base classes are beneficial, or why a class with only static members
isn't the same as a singleton, or why polymorphism is better than
dynamically defining classes, is extremely difficult.
--
Oli
