Comment by josteink | Hacker News Reader

Comment by josteink | Hacker News Reader

Parent Full thread

I'll be intellectually honest and admit that, no, I haven't really touched PHP for anything near a production app in the last 5 years.

But to be absolutely clear: before PHP used to be the only language I wielded for money. I have enough lines of PHP on my back to claim the right to an opinion.

That said, last time I looked into PHP, modus operandi seemed to being focusing on making things easy, not making it easy to do things right.

AFAIK this one quote from "PHP is a fractal of bad design" still holds true and that if you ignore all the other obvious things (wildly inconsistent BCL, etc), it is probably the core reason why I can never bring myself to like anything PHP:

PHP is built to keep chugging along at all costs. When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical. Anything is better than nothing.

AFAIK that's still true, and I find it hard to have confidence in any code written on top of something based on that core tenet.

Edit: Experience clarification

So why did you comment in the first place, in what world do you find it expectable to berate something with no working knowledge?

Also I have no trouble developing PHP code that halts on the first sniff of an error. But yes, with no experience of the language it will happily chug along.

See my clarification. I think I may have been a bit unclear and/or you may have misunderstood my post.

Talking about the PHP of 2006 and then blasting the PHP of 2012 is like talking about George W Bush and then blasting President Obama.

They're almost completely different language, and while PHP 5.3 certainly has warts it's vastly better than PHP 5.0.

To me, every PHP version being vastly better than the previous version says something: the current version is shit too, it's just going to take another few versions until you admit it :P

Compared to something like python, where version 3 has basically one major improvement over version 2 (ie, a unicode core); everything else was done pretty much right the first time, and massive changes aren't needed.

Heck, you can still use 2.5 (the python of 2006) quite happily today, and you'll be missing out on a few nice features that would make your life easier, but there's nothing wrong with it like there is with previous version of PHP.

If I plot two lines on a graph for you:

y1 = 0.02x + 1

y2 = 0.10x + 0.5

Regardless of the fact that y2 started at 0.5, fully half of what y1 started at, at some point y2 overtakes y1. It's impotent to whine endlessly that a language used to be bad.

So PHP 5 years ago was terrible. PHP today is 'nearly as good' as Python (I'd argue it's better). In 5 years PHP is going to blow Python out of the water.

These languages that are 'better than PHP' have no appreciable market share, and it's not a vast conspiracy and it's not because PHP caters to the lowest common denominator. It's because they suck, fundamentally, at getting things done. WordPress doesn't exist in Python. Symfony doesn't exist in Python. Doctrine does, but PHP has more database drivers than Python so Doctrine is better.

You can be terse, elegant, and beautiful in Python. That's great, but no one I know has ever cared about what the code they're paying for looks like. They care about stability, agility, and testability - things you've been able to get in PHP since 2005.

I think your graph is accurate when it comes to the amount of effort put into polishing each language -- but as to actual quality, I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges, but the core is solid and needs no more changes), and it doesn't account for the fact that with a constant large amount of effort as input, progress as output slows down exponentially due to backwards compatibility concerns. As such, I still think that starting off good and evolving slowly is better than starting off awful and rapidly turning into a giant blob of band-aids :P

Again with the scales, I agree that PHP is great for getting things done to start with, and once you've started with something then carrying on using it is easier than changing. That's why my biggest and most successful project still uses PHP, even though experience has taught me that everything else is more productive after the initial setup hurdle~

Stability, agility, and testability have been in other languages for decades, and in all three cases other languages have done them better, so I'm not sure why PHP having them since 2005 is supposed to be a good sign...

> I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges,

Not your functions, not your plane, you don't get to define parameters.

> starting off awful and rapidly turning into a giant blob of band-aids :P

PHP has been completely rewritten at least twice.

> everything else is more productive after the initial setup hurdle~

Can you give a single example of something in Python that introduces greater productivity than PHP?

> and in all three cases other languages have done them better

> so I'm not sure why PHP having them since 2005 is supposed to be a good sign...

Now you're just being a pedant. The point is that it isn't 2005 and it's not 1978. It's 2012. Talking about what the capabilities of a language were almost a decade ago is useless.

Surprisingly, out of all the comments, this one caught my eye. I've been hiring programmers since 2005 that have to maintain or extend PHP systems. In 2005, it was difficult to find programmers that knew only PHP (or Perl, which was still used) who had any familiarity with object-oriented programming. Over time, PHP has bolted on features, and at each point, the vast numbers of available PHP programmers are (understandably) not familiar with those features. And obviously the systems that have to be maintained don't have these features. So the armies of PHP programmers are well matched to the old systems. This eliminates a huge risk to the business -- finding relatively inexpensive developers. This is an often cited advantage of PHP. But only the PHP of 2007 (or so) is relevant.

The PHP of 2009 might be worthwhile for the creation of business value (and possibly the reduction of maintenance-related risks), but as I said, the easily available programmers have no experience in those features or concepts. The more common scenario is that a particular programmer has experience in some other language that already included those features and doesn't mind working on old PHP systems. Believe me, there are not legions of these people.

And regarding the 'PHP of 2012', the major problem isn't the availability of programmers who have experience in the new features (they almost don't exist). It is the availability on distros stable enough to support an SLA or provide a modicum of security assurances. This problem applies to all languages though. I'm just pointing out that the 'PHP of 2012' is not as much of an option as it may appear.

The PHP interpreter is much like any other compiler or interpreter. It will halt on errors. It will, by default, output warnings/notices for things like accessing uninitialized variables. Like any other compiler or interpreter, you can tell it to hide warnings, or to halt on warnings, or to log them somewhere instead of outputting them. What makes this a fundamental weakness of the language, but not of, say, C, where gcc will also happily compile code no matter how many warnings it runs into?

C is intended to be low-level, like an extra fancy set of macros for writing assembly. It is intentionally not supposed to do that much for you because you need greater control to do things like writing UNIX. Nonetheless, if you use it seriously then you will find that gcc does outright refuse to compile a great many things that it recognizes as broken, rather than chugging along. There is no way to simply suppress all compiler errors because there should not be.

Nobody in this discussion has raised the possibility of writing web apps entirely in C and suppressing all compiler warnings as they did so. That is a scary idea. And it gets even scarier if we are advocating for newbies to start writing web apps that way.

HTML also chugs along at all costs:

You don't have to close tags,.

You can add(misspell) unknown attributes to tags.

<input type="text"> works the same as <input type="foobar">

You can have multiple tags with the same ID field.

You can do ALL that and your page will still render, and probably look just fine. That's a major reason why the web took off. Because it didn't take perfection to get something done. Anyone that wanted to make a webpage could fumble around and make something that looked like a webpage.

Perhaps the web would be in a better place if browsers gave an fatal error if it tried to load a page that doesn't validate ... or maybe there wouldn't be a World Wide Web, much like there aren't any CueCats lying around.

Hey now, I still have my CueCat... I hacked it to work as a standard barcode scanner.

Reply on news.ycombinator.com