nikic

I think he is mocking the general pattern of over-engineering and PHP just happens to be the language he wrote this in.

At least PHP is not a language known for massive over-engineering. Usually people associate the exact contrary with PHP.

But there is indeed a recent trend towards better object oriented designs in PHP and with it comes also more over-engineered code. But I have yet to see any Java-style absurdity. Maybe we'll still get to that ;)

DLLs for PECL exts are currently available here: http://windows.php.net/downloads/pecl/ Not for all of them, but some of the more important ones. If you want something added to the list it's usually as simple as pinging Pierre on IRC :)

ZO+ will replace APC, only the user-cache from APC will be left (see also this comment: http://news.ycombinator.com/item?id=5343883).

Object literals and scalar type hints won't be in 5.5. Scalar type hints may be in the next version (it's a rather tricky topic). For object literals I don't see reason to add them at all (in PHP you can just use arrays ^^).

We will provide a separate extension (currently called "apcu") which contains only the user-cache part of APC. ZO+ and that extension together should behave the same way as APC currently does. This will actually work even better, because both components will be completely separate (the shared cache had fragmentation issues in APC.)

ZO+ was chosen over APC because it is more stable. ZO+ is (more or less) PHP 5.5 compatible already, whereas APC still tries to cope with 5.4 compatibility.

For those wondering what the new features for PHP 5.5 are at this point, here is a small (not complete) list:

Large language changes:

* Generators and coroutines (https://wiki.php.net/rfc/generators by me)

* `finally` blocks (https://wiki.php.net/rfc/finally by laruence)

Syntactic sugar:

* Support for function calls in `empty()` (https://wiki.php.net/rfc/empty_isset_exprs by me)

* Support for `list()` in foreach (https://wiki.php.net/rfc/foreachlist by laruence)

* Constant array/string dereferencing (https://wiki.php.net/rfc/constdereference by laruence)

* Getting the fully qualified class name using `ClassName::class` (https://wiki.php.net/rfc/class_name_scalars by ralph)

Standard library:

* Simplified password hashing API (https://wiki.php.net/rfc/password_hash by ircmaxell)

* `hash_pbkdf2()` function (https://wiki.php.net/rfc/hash_pbkdf2 by ircmaxell)

* DateTimeImmutable, which is an immutable variant of DateTime (by derick)

Key anti-features (aka BC breaks):

* Dropped Windows XP and 2003 support (by pierre)

* ext/mysql deprecated (https://wiki.php.net/rfc/mysql_deprecation by aharvey)

* preg_replace /e modifier deprecated (https://wiki.php.net/rfc/remove_preg_replace_eval_modifier by me)

* Logo GUIDs removed (by ajf)

For the beta 1 (the next planned released) at least two more things are planned:

* Bundling of ZendOptimizer+ (https://wiki.php.net/rfc/optimizerplus by zeev)

* Allowing non-scalar Iterator keys in foreach (https://wiki.php.net/rfc/foreach-non-scalar-keys by me)

Most people just miss the common C++ idioms that solve many of the exception issues in very elegant ways (and give a lot of benefits at the same time).

E.g. the example with file open + close in the presentation is laughable. Every C++ programmer knows that this is something that should be done with RAII. I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you remembering to add a close call on every possible exit-path.

Also one should point out that C++11 has unique_ptr and shared_ptr which in many cases remove the need for the programmer to manage things by himself.

PHP has changed a lot over time. It moved from a C-style procedural language to very Java-esque object oriented language. "PHP" hasn't been "PHP" for a long time already.

It's always hard to do large language changes, but it's not impossible. E.g. consider the change that PHP did from version 4 to 5. That was a pretty major paradigm shift, with lots of broken code, but it worked out well in the end :)

Which classes are you specifically missing?

I think this is (once again) just a question of finding the right balance. Using polymorphism to avoid manual conditionals is a practice that can often improve readability and maintainability. One just shouldn't drive it too far.

I do agree that people are massively overusing inheritance. In particular its often used as a means for code reuse, not for polymorphism. In most cases composition should be favored over inheritance.

3 and 4 are weak because we have pretty good heuristics on how passwords are composed so it wouldn't take much longer to brute-force them than it would to do password123.

I've seen this story on a few sites now, and none of them bothered to show just where exactly in that image the part is supposed to be. Very helpful.

Context: http://en.wikipedia.org/wiki/Shor%27s_algorithm

The RFC was accepted. So it will be in PHP 5.5 (unless some serious flaw with it comes to light in the meantime).

Just to clarify a bit more: Usually you need more (a lot more) code than this on pre 5.5. In particular you can't normally assume that `openssl_random_pseudo_bytes` is available. Instead you'll go through various entropy sources (typically `mcrypt_create_iv`, `/dev/urandom`, maybe COM, with fallback to `mt_rand`).

People often get the salt generation wrong, e.g. by just using a substring of `md5(mt_rand())`, which is obviously wrong (in several respects) :/

I wanted to watch the video on the page, but it told me to install QuickTime. Yeah, sure...

I'm not really sure what I should with this comment. It doesn't make sense to me.

Generators and coroutines are a well-known concept implemented in many languages, in particular Python and C#. It is also part of ECMAScript Harmony as far as I know. Other languages implement the more generalized concept of continuation passing (usually providing generators implemented on top of them).

Callbacks can be used to implement some of the use cases of generators. To be more precise they can be used if the callback is stateless (as in your above case). If the callback had to handle state, you would have manually implement a state machine, making the code hard to understand and adding a lot of boilerplate.

Generally PHP does not make extensive use of callback-y programming, but does make extensive use of iteration. That's why generators integrate much better than callback based producers. The same applies to Python, that's why they too have generators.

You need to understand that Ruby has a different underlying philosophy, which is not directly transferred to other languages. What might be nice in Ruby will be considered really ugly in Python or PHP and vice-versa.

Just because you can, doesn't mean that you have to. Look at Google. That's a nice company, which keeps the patent trolling down.

1. Opened http://docs.phalconphp.com/en/latest/reference/tutorial.html

2. Saw lots and lots of static method calls

3. Closed page again.

This way of judging frameworks has never failed me.

I don't think that this is the judges fault. The law (at least to some degree) dictates the decision. If that decision is not good for the general public, then it is the law that needs change. (And we all agree that it does.)

I like this attitude. It is better to lurk than to reply with low-quality posts :)

I think the app looks very nice :)

One thing that I'm missing here are the Terms Of Service. Uploading stuff on other people's servers is always a legally problematic business. It should be made clear that the uploader retains all rights on the images.

What are the reasons for hiding it?

This is missing the supports list for the Intel Compiler (which to my knowledge has a pretty good C++11 coverage).

Sometimes used in earth-based applications too. See http://en.wikipedia.org/wiki/Radioisotope_thermoelectric_gen....

For context: This means that the infamous ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 won't work anymore ;)

The article wasn't really meant as "Patch your own PHP and break compatibility". Rather it was intended as "Contribute new language features to the main PHP distribution" :)

I wouldn't advise anyone to run PHP with patched syntax ^^

Only tangentially related, but I'd like to know:

The Wikipedia article on the incident says "The first phone calls to emergency services via 9-1-1 were made at 12:39 a.m. The police arrived within 90 seconds and apprehended the suspect."

I'm wondering, can this be true? Are they really that fast? If so, impressive.

Just a bit feedback on the blog: The background image was very distracting for me. My eyes were always wandering off from the text. Not sure if that's just me or if others had that problem too.

I love this. It's always nice to see PHP being implemented on new platforms (we already have it to some degree running on C++, on JVM, on .NET, now on PyPy). Sadly most of those projects don't really make it to a production-ready state :/

In any case, keep up the work!

I like the general idea of this, but think that it is nearly useless in its current form. It's way too superficial. To teach newbies how to do things right it doesn't suffice to link to a few resources and hope that they'll read them (hint: they won't). Instead one needs more concrete code examples, etc. Which would obviously be too much for one page :)