
The Lesser Known Contributors Who Are Trying To Make PHP Good Again - DanielN
http://www.danielnill.com/blog/the-lesser-known-contributors-who-are-trying-to-ma/
======
adaml_623
Article title seems to imply there will be some info about the people who
programmed these new features... instead there's a rehash of the new features
and mention of a library or 2 that we could read about elsewhere.

Author says, "the developers of these new tools deserve some serious
recognition for the work they are doing" and then totally fails to mention
them!

So now we've again been suckered into the 'PHP good' vs 'PHP bad' non-debate.

------
error54
While I've bashed PHP as much next guy, these are the facts:

-Take away PHP and the internet would break. The vast majority of websites are either written in PHP or have a PHP back end.

-The LAMP/LNMP stack is by far one of the most deployed web server configuration.

-PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web.

PHP is the Model T of web languages: people love to laugh at it because it's
old and ugly but it nearly single-handedly revolutionized the landscape. I for
one applaud any efforts to revive and improve this language.

~~~
josteink
_PHP is extremely well documented and it's been around so long that it's easy
to find solutions on the web._

I can agree that PHP is documented. That it is _well_ documented however is
something I'm very much willing to argue against.

PHP has string-operations documented to be "binary-safe" without ever saying
what that is supposed to mean, if it's good (it's not), if it's bad (yes, yes,
yes it is) and why you should have an opinion on that at all. Nothing about
that. "Binary-safe" is not defined anywhere. It just "notes" that all these
operations which should operate on text is "binary-safe". And "safe" makes it
sound like a good feature, right?

Documentation like this is probably written by people who have no idea what a
character encoding is and thinks that being able to strpos() on raw byte-data
is a "cool feature", without understanding that text and it's encoded
representation are two very different things.

Basically, the documentation is written by people lacking any deep
understanding of the subject they are covering, and they pass their confusion
on to whoever may be unfortunate enough to stumble upon it.

So... Is bad documentation better than no documentation? I don't know. Maybe?
Still: PHP documentation, good or bad, represents the blind leading the blind.

If you want "extremely well documented", head over to MSDN and check the .net
docs. It's systematic, it's consistent and it's thorough. It's written by
people who understand the difference between Unicode, UTF8, text and bytes. Or
whatever else the subject you are reading about covers.

But people peddling in PHP wouldn't know that, because they wouldn't want to
go too far outside their comfort-zones, and hey, they _definitely_ wouldn't
want to look at anything done by Microsoft.

~~~
krob
@josteink, you don't really understand what good documentation is do you. A
large amount of PHP documentation provides context in which you may
effectively implement a piece of code by providing "sufficient" examples. A
grenade I can almost guarantee you probably comes with documentation, but
probably a warning which states when you pull the pin, it will blow up. PHP
will not blow up the world, or blow your hands off. The documentation does not
have to be "perfect". PHP has changed web development in many positive ways,
by increasing what could be done via simplicity using what you might call poor
documentation. It has sufficed enough that good developers found it sufficient
to build large complex code-bases which they could both build on and make
money from. Much of MSDN library is created from internal comment-style
documentation automation(JavaDoc,PHPDoc, XML Comments). MSDN will often times
lack easily readable code-samples, and provide enough context in which you may
actually use a library. Just because you define a prototype with long naming
conventions doesn't mean Joe schmuck has a clue. PHP examples are generally
not obtuse, or obfuscated to newbies. It's the "I'm going to show you how to
hunt fish" and nobody said it had to be pretty. MSDN has gotten better over
the years, but there are still many areas in the many libraries hosted on
there which don't have "even good enough" documentation to help you to the
most basic things.

------
ericclemmons
Time to beat this dead horse again!

PHP as a language isn't great, since it has been around the block in a
volatile environment (the web) and shows lack of foresight in language design.

However, PHP is experiencing a renascence with modular components, frameworks
and tools utilizing established design patterns, and an overall boost in
contribution and collaboration in the open-source community, in large part
thanks to Github.

PHP is not dead, and vibrant communities around Symfony and Doctrine are
pushing it forward considerably.

In my opinion, large applications can and have been built primarily on PHP
while leveraging other languages and tools for their strengths.

~~~
mseebach
A lot of good people are working on a lot of PHP that isn't going away, and
obviously they are going to improve tooling and the language itself. There is
a renaissance in terms of making PHP development sane and thus not something
good people run away screaming from - a bit like Java.

But the benefits of starting a new project in PHP are few: All of the original
benefits (mainly low barrier to entry) are eradicated, and that leaves PHP to
compete directly, as a full development environment, not as the only easy way
to get code on the web, with a myriad of other languages that can, almost
objectively, be thought of as better. Again, a bit like Java.

------
mseebach
PHP was never good, but it abstracted away some basic web specifics -- as
opposed to CGI/Perl that required you to care about protocol details such as
starting output with two newlines -- and hit a sweet spot infrastructurewise
-- dead easy to get started with, dead easy to get hosted for next to nothing
-- that gave it enough traction to grow very quickly.

~~~
fallous
I'm not sure that was so much the attraction when PHP first started gaining
traction given the existence of CGI.pm

From my experience in the 90s, most of the early adopters of PHP were more
smitten with included PHP code in otherwise static HTML files. It was SSI++

------
acabal
Those are all nice, but as a long-time PHP dev, the only way to make PHP truly
better is to do a Python-style hard version bump. Rip off the band-aid, so to
speak. Create an entirely new, consistent, object- or namespace-oriented
standard library to replace the mess that exists now. The majority could just
be wrappers for existing code, which is fine but just inconsistently named and
parameterized. Then fix the terrible namespacing implementation, consolidate
the jumble of operators (::, ->, ., +, etc.), add some syntactic sugar to
objects (getters and setters?), add native Unicode support, and call it all
PHP X or something.

There's much to be said for backwards compatibility, and PHP does that really
well; but there's also much to be said for a new generation built with the
mistakes of the past in mind.

I actually really like PHP despite its flaws. It gives the programmer easy,
deep control over HTTP output, it's easy to install on new servers, it's easy
to deploy (no compilation, just rsync everything!), it has decent built-in
templating (if you can learn the quirks), it's OSS, it has rich libraries,
rich documentation, and a rich community. But it's also deeply flawed and it
deserves a break from the past.

My ideal sort of web language would be something with C# syntax and libraries
but with PHP-style OSS-ness, simplicity in output and compilation, and
expressiveness in HTML. That would be nice!

------
zdw
Everyone probably knows this, but PHP's Smarty template engine
(<http://www.smarty.net>) is really awesome.

I've yet to see a better one in any language - it has things like Unix-like
pipe chaining of filters, user defined functions, and intelligent caching
built in.

I reduced the number of lines in one codebase I worked on by 70% through use
of Smarty.

~~~
mtts
PHP is itself a template engine.

Bolting a template engine on top of that makes no sense whatsoever.

~~~
andersbreivik
I hate PHP and don't even want to talk about it but I did skim through the
docs for Smarty. The rationale is that PHP sucks as a template engine, so why
not create a new one and use PHP for the model-controller/whatever.

Maybe that seems perverse, but you have stuff like Node.js in existence that
oddly enough solves some problems quite nicely, so maybe it works for PHP
guys. I'll never see the appeal compared to other languages though.

edit: That being said, the final result looks kind of horrible to me.

~~~
josteink
Completely unrelated: I'm not easily offended. Right now I'm not offended at
all, in case anyone would interpet this post to mean so. I'm all OK. Really.

But that said: I'm severely puzzled about your choice of HN username.

~~~
ingve
Breivik is a fairly common last name. There are actually 8 men in Norway who
have Anders as their first name, and Breivik as their last name.[1]

[1]
[http://www.ssb.no/navn/sok.cgi?lang=n&fornavn=anders&...](http://www.ssb.no/navn/sok.cgi?lang=n&fornavn=anders&etternavn=breivik)

------
jrockway
So does PHP not let you mock things by actually writing classes in the test
file, like:

    
    
       class FakeFooBar(FooBar):
           def my_method(self, *args):
               self.last_my_method_args = args
               return self.result
    
       class TestFooBar(TestCase):
           def test_my_method(self):
               foobar = FakeFooBar()
               foobar.result = 42
               self.assertEquals(
                   foobar.use_my_method('hello world'), 'forty two')
               self.assertEquals(
                   foobar.last_my_method_args, ['hello world'])
    

This is more verbose than mocking things out, but the control flow is more
obvious and you don't have to rewrite the entire test case every time you
change one tiny implementation detail (which is what I've had to do with every
mox test I've ever written).

Actually, it's not even that verbose compared to mox :)

~~~
TomNomNom
It does; it's just not very common.

Defining mocks manually is my preferred method. I find things like Phake and
Mockery to be a little too opaque and hard to debug when you get subtle
problems. I think they also add to the learning curve when getting new devs up
to speed.

IMO one reason a lot of PHP devs avoid the manual method of defining mocks is
just laziness.

------
jey
When was PHP good in the past? (Honest question; I don't use PHP.)

~~~
DanielN
Quite possibly never, but it was arguably the best web language in the early
2000s.

~~~
plorkyeran
Perl fans would probably object strongly to that, but it is true that when PHP
first caught on there really weren't any great choices.

~~~
prunebeads
The strong selling point of PHP for a long time was cheap hosting. Combine
that with a fast learning curve and you're set.

Nowadays, it's not so clear cut price wise, but PHP took a strong advance in
term of user base - look at the number of libraries, projects, and jobs (!)
available in PHP, vs python or ruby.

~~~
gubatron
good selling points, but those things never made it a good language, it was
just convenient.

~~~
prunebeads
PHP followed a very uncommon path. Features were added as needed, in an
incremental fashion. Nice syntax is never a huge problem, though that's
probably most people complaint. That said, it isn't worse than its
"contenders" in terms of feature set. You get a decent object system, lambdas
(note that they'd been there for a long time, but it's more convenient now), a
wide range of bindings. It's not pretty, but it does the job in many cases.

But, anyway, if you're really looking for a good language (something
efficient, where you don't have to spend hours to spot a stupid bug), skip the
dynamic ones altogether, and go for as much static analysis you can get.

------
languagehacker
Those examples aren't good differentiators between PHPUnit and Phake. And
unfortunately, despite how goot Composer it, it just adds another package
management system into the mix. GitHub has ended up being the best package
manager PHP could really ask for.

I kind of view the native PHP development server as getting featural parity
with Rails and Django. But it seems like that's a major gripe for developers
who are averse to working with Apache or Nginx for being too complex.

I'm very excited for traits as a feature. This is when we get into real
language features other, more prestigious or "hot" web development languages
actually have that PHP lacks. These result in true architectural deficiencies
requiring annoying hacks to accommodate.

In the end, PHP itself benefits most from expanding its capacities as a
logical formalism. Tools are great, but they're also a lot less easier to get
right.

------
lunetics
You shouldn't forget about PSR-0 / <http://www.php-fig.org/>

~~~
Dachande663
PSR-0 would be great, except for the use of mixed case filenames. The number
of packages that have obviously only been tested on HFS+/other case-
insensitive filesystems is staggering (or maybe I just have bad luck picking
ones). The only logical reason I can see they didn't normalize and lowercase
filenames is that the big boys had too much legacy cruft already broken.

------
TamDenholm
To all the language bashers, can we all agree that a good developer beats a
bad developer in any language?

I wrote a post on this: <http://news.ycombinator.com/item?id=4606961>

------
jentulman
composer is great, I'd just like to add that the docs make the distinction
that it's a dependency manager rather than a package manager.

------
eik3_de
Serious question: Do you know of successful/large web startups in the last two
years that used PHP as their main language?

~~~
robryan
I would be interested in the answer to this also, but I am coming from the
side of expecting lots probably are.

------
gubatron
Again?

