Announcing a specification for PHP | Hacker News Reader

Announcing a specification for PHP

hhvm.com

346 pointskeso256 comments

After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it.

But the stdlib is still hard to manage. Different naming conventions, different order on the parameters for functions that do almost the same thing, and every function is global. Couldn't they keep all that for backwards compatibility, but create more sane wrappers and include them as part of the stdlib? For starters, group them by what they work on (arrays, strings, numbers etc.) as static functions on some relevant class ( String::str_replace(...) ), and later have more methods one can call on the objects themselves ( myStr.replace(...) ).

Is this being worked on? Can this spec help with that?

If you want to order your program in a specific way, you introduce the appropriate level of abstraction. Same as with any other language.

EDIT: i totally agree that the standard functions are a complete mess in PHP. But they have to stay around for backwards compatibility. Have a look at the SPL classes: http://php.net/manual/en/book.spl-types.php

When you're talking about the core libraries that ship with the language, it seems unreasonable for every PHP developer to have to introduce it themselves.

This simply isn't possible in a way that would be convenient.

For example, how would I make a string abstraction? Create a class? Ok, so we have:

$str = new String("foo") $str->replace(...)

over

$str = "foo" str_replace($str, ...)

This is fine, if we ignore the fact it's much slower.

Where it really gets annoying is PHP's lack of operator overloading. That means to concatenate I'd need to do

$str->concat($str2)->concat(new String(" "))->concat($str3)

instead of

$str . $str2 . " " . $str3

There's things you can do to make the API a little bit more convenient (i.e. allow it accept PHP strings, etc.), but ultimately it becomes a huge pain, especially if you want to start interoperating with other libraries that are using a different abstraction or, more likely, using the regular PHP types and functions.

Well, it doesn't have to be slower. The generated bytecode can be the same. And there could still be syntactic sugar left to allow for easy concating.

Javascript doesn't have operator overloading, but it doesn't stop you from doing

    "foo".replace('oo', 'ood') + " tasty"

I don't see why PHP can't treat strings specially as well.

Many PHP data types (such as mysqli etc) have been made into objects, and I agree 100% that it's silly to do this with strings. Ease of string manipulation is a PHP strong point.

You'll be giving PHP devs a loaded gun by allowing them to register primitive types (as proposed by nikic). Most frameworks would add to them, but I know some people would change default behaviour to 'fix' issues such as db character encoding issues which would make debugging hell.

> Where it really gets annoying is PHP's lack of operator overloading. That means to concatenate I'd need to do

> $str->concat($str2)->concat(new String(" "))->concat($str3)

> instead of

> $str . $str2 . " " . $str3

Erm, no you wouldn't. What's wrong with either of these?

    String::implode($str1, $str2, new String(" "), $str3);
    String::sprintf("%s%s %s", $str1, $str2, $str3);

Of course, if you want to add operator overloading, you might as well overload '"' as well, so you can use "foo" instead of new String("foo").

Personally, I'd prefer operators to have function equivalents, so your example could be written:

    array_reduce([$str1, $str2, " ", $str3], '.', "");

I've raised this at https://bugs.php.net/bug.php?id=66368

Please no. This is awful verbose syntax. Use Java if that's what you want.

This is not PHP, this will never be PHP. Some people need to remember the purpose for which PHP was started and what it still is great at: making websites.

You guys are stuck in high brow academic debate on the semantic of a language that was born before many of us started coding, and that helped the web become what it is today. And that has come a long way.

I'm not saying to stop improving the language, but as someone who has used PHP for 15 years, all the issues I see come up constantly in threads like this are non issues, never encountered them in any web situation, you have to seek these "bugs"/annoyance, or be seriously inexperienced with PHP, or as I've been saying for years any time I do conferences: you are using PHP wrong.

So please, keep your verbose syntax in other languages that "need" it, while there are improvement to be made on PHP, this is not an area that needs one.

Also, looking at your bug submission/request, I share krakjoe sentiment: what the F are you trying to achieve? Seriously, I am curious. To me it screams wrongly used PHP.

> To me it screams wrongly used PHP.

Of course it's wrongly used, since it doesn't work (hence my request to make it work).

The issue is not whether we should write such code now (we obviously shouldn't, since we'll hit all kinds of language problems); it's whether we'd like to write such code in the future (in which case we need to fix those problems now). Personally, I would like to avoid redefining built-in capabilities over and over.

As for what I'm trying to achieve, the same as everyone else: clean, understandable, maintainable code.

Here's something I ran across this week. I'm instantiating a class $class (read from a config file) and need to inject dependencies ($dep_classes, read from a config file) into the constructor. How to do it?

    $deps = [];
    foreach ($dep_classes as $dep_class) {
      $deps[] = new $dep_class;
    }
    $instance = new $class(...$deps);

It works, but turning $dep_classes into $deps is clearly a use-case for array_map. We shouldn't reinvent the wheel:

    $deps = array_map(function($dep_class) { return new $dep_class; }, $dep_classes);
    $instance = new $class(...$deps);

Again, it works, but that anonymous function is pretty horrible; we might have been better off with the loop!

However, it's clear that, again, we're reinventing the wheel. array_map passes the class names to its callback, so why are we passing them to "new" ourselves?

    $deps = array_map('new', $dep_classes);
    $instance = new $class(...$deps);

This gives an error, since "new" is an operator. Does this scream of "wrongly used PHP", or is it a problem with the language that would be nice to fix? I'd say the latter, since at the moment we're forced to do one of two things:

- Use a foreach loop to duplicate the functionality of array_map. - Define a new function which behaves exactly like "new".

Perhaps 15 years with PHP has given you a "gut feeling" to avoid programming styles which will inevitably run into problems; I've certainly got such a feeling after 4 years. While avoiding those problems is useful to get a job done today, it would be even better if we didn't have to worry about them tomorrow.

There's no point adding features like array_map, anonymous functions, etc. to the language if we all have to learn to avoid them to avoid parser errors.

I thought something along the lines of keeping the existing global namespace mess but also add in namespaced, consistent aliases like you've suggested, i.e. myStr.replace()

As the new ones get more use, slowly deprecate and remove the original global namespaced functions, in the same way they phased out register_globals

right, and then it becomes even less readable because someone calls in the namespace somewhere and half of your project uses 1 version, half the other.

No, just stick with the consistency of using the stdlib as is. If someone really has a problem with these specific issues they don't need to be developing, period.

I would like to think that in any sane project they would choose one of the namespaces and stick with them. Moreover, I think that as you deprecated the older namespaces, this problem would go away.

You could make the exact same argument with removing register_globals: half the project using it, while half the project using the superglobals. Clearly there'd be some pain, but I don't think it would be as bad as you're trying to make it sound.

I'm not really sure I follow the logic that if someone has an issue with the state of a programming language then they shouldn't be developing. How does that make any sense?

because you're involved in a strawman. funny how that works.

It's in the nature of developers to care about API design, which is really what this is about. Would you want someone to design an API for your software product that does so as haphazardly as the PHP standard library was designed? Probably not. It's only natural that people want to discuss why it's bad and how it could be fixed. I would be more concerned if you were a developer and didn't care about these kind of issues.

if it aint broke, don't fix it, and PHP's stdlib aint broke. It just aint perfect. It will never BE perfect.

And that's ok. There's a million things I'd like to see before people start trying to "fix" an stdlib that's been around for so long.

or just distribute an upgrader with the next release. I'm sure it's more complicated than just find and replace, but the interpreter has a perfectly good parser right there. eval is impossible (or very hard), but it's pretty legit to error out in that case.

It's not legit to error-out for eval, since PHP has all kinds of eval-like things.

For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example:

    $my_anon = function() {};

    function my_named() {}

    // Valid
    array_map($my_anon, []);

    // Invalid
    array_map(my_named, []);

As a workaround, whenever PHP sees a string when it's expecting a function, it will try to find a global function with a name matching the contents of the string. In other words, we can do:

    // Valid
    array_map('my_named', []);

This is basically a weak form of eval: taking a string of PHP code ('my_named') and getting back the value it evaluates to (the my_named function). If you error-out for eval, you have to error-out for this, since the content of strings is runtime information and there's no way you can infer it well enough. For example:

    function smart_replace() {
      $args = func_get_args();
      $func = array_shift($args)? 'str' : 'preg';
      return call_user_func_array("{$func}_replace", $args);
    }

Other eval-like things in PHP include variable property lookups, variable method calls and "variable variables":

    $foo = "hello";

    $object1->$foo = $object2->$foo;  // Sets $object1's "hello" property to $object2's

    $object3->$foo();  // Calls $object3's "hello" method

    $bar = "foo";
    echo $$bar;  // Outputs hello

One interesting fact about these features is that, since they're not as powerful as a real eval, it can often be perfectly safe to supply them with unvalidated user input:

    array_map('str_' . $_GET['string_function'], $my_array);

There's no way we can swap out things like this reliably, and remember that these are not just "crazy uses of eval", they're officially sanctioned ways of working, which in some cases (eg. function names in strings) have no alternatives (short of redefining your own standard library).

You're talking about the very things that make PHP flexible. I don't see how 'swapping out' things like these would make PHP any safer, faster, or easier to read. C/C++ function decorators, or dynamic programming constructs are not exactly that clearer.

Nobody's talking about "swapping out" the eval-like features.

The parent was saying we could swap out all usages of 'old fashioned' functions like str_replace for some 'new fashioned' alternative, like String::replace, using some kind of upgrader tool.

I was pointing out that the PHP's eval-like features make it difficult for any such tool to exist. In particular, with Python or Javascript we might spit out a warning "Eval spotted; this upgrade might not work!". If we did the same in PHP, everyone would get a warning! "String used as function detected; this upgrade might not work!", "Variable variable detected; this upgrade might not work!", and so on.

That's really helpful and insightful. I had specifically avoided mentioning dataflow analysis, I still think a lot of progress could be made with that approach. Essentially modify the interpreter to run every branch, both the true and false clauses of if, and note what strings have what value at that point of execution.

in your final example, you can replace the map with a big case switch of all known functions and an error clause.

That's of course, a lot of work. I'd guess it's just not worth it.

Nikita proposes methods on primitive types: http://nikic.github.io/2014/03/14/Methods-on-primitive-types...

Myself, I like this proposal.

Soon all dynamic languages will be one. Except for the method call syntax.

Actually, that's Uniform Function Call Syntax http://www.drdobbs.com/cpp/uniform-function-call-syntax/2327...

And it doesn't make a language 'dynamic'. The language I found with UFCS is both static and compiled.

That's not what I meant. PHP code was built around its SPL, if they accept nikic proposal, people will code using base types with similar operations set found in many dynamic languages.

What's left is [1,2,3]->slice(1,2) versus [1,2,3].slice(1,2)

ps: dynamic can be compiled and compiled can be interpreted, so I understand that it is unrelated.

Walter notes two advantages of that scheme over extension methods. One of them is that extension methods can not be called with the standard prefix notation. This is not actually true, at least in the languages most known for extension methods, Visual Basic and C#.

You mean all dynamic languages are Lisp?

Having read Lisp in small pieces I can't hide that it was on my mind. But without parens smugness, right now php, python, es6 are getting closer and closer.

See https://github.com/devyn/unholy (Ruby to Python bytecode, then Python bytecode to Python source). Used to run Ruby on Google App Engine, I think.

The usual way to run Ruby on GAE is just to use JRuby on the App Engine Java runtime. Unholy has been dead for years, and from the commit messages seems to have never gotten to more than very basic functionality; I doubt very much that you could run meaningful code with it, on GAE or otherwise.

I like it too, it's clean. But reality is that PHP will have to be backwards compatible.

Which means you will see old function based implementations and new object based implementations.

Image dealing with both implementations within the same code base? Eek.

This was how a lot of perl5 was when I used it in the early 2000s.

Fun with PHP:

    $a = 'b';
    $b = 'a';
    echo $a."\n";
    >>> b
    echo $$a."\n";
    >>> a
    echo $$$a."\n";
    >>> b

Yaaa

    $obj = new StdClass();
    $obj->x = 1;

    function x_plus_one($obj) {
        $obj->x++;
    }

    x_plus_one($obj);
    var_dump($obj);
    >>> object(stdClass)#1 (1) {
    >>>  ["x"]=>
    >>>  int(2)
    >>> }

Huh? A local change to the object changed the object outside the local scope? It must have been passed by reference...

    function null_the_object($obj) {
        $obj = null;
    }

    null_the_object($obj);
    var_dump($obj);
    >>> object(stdClass)#1 (1) {
    >>>  ["x"]=>
    >>>  int(2)
    >>> }

Huh? Before when I edited the object within the function, the object I passed in was edited, what gives?

We don't actually pass objects to reference in PHP, we pass them by "object reference." But don't worry, you can still null objects that get passed to you:

    function null_the_object_2(&$obj) {
        $obj = null;
    }

    null_the_object_2($obj);
    var_dump($obj);
    >>> NULL

Sure it's not as bad as it used to be. Yes, a disciplined developer can make good software with it, but it's still a pretty quirky.

To be fair, all languages are "a bit quirky". It gets worse when you start including things that are in the PHP stdlib but aren't in other languages by default. [e.g. When they basically re-implement how php-fpm handles requests and thread safety]

>>> To be fair, all languages are "a bit quirky".

Agreed. These are just a few quirks in PHP I find amusing.

They are amusing indeed. :)

I'm sure you've already seen this (it's been around a while), but if not, you'll find it amusing:

http://www.phpwtf.org/

Last I checked, it wasn't quite as good as wtfjs, but it looks like quite a few new surprises have been added rather recently.

Edit: Correction, there's only one new entry as of this year, which is a shame. :)

The first two I read aren't even WTF the worthy and are perfectly reasonable. Even in the classic fractal of bad design article, only 1/3 of it is actually valid.

I half agree, but I'd like to point out that the likely reason the curator of this site thinks of these as "WTFs" has more to do with PHP's (lack of?) consistency and it's relatively bizarre behavior when compared with saner languages.

The other thing to consider (looking at it again, particularly at the second example) is that there are some surprising side effects that can snag newcomers, depending on their background and whatever other languages they know.

Perhaps one of the drawbacks with programming PHP is that you become so desensitized to weirdly inconsistent/surprising behavior that there's almost nothing left to be surprised about.

It's nit-picky to the point of ridiculousness. Take the first example, even the title "Objects with __toString are not strings." is already WTF worthy. Of course objects with a __toString method are not strings! It means they can be converted to strings when unambiguously used as strings. Which is exactly what happens! The whole entry is stupid. The author even complains that PHP will issue an error if __toString doesn't return a string! I mean really.

Most other entries involve doing something bizarre with obviously undefined consequences and then marveling that PHP does it different than they expect. Or failing to understand PHP's basic rules and then again, on edge cases, marveling at weirdness of the perfectly logical result.

The "PHP protected and an assault" entry just fails to comprehend how access modifiers actually work with the classes.

There are real PHP WTF's but honestly they were all discovered 10 years ago. Probably 50% of all entries on the site are people misunderstanding how references work over and over and over.

I'll grant you that, although I get the impression it's largely someone wanting to have fun with oddities of the language. Although I wouldn't necessarily go as far as to claim that it's "marveling [sic] at the weirdness of the perfectly logical result"--there are some PHP behaviors that are just plain strange.

On the other hand, had you written "perfectly logical result (within the confines of PHP's idea of what's logical)," then I might be inclined to agree.

But yes, I made the mistake of linking the site without re-examining it. I recall seeing it first from HN some time ago (probably 2010ish) and thought it might have improved. I do believe I may have indicated its quality isn't on par with wtfjs.org, however. Take it as you will.

Weird, clicked the link, and my computer crashed. Opened it now, perfectly fine. Weird.

Java willl have the same behaviour for function like x_plus_one. And function null_the_object_2 cannot be made in java.

Honestly the reference passing quirks you mentioned behave exactly as I would have assumed, am I alone in this?

Nope. I'm more of a Python/Java person and even I expected the observed behavior. Given that Python is my primary language, I'm pretty sure that I'm supposed to hate on PHP as much as I can, but really, this is stretching it.

There is nothing unexpected by this behavior -- this works exactly the same as any language with the same features (C++, C#, etc). I don't know why you found this at all surprising; it's not at all quirky in this example.

Got any counterexamples? What well-known OO languages don't work like this?

If you're going to rag on a programming language on a site like Hacker News my advice would be to make sure you know what you are on about before you do. There isn't a programming language out there that doesn't have its quirks, look at Javascript, it has more quirks than you can poke a stick at, but that doesn't make it a bad language.

In your examples I am not seeing the issue? Am I missing something here? Your examples work exactly as I would have expected them to, as they would in other similar languages like Java and C++. Lets stop the hate for the sake of hating PHP, it definitely has its quirks in relation to methods and order of parameters in particular, but things are getting better and they're not deal-breakers for getting things done.

If you want to see how great things are in PHP, I would checkout the Laravel PHP framework. It is a very well built and robust framework that uses the best parts of PHP and abstracts some of the worse parts to make the experience of developing in PHP fun again.

The presence of some quirks isn't the issue. Of course every programming language has some.

PHP and JavaScript, however, have unjustifiable quirks with some of their most basic functionality. We're talking about stuff as basic as their comparison operators being quite broken, for example. That's where the problem is. Furthermore, the fact that these issues have been around for well over a decade or more without being properly addressed just makes the situation even worse.

Compared to other mainstream languages like C, C++, Java, C#, Python, Ruby and even Perl, both PHP and JavaScript are quite inferior in many critical ways. Perhaps things will improve over time, but we really haven't seen that happen so far.

So let's not pretend that they're "good" just to be politically correct or to try to avoid offending anyone. PHP and JavaScript aren't good languages, and they won't really improve until their communities admit that there are some very serious issues, and then commit to getting them resolved properly and rapidly.

> The presence of some quirks isn't the issue. Of course every programming language has some.

It is a very weird argument that often comes up when discussing programming languages - "Lang X is weird/stupid in some ways, but no language is perfect, so it's fine and there is no reason to call it out."

So, because nothing is perfect (almost by definition), it apparently isn't a big deal that some things are weird/dumb/broken. And let's also just muddy the waters by implying that, since all languages have imperfections, talking about some other language's imperfections is just being pointlessly selective (even though one of the languages imperfections are much more horrible).

It's just overall a non-argument. Maybe the point is to come off as being "above" the opposite camp (which are: mindless language bashers). But it's about as intellectually stimulating as mindless language bashing: it doesn't take much intellectual curiosity or rigour to bash a language, and neither does being perfectly neutral and non-offensive by throwing around platitudes like "no language is perfect", "choose the right tool for the job", etc.

Exactly. The trend in modern languages is to try and eliminate as many surprising quirks as possible. If you look at Kotlin, it's basically advertised as resolving around half of the famous Java Puzzlers. And those puzzlers were themselves introduced by the authors with the proviso that Java has remarkably few quirks for something so very large, and that this is/was tremendous progress.

I'll stress that I was agreeing with Pacabel, which might not be apparent from looking at the quote I chose to use in isolation.

I don't hate PHP, I hate the fucktards who use it. (bye karma...)

Pointers.

> It's changed a lot since I first used it.

Have any good examples? I haven't used the language in years, would love to see what "modern" PHP looks like. (Seriously, not trolling at all)

http://radar.oreilly.com/2014/03/the-new-php.html

I just came back to PHP myself after 4 years away and have been pleasantly surprised. A lot of it has been community driven with things like the PHP-PSR standards and Composer, in additional to all the language features that have hit since 5.3

Apart from the language in itself, the ecosystem has matured leaps and bounds. Symfony is the poster child of the new frameworks: easy to use, flexible and powerful. I haven't used rails but I heard it's going the same direction.

Sometimes I feel we're getting too close to Java territory in terms of abstraction and reliance on libraries, but that would also be a sign of maturity.

Symfony2 is definitely not going in the direction of Rails. It was and will be Rails' opposite: built around a dependency injection container, favors configuration over convention and uses as little magic as possible.

I made a blog post that compares Hack and the new Javascript specifications ES6 and ES7[1]. They have a lot of features in common.

[1] http://blog.vjeux.com/2014/javascript/hack-is-to-php-what-es...

PHP the Right Way is a good place to start:

http://www.phptherightway.com/

The Laravel framework[1] is a good place to start, it's quite well designed and elegent. It requires at least PHP 5.4.

[1] http://laravel.com/

Laravel alone was enough to bring me back to PHP. It seriously has made PHP exciting again (I come from a Codeigniter and Zend background). It takes all of the things people love about Ruby on Rails and brings them to a PHP framework utilising modern features like traits alongside the fantastic selection of packages like Cashier. The even more surprising aspect of Laravel isn't how great it is, but rather the fact it was built by one guy... Other frameworks like Zend, Symfony, Codeigniter were built by teams. Of course, Laravel has contributors nowadays being an open source project, but in the early days it was mostly Taylor taking the reigns.

If you like it because it's like rails, why not just use rails? The rails ecosystem is undoubtedly stronger than laravel's, and it's a more mature framework. I don't see where laravel fits in the spectrum of PHP frameworks.

Using Rails requires Ruby, and arguably the PHP ecosystem is stronger than the Ruby ecosystem.

>"If you like it because it's like rails, why not just use rails?"

PHP is ubiquitous on shared hosting platforms, there aren't that many "shared" Rails hosters out there. Morts still use shared hosters.

This was a much more compelling argument when shared hosting was still cheaper than a VPS with root access. But now you can get a VPS from any slew of providers, like digitalocean, for $5 a month. Root access computing has never been more accessible, and shared hosting is rapidly losing any value proposition it once had. So targeting PHP purely because it's more ubiquitous on shared hosting than Rails, is making less and less sense.

Upload and run with all the security and management done for you is a great way to get going in web development. I don't feel that the idea that everyone doing reasonably simple PHP stuff should have root access 'makes sense' actually does.

I don't want root access. I want to sign up, upload my files through FTP and have it working instantly without having to worry about anything else.

... which you can also do on platforms like digitalocean. Just spin up a preconfigured dokku droplet and git push.

> Just spin up a preconfigured dokku droplet and git push.

Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.

That workflow is pretty outdated, you know. It's about akin to using tables for layout, and about as much of a no no. I know, git can be pretty confusing, but using version control, even in a one man shop, is a huge boon.

who says Kiro isn't using version control?

traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that.

You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid workflow for a lot of people who don't want to be sysadmins in addition to developers

It's a strong implication.

Kiro quotes two items from the parent, and says he doesn't want to be bothered with "those" things.

Kinda implies he doesn't use git, since that was one of the two items quoted.

I do use git. Just not for deployment. To be honest though I could live without it.

So that would be "I don't want to be bothered with two clicks and a single terminal command." Really?

Leaving aside the whole "PHP sucks" vs "PHP is great/fine for my purposes" thing, this is really breathtaking. The fact that you can just FTP up your folder does not mean that's a sensible best-practice way to deploy anything, PHP, Ruby, Brainfuck or whatever you like. It isn't. FTP is insecure[0]. If you're balking at 'git push', then presumably you're balking at source control, which involves a lot of that sort of thing. That is just entirely unprofessional.

And 'no replacement'? FTPing a bunch of stuff into a public folder allows you to deploy something quickly and easily. So does the GP's suggested workflow. It is, exactly, a like for like replacement - except that it's a more secure and less fragile workflow.

I repeat - this has no bearing on the pro/anti-PHP holy war (I lean towards anti, but there's good PHP code out there, whatever. Hopefully a proper language spec will shove things in the right direction). If your argument for PHP is that it allows you to easily evade responsible working practices in software development, however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer.

[0] http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security

What I use it for: my own personal projects where I don't care about security. What I don't use it for: work.

Even if I can configure it down to two clicks it still comes with the cost of having to worry about maintaining a VPS.

>FTP is insecure

Really [0]?

>however, you're getting dangerously close to the anti-PHP stereotype of the average PHP developer

I think you're getting dangerously close to coming off as condescending and insulting.

Despite what you may think, plain old fully managed shared hosting is still massively popular, especially here in the UK.

Our client base are design and development houses who want a reliable, tinker-free fully managed, predictable and secure environment. These folks aren't as backwards as you think, they already have a development workflow that works just fine. They push their stuff to their htdocs folder (via FTPS) and it just works. We even support WebDeploy (also secure) on the Windows platform so they can build MS deploy packages and push them up.

Most of our clients do use source control, they're not that naive but not all of them have drank the Github Koolade. They're happy with their own private source control arrangements.

It's an environment and process that's tried and tested so they can get on with building apps that pay the rent and keep the lights on without futzing about with dynos and droplets and the like. Not only that they can pick up the phone and within two rings get access to an experience frontline engineer who will fix a problem or answer a question within a couple of hours.

I can speak about this from experience as an engineer who works for a UK shared hoster. Admittedly we're not a bulk shared-hoster like GoDaddy, our services are tailored towards the needs of business clients, not someone's granny deploying a Wordpress site with pictures of cats.

[0]: http://en.wikipedia.org/wiki/File_Transfer_Protocol#FTPS

Compared to the php workflow, this is pure technobabble.

That's still $60 a year, which is at least double the price of a simple reliable shared hosting package. The shared hosting has other conveniences too. I'm not saying it's without downsides, but there are cases for choosing it, and therefore for choosing PHP.

You must value your time and sanity really low if you are willing to put up with PHP instead of Ruby for $30/year.

This was already an outdated argument 5 years ago.

If you already have a lot of existing PHP code it wouldn't make sense to move to Ruby just to adopt a framework.

What makes you think I don't use Rails? I use whatever I think fits the purpose at hand. I sometimes use Rails for a project, sometimes I might use Node.js and other times I'll use PHP. It all depends on different factors like budgets, time, the task and team (if any).

Frameworks and languages are a lot like databases. They all achieve the same thing, they're just all slightly different and good for different purposes. I sometimes use MySQL, other times I'll use PostgreSQL, sometimes I might use a graph database like Neo4j or other times I might even use something like MongoDB.

The Rails community has been around a lot longer than Laravel's community, so you can't even compare them. The only community worthy of being compared to Rails is Codeigniter's and at the peak of Codeigniter's popularity, I would argue Codeigniter had the bigger community. Laravel is a mere couple of years old, the community is already pretty strong. Lets reevaluate soon when the right amount of time has passed and then see where the community is at. You only have to look at the amount of Github stars to see how popular it is.

So Laravel is a lot like Rails, but it doesn't compare to Rails because it's not matured yet. Ok..

MySQL vs PostgreSQL vs MongoDB vs Neo4j are all data stores with very different principles and goals. To say they all "achieve the same thing" is like saying an airplane is the same as a speedboat because they both get you from point A to point B.

I certainly believe that frameworks and libraries are tools for different problems and there isn't a one size fits all approach, I just have trouble discerning what problem Laravel is solving better than other frameworks or what makes it advantageous to use.

> The even more surprising aspect of Laravel isn't how great it is, but rather the fact it was built by one guy

... using mostly 3rd party components, the majority from Symfony. So no, it's not "built by one guy".

Irrespective of the fact that Laravel is made up from some Symfony components, before Laravel came along no other framework (not even Symfony) managed to turn the tide. Zend was seen as this mammoth framework not targeted at the mainstream, Codeigniter was at a cross-roads losing prominent developers in the community and lacking in features (PHP 4 support as well). The issue with Symfony is that it is inaccessible, I've seen it used in the enterprise much like I've seen Zend used in the same space, Laravel is more of a peoples framework targeted at everyone from entrepreneurs to large companies and it is more accessible.

It would be in the best interests of Laravel for Symfony to succeed, but you have to realise they're targeting two different subsets of users. I think what makes Laravel more appealing to me as a developer is it takes the good from the likes of Symfony, takes the great documentation and accessibility aspect from Codeigniter all while remaining a relatively soft opinionated framework, it provides you with a structure but the IoC container means you can structure it however you want. The Blade templating system is fantastic, the ORM is feature-rich and very powerful and the addition of database migrations right out of the box.

There isn't a lot of different between Laravel and Symfony considering they share similar components and the unique selling points of Laravel are components that can be used within a Symfony 2 application. I think Laravel gives you a little more out-of-the-box, whereas Symfony makes you add what you need and I can see the benefits from both sides of the fence. If you want to compare frameworks, a real comparison would be Laravel and Silex.

One aspect I like about Symfony is the ability to define routes 4 different ways; YAML, PHP, XML and Annotations in a controller. Compared to Laravel's routes.php file. If you're a developer that wants to customise absolutely every single aspect Symfony is probably a better choice, if you're happy with the guiding hand Laravel gives you out-of-the-box and don't care what format your configuration files and routes are written in (amongst other aspects), Laravel is the better choice. The learning curve of Symfony is far higher than Laravel due to the amount of configuration it allows you to do and the fact it is completely unopinionated.

So, while Taylor didn't build every aspect of the framework (a very well-known fact), there are certain aspects he did build specifically for Laravel. He also took the time to piece all of the components together from Symfony and other authors to create what is arguably one of the most developer friendly PHP frameworks since Codeigniter hit the scene in 2007. Before Laravel came along, I can't recall anyone else attempting to make a consumer friendly framework, can you?

PHP was always stupid easy to use (and abuse), the fact that Laravel is another easy framework doesn't turn any tides. The actual tide was turned by Symfony2 which was the first well architected, well designed PHP framework when it came out in 2011. Since then a mature, knowledgeable community created a lot of great components.

Laravel on the other hand is exactly where Codeiginiter was: easy to pick up, and easy to write crap code in. The whole Facade nonsense is already being abused to no end, not to mention the ORM, Eloquent. Similarly to CI, if you want to do something remotely advanced with it, you end up reading the code constantly, because the "great" 10 page documentation is only for absolute beginners.

Every time I found something I liked about Laravel, it turned out to be a Symfony component. Every time I found something I hated, there was a Symfony component that did it better.

The best example has to be the templating languages used. Blade is a weird port of ASP.NET MVC's Razor syntax and I've never understood why anyone would use it over Twig (or even just raw PHP).

Whenever I do use Laravel the first thing I do is swap out blade for twig. I'm pretty sure no one would use blade if Laravel hadn't decided on it.

It's weird that a framework so self-consciously dedicated to 'best practices' would ignore what's considered one of, if not the, best templating systems in PHP. Particularly given the extra benefits twig provides out of the box (automatic escaping, a function sandbox, hooks for writing your own plugins and parsers, etc.)

The last goddamned thing I want in what is fundamentally a string-spitting language is to have the string features wrapped. Do what you will with the rest of the modules, but leave the damned strings alone.

"Foo".replace("o","O");

Not a big deal.

Despite peoples grumblings about parameter order the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack. Once you know that its not that difficult.

Some other minor inconsistencies like array_map vs. array_filter are simply due to the fact that optional parameters have to be at the end of function calls. On array_filter the callback is optional, whereas on map you can map a list of arrays.

> the only real reasonless difference is string functions are haystack / needle, whereas array functions are needle / haystack

There's a trick to this that isn't too hard to remember. Searching for a value in an array is much more akin to searching for a needle in a haystack.

So, for array functions, it's like searching for a needle in a haystack. For string functions, you're searching in a haystack for a needle.

I'm not really commenting on whether one should have to remember this, only that it helps if you need to remember it.

> searching for a needle in a haystack > searching in a haystack for a needle

wait, what's the difference?

The order of the words.

Parameter order is an important part of a function's interface. In particular, commonly-used arguments should occur before call-site-specific arguments, so that we can specialise the function. array_map gets this right:

    $asBools = partial_apply('array_map', 'boolval');

    $asBools(['hello', '', 'world']) === [true, false, true]
    $asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true]

array_filter and array_reduce get this wrong, requiring awkward argument-shuffling:

    $inverseFilter = partial_apply(flip('filter'), 'boolNot');

    $inverseFilter([-2, -1, 0, 1, 2]) === [2 => 0]
    array_keys($inverseFilter(['foo' => true, 'bar' => false])) === ['bar']

    $allTrue = partial_apply(flip(partial_apply(flip('array_reduce'), 'boolAnd')), true);

    $allTrue(['hello', 'world']) === true
    $allTrue([true, true, 0, true]) === false

Note that a) if specialisation was easy, there would be no need for default arguments and b) having default arguments at the end is exactly the wrong way around for making specialisation not suck.

We could sweep this under the rug by saying it's awkward because it's not idiomatic PHP; but one reason why it's not idiomatic is that it's awkward!

Just look at Javascript, where functions are slightly less awkward; there are lots of functional APIs in wide use, eg. Underscore.

The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.

That's something I'm working on by adding function references. Not sure if it'll be accepted.

I feel like its callable system is simple, easy to use, and frankly awesome.

I can do $func = ['object', 'staticMethodName'];

$func = [$instance, 'publicMethodName'];

$func = 'functionName';

$func = '\namespaced\functionName';

$func = function(){ ... };

$func = $callableObject; // ( http://php.net/manual/en/language.oop5.overloading.php#objec... )

I can execute any of the above by calling `$func('doIt');`

Moreover all of those will all pass a `callable` typehint on a method call as well as the is_callable if they exist and are callable. Its quite powerful.

The problem is that a function is a thing. A string is a different thing. Imagine if arrays were represented as comma delimited strings, and you had a function isArray to check if a string has the right format to represent an array. That would be ridiculous right? An array should be its own type. The same goes for functions. Representing functions as string names is just as crazy as representing arrays as comma delimited strings.

Though who am I kidding, PHP is also confused between numbers and arrays and strings, so I guess at least it's consistent that the language is thoroughly crazy.

Ridiculous or not, Tcl works like this. Everything is a string.

A lot of languages have ways of calling functions and methods by string names -- PHP just makes it very easy and the design is actually really clean.

> PHP just makes it very easy and the design is actually really clean.

Very little about PHP's treatment of functions is easy or clean.

    function foo() { echo "Hello world"; }

    $w = 'foo';
    echo $w;  // foo
    $w();     // Hello world
    'foo'();  // PHP Parse error: syntax error, unexpected '('

    function bar() { return 'foo'; }
    $x = bar();
    echo $x;  // foo
    $x();     // Hello world
    bar()();  // PHP Parse error:  syntax error, unexpected '('

    $o = new stdClass;
    $o->baz = 'foo';
    $y = $o->baz;
    echo $y;  // foo
    $y();     // Hello world
    $o->baz();  // PHP Fatal error:  Call to undefined method stdClass::baz()

Heck, PHP doesn't even recognise function-call syntax applied to a function!

    $z = function() {
           echo "Hello world";
         };
    $z();  // Hello world
    (function() {
       echo "Hello world";
     })();  // PHP Parse error:  syntax error, unexpected '('

When this[1] RFC goes through most of those issues will be resolved. Even without them, ignoring edge cases ('foo'() isn't useful), it's still quite reasonable. The RFC linked above just improves on the design, it doesn't change it.

[1] https://wiki.php.net/rfc/uniform_variable_syntax

> After recently having to work with modern PHP, I have to say a lot of the criticism of the language is unfounded. It's changed a lot since I first used it.

Criticism doesn't become unfounded because things become better. Things become better because of criticism.

But if things have got better, then perhaps the criticism is no longer valid? Criticism leads to things getting better which leads to the (original) criticism having been resolved and no longer applicable to the current versions.

(I'm not going to weigh in on whether any of the criticisms have been resolved in PHPs case specifically, as I've been away from PHP long enough to not be able to talk on any problems with the current language)

> But if things have got better, then perhaps the criticism is no longer valid?

Part of that is due to the share amount of code out there doing things bad ways that were almost encouraged years ago, and tutorials still out there teaching people to do things the old less good ways.

Of course a lot of it is people who haven't touched the language for many years (such as myself) who are at this point a lot less informed than they think they are!

Another issue is that the new frameworks seem to get the positive news, not the core. The language use to describe PHP related libs/frameworks is different in my experience which makes a perception difference: PHP frameworks are often referred to as "making PHP behave" or "removing the cruft from your workflow" where frameworks for other platforms would be described as "helping you make the most of <platform>" and "increasing your efficiency".

things do not merely become better because of critism, criticism becomes worse as things get better.

https://www.youtube.com/watch?v=b5I94bT23cQ&t=1m34s

Having used PHP actively for 9 years, having seen it 'evolve', and having started with a number of different languages/platforms (Python and Node.js in particular), I can say without a doubt that PHP is still awful.

Yes, things are being improved. But in terms of language usability and consistency, PHP is still miles behind pretty much everything else, especially given the slow deployment of new versions of PHP. As for "unfounded criticism"... some particular inconsistencies have been fixed, but the original criticisms are still valid - they just apply to different things now.

If you look into the way the PHP interpreter actually works internally, you'd rapidly find that suggestions like "methods one can call on the objects themselves" is more or less an impossibility. As far as I'm aware, rather than treating base types as special kinds of objects, PHP seems to treat them as entirely differerent types, which leads to something like "calling a method on it" being a technical impossibility in the current architecture.

I'm absolutely not an expert on the internals of PHP - but from the design flaws that leak through at times, it becomes obvious that the PHP internals consist of a lot of hard-to-maintain code bloat, and that code reuse/abstraction is not as common as it should be. One particular example I ran across myself was this: http://www.reddit.com/r/lolphp/comments/1twal5/really_php_re... (the paste no longer exists, sorry for that).

> PHP seems to treat them as entirely differerent types, which leads to something like "calling a method on it" being a technical impossibility in the current architecture.

Most platforms treat scalars as entirely different types at some level and then paper over the differences. As for the PHP architecture, I've actually looked into this, and it would take only one small change to the method-call code to add methods to scalars. In fact, the design of PHP makes this surprisingly easy to add.

The short answer is yes, they continue to wrap older code in new neatly-packaged libs and extensions. For recent examples, you can check out these links:

http://php.net/manual/en/migration54.classes.php

http://php.net/manual/en/migration53.classes.php

http://php.net/manual/en/migration53.new-extensions.php

In 5.5 they didn't add a bunch of new extensions or classes, but they did add generators and finally.

http://php.net/manual/en/migration55.new-features.php

They haven't taken to packaging up arrays or strings yet, but I wouldn't doubt you'd see it over time.

I sure hope Sara Golemon gets the recognition out of this that she deserves (and which the article starts to build.) Having met her at a couple conferences, she continues to demonstrate a brilliant understanding of what it takes to build a programming language WHILE being a tremendous advocate and builder of a community where being a member isn't always... popular.

Rock on, @saramg

The props go to Joel Marcey, Drew Paroski, and Rex Jaeschke though.

Recently i feel there even is a kind of PHP renaissance. I think its a good time to revisit PHP and look at what it has to offer these days. The community is enormous and open source frameworks like symfony2, zend2 or laravel are thriving like never before with solid implementations for nearly everything. With composer there is mature packet management now and in general the code put out for these kind of projects is of very high quality. And then there is facebook pushing PHP forward with things like HHVM, however for most stuff i have worked on, php execution time hasn't really been the bottleneck anyway, but its nice being able to squeeze out even more speed.

These days i also work a lot in node and angular, but PHP (using symfony) is still my goto language for a solid REST backend and/or classic static content based websites.

I'm not really a fan of having a second source of truth compared to in depth material already on php.net. The two will invariably start to disagree and php.net is much, much better than any spec or documentation I have ever read. Using Android is a nightmare compared to php.net because every single thing on php.net has extensive user generated documentation whereas Android is just some broken official docs. I submitted a bug report with a fix for the Android docs telling people to make dialogs in a way that simply crashed and didn't work and it was never merged in for years and years. So official specs tend to suck.

I think a spec benefits language implementors more than it does every-day users. Sure, it will influence things in every-day PHP programming but ultimately I think the target audience is different.

Think of it as what the ECMA spec is to the Node.js API docs. Rarely does a user writing JS code using Node need to reference the ECMA spec (though they should by all means be familiar with it!) but they almost certainly have the API docs bookmarked.

The ECMAScript spec might be a bad example, simply because Annotated ES5 is so good. http://es5.github.io/

This is great news for the PHP community, and I for one applaud their effort. Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward.

* Hack introduces type hinting, imo the major lacking part in PHP.

* HHVM introduces speed to php. On a personal project calculating perlin noise, I got about 8x speedup on HHVM.

* The specification helps pave the way for more implementations of PHP.

>Hack introduces type hinting, imo the major lacking part in PHP.

Hack extends PHP's type hints, it doesn't add them. It also makes PHP statically typed.

I stand corrected.

PHP does not have type hint for their internal datatypes (int, float, string). Only array is supported. Type hinting for your custom datatypes is supported, when used as function arguments.

Also hack introduces type hint for function return type.

Scalar (int, float, string) type hinting may be added in a future PHP version, and there's currently an RFC for return types (I expect it'll pass myself). PHP already let you type hint for classses.

Cool! I wasn't aware of the RFC. Must be this one then? https://wiki.php.net/rfc/returntypehinting

Yep.

You can also hint on interfaces. If strict typing is important, I use the SPL primitive wrapper classes like SplString or SplInt http://php.net/manual/en/class.spltype.php

nit:

It makes it gradually typed. The types are only as static as you choose to make them.

It does have a fully statically and strictly-typed mode, though, and regardless of its strictness, it makes PHP fully static in strict mode, to my understanding.

> It also makes PHP statically typed.

I disagree. PHP finds this perfectly acceptable:

    class Foo {}
    class Bar {}
    function foo(Foo $x) {}
    function bar(Bar $x) { foo($x); }

PHP is clearly checking types (actually, class tags) at runtime, every time a function/method is called. That's dynamic typing, not static typing.

Crucially, static types can be erased before execution without affecting the behaviour of a program: http://en.wikipedia.org/wiki/Type_erasure

I meant that Hack is statically-typed, not PHP. PHP is obviously dynamically-typed.

Hmm. Looks like Hack still includes files based on strings: https://github.com/hhvm/hack-example-site/blob/master/index....

How can a language be statically typed when the instructions telling it what code to use are dynamic?

include "foobar.php", IIRC, is executed at compile-time, and I assume must be in Hack's type checker too.

Also, I don't see how pausing execution and re-invoking the compiler at run-time to load the rest of the code base (which you can do in PHP with a conditional include, don't know about Hack) can't be done with static typing.

Let's say we have the following:

file1.hh:

    <?hh
    $giveMeAnArray = (time() > 1)? function(array $x) {}
                                 : function(stdClass $x) {};
    $anArray = [];

file2.hh:

    <?hh
    $giveMeAnArray($anArray);

file3.hh:

    <?hh
    list($f1, $f2) = (time() > 1)? ['file1.hh', 'file2.hh']
                                 : ['/dev/random', '/dev/random'];
    include $f1;

    if (time() > 1) $anArray = new stdClass;

    include $f2;

As far as I understand it, the following will happen when we run file3.hh:

- HHVM will compile file3.hh. This phase doesn't know what $f1 or $f2 will be, or whether $anArray will become a new stdClass, since they depend on the output of time().

- HHVM finishes compiling file3.hh

- HHVM will execute file3.hh, setting $f1 to 'file1.hh' and $f2 to 'file2.hh'.

- HHVM will compile file1.hh. This phase doesn't know what $giveMeAnArray will be, since it depends on the output of time().

- HHVM will finish compiling file1.hh

- HHVM will run file1.hh, defining $giveMeAnArray = function(array $x) {} and $anArray = []

- HHVM will resume running file3.hh and set $anArray = new stdClass

- HHVM will compile file2.hh, which contains a type error. How does it know?

The most likely answer is that type information is stored in values and checked during usage. That is not static typing, it's 'dynamic typing' (tag-checking).

There is an alternative possibility: the state of the compiler could be preserved between files, so type information from file3.hh and file1.hh is available when compiling file2.hh. However, this information wouldn't include knowledge that "$my_account = new stdClass" has been executed, since that's dynamic run-time information which is only knowable after file3.hh and file1.hh have finished compiling.

There is no way (to my knowledge) that interleaving static type-checking with dynamic execution can produce a type-error when file2.hh is compiled. The type-checking must have access to the execution state of the program, ie. it must be dynamic.

If type-checking happens during/alongside/interleaved-with execution, the compilation phase (which must be done prior to execution) cannot know the types of the code it's compiling. Without this knowledge, the first unit of code it produces is forced to use dynamic types (AKA a unitype). Once that unit is type-checked/executed, the runtime information gained may be used to partially-inform subsequent compilation, somewhat like a JIT, but there would always need to be dynamic fallbacks. Of course, a dynamic fallback defeats the main point of using static types: being informed when there's an error. There may be incidental benefits from doing this though, like faster code.

I don't think many would claim that PHP isn't capable. It's that some of us just don't enjoy it and find it to ugly. Especially given how mature competing languages have become.

I agree, but there are many with a large investment in PHP, and since it isn't going away, it's very much worthwhile to make it better.

Perhaps time to revisit PHP some time then? It also has become more mature :) Much of PHP's old built-in functions are crap (side effects, inconsistent parameter order, wierd naming), but you can't really (and shouldn't) compare those parts with another language as there is no correlation.

All due respect it is easy to write shitty code in PHP but you can also craft elegant design patterns that are easy to grok.

I can't think of a language that has out of box adoption for web development similar to PHP.

I work at a PHP shop, coming from a Python background. I chose to come here for the team, certainly not the language. When I asked about why some things are inconsistent in PHP compared to other languages, its age was a common defense. I was shocked to find that Python is older than PHP, and Ruby is the same age!

However, Ruby didn't see the uptake of usage that PHP did. It was popular -- one of the first languages that you could use as an alternative to CGI!

However, age isn't why it's got so many sharp edges. That's Rasmus' fault, and the core team's.

> Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward.

This attitude really frustrates me. I'm a developer with over 20 years of experience. I don't use PHP because (a) I have had poor experiences with it in the past, (b) I am enjoying my current stack (Java8/Clojure/Groovy), and (c) would go with stacks like RoR over PHP if I had to choose, simply because I've had good experiences with Rails.

You're implication that this has something to do with trendiness is frankly insulting.

Not parent, but if you make those (completely reasonable) points when you criticize PHP he's not talking about you when he says "HN Hipsters." He's talking about the "What kind of idiot uses php?" crowd, which unfortunately hangs out here too much, and frankly doesn't understand which parts of php actually are good or bad because their entire opinion is based off blog posts not experience.

I don't think you're one of those.

Sorry if i offended you. I really did not try to imply this has to do with trendiness, but it was a frustrated outbreak from my end. I've seen way too many poisonous hater comments against everything PHP here since I started visiting.

I myself use (besides PHP) C#, Javascript, Python, and recently revisited C++ to check out C++11 (I am thrilled). I have been working developing in mainly PHP since 1999 so I have seen most of it's ugly sides.

This thread however was about PHP, not wether Java is good or bad.

> I am enjoying my current stack (Java8/Clojure/Groovy)

Not just trendiness, but also whether a spec exists, from which alternative implementations can be reliably built. Some language despots (e.g. Python's) have even had moritorium periods of no new features specifically to help other implementations catch up. The spec announcement is a step forward for PHP.

Your current stack is at widely varying extremes along the spec continuum:

* Java 8 is fully spec'd to intricate detail, and Java has implementations other than Oracle's. Anyone can build an implementation as long as they don't call it Java.

* Clojure is informally spec'd by the comments in the functions, and what little grammar there is is explained on the clojure.org website. Alternative implementations exist to varying degrees of compatibility, e.g. ClojureScript doesn't have native macros.

* Groovy has virtually no spec at all after 11 yrs. Despite it being spec-driven at first, its JSR was inactive for 7 yrs, then changed to dormant status 3 yrs ago. My personal experience is the Codehaus project management actively prevent other implementations being built.

I was untder the impression that a Java implementation that wants to call itself Java can actually call itself Java if it is made to pass specification test suites.

There is currently one major Java(-like) implementation that does not do that, and that is the variety that runs on Android. But there are plemty of other Javas that call themselves a Java.

Right, you have to buy and pass the test suites (TCK).

The thing with Android is they are not close passing the test suites (AFAIK Harmony was close but Android is only a fraction of Harmony).

Compare what Android implements: http://developer.android.com/reference/packages.html And what they would have to implement: http://docs.oracle.com/javase/6/docs/api/ Of course the difference is even bigger for newer Java Versions (NIO.2, Date Time API, Fork-Join, …).

In addition I believe the linking semantics in Dalvik are slightly than in Java, eg. slf4j needs a special version to not fail during dex translation.

I'm not sure whether there is actually an official Java implementation that does not have a license of the implementation from Sun/Oracle or uses OpenJDK. If not they would have to reimplement all of the classes including AWT/Swing. Azul for example does have a license for Zing. I'm not sure if IBM already builds on OpenJDK.

Agree. PHP started itself out with the handicap of a lot of shitty misfeatures, and now that they've beaten it into a state that it's possible (though in no way encouraged) to write decent code in it, anybody who doesn't put on a "PHP: It's not that bad!" party hat gets called a hater.

I'm afraid they're going to have to show me reasons it's actually superior to other languages before I'm going to jump on the train. This "it's less broken than it's ever been" stuff isn't going to cut it.

One thing that makes me chuckle every time I decide to give PHP a fair glance again is "<?php" at the beginning of all the source files. It's hilarious to me that with all the well understood best practices about separation of logic and presentation, people are still seriously using a language where you have to use a little signal to the compiler that means "ok, here's where the HTML stops and the code begins!" I assume at this point it's a vestigial tail, but it's just one irritating reminder that this language was originally designed for half-ass hacks.

So, if your PHP programs don't embed HTML in ?><?, and you use a framework with its own URL routing instead of multiple files, and your framework has plugin autoloading and initialization on every page request… why are you using PHP?

In case that was not a rhetorical question: I'm not using PHP.

> a fair glance

If you're going to harp on the most unbelievably trivial things, no, you never intended to give it a fair glance.

That, by itself, is not trivial.

Compounded with a hundred small little annoyances, it makes the code comparatively unpleaseant.

<!doctype html>

Meanwhile, that user presumably has the impressive track record of 2 days of posting on HN, making him/her a true expert on the HN crowd.

Don't assume that just because an account is new that the person behind the account hasn't been reading the site for years.

That's why I said "presumably", and only referring to posting on HN, specifically (i.e. could have had previous accounts).

This is very subjective, but I find people who (again, presumably) haven't been involved in a community who all of a sudden start right off the mark by posting in that community with a phrases like "HN hipsters", to be rude.

Alright, I'll say it then. I've had an account for 1300~ days, 3 times as long as you and I've been reading for longer then that.

HN hipsters dislike PHP.

So do scarred ex-PHP-developers.

Divining which is which from posts is a dicey proposition.

It is not a matter of what was said, it's a matter of the fact that it was said by a (presumably!) newcomer.

I'm not a web-developer (or whatever you would classify PHP as), so I don't feel hit with the remark.

I don't think it was an attempt to be rude.

"Hipster" is a term commonly used to describe those who advocate so-called "Web 2.0" technologies like Ruby on Rails, JavaScript, HTML5, NoSQL, and so on. These people openly admit that they dislike the previous generation of web development technologies built around languages/platforms like Perl, PHP, and Java.

There are many of those people here, so it makes sense to refer to them collectively, especially given their typical stance toward PHP. Asking them to revisit their current state of PHP is a reasonable enough request.

Now, "hipster" is also often used as a derogatory term, too. It's quite understandable, after dealing with some of those kind of people. But I don't think it was used in that sense in the earlier comment.

I've only seen "hipster" being used in a derogatory way on the Internet. But maybe this is some more HN-specific way that I haven't seen/before, which shows that I'm too inexperienced on here. :}

2522 days here. He's pretty much spot on. You, however, with your trivial sub-500 day membership, don't understand why calling out such things are immature and not welcomed here on HN.

Seriously, calling people out merely for their account age? Really? You really think that's a valued contribution? I mean, your comment amounts to nothing more than a weakly flung insult.

Really? Seriously!? Really? You're hard-hitting reply makes me feel filled with shame. I repent!

> PHP is quite a capable language

I don't think anyone is complaining that it's not turing complete (or whatever), it's all the times php has dropped the ball in the std library, both with respect to being consistent with itself and just being plain broken. I don't think any sane person would switch from a language INTO php, given how many languages that are just as capable as php without having all of its various historical burdens (sigils, stdlib, mediocre type system).

Amen. I think this thread could use a little: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

It has never been about whether PHP can get shit done, it's that given languages that actually had formal design processes and make your days as a coder a joy, why would you move TO PHP.

There are simply so many other options.

There are many other options, none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts).

The barrier to entry is higher if you want to run a site on something else.

That is the sole reason PHP is as popular as it is and part of the reason why it stays popular and powers so many of the internet's top websites.

Other reasons why it stays popular is that they really have improved it a lot over the years and knowledge on how to run PHP at scale is quite easily available. The community is improving along with the language.

Yes, the standard library is frustrating but that is a pretty minor inconvenience honestly. Every language has a frustrating part of its design. This wart on PHP can be fixed and there are some great recommendations on how to transition to a better std lib in other comments on this OP.

> There are many other options, none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts).

What is this really an issue for? I mean, sure, there may be more choices of low-cost low-feature shared hosts that support PHP than other languages, but its hardly as if there aren't a sufficient quantity of low-cost (even, in some cases, with free tiers) platforms for apps in a wide variety of languages.

Unless you are literally compelled to choose a host at random, the fact that a randomly-chosen shared host is more likely to support PHP shouldn't really matter.

> none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts).

So, choose the language based on the ease of the first 15 minutes of your startup?

I think that depends on whether an individual can get past that first 15 minutes. Me, I can have a virtual host running anything I want in a couple of minutes. You too, I'm sure. But for people who aren't pros, just getting something hosted can be a major battle. Not as major as when PHP got its start, but it's still too hard.

That's the lesson I'd love to see other ecosystems learn. PHP, by being very novice-friendly, has developed an enormous user base. How much better off would those people be if they had started with a language that was awesome not just for starting, but for the long term?

(As an aside, I'm throwing no stones here. My first programming language was BASIC, and it took me a long time to unlearn the bad habits it gave me.)

I'm talking about people who need websites in general. Not your fancy startup. Also please name me a single startup that for some reason could not flourish using PHP as opposed to some other language?

It's really more about the talent of your team than the language you choose to write your app(s) in.

> It's really more about the talent of your team than the language you choose to write your app(s) in.

If you have a talented team, why on earth did you choose PHP?

It's too bad to see that your comment was voted down. It's a legitimate question, deserving of an answer.

It isn't the late 1990s any longer. Perl and PHP aren't the only viable options available for web development. We have more alternatives now than ever before.

It was one thing when a team chose to use PHP because it was all that their preferred hosting provider supported, for instance, but those days are long gone. There really is very little reason to use PHP these days, especially for new development.

Especially since platforms like Heroku makes deploying a Python or RoR app in 15 minutes really simple.

I could say it worked pretty well for Facebook but that would be too easy. Seriously though, I know it is very in vogue to hate PHP or at least favor X language over PHP and has been for a long time. I'm not trying to sell you on the idea that PHP is objectively the best language or even a "good" language. That is beside the point I'm trying to make which is that it literally (still) powers the majority of the internets' websites. Tons of new websites are still being made using PHP and THAT is a tough pill to swallow for many people of the opinion that it has no merit.

I don't personally enjoy programming in PHP but the way people act as if it isn't massively important strikes me as obtuse and/or petty.

The PHP Bad Fractal Design article is The Godwin's Law of PHP programming discussions.

If you slog through that, might as well read the rebuttal http://forums.devshed.com/php-development-5/php-fractal-bad-...

For me this is the important part.

I have a team with java/php/javascript experience. PHP will not be an option for my use case. I need a json based rest interface with a decently discoverable web interface. Java has stupidly powerful rest interface libraries with jersey or full application servers, and javascript has hugely powerful frontend interfaces with angular or other frameworks, based on a strong rest interface. And the strong rest interface goes right back at java.

And we are just a limited team with java* experience. I don't know what teams with django or other twisted libraries will do, or what ruby shops will do. The era of "just make it easy to print html" is gone.

>I need a json based rest interface with a decently discoverable web interface.

php has apigility for this.

Though if you don't have php experience I wouldn't switch languages to get it

https://apigility.org/

Dingo for Laravel might be worth a look for you.

https://github.com/dingo/api

edit: I misunderstood your post I think.. But if you're looking to generate APIs, Dingo is still worth a look just for reference.. :-)

That's the beauty of an API. It doesn't really matter what backend language you decide to use. To the front-end client, it's just good old endpoints sprinkled with JSON.

Have there been any implementation decisions that have forced PHP to take a step backwards?

There are many things that they language has had to fix, and some that still need to fix. But I honestly don't feel that the direction in which the language is headed is encumbering the language further.

PHP the language and the development environment around it is quite capable, however the unwashed masses of "developers" and the plethora of code spewed forth from them would cause you to avoid PHP like the plague.

PHP is fantastic if you are starting from scratch and you don't necessarily need any third party libraries. PDO is very well done and the native database drivers are some of the fastest available.

With a properly tuned nginx/fpm/apc stack, I've been able to deliver solutions that truly back up the results you see from comparison benchmarks like Techempower.

In many cases in web development, PHP can be the right tool for the job!

With HHVM + nginx you can really fly! Seriously, it's amazing how fast it is (and the Techempower benchmarks put it at #1 for anything with multiple requests and data handling!)

You are spot on, Nginx+HHVM is really fast. I am an early adopter of HHVM (since Dez 2012) and it really shines on sites with thousends of requests per seconds. I heard PHP 5.5+ on Nginx (FPM) is fast as well.

And I prefer PHP as I can code websites without the need of frameworks (PHP is "the framework") with a C/C++ like syntax. The idea of libraries is much older than frameworks, and in the end libraries are so much more flexible IMHO.

> And I prefer PHP as I can code websites without the need of frameworks

That either means A) you re-invent the wheel every time you start a project or B) you have your own implementation of commonly used items (your own framework)

I personally would rather have a framework vetted & maintained by thousands of other developers than one I put together myself.

PHP, Node.js, Go and OpenResty have a versatile ecosystem with both libraries and optional (micro) frameworks.

I prefer the newer trend of micro frameworks and for simple websites just raw PHP 5.3+.

To be fair, PHP's stdlib is essentially a Web framework. It comes with $_SERVER, $_GET, $_POST, header(), etc. built in, which other languages (Python, Haskell, Perl, etc.) would define in a framework. Hence there's no need to redefine stuff over and over. Hell, PHP is even a templating language by default, thanks to its <?php ?> tags.

Of course, this doesn't answer the related questions: is PHP's built-in framework any good? Is it a good idea to include a Web framework in all scripts (even non-Web ones)? Is it a good idea to write all application logic inside giant <?php ?> tags in template files?

Using php-5.5 with php-fpm and nginx, can confirm.

There are some gotchas that you will trip over along the way, but after that it's nothing but smooth sailing.

As a discussion of any programming language grows longer, the probability of a bashing against such language approaches 1.

Any similarity with Godwin's law is mere coincidence.

There are languages that everybody hates, and then there are the languages nobody uses.

This is sadly true, on so, so many levels...

There are languages whose communities everybody hates, but it doesn't seem to be that everybody hates Ruby or Clojure or whatever. Just that everybody hates their trendiness.

I haven't found the Clojure haters yet but I can find a Ruby hater without looking too hard.

Curious about the hate. As far as languages go Ruby is as coherent as it gets.

All the reflection and abuse of mixins are pretty worthy of hate.

That's like saying you hate lisp because of macros or that buffer overrun exploits are reason to hate C. That's just shitty programmers doing shitty programming.

Buffer overruns are a completely valid reason to dislike C.

Clojure is the language I hate the least!

I believe C++ is not hated universally and is still used like everywhere.

Fair enough... it's not hated universally, but it is hated passionately by some.

No language is hated universally, even JavaScript got some love[1].

[1] http://javascript.crockford.com

To better word the original saying: "There are languages that the minority of geeks that like to quarel about languages hates, and there are languages that nobody uses -- but for both cases, the millions of programmers out there could not care less".

And then there is C#. (implication being that I almost never see anyone hating on C#, and yet C# is really used a lot, obviously. Hey, I was probably gonna have to add this part to the post as an edit, anyway; might as well get it out of the way.)

Ok. I can't argue with that. C# is actually pretty nice.

Although I suppose one could rant about it being so deeply tied to Microsoft and the .net architecture.

Just learn and code in c#.. Really tense... Code work in visual studio but compile output diff.string and array kinda weak to me..I love pup because of string manipulation.(string) (int) casting both in php and c# also..still learning c#.

As any discussion grows longer, the probability of an utterance in the discussion meeting any particular description increases monotonically with a limit of 1.

The similarity between your observation and Godwin's law (and every possible observation of similar form) is not coincidence.

Can someone explain to a layman why this is significant? I'm genuinely curious.

As far as I know, this is providing a better answer to "How do we know this is valid PHP code?" Currently, the answer to that question is "Because it does/doesn't compile using the standard PHP interpreter." When this spec is finalized, the answer will change to "Because it does/doesn't follow the rules laid out in the PHP specification."

In practice, there is a PHP spec, it's just an "unwritten" spec that is defined in the code of the PHP interpreter. With an official "written" spec, it will open the door to alternative PHP interpreters (like HHVM), since they will be able to say that they also support "PHP" as defined in the spec.

Hope this helps!

Hoping to tide you over until a better answer comes along...

Generally when complex programs (like an entire programming language) are made, there is usually a "specification" of its behaviors. This way, you can communicate to people, hey, my program does ABC and does NOT do XYZ.

Also, it helps you delineate between bugs and what not. My program does AB DEF. Is that a bug? Or a feature? What does the specification say?

Not all programs have a specification. It's a bit formal and unnecessary. Except in a specific scenario where you have multiple/competing implementations of the same programming language. Now that there are multiple players, we need to know exactly which behaviors are per the spec and which behaviors are per the implementation.

All coffee makers must make ABC XYZ. This is the spec.

Sony CoffeeMate makes ABC DEF XYZ. It matches the spec and throws in some extra features.

Samsung Coffee Xtreme makes ABC PQR XY. This also throws in extra features but is actually missing one from the spec.

TL;DR it helps a language evolve independently of its implementations (come the day that a language != its implementation)

Another way to answer this question is that a programming language specification tells what the language does in the case there's no stack overflow answer for the question.

There are a myriad of PHP "gotchas" and many change per release and are undocumented. This should help alleviate that.

A language spec is roughly analogous to the definitions of scientific units of measurement[1]. They among other things, allow us to verify something independently of a specific kind of measuring device.

[1] http://physics.nist.gov/cuu/Units/current.html

For one, a language specification is mandatory if you want to standardize it (ECMA, ISO, JIS, ...).

Secondly, it paves the way for competing implementations. Having more implementations automatically means more performance, because they compete with each other.

And finally, a language specification is also super useful to people who create tools such as IDEs, linters, or compilers/transpilers.

This is good and long overdue. I disagree with the claim of it being the lingua franca of the internet though.

> PHP is definitely the lingua-franca of the internet.

Definitely wrong. If there's a lingua-franca of the internet, it's JavaScript.

The internet does not have a lingua franca. The web does, and it is HTML.

Sorry, that's total nonsense. Far more of the Internet depends on C, C++, or some mix of the two. Software written in them runs the networking gear, the servers, and the clients that are critical to the Internet's existence.

And keep in mind that the major JavaScript implementations today are all built using C and/or C++ in one way or another. So pretty much anywhere that JavaScript is being used, then C and C++ are being used, too.

JS is the lingua franca of the browser, but PHP is the lingua franca of the server side.

> PHP is definitely the lingua-franca of the internet.

I think they misspelled Javascript.

PHP is on the server.

A lot of the sites we frequent have python, ruby or C# on the server.

That's not the point. PHP is the lingua franca of the server-side as it's by far the most commonly used language and widely understood. Do others exist? Sure. Just as other languages exist. But PHP's the big one.

The PHP grammar in BNF starts at line 10354. It not that extensive as some may think and rather similar to what Java BNF looks like. The expression statement is a bit more extensive than in most languages, as PHP also supports the little known template-style (if elseif endif;): http://php.net/manual/en/control-structures.alternative-synt...

Thanks for the PHP spec.

Btw. GitHub says "Sorry, this blob took too long to generate.": https://github.com/php/php-spec/blob/master/spec/php-spec-dr...

I got the same message on GitHub. Did you checkout the repo in order to read it?

Personally, this is exciting news, but I'm not sure that PHP is ready for this after 20 years. There's plenty of cleanup that needs to be done to userland naming conventions and parameter orders that in all likelihood won't get done anytime soon to avoid breaking BC

yes, you can also use the "Download Zip" button there: https://github.com/php/php-spec

PHP ships with a lot of third party C libraries that are exposed in PHP with usually their original function names. Object orientation came with PHP 4 and later with PHP 5 the new better one (5.3+ with namespace support, traits, etc.).

You can think of PHP as a mixture of C, C++ and Java for web development and CLI tools. I personally use all four languages, each one for specific purposes where the fit best. You can find function names like strstr in C, C++ and PHP (= indexOf in Java and JavaScript) - not a big deal.

I'm at work so I was looking to peruse the proposal without downloading things. You can read it from PHP's git mirror: http://git.php.net/?p=php-langspec.git;a=blob_plain;f=spec/p...

I'm not sure that I would call PHP4 objects object oriented, as I remember it, it was all such a huge hack (down to being able to return null from a constructor). I only had to maintain some code like that at the tail end of PHP4's life, so I never found out whether that was how OOP was done in PHP4, or if it was a hack to simulate OOP in a language that didn't support it.

Hack has actually dropped support for that format, the only place I've ever seen it used seriously is in wordpress.

The alt syntax is pretty heavily used in frameworks that use vanilla PHP for their view templating, including the Zend Framework..

Maybe I'm missing something here...but the OP links to what must be a gigantic Markdown file that Github will not serve up...Is the spec meant to be in a giant doc, or will it be split up into smaller sections? This seems like a perfect use for Jekyll if they're going to publish on Github...

In any case, I did a quick-fork and generated a Github page from the Markdown file linked to by OP: http://dannguyen.github.io/php-spec/

Nice. Thanks.

In my mind, there will be multiple renderings of the spec (like what you had done here). I have plans to split the spec into multiple, smaller .md files based on topic. The gating factor was managing the internal reference links, but I can work around that with some tooling. I did not want this to hold up getting the spec out there though.

It took a while, but I read the spec and wrote a critique:

http://blog.circleci.com/critiquing-facebooks-new-php-spec/ (comments at https://news.ycombinator.com/item?id=8114919)

Rookie question, but what does a language specification for PHP do or mean? I assume this is good, but don't know why. :)

The obvious thing it does is lays the groundwork for multiple first-class implementations. As it stands, the program php essentially is the reference: whatever it does, implementation quirks, bugs, and all, is what php should do.

What is a language, really? It's not really an implementation (necessarily); a language can have multiple implementations, in which you have to ask "which one is the language?" if they have subtly different behaviour.

In order to enforce what a language is, you can introduce a specification. This will say that "given a program X, the language will behave like Y". Now any implementation of the language can be checked for conformance.

The spec itself might be some document, or perhaps just a "blessed" implementation ("the implementation is the spec").

This is great news, now we just need to lobby for the creation of this specification in machine readable files, using something like the K Framework, instead of using the usual wall of text.

http://www.kframework.org/index.php/Main_Page

This should help the PHP-NG project too. I was a bit worried to see they were doing large refactorings to increase speed when the PHP test suite only has about 30% code coverage.

At first I thought they were announcing a formal specification for PHP. Who's going to win the race to build the first formally verified blogging platform?

Looks like PHP spec is about twice smaller than ECMAScript 5.1 (http://es5.github.io/)

~42K vs ~82K words.

The ES5 spec specifies its whole standard library, however ;)

“PHP is definitely the lingua-franca of the internet.” Uhm, no.

fantastic work that's long overdue. any commitment from the zend team to implement it? if not it's a specification for HHVM, not PHP.

Better late than Python.

Hahahah.... what a waste of time and resource. FB would rather direct their resources towards this meaningless crap then run the risk of their top employees getting bored -- and leaving them.

Javascript is the lingua-franca of the internet not PHP.

Facebook first needs to bring HHVM up to full compatibility before they try altering the spec.

I also discovered Facebook makes all their "contributors" (anyone who does a pull request) sign an agreement with them, which seems weird and not cool. https://code.facebook.com/cla

It's not unprecedented. GNU projects require contributors to sign over the copyright for their code. Facebook's requirement of copyright and patent license is relatively restrained.

> Facebook first needs to bring HHVM up to full compatibility before they try altering the spec.

Defining a spec (there isn't a pre-existing spec that is being "altered") is an important part of moving to acheive compatibility, since its how you know what the target is.

HHVM spawning a spec effort for PHP is a lot like Rubinius spawning RubySpec.

> I also discovered Facebook makes all their "contributors" (anyone who does a pull request) sign an agreement with them, which seems weird and not cool. https://code.facebook.com/cla

This is standard for virtually any open-source project backed by a large company and for many that are independent (e.g., all Apache projects: http://www.apache.org/dev/new-committers-guide.html#cla).

These CLA are fairly common arent they, esp. among largercompanies that have/run open source projects? ? e.g. https://github.com/angular/angular.js/blob/master/CONTRIBUTI...

What's it been, 20 years?

If you read the article you would have known this. It is literally the first three sentences they cover this.

smartass, meet smartass.

Too subtle, I guess. I was responding to the facts of the first sentence: More than twenty years without a spec.

Why yes, that does remind me why I chose other languages.

A language without a spec ? Damn, php is even worse than I thought. Still, FB may turn it (with hack and HMMV) into something interesting.

That's not uncommon for implementation-defined languages. Ruby didn't have a language specification until the community set up rubyspec as it started getting serious about alternative implementations.

Facebook is apparently getting serious about its own alternative implementation (or at least intending to be taken seriously) and are thus stepping in with a spec.

Often I wonder if going without Spec is a good thing. Ruby doesn't want a Spec because Matz said Ruby is an always evolving languages. But the same could be said about HTML 5 where it does have a living spec.

Python has a spec[0] and Python is an always-evolving language as well[1], so I'll just go ahead and say that it's probably an excuse for laziness rather than an actual justification for not having a spec.

[0] https://docs.python.org/2/reference/

[1] https://docs.python.org/3/reference/

Well, sometimes it's good to be able to tell whether some code is of the language in question or not. That's were a spec comes in handy, whether it's considered ongoing or not.

> Ruby doesn't want a Spec

Both RubySpec and the ISO standardization effort suggest that this is less than true.

> because Matz said Ruby is an always evolving languages.

That's not a reason not to have a spec; that's a reason that the current bleeding-edge version might diverge intentionally from the spec and that the spec might trail.

(Or, as in the case of HTML/HTML5, its why you might have both an evolving target spec, like WHATWG has with the HTML living spec, for language implementers to develop toward, and a more conservative one, like the W3C HTML5 spec, that is more geared toward what language users should target.)

Without a spec -- preferably one that is or includes an executable test suite -- independent implementations are problematic, and multiple independent implementations that can experiment with different innovations is good for an "always evolving language".

Reply on news.ycombinator.com