List of possible changes, updates, additions for PHP 6 | Hacker News Reader

List of possible changes, updates, additions for PHP 6

wiki.php.net

65 pointsmariuz64 comments

The main pain-point I have with PHP is how clunky its functions are; it seems like first-class functions have only been added so they can tick a box on their feature list, since many aspects of PHP make them unnecessarily hard to use.

Passing function names around as strings is, of course, a hideous consequence of using separate namespaces for functions (foo) and variables ($foo), so it's at least understandable.

Having to explicitly list a function's free variables with "use" is a hideous consequence of not having lexical scope from the start, so again it's understandable.

What I don't understand is why functions aren't first-class in PHP's parser. For example, the parser doesn't know that functions may be returned from other functions:

    $foo = function() { return function() { echo "Hello;" }; };
    $foo()();  // Parse error

Instead we have to perform some indirection like this:

    call_user_func($foo());

Or like this:

    $bar = $foo();
    $bar();

Likewise, the parser doesn't realise that functions may be stored in objects:

    $baz = new stdClass;
    $baz->quux = $foo();
    $baz->quux();  // Error, no such method

Again, we have to add an indirection:

    call_user_func($baz->quux);

    $foobar = $bar->quux;
    $foobar();

Named functions can't be closures, even though we can declare them anywhere, presumably for historical reasons, ie. this is a syntax error:

    function foo($bar) {
      function baz() use ($bar) {
        echo $bar;
      }
    }

Another example of making it unnecessarily hard to use functions is iterable objects, which can only be iterated via foreach loops (ie. there is no way to map, reduce or filter them).

Of course, I could also complain about no tail-call optimisation, functions not being curried, etc. but those aren't PHP-specific since very few scripting languages seem to get them right for some reason :(

> Having to explicitly list a function's free variables with "use" is a hideous consequence of not having lexical scope from the start, so again it's understandable.

No, it's a clear avoidance of the problems of the Javascript lexical scope. Yes, it'd be nice to have that "for free", but there's far worse that could happen if you had free access to all variables. The GC complexity alone would outweigh the benefit.

> Likewise, the parser doesn't realise that functions may be stored in objects:

A contrived example actually. First, the interpreter only interprets "$foo->quux()" as a method call on a non-existent method. You are not accessing a property of the object, ever, through a method call like that. Instead, you have the option to implement __call.

    class foo {
        public $quux;
        
        public function __call($method, $args) {
            if (property_exists($this, $method) && is_callable($this->$method)) {
                return call_user_func_array($this->$method, $args);
            }
        }
    }

    $foo = new foo;
    $foo->quux = function () { echo 'hello'; };
    $foo->quux();

Changing this behavior could single-handedly break compatibility with all libraries making use of __get/__call methods. It could have been implemented, yes, and probably should have been. However, most people using PHP aren't throwing closures on an object (the closure won't have access to $this scope till 5.4 or later, you know) and expecting them to work like a method.

I may address the other points later, but I'm pretty sure that if you'd take a look and try writing idiomatic PHP you'd find it easier than assuming that your idioms from other languages will work directly and without modification.

> No, it's a clear avoidance of the problems of the Javascript lexical scope.

Do you mean problems with the way Javascript implements lexical scope (no "let" blocks until recently, hoisting, global-by-default, etc.) or problems with lexical scope in general? Lexical scope's been around since at least ALGOL60, but really started to shine in Scheme.

I agree that there's a tradeoff for GC, and as I said it's understandable why "use" acts the way it does, since lexical scope wasn't in there from the start (where it could have informed other scoping policies).

> A contrived example actually.

I agree, but it's contrived precisely because PHP's OO and functional features don't play well together, so everybody's learned not to do it.

> First, the interpreter only interprets "$foo->quux()" as a method call on a non-existent method. You are not accessing a property of the object, ever, through a method call like that.

That's exactly my point! :)

> Instead, you have the option to implement __call.

Yes, this is a decent workaround for a self-contained library/app/etc. but it shouldn't really be necessary.

> Changing this behavior could single-handedly break compatibility with all libraries making use of __get/__call methods.

That's an issue, but I don't think it would be as calamatous as you say :) It would mainly alter behaviour for those who are putting functions in their objects, but as you say that's not commonly done!

> However, most people using PHP aren't throwing closures on an object (the closure won't have access to $this scope till 5.4 or later, you know) and expecting them to work like a method.

I wasn't saying that a function property should act like a method semantically (ie. be called with an implicit $this argument), only that it should be possible to call it like a method syntactically, ie. the syntax "A(B)" should call "A" with arguments "B". Note that it's not just functions; quux could be anything callable.

> I'm pretty sure that if you'd take a look and try writing idiomatic PHP you'd find it easier than assuming that your idioms from other languages will work directly and without modification.

I've been writing PHP since 4.2, so I'm perfectly aware of what does and does not work. I'm pointing out what could work, and make PHP much nicer. Sticking to standard practice is a good idea when writing libraries and applications, but is stifling when brainstorming for a new version of PHP.

My problem with idiomatic PHP is that it's usually incredibly verbose, usually because everything's been collapsed down to be first-order, which leads to boilerplate (eg. repeated build-up and tear-down code) and copypasta ("multiply_all_foos" and "sum_all_foos" which are the same except for the operator, or "Foo->multiply" and "Foo->sum" if you prefer). A few higher-order functions, like function composition and partial application, can cut down this bloat tremendously. It's just jarring when this bumps into a completely unnecessary PHP quirk, like having to put "call_user_func" all over the place ;)

> Do you mean problems with the way Javascript implements lexical scope (no "let" blocks until recently, hoisting, global-by-default, etc.) or problems with lexical scope in general?

In general. It's powerful to be able to reach out of your immediate scope to access something outside it, but then everything from the defining scope must be retained for later. Because of variable variables, which can be either wickedly difficult to debug or incredibly handy, virtually anything from the defining scope could be accessed in a way the interpreter couldn't predict.

In some ways, I can already see the mess that could ensue. Which is precisely I appreciated the "use ()" syntax.

> I wasn't saying that a function property should act like a method semantically (ie. be called with an implicit $this argument), only that it should be possible to call it like a method syntactically, ie. the syntax "A(B)" should call "A" with arguments "B". Note that it's not just functions; quux could be anything callable.

I guess I can see the value in that. However, that leads to ambiguity during debugging, especially if you've included a dependency and haven't thoroughly vetted it. In that case, you need some XDebug magic to know if $foo->quux was a closure, callable array or string, invoke-able object, or a method. Then you need to determine its call semantics, etc.

I don't think "anything callable" is appropriate. But I do think anonymous functions, closures, and invoke-able objects are. You could then make strings and arrays invokable by wrapping them in a class, but without trying to execute an erroneous string or array.

> I'm pointing out what could work, and make PHP much nicer.

Yeah, your suggestions could work. Whether it would make PHP better or worse depends on the programmer, and the change's second-order effects on how the object model works. But I'm skeptical of its benefit. It would probably wind up muddying the execution logic till at least 1 patch level further. I'd have to see some real-world examples of how this would be useful to fully convince me.

Call me paranoid if you wish, but I wouldn't want a novice programmer stumbling on that change by accident. I can already envision the spaghetti they'd use it to write, then we'd have to come bail them out. ;)

A well-reasoned argument about pain points you've experienced with php! I have also been bitten by this non-feature and wish I had the time to learn C well enough to be able to contribute towards these sorts of things.

There are people trying to take care of some of that already. https://github.com/php/php-src/pull/301 was at some point hoping to get into 5.6 but I don't know what happened to it since then.

You're right that the parser would benefit from some more work to make edge cases like $foo()() work correctly. It'd be the single most important feature for a 6.x version as far as I'm concerned.

It wouldn't need to be a version 6 feature, since it wouldn't break backwards-compatibility, but it may end up having to wait if that part of the interpreter is particularly gnarly (I've played with PHP's C code and I could see why it may be difficult!). Also, I'd hesitate to call "$foo()()" an 'edge case', since that implies that it's somehow different to any other function call. Making such a distinction is exactly what PHP got wrong here, ie. the parser should allow any expression to be called as a function, including other function calls and property lookups.

Presumably there are two reasons why this happened:

1) Languages with first-class functions (and lexically-scoped closures) have fewer distinct features than languages without them; ie. functions are no longer distinct from other values (ints, bools, etc.), function names are no longer distinct from variable names (foo vs. $foo), methods are no longer distinct from properties ($foo->bar() could be a method call or a function call), functions and classes begin to overlap (lexical scope competes with instantiation and inheritance for resolving free variables)

2) For performance reasons, when these features were still distinct, they were branched on as early as possible, ie. in the parser.

Essentially the problem is that the parser is still making distinctions which first-class functions have unified. The solution is to delay committing to these branches until further down the pipeline, ie. using a generic "expression" token, which "$foo" and "<expression>()" both parse to. The action to take can be resolved at runtime (when the value of the expression is known). In other words, there should be no difference between "<token>(<args>)" and "call_user_func(<token>, <args>)" (except maybe for things like pass-by-reference).

> Making such a distinction is exactly what PHP got wrong here, ie. the parser should allow any expression to be called as a function, including other function calls and property lookups.

I didn't imply that I would have done it the same way they did! I merely expressed the feeling that the parser might be implemented in a way that makes this hard to fix without an extensive rewrite.

From the parser's perspective this might be an edge case. Admittedly, you know more about PHP internals than I do, but I assumed there would be hurdles in there - otherwise this should have been done years ago. Especially since I expect there is no compatibility downside in making these cases work.

Working with PHP I got the same impression as you did, namely that the parser makes certain assumptions about the code structure that causes the result to be more rigid. I agree that ideally the parser should just be agnostic about stuff it can't meaningfully reason about.

The biggest hurdle I find in PHP at the moment is how difficult it is to get a debugger working. XDebug requires a bunch of installation and configuration and the PHP built in webserver doesn't seem to solve this problem at all.

Most PHP programmers seem to have given up and resorted to using echo for debugging.

apt-get install php5-xdebug and enabling it in the config isn't exactly hard. Getting it to integrate with your IDE might be slightly more involved, but still no rocket science.

It's also something you only have to do once, on your development box. So I don't really consider that a hurdle.

It's not so much the degree of difficulty, but rather that the difficulty exists in the first place.

The PHP experience is absolutely horrible compared to those of Java, Python, the .NET languages, and even to those of C, C++ and Objective-C.

Take Java, for example. Debugging works seamlessly in pretty much every major Java IDE, including the free ones, on pretty much every platform used for Java development. This has been the case for a decade now, if not longer. It takes basically no effort to start debugging Java code.

The .NET experience is even better, although more limited in terms of tooling. Debugging is stupidly simple and very efficient when using C# and Visual Studio. Again, it has been like this for many years now.

PHP needs to get its act together so that debugging is at least as simple as it is when using those other languages and runtimes. Anything less is just plain unacceptable today.

+1 if debugging is present out-of-the-box, even first-time users will have no excuse not to use proper debugging.

While installing XDebug may be no rocket-science, I've encountered too many situations that it just didn't work reliably, causing developers to revert to nasty var_dumps() for debugging.

The only things I managed to get working reliably with xdebug were

• break at the first line in a script (very annoying when you have to debug something very deep)

• generate tracing logs (horrible to read but the best debugger replacement I had at the time)

• generate profiling logs (very helpful)

I never managed to get arbitrary breakpoints to work so I basically resorted to either traces or var_dump.

At which point it will happily ignore all of your breakpoints unless you invoke the right voodoo to make everything line up and do this every time you want to use a new system or VM for debugging. Total contrast to every other language where you don't have to think about this stuff.

This is true 90% of the time.

From there, some libraries like ezpublish will cause all sort of problems with xdebug depending on where you put the breakpoint (it might be due to the number of recursive call or stack depth), and you'd really want to enable or disable debugging case by case, from your IDE ideally.

Then debugging on a non dev server means installing a new package, configuring it and disable it afterwards just in case it has ill adverse effects.

Then some eclipse pdt versions were stuck when using xdebug on some configs.

Overall it works, but in practice, there's not enough cases IMO where step by step debugging is valuable enough to bother dealing with the not so exceptional weird things.

> Getting it to integrate with your IDE might be slightly more involved, but still no rocket science.

Which IDE do you use? Granted, most of my issues come from the IDE vendor's browser extension, which only triggers debugging when there's an 'R' in the month... which is highly frustrating.

I created a tool called PuPHPet that makes Xdebug installation as simple as clicking a checkbox. Maybe it can help you?

[0] https://puphpet.com

> Support of UTF-8 for the language itself, as PHP currently allows non ascii encoding in scripts, I would recommend to stop supporting it, except in comments.

Yes, how dare these people use their own alphabet.

At least when your library is guaranteed to have ASCII functions and objects I can still type them. Otherwise non-ASCII libraries would be utterly useless to me.

But that's a different problem altogether, being able to do my own code in my own language and making things I share properly accessible and usable to everyone.

Also, you should note the recommendation I quote is not about adding the ability to use non latin alphabet, this is about removing that ability. It's been there for over a decade and I don't see that rendering libraries developers brainless, so I would say your point doesn't apply.

Sometimes I wonder how important backward compatibility is. A lot of <=PHP4 libs wont run on a modern server so there are already compatibility issues.

Maybe PHP6 could be a complete cleanup. And maybe the focus shouldn't be on backward compatibility but on running <6 and 6 side by side.

I agree completely, maybe PHP should use the same approach as the jQuery migration-plugin, which;

- Logs usage of old or (to-be) deprecated functionality

- Provides deprecated functionality so that existing code doesn't break

This way;

- The PHP API can finally be cleaned up (please, also move those old functions to a separate section in the documentation)

- Older code can still run, but enabling the 'migration/compatibility' plug-in (should be possible to enable/disable this per site, not for the whole server at once)

- Developers are informed that their code uses deprecated functionality, giving them time to migrate code.

Although this approach is comparable to the E_STRICT flag, it is going one step further, in that the deprecated functions are actually removed from the core, and must be manually enabled/added via an optional plugin.

Reorganising the documentation is an important part of this; cleaning up the old stuff will make PHP less confusing (should I use 'implode()' or 'join()'?), and will silently guide new developers away from the old stuff.

On a final note; if this approach allows hosting-providers to upgrade PHP without breaking their client's code, adoption rate of newer PHP versions will probably be faster as well!

They better keep the backward compatibility, or you face the fiasco of Python 2 vs 3. The way that PHP deprecate API functions slowly over a period of time is prefered.

the migration from v4 to v5 went ok, considering there was a large blog campaign against end-of-lifing php v4 (I remember Matt Mullenweg, amongst many other bloggers and hosting companies, had the badge in their blog sidebars) and there was a lot of resistance to it.

The big thing with PHPv5 was not just having to migrate code, but even at the time v4 was no longer supported and v5 had been out for years in benchmarks v4 was still 20-30% faster then v5.

v5 to v6 could be a similarly smaller scale migration. The number of backwards incompatible changes in 4 to 5 wasn't long:

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

Slashdot thread from the time with some details on the resistance:

http://beta.slashdot.org/story/87591

Migrating from v3 to v4 was also a backwards incompatible leap:

http://www.physnet.uni-hamburg.de/physnet/php/migration4.htm...

So the PHP project has pulled it off twice already, perhaps they don't get enough credit for that.

I don't see how the Python 2 to Python 3 transition has been a "fiasco". It may not have been the fastest transition, but that really doesn't matter in practice.

Individuals and organizations with extensive Python 2.x software systems have been able to continue using those with no problems.

Development has been able to continue on Python 3.x without needing to worry about backward compatibility with Python 2.x. It is a cleaner language, in many ways.

Over time, we have indeed seen libraries, frameworks and users migrate from 2.x to 3.x as it benefits them. It's not something that's forced on them, causing disruption and anger.

And so we've gradually seen Python 3.x starting to become more and more adopted, while Python 2.x slowly fades away. It's a non-disruptive, steady transition.

If you want to talk about a real fiasco, Perl 6 is a much better example. Having no truly usable implementation after nearly 15 years, and thus basically no adoption, does qualify as a disaster in every sense.

True, Perl 6 is an amazing fiasco! Every bad thing in software has happened, so it's the world's most sensational counter-example! Stay away! Hide your kids!

P.S. But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades. Even if Perl 6 never ships, it's contributed tons of shipping code for Perl 5. Yes, it's hard to understand that from a distance, and it's not a PR dream, but oh well.

But from close-up, it's the think-tank and test-bed of potential Perl 5 upgrades.

I question this claim. Perhaps it's true of some syntactic features (`say` comes to mind as do some proposals for function signatures), but the semantics rarely translate over well (consider smartmatch). If you squint and tilt your head you can claim that Moose is an example of a feature designed in one language and implemented in another, but Moose is more an exercise in language/feature syncretism than it is porting something complete in implementation or design to Perl 5.

Well I was thinking about Python when I wrote my comment :)

One of the problems with Python is that they almost encouraged writing code in 2 and porting it to 3. Also: Python 3 is almost a complete different language.

It would be the same when PHP6 would use a + as string concatenation. Such changes would turn it into a complete different language.

Have you ever actually used Python 2 and Python 3? Python 3 is not "almost a complete different language", as you put it.

Somebody who has used both will notice that Python 3 is syntactically and semantically almost identical to Python 2 in most respects. The main differences are in terms of removing redundancy, removing outdated features and functionality, increasing consistency, vastly improved Unicode support, and standard library improvements.

A developer with Python 2 experience should be able to pick up Python 3 in about 30 minutes, at the most. That's not what we'd expect were Python 3 "almost a complete different language".

Hopefully, PHP.net community won't go this route. The C-like syntax and the more or less stable code base (compatibility) are the main advantages over Python, Ruby, Go.

A core API cleanup would be nice, but I think they have to worry about the transition. There would have to be a period when both APIs work so projects can transition gracefully and servers can host code written for both. An abrupt change would probably hurt the new version, the old, or most likely both.

If we could get on the same page what the new naming conventions and parameter orders are supposed to be, we could start to use a shim file on 5.x to prepare for 6.x.

Agreed. Backward compatibility is nice, but you have to draw the line somewhere.

I can't wait for PHP6 to be released for the second time. I already own a book about it!

To make sure you have proper context: With one or two exceptions, those proposals are just vague ideas of what we might want to do in PHP 6. It says very little about what will actually go in. Most of it won't, at least I dearly hope so - otherwise we wouldn't get a release in the next decade ;)

I see no "optional static typing" in the list.

Would be great if PHP.net and HHVM (Facebook's HipHopPHP) would go on in the same direction (somehow).

If only php changed concatenation from . to + and then used . for classes and packages I believe it would have a bigger impact.

So honest question, what if somebody forked php and made those simple changes, how many people would switch?

I would without hesitation.

I wouldn't. I do find the use of . for concatenating strings to be annoying, but I wouldn't switch to a PHP fork that didn't also address bigger issues (saner function support, optional strong typing, named params maybe, operator overloading.)

But then at some point you no longer have PHP you may have something which is close enough to an existing language that just switching to it becomes a more palatable option.

As a hobbyist and freelancer I don't use any of these 'bigger issues' (saner function support, optional strong typing, named params maybe, operator overloading.) for my casual projects.

So no, I'd benefit the most with a cleaner syntax than with cooking unicorns in fairy sauce. And I believe 80% of casual programmers agree with me.

Pareto wins.

Syntactic headaches mean less than semantic ones. PHP fails to support, or supports quite poorly, many semantics which more competently designed languages handle well. If PHP is your primary, or worse your only, programming language, then this deficit leaves you at a disadvantage when it comes to growing more skilled in your craft, because after a while you're not learning new things which generalize across languages, but rather learning how to work around the famously irreducible piles of manure unique to PHP.

You can get quite good at doing that, of course, and it's even a useful professional skill, there being so much PHP code in the world, and most of it awful. But doing so does not make you a better programmer, because at best it teaches you nothing useful about how to use less programmer-hostile languages, and at worst it inculcates habits which will prove actively harmful in any later effort to develop skills in such languages.

That you are unable to appreciate this qualitative distinction does nothing to erase its existence, but it does provide an excellent example of the conceptual deficiencies which result from a PHP-centric perspective on programming -- even something as trivial as proper first-class functions you dismiss as "cooking unicorns in fairy sauce", and since PHP doesn't have them, how would you know otherwise?

Whether you choose to address these deficits in your education is, of course, entirely your lookout. I'm just here to point out that they exist. You're free to argue otherwise, should you so choose, but you'll be wrong to do so; I speak here from experience gained in working with people who similarly mistook PHP for a worthwhile general-purpose web development language, who began their programming careers by specializing in it, and who in so doing unwittingly stunted their professional growth in precisely the manner I describe. Some overcame it, and matured into truly professional programmers with whom it was a pleasure to work; some did not, and most of those, as far as I've been able to keep track, eventually drifted out of the field entirely. All, having been seduced by that syphilitic temptress of innocents we call PHP, suffered unduly as a result. (I'd have been among them myself if not for early exposure to Perl, which for all its warts is a thousand times preferable to PHP; having cut my teeth on a language which is merely bad, I was equipped in my first encounter with PHP to recognize the legendarily awful when I saw it.)

It's for reasons like these that, to borrow a quote from the UNIX-HATERS Handbook, "I'm rather surprised that [Rasmus Lerdorf] is still walking around alive"; indeed, long may he continue to do so, for if there's a special hell for programmers, then in its frozen ninth circle there must surely be a waiting hole in the ice with his name carved around the edge -- or, just possibly, a throne.

This went from "insightful" to "rant" pretty quickly. I was with you until "mistook PHP for a worthwhile general-purpose web development language". That's exactly what PHP is, a worthwile general-purpose web development language.

I understand your grievances with PHP's semantic issues, and I can appreciate that PHP's lack of support for newer, common language paradigms inhibits growth in professional development.

But you replied to a guy who starts his comment with "As a hobbyist". Most of what PHP is used for is for small web development projects that in no way need optional strong typing and full functional support.

At the beginning of your comment you say that if PHP is your only programming language than this deficit leaves you at a disadvantage. Well no shit! There's no silver bullet language that can do everything for everyone 100% of the time. In one breath you lambaste using PHP as your only language; in another you identify that PHP's lack of support for x, y, and z cause the developer to stagnate in learning new things. It seems you condemn using PHP for everything, and then are upset that it can't do everything!

To this I would say use the right tool for the job.

You seem to see "insightful" and "rant" as mutually exclusive. I don't agree, but that's merely a quibble; to address the meat of your response, I say that, while of course you're right that no language is ideal in all cases, PHP exists in a unique local pessimum compounded of its attractiveness to novice programmers and its unmatched ability to hamper them from learning lessons they will find useful in becoming familiar with languages other than PHP -- indeed, it is far more successful at making it harder, not easier, for novices to gain a grasp of any other language, and it is precisely this trap which incurs my loathing.

Small web development projects, as you say, do not require strong typing, first-class functions, &c. But they certainly can in many cases be improved by these capabilities, and, in any case, few languages which offer them outright require their use; meanwhile, a language which either fails entirely to offer them, or worse offers a broken, awful version of such functionality to newbies who are not equipped to recognize such enormities and are thus vulnerable to the fallacy that that's how such things are and should be done everywhere, is one which can inflict enormous harm on people who frankly don't know enough yet to look out for themselves -- precisely the sort of people, in other words, which PHP so successfully attracts, through its presentation as the right tool for every web-facing job.

Perhaps you mistook my colorful phrase, "that syphilitic temptress of innocents", for mere hyperbole, and failed to recognize it as the precise, if metaphorical, description which it is. If you have so mistaken me, then I hope this comment helps to clear up the matter somewhat.

Haha, ok fair enough. I agree with everything you just said. I honestly wish PHP would implement these features and break backwards compat for those same reasons.

Thanks mike for your defense.

The internet is such a wonderful place where we start a fight with someone we don't know if it's a dog with a keyboard or a guy with 25 yrs programming experience with fluency in 22 programming languages.

But what do I know? I am just a hobbyist.

;-)

No one with the experience you describe is just a hobbyist. Nonetheless, I stand by what I said above.

I fear, they will give unicode another try, fail again and just keep on bloating the API. I bet there is a language out there, which way to set or get attributes, PHP has not yet copied.

to join in the other Unicode posts

Utf is not Unicode

https://enjoydoingitwrong.wordpress.com/2009/06/22/unicode-i...

They had me at "Unicode support".

Assuming it somehow works.

If the internal representatiom changes, I wonder how much the current mb_* functions will be affected. I hope reimplementing them is trivial and doesn't affect edge cases. I've seen a lot of very very hacky code relying on them, there was no evident clever solution, and it would be a nightmare to go back on all these and test all the wicked pattern they were supposed to cover.

Considering all its problems, I wonder why PHP has not been forked already in a saner language.

I mean who in 2014 is going to start a new project in PHP apart from people that can't be bothered to learn something else ?

> I mean who in 2014 is going to start a new project in PHP apart from people that can't be bothered to learn something else ?

People who refrain from having the standard knee-jerk "lol php is bad" reaction whenever it's being mentioned. Of course the language has its warts and pitfalls, but then again, most languages do, and it's a fairly usable tool for a fair amount of jobs.

Care to show me a language with the same adoption rate (especially among hosters, which is something a lot of web devs simply have to keep in mind), ease of getting a project from zero to gone live?

PHP 5.3+ isn't really as bad as people make it out to be. Sure, it's not flashy, but it can definitely get the job done. I've been exploring Laravel lately and it's certainly a lot of fun.

For me the pros/cons balance is still heavy on the pros side. So yeah I'm starting PHP projects in 2014. And as in every other language your own skills are the biggest bottleneck.

Maybe people who already build and maintain apps in one of the most widely used language on the web?

Check out Hack for HHVM[0][1][2]. It's a lot saner than PHP, but it's not documented or well known outside Facebook.

[0]: Strangle Loop 2013: Keith Adams, Facebook: Taking PHP Seriously https://raw.github.com/strangeloop/StrangeLoop2013/master/sl...

[1]: CUFP 2013: Julien Verlaguet, Facebook: Analyzing PHP statically https://www.youtube.com/watch?v=gKWNjFagR9k

[2]: HHVM and Hack – Can We Expect Them to Replace PHP? http://www.sitepoint.com/hhvm-hack-part-1/

My cients's hosting providers only support PHP, so yeah...

Frameworks such as Laravel has made this much less of a problem.

Frameworks replace one problem with seven others.

For me the main reason to use PHP rather than say Python is that there is a load of not too bad open source stuff out there that you can use and modify.

Uh...

http://pypi.python.org/ - 40,037 packages

http://rubygems.org/ - 70,678 packages

http://www.cpan.org/ - 129,447 packages

http://packagist.org - 24,244 packages

There's a lot of open source code out there for all major languages. And, based on the canonical package indexes, a lot less for PHP than the other main contenders in the OSS web-ready scripting space (although, obviously, PHP is very domain-specific compared to the others I've listed, so the comparison is not completely fair - even with that caveat, however, I would expect Perl and Ruby to have PHP licked).

There are compelling reasons to use PHP - omnipresence, ease of deployment - but this isn't one of them.

To be fair, Composer can handle a lot more than just the list on Packagist, so I don't how "canonical" Packagist really is for php, as opposed to being the "default", if it matters.

https://getcomposer.org/doc/05-repositories.md#types

Though I'd agree it is still a weak argument in favor of PHP.

Maybe but the couple of jobs I did / am thinking of doing were putting up a jobs board and a dating site. I found jobberbase for jobs and osdate for dating which are free and you could stick up there and modify a bit. Are there equivalents in Python say? Or Ruby?

The same thing is true of Python, though. Use PHP if you want, but not because Python doesn't have open source stuff out there

It's easier to just use one of the many other better languages.

Reply on news.ycombinator.com