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?
Myself, I like this proposal.
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.
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).
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.
Criticism doesn't become unfounded because things become better. Things become better because of criticism.
(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)
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
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.
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.
$asBools = partial_apply('array_map', 'boolval');
$asBools(['hello', '', 'world']) === [true, false, true]
$asBools([-2, -1, 0, 1, 2]) === [true, true, false, true, true]
$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
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.
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.
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)
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.
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
[1] http://blog.vjeux.com/2014/javascript/hack-is-to-php-what-es...
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.
Not a big deal.
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
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.
$a = 'b';
$b = 'a';
echo $a."\n";
>>> b
echo $$a."\n";
>>> a
echo $$$a."\n";
>>> b
$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)
>>> }
function null_the_object($obj) {
$obj = null;
}
null_the_object($obj);
var_dump($obj);
>>> object(stdClass)#1 (1) {
>>> ["x"]=>
>>> int(2)
>>> }
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
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.
* 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.
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.
I don't think you're one of those.
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.
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.
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 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).
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.
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.
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.
I can't think of a language that has out of box adoption for web development similar to PHP.
Hack extends PHP's type hints, it doesn't add them. It also makes PHP statically typed.
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.
I disagree. PHP finds this perfectly acceptable:
class Foo {}
class Bar {}
function foo(Foo $x) {}
function bar(Bar $x) { foo($x); }
Crucially, static types can be erased before execution without affecting the behaviour of a program: http://en.wikipedia.org/wiki/Type_erasure
It makes it gradually typed. The types are only as static as you choose to make them.
Any similarity with Godwin's law is mere coincidence.
The similarity between your observation and Godwin's law (and every possible observation of similar form) is not coincidence.
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)
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!
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.
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...
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
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 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
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.
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).
Definitely wrong. If there's a lingua-franca of the internet, it's JavaScript.
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.
Why yes, that does remind me why I chose other languages.
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.
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!
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.
I think they misspelled Javascript.
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").
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.
Rock on, @saramg
The props go to Joel Marcey, Drew Paroski, and Rex Jaeschke though.
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/
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.
~42K vs ~82K words.
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.
http://blog.circleci.com/critiquing-facebooks-new-php-spec/ (comments at https://news.ycombinator.com/item?id=8114919)