PHP 5.5 | Hacker News Reader

PHP 5.5

github.com

106 pointsdave1010uk109 comments

Seems like a bunch of really welcome improvements. Wish I hadn't known about them though, as I probably won't be able to use them in our production environment for the next 2 years or so.

Can I ask why it will take so long? I'm working on a medium to large scale project and we will be likely rolling the new version out to our staging environment within a week and assuming everything goes smoothly to the production environment not long after that.

If michh is working on plugins for other people, shared hosts can be pretty behind on their PHP versions. I just had to backport a wordpress plugin to 5.2(!), which came out in 2006.

EDIT: meant PHP versions, not plugins.

Thats the curse of distributable code unfortunately. And PHP only makes it worse because it's old versions are absolutely terrible...

> And PHP only makes it worse because it's old versions are absolutely terrible...

You just need to put your foot down. 5.2 is absolutely too much, I would never develop for it. Just tell them to stop being so damn cheap and upgrade to a decent hosting company. AWS is free for a year for new clients, there's no reason for them not to switch to something decent.

My biggest nemesis: legacy...

Am I the only one thinking PHP needs more stuff removed rather than added ?

If you mean deprecation and then removal, yes. Search for deprecation in the changelog to see that it's happening already! ;)

Yes.

Removing stuff from a programming language has virtually no benefit and a huge real economic cost. That, of course, is under the assumption that the programming language has users.

I could see them deprecating some stuff, and adding yet another E_EVEN_STRICTER level that tosses ugly notifications when deprecated things are done. That would be nice.

IIRC E_DEPRECATED notices are triggered when deprecated stuff is referenced.

http://php.net/manual/en/errorfunc.constants.php

E_DEPRECATED - Run-time notices. Enable this to receive warnings about code that will not work in future versions. (Since PHP 5.3.0)

Indeed; in fact this update issues an E_DEPRECATED warning when you attempt to connect to a MySQL database using the old MySQL extension.

Hmm, but does it have to be that way? What if every new version of a programming language came with a tool that converted old source code to new source code, like Python's 2to3? That way you could cleanly handle removals, renamings and all sorts of other changes... maybe even provide implementations of old library functions in terms of new ones.

Automatically updating someone else's code is more difficult than it seems. Any Python project of significant complexity will need manual adjustment before or after passing it through 2to3, and even then you'll need to perform a lot of tests to make sure that everything behaves as expected. Similarly, the upgrade wizard in .NET always breaks a thing or two. I would expect a PHP upgrade wizard to fare no better.

For example, PHP allows you to keep the name of a function in a variable and call it as if it were an anonymous function. So you can do something like:

    $h = 'htmlspecialchars';
    echo $h('<script>');  // &lt;script&gt;

Of course, it's probably a bad idea to do this unless you really have no other option. (By the way, the above example is not how Lithium uses $h. But we can easily imagine a lame imitator doing the above.) But given that some programs do rely on features like this, how would you update them automatically if you decided to change the way htmlspecialchars() works?

Things get even more complicated when functions change in more subtle ways. If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects. If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.

A better solution is actually what PHP has been doing for the last few minor versions: deprecating stupid functions like mysql_real_escape_string() and encouraging people to migrate to modern alternatives. Once a function is marked as deprecated, it will be removed in a few years. This process takes longer, but it gives everyone enough time to update their own programs.

> how would you update them automatically if you decided to change the way htmlspecialchars() works?

I see two possible cases, the choice between which can be made by the converter developers or by the user (maybe via command-line flags to the converter):

1) If the new functionality is intended to be a drop-in replacement (e.g. it fixes a security bug), no change is necessary.

2) If we want existing programs to keep using the old functionality, you could automatically translate all cases like this (assuming we're translating from PHP7 to PHP8):

    echo $h('<script>');  // PHP7 code

to this:

    echo php7_varcall($h, '<script>');  // PHP8 code

To clarify, php7_varcall() is a function in PHP8. When it receives 'htmlspecialchars' as an argument, it calls the function php7_htmlspecialchars() which is a faithful rewrite of PHP7's htmlspecialchars() in PHP8.

> If a function that used to return FALSE on failure is updated to throw an exception instead, an automated tool would have to wrap every function call with a try-catch block, with potentially unexpected side effects.

In general, any php7_builtin() should be implementable in PHP8 somehow. If that's not possible, I'd say there's a gross design error somewhere.

> If a function that used to take strings in the system charset by default is updated to take UTF-8 all the time, you'll have to throw in some code for charset conversion before every occurrence of that function, but some servers might not have mbstring/iconv installed and turn that into a fatal error.

In general, if the implementation of php7_builtin() in PHP8 relies on some library, then that library should be included in the "compatibility library" required to run all converted code.

So your solution is to add more functions, like php7_htmlspecialchars(), php7_htmlentities(), etc. whenever a function needs to be deprecated, just like PHP historically added functions like mysql_escape_string(), mysql_real_escape_string(), etc.? I don't think that will help the language and its ecosystem at all. I can almost see the tutorials in my mind: "If you upgrade to PHP 8 and your function call suddenly starts spewing errors, just use php7_function and your problem is solved!" Then 3 years later: "just use php8_function!"

Anyway, my point was that static analysis, which an upgrade script needs to perform, has serious limitations when it comes to dynamic features. Callable variables are a good example of this. What if there are 100 places in your codebase where a variable is callable, but only one of them is ever going to contain a deprecated function? Static analysis can't tell which one it is, because at runtime, the variables might come from anywhere: user input, a database, a command-line argument, or the phase of the moon. The only bulletproof solution is to convert them all to php7_varcall(), even the 99 variables that don't need upgrading. But then your code just becomes unreadable, and therefore even more unmaintainable than before.

Functions like php7_htmlspecialchars() wouldn't live in the standard library, they would live in the "compatibility library" instead. That might help discourage new users from using them and mentioning them in tutorials.

I agree with your point that bulletproof conversion will make reflection-heavy code less readable. But still, if we can make a bulletproof converter that works on 100% of old code and leaves simple code relatively unchanged, doesn't that open up some nice options for everyone?

- Users who don't care about code quality, and just want their old code to work, will be happy because they will have a push-button upgrade solution.

- Users who care about code quality will also be happy, because they can run the converter and have a complete working program right away. Afterwards they can modernize it piece by piece, at their own pace, having a complete working program at each step. Without the converter they'd be stuck doing a full rewrite.

- Language implementors will be happy because they can keep the language clean as it evolves. Imagine how awesome Java could be today if they took this route.

I sort of agree with you, but then I come at it from the view point of why choose PHP? Myself, I can't think of a single awnser, but then again I'm the kind of person who learns a programing language or paradigm for fun.

However there is an elephant in the room with PHP, it has, quite frankly some terrible creations made by it. In much the same way MS had a whole bunch of technologies around DCOM and the like which suddenly found themselves disabled and strongly advised against use in XP SP2. I think PHP really does need to try and clean up its image.

The whole 'lets go find some sql injection vulns on github' game demonstrates many people still use the tool badly.

At what point does someone say, that they should re-design the tool, so that they encourage better use.

I'll be honest, if I hear someone say "we're using php for this" I assume its just because they are ignorant of other languages. I can't think of any problem I've been faced with, where PHP is the best solution.

So ultimately, if your going to try and remove stuff, why bother, you'll only break the existing projects, rather than improve them. The best thing is to treat the language as depreciated.

From an engineering perspective you're probably correct. However, from a commercial perspective (be it long-term support, business continuity, cost of developers/support) PHP is one of the best solutions.

> I think PHP really does need to try and clean up its image.

Sorry, but you obviously have not been taking notice over the past year or two. PHP really has been cleaning up its image. Go have a look at PHP-FIG, composer and packagist for starters.

Yes, there are problems. Yes, some/most may think that there are better solutions. But to think that PHP has not been "cleaning up its image" is just wrong.

>Sorry, but you obviously have not been taking notice over the past year or two.

I'll admit, I haven't really, because I'll turn it round, why would I?

We've seen Erlang start to be used quite a lot, Scala is becoming very interesting, and F# is appearing suitably mainstreme.

What features would make me think "hmm, I should check out what they are doing in PHP"?

Looking now I still see a cluttered array of APIs, some pretending they are C from the 80s, others hinting that they at least knew of objects in their design.

A quick look for static analysis rule systems for say our CI system: http://mark-story.com/posts/view/static-analysis-tools-for-p...

Wow, that's pretty poor.

What I do again see, are PHP developers who are not fluent in any other language. I always find that odd. For instance I've been doing mostly C# since version 2. But I would probably pass most Java or CamL interview questions anyone had. I am happy in C# knowing what I am missing from other languages (well, not happy, just its the right choice for the things I've been doing).

In short, PHP has an image problem with plenty of people. I am one of them. They can't easily solve it, without breaking a whole bunch of existing code, as most of my complaints are inherent languages features and core API design (or lack there off). I don't nock languages that eschew OO, but I do nock ones that implement it, just very, very badly.

>We've seen Erlang start to be used quite a lot, Scala is becoming very interesting, and F# is appearing suitably mainstream

Your definition of mainstream must differ from the dictionary's.

>Your definition of mainstream must differ from the dictionary's.

I have got the same two agents constantly bugging me "oh you know some Erlang right?" at the moment, but the only one that I begin to describe as mainstream is F#.

If your in any kind of LOB space which deals with 'Maths' F# is rampant now. Which is handy for me, as I used to instruct labs on OCaml at uni.

Just using www.inqjobs.co.uk looking in London for contract rates on 500pd+ I find over 20 roles for F#. Compare that to the Python or Ruby number.

That to me, is mainstream. Not quite Java/C++/C# league, but certainly out there.

My biggest problem with PHP is that I was never able to find a good framework for it. After I found Laravel I started liking it a lot more.

Well actually I don't use PHP that much anymore, but I do keep an eye on it; there's been a lot of improvements, mostly on the ecosystem side. It's definitely not my language of choice, but one still has to eat, and PHP jobs are unfortunately way more common than most other stacks around here, outside of the enterprise stuff which I'm currently doing.

But isn't that the point of PHP? Removing stuff creates version instability. If you want something lower level then there's lots of alternatives.

Removing things from a language is a difficult proposition. I think increasingly a case could be made for a cleanup of many of the core functions, and I personally would remove some of the OO sugar coating added as of late. But that's probably more trouble than it's worth.

As core function naming and argument order is a pet peeve of mine, I would welcome a cleaned-up API2.0 if you will, while beginning the long phase-out of the old one.

I would agree though that some features should not have been added in the first place. But they're in now, and once they are in they should probably stay in for a while.

That's pretty much what I had in mind with this comment, I should have expanded it a bit. What grates on my nerves when writing PHP is indeed the awfully inconsistent standard library. Though some syntax choices (namespaces for instance) are also pretty weird.

Maybe someone should fork the parser/lexer and see what a cleanup can accomplish. There are a few tons of "features" I would delete immediately. And I agree the namespace syntax is horrible.

> Am I the only one thinking PHP needs more stuff removed rather than added ?

You can remove things yourself? The PHP codebase is extremely modular. Just compile your own PHP and leave anything you don't want out. Has a wonderful --disable-all flag and then you just add the stuff you need.

One of the most overlooked features of this release is the "::class" option. Using fully qualified string literals for type (class, interface, and trait) names has really hurt refactorability.

I can see array_column being useful instead of using foreach on sql query results.

...or PDOStatement->fetchColumn('column-name').

PDOStatement->fetchColumn() accepts only integers as an argument.

http://ca.php.net/manual/en/pdostatement.fetchcolumn.php

It does not do the same thing, does it ?

http://benramsey.com/blog/2013/03/introducing-array-column-i...

It's useful for a whole bunch of things!

I had it implemented in userland as a utility for years.

It's useful for lots of things, I implemented something similar as array_pluck recently and immediately noticed lots of places where it could have been used.

Biggest change? - Drop Windows XP and 2003 support

And PHP finally gets finally, I guess.

Most interesting things for me:

* PHP is getting the yield keyword (i.e. generators and coroutines), which many other languages have had for a while.

* A sensible and simple built-in password hashing API

* Error when using the deprecated mysql extension, which should hopefully get more people moving to PDO (e.g. WordPress: http://core.trac.wordpress.org/ticket/21663 )

For the last one, won't people just move to the mysqli_* function group instead? It's almost identical API-wise.

Line 11 is "Added simplified password hashing API"

I'm trying to push for that WordPress ticket, but it's unlikely that we'll get any significant traction for a while. The database class in WP (apart from being fairly horrible) is a huge component to make major changes to like that, and we have to consider backwards compatibility.

Here's hoping it gets merged in the next 5 major releases. I'm not holding my breath.

Only if you're using them in the first place. Most people deploy in Linux. Hence, totally irrelevant for them.

Deploy yes, but not develop with. Most people don't really use virtual machines (vagrant and friends) if they have XP.

I would say that people who develop on XP are even fewer than those who deploy on XP. It's a 12 year old OS -- surely they have moved to Vista, 7 or 8 by now.

You would think, my employer is still running XP on the developers machines, with no plan on an upgrade in the near future.

Run, don't walk (if you can).

You can have a modern development framework for php. You guys should try http://laravel.com/ such a fresh air into php development.

A nice meaty change list there. Get compiling :D

Download: http://php.net/get/php-5.5.0.tar.bz2/from/a/mirror

And what I still don't see is anything saying they are taking their performance problems seriously. Still nothing saying they are fixing their documentation. Nothing addressing their hodgepodge of legacy code and mixed methods of implementing features. Its like their upset that people have moved on, but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the language hoping to get more people sucked into developing for it only to realize that once they do anything of significant size in PHP they will need to do a full rewrite into a language that can actually scale or turn to a PHP to C++ lexer to actually get a product that doesn't also server as a Data center toaster oven.

Out of interest, what do you find wrong with the documentation? I've always found it pretty comprehensive and relatively easy to navigate.

I personally found it very incomplete. The comunit makes up for it but quite often there were large gaps exspecially regarding edge cases and details on how functions would behave if they failed. The comments did a really good job of filling in these gaps but the documentation alone was often inadiquate to understand how the code would behave.

Generally very little, but there are things like http://php.net/trader_stoch

To be fair, that is an optional extension and not bundled into PHP by default.

http://www.php.net/manual/en/internals2.apiref.php

5.3 and 5.4 had significant performance increases. 5.5 has integrated opcode cache. IMO, PHP has one of the best documentations of any programming language. Many bad bits have been deprecated in recent versions and there are PSR recommendations which make it easier to write decent interoperable code. PHP is growing up.

However, if you don't like it, nobody's forcing you to use it. Just walk away.

This ^

I find the people doing the moaning about PHP are the noobs who are regurgitating what they read or heard elsewhere in order to appear smart, Having moved to PHP 10 years ago after C and Java and .NET development I am happy for having changed direction and have made a bootload of money and saved alot of time thanks to PHP over the years.

Great response, i love the PHP documentation. Writing clean PHP is not hard, its just easy to write bad PHP. In general it is one of the simplest languages to get started with and it'll stick with you a very long time because of its flexibility.

The PHP team does take speed seriously and just about every minor release gets a little bit faster, sometimes alot, like 20% faster. I'm not even including stuff like the opcode caches that are built in now like APC or Zend Optimizer+. Lots of times, minor releases also get more efficient with memory usage too. If you are not happy with the speed, PHP is an open source project and you can contribute patches to speed it up.

Documentation gets fixed all the time. PHP has been historically known as having one of the best docs and the docs have contributed to its success. As with the source code, the docs are open to contributions if you feel the need to modify or add something.

That's funny you say PHP can't scale. Facebook, Yahoo, Etsy and a whole lot of other big PHP shops get more traffic than most of us will ever see in a few life times. So, PHP scales. Even pre-Hiphop Facebook got more traffic than most of us will will ever see. Many times scaling is more about architecture design/implementation than language. App Engine is all about scaling and PHP runs on it. Oh by the way, at scale, every language is a data center toaster oven.

PHP people aren't mad that people are leaving. They are happy that it is still the #1 language used for web development.

The only valid argument you have is the mixed methods and stuff. It would be cool to fix, but it would mean seriously breaking the API and would cause a lot of confusion. Every minor release breaks the API a little bit and people are unhappy. So, this might never change. I don't see it as a big deal because if you are a great programmer, you know the quirks of your language and they don't throw you off. Also, there is auto-completion and docs for you to look up things if you don't know stuff off the top of your head.

It is true that lots of developers have left PHP, but it is a falsehood that everybody is moving away from PHP. If that was the case, PHP wouldn't be running on 75% of the public facing web hosts out there. There would be a business incentive (because they are using another language) to get PHP off their box. They could devote those resources to the new language they are using. The 75% number shows that their is no mass exodus, but definitely evidence not everybody is using PHP.

Oh, by the way, PHP is open source so you can help contribute to its continued success if you like. If somehow you have already contributed, don't stop till the work is done.

I do contribute to PHP. I have had a few patch submission fixing bugs here and there, but then you run into this

    http://www.php.net/manual/en/internals2.apiref.php

This is PHP's documentation for fixing things internally to it. Which would be fine if the internals made any sence whatsoever, but between the implementation of steams and the abmismal design of zval's there isn't much to logically make sence of.

And this isn't just well if you find it lacking its open source so make it better. We have we made better PHP's and named then things like Node.js and Python. Why would I implement a JIT in PHP when I could just use V8 and have an awesome runtime right out of the box ? Imperically PHP isn't nearly as fast or efficient as other languages, that’s not just an opinion it's been shown in multiple benchmarks and tests. I know it can be used for doing useful things and can even be used for large projects. I work on one of those daily, the issue is no one seems to care that as a platform PHP is _not_ a good choice any more, and increasingly the community isn't making a point of steering the platform to where it is a good choice. They just rattle off the same talking points of "Well facebook uses it" and "XX% of websites are using PHP so clearly it is good"

You want a good PHP release?

Provide documentaiton on the entire platform (http://www.php.net/manual/en/internals2.apiref.php)

Fix the zvals to make thbem memory efficient

Speed up the core ( not a opcode cache a real tracer and JIT )

Then add in yield and continuations, because without the other parts no one should care about language niceties, because no one should be using the language.

Another person who knows nothing about PHP, yet still has an opinion on it? Color me shocked.

> And what I still don't see is anything saying they are taking their performance problems seriously.

Hmmm, you have heard about PHP-FPM right? And the built-in APC cache? And HipHop?

Besides, in my experience performance problems will arise with other parts of your architecture a lot sooner that your application code (e.g. database if you're not clever about load balancing and caching), regardless of what language you are using. Network calls and disc I/O are a lot more expensive than CPU cycles in your app code.

> Still nothing saying they are fixing their documentation.

Define fixing. It works fine for me as-is.

> Nothing addressing their hodgepodge of legacy code and mixed methods of implementing features.

Again, define addressing. Deprecating? They're doing that. What else do you suggest, breaking existing popular applications by removing legacy code that you find offensive? Let me know how that works out (see Perl 6, Python 3...).

> Its like their upset that people have moved on,

Define people. Seriously.

> but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the language hoping to get more people sucked into developing for it only to realize that once they do anything of significant size in PHP they will need to do a full rewrite into a language that can actually scale or turn to a PHP to C++ lexer to actually get a product that doesn't also server as a Data center toaster oven.

Wow, that needs a comma.

I hate these ranty posts attacking open source projects. Have you any idea how many hours of dev time went into PHP 5.5, free of charge? If they work that hard to build something this significant for the community free of charge, the least they deserve is your respect. In the meantime, feel free to go use Scala/Ruby/Node/whatever excites you.

I do respect the work they have done to the language, and I have also spent many hours contributing back to PHP and the various projects in the PHP community, however that doesn't change the fact that the _community_ collectively has a hard time dealing with the hard issues that need to be solved. Proof of that is the response you see right here on this forum. Mention how PHP's internals are lacking and get told how I must be a n00b and should just turn on APC. Until PHP starts to take its core defects seriously I don't think it will ever make significant progress as a platform.

> Until PHP starts to take its core defects seriously I don't think it will ever make significant progress as a platform.

I'm sorry, but given that PHP the platform (forgetting about gripes with the language syntax for a moment) has been used on major projects for years, what more significant progress do you want?

Your talking about it as if it needs to prove itself as a viable technology, when clearly this is not the case.

^^^^^^ This is the attitude I am talking about. Clearly since it's popular then there is nothing wrong with it. Thats total BS. There are tons of things wrong with it. Yes people do really cool things with the language and the run time, but just because someone using it doesn't make it _good_.

> just because someone using it doesn't make it _good_

Actually, it does. When you give people a large array of choices and they consistently choose the same thing, over and over again, that makes that thing good. Now, it may not be good for exclusively engineering reasons, but it is still nevertheless good.

Could you be more specific? What's your performance problem? Where do you think the documentation is bad? In my experience these are two areas where PHP is doing pretty well.

I share your reservations about legacy API (the naming scheme and parameter order of many standard PHP functions should have been cleaned up years ago) and I think adding yet another slew of OO sugar coating isn't going to encourage developers to write better PHP apps, quite the contrary.

> Its like their upset that people have moved on, but instead of providing a better core for people to build products on they keep adding chrome to the fringes of the language hoping to get more people sucked into developing for it only to realize that once they do anything of significant size in PHP they will need to do a full rewrite into a language that can actually scale or turn to a PHP to C++ lexer to actually get a product that doesn't also server as a Data center toaster oven.

Wow. This big run-on sentence about not being able to do "anything significant in PHP" is just not true, and that's me parsing it generously. Big projects can and do run on PHP. It's a valid choice. If you're using PHP for genome sequencing analysis, you're not using the right tool to begin with - but the same applies to pretty much any other web language as well.

When I say documentation I mean the internals of PHP. Here is their documentation page

http://www.php.net/manual/en/internals2.apiref.php

I must confess my knowledge about PHP internals and the perspectives of being a core runtime developer is pretty much non-existent. All I have to go by are the API and language features exposed to any web app developer - and that paints a different picture. Are you, by chance, a core contributor?

I have contributed patches to the PHP core, but I am not a core developer.

What would be valid choices for using PHP today if not for dealing with legacy code bases? It's the only thing you know? You don't have money to pay programmers for other languages? (PHP devs are commonly the cheapest)

There is not really a lot of substance in those assertions. There might be more legacy PHP codebases than, say, Ruby ones, but that's going to change as Ruby ages. The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait. You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones. Same goes for RoR and Python/Django by the way as they become mainstream. As you move away from the cutting edge as successful projects do, there is always an influx of less-skilled developers trying to hop onto the wagon. That doesn't say anything about the things good developers can do with the right tools.

In the end, there is just nothing constructive here. PHP haters, fashionable as they may be, will agree with you. PHP users will roll their eyes and move on. And very little factual arguments have been exchanged beyond useless posturing.

> The allegation that PHP is being used by people who don't know anything else is just subjective and wrong, and ultimately nothing but flamebait.

That wasn't my allegation, though it's a good point you bring; PHP is sold as a language for novices, and novices tend to use it, despite being the most difficult language in common use due to its innumerable pitfalls, which isn't aided by the poor instruction material all over.

> You can get cheap PHP devs because PHP is so ubiquitous. You can also get really good ones.

No, but really, the pay is generally less. Being a good PHP dev is less profitable than being a good Java or Ruby one, if the same holds for other countries, then I guess that accounts even more for the reputation of the language (people who are actually good programmers tend to move to other languages for better pay among other things).

And, you know, this wasn't the point. With much better alternatives available, why choose PHP if not for familiarity or cheapness of labour?

> PHP is sold as a language for novices, and novices tend to use it

These things are highly cyclical as I said, and I believe "PHP for absolute dummies"-style literature is already well past its heyday, being replaced by "RoR for absolute dummies" and, in time, other languages and frameworks. I agree about the pitfalls and that PHP is not a good language for beginners.

> Being a good PHP dev is less profitable than being a good Java or Ruby one

I don't know, it's possible. I look at this from an all-rounder's perspective, so the process is generally different. In most cases, language choice is something that happens after the project's needs have been identified. And yes, sometimes that does mean I suggest PHP when I think it's appropriate. It's never been an issue once, neither as far a client acceptance nor technical follow-through was concerned.

> why choose PHP if not for familiarity or cheapness of labour?

There are a few factors that influence this, and the developer's taste is always a big one. When in doubt I tend to avoid the application server pattern. But things that have moved me towards PHP in the past were pretty diverse. PHP's per-request execution model can have big advantages, especially when dealing with huge applications. Depending on the nature of the project, development speed can be faster. Sometimes I choose PHP over another solution because I know there will be less code to write (and I avoid it in situations where a PHP solution would be more complex). Server availability and access to support personnel can also be a factor.

You're living in a HN bubble if you seriously think no new projects are being created in PHP, or if you think there are no valid use cases for PHP in modern applications.

Simply take a look at popular job sites - you don't even have to look at Monster.

PHP devs may be the cheapest as a whole because there's so many. If you're dead-set on finding a Go programmer they will come at a cost because there's so few.

Once you get into the higher level of skill, though, it starts evening out. IIRC the average senior salary for Ruby/RoR devs is only ~$5,000 more than a PHP dev.

> You're living in a HN bubble if you seriously think no new projects are being created in PHP, or if you think there are no valid use cases for PHP in modern applications.

I asked for reasons. You just told me it happens. I know it happens, I want to see a solid justification.

> Simply take a look at popular job sites - you don't even have to look at Monster.

For less pay.

> Once you get into the higher level of skill, though, it starts evening out. IIRC the average senior salary for Ruby/RoR devs is only ~$5,000 more than a PHP dev.

Why shouldn't I take the job with better pay and a better language?

The performance differences between all of the major scripting languages -- Ruby, Python, PHP -- are insignificant, unless you are operating at Facebook scale (and Facebook, which still uses PHP, supports the HipHop project). Your web app bottleneck is not going to be PHP. Plus the PHP community is coalescing around Symfony2, which is a best-of-breed framework. Things have never been better in PHP land.

Now I just have to wait my ISP would eventually some day upgrade from 5.3.

Or you now, get with the program and get a VPS like everybody else.

I don't think this is a solution for everyone. Even though VPSes are cheap, if you're not making any money from running them, they're still a cost to you.

$5 a month is pretty much insignificant for a VPS.

>I don't think this is a solution for everyone.

No, but it's very much a solution for any HN developer in a Western country.

He knows what to do (hence "HN") and the money are insignificant.

I got a 512MB SSD VPS for $5/month from a major player. Similar plans exist all around. If $60/year is a "cost to you" and you are a developer in the US/Western Europe, then you're doing it wrong.

Mind sharing this $5 vps please? I'd like one.

Digital Ocean

Great! Just got an account with them and set up NodeJS in 2 minutes. Love that there is month to month payment and that you can change the plan. The control panel is very nice. Next PHP 5.5...

It looks like Digital Ocean: https://www.digitalocean.com/pricing

https://www.digitalocean.com/ is one .

I use DigitalOcean.

I just want to eventually refactor some code to take advantage of more recent features, what I pay for the site and what I do with it, is not worth the trouble to migrate to a VPS.

Best resource for learning about coroutines in (PHP|general)?

Check out Lua Coroutines, here's a starter link: http://lua-users.org/wiki/CoroutinesTutorial

>Exceptions can be thrown into the generator using the Generator::throw() method.

>Rewinding a generator

...wut

They added coroutines in a minor number patch. wat.

Just as rails has added the asset pipeline in a minor number patch. Or as ruby changed to unicode with 1.9. Or as python added a whole new syntax for exceptions with 2.6. As with many other languages, incrementing the minor number usually means quite big changes while more or less keeping backwards compatibility.

Changing the major number is something that's done when backwards-compatibility is hugely affected.

The exception is probably ruby which greatly broke backwards-compatibility with 1.9 (unicode) and mostly just changed internals with 2.0

Oh, I'm not about to hold up ruby or python as shining beacons here--though I will smugly admit that the rubyists seem to be pretty fast at updating their gems.

Still, it's weird practice nonetheless, right?

Actually, I think it's fine for languages:

Backwards-Incompatible change? Increment Major version

Many new features, but (largely) backwards compatible? Increment Minor version.

Bugfixes? Increment Patch.

I think this also perfectly maps to Semantic Versioning (http://semver.org/)

>Still, it's weird practice nonetheless, right?

No, it depends on the versioning number scheme. Not all schemes mean the same thing with major/minor/minorer.

PHP's versioning has generally been a bit weird since the abortive PHP 6 project. PHP 6 was meant to be the version that implemented full unicode support, but this proved to be very difficult, with the result that major new features had to go into the 5.x branch while 6.x remained in development (which, I guess, it still is).

5.3 added closures and 5.4 added traits, so adding coroutines in 5.5 is not inconsistent with past behaviour. I guess it's sort-of like how every version of OSX is 10.x, even though there have been massive changes between 10.0 and 10.8; it makes more sense to think of 10.8 as being 'OSX version 8'. Likewise 'PHP5' has been around for so long that nobody really looks at the major version number any more.

It seems like every major software project reaches a point where the major number just stops changing. Linux too - it became clear that it was going to be 2.6.X.Y forever, so they renumbered to 3.X.Y to make the version string shorter.

I guess it's a sign of maturity: the project has reached a solid codebase with good development practices so there won't be any more overhauls that warrant a major number increase.

Chrome is a good counter-example, but I agree that it's rare.

I view Chrome (and Firefox now) as essentially having "Chrome" and "Firefox" as their major version numbers, if that makes sense. It's so unlikely that they'll break compatibility that any such break would probably result in a completely new product/branding.

This is standard in PHP's release process [0]. New features are fine, as long as they don't break backwards compatibility. This is the same as semantic versioning [1].

[0] https://wiki.php.net/rfc/releaseprocess

[1] http://semver.org/

Except that PHP's 'minor' version changes do break backwards-compatibility:

http://www.php.net/manual/en/migration55.incompatible.php

http://www.php.net/manual/en/migration54.incompatible.php

http://www.php.net/manual/en/migration53.incompatible.php

http://www.php.net/manual/en/migration52.incompatible.php

As someone who has maintained open source software for PHP, the idea that there's backwards-compatibility between different versions of 5.x is not really correct. From a features perspective I think this is a good thing - PHP needs to move forward - but it's wrong to say that PHP entirely follows the SemVer standard.

5.x releases are bigger than the versioning suggests, the 5 series is likely 10 years old now?

Breaking changes in each is fine.

I agree. It's just not what the SemVer standard[1] says.

To be honest, I don't really care about following SemVer exactly. And PHP does follow SemVer if you pretend that the major version number doesn't exist, and the minor version number is really the major one (hence we're just seeing the release of version 5.0 of 'PHP5', rather than 5.5.0 of 'PHP'). This is all pretty easy to understand and it's not a bad way of doing things, but claims that PHP follows SemVer are incorrect and will cause confusion.

[1] http://semver.org

Not all versioning schemes are the same. You have to know what the versioning scheme means in a particular project to judge that.

The minor number in PHP does not mean bugfixes and small stuff only, as does in some project. The second even minor-er (!) number (.x.y) is for that.

PHP has always added tons of stuff in .x releases (closures are another example).

Python also adds major features in minor versions all the time. You can find similar grand changes between 2.x releases.

PHP - where technology meets obesity :)

It's not fat... it's overloaded...

Reply on news.ycombinator.com