Hacker News Reader

Comment by rubiquity | Hacker News Reader

> generators for simpler iteration, namespaces, and variadic functions and argument unpacking. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style.

"The new Java"

It's good to see PHP maturing. However sometimes the most important features of a language are the features you don't add. I think PHP would do itself a big favor by cleaning up its main APIs and standard library first. Maybe they will do that in PHP 6, since I doubt they want to break APIs in minor releases.

View on HN

PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x series improves the language mostly through additions. I think that's good. PHP has been missing a number of things that are now present.

However that doesn't work forever, at some point you need to clean up some of the old stuff. That's why a PHP 6 release is planned in the near future (i.e. somewhere in the next three years ^^).

The very first programming book I bought was "PHP6 and MySQL5" by Larry Ullman. I bought that one specifically because I had another job (career, really) and I knew it was going to take a while before I really got into programming and I didn't want to buy a book that was going to be out of date in 2 years. That book is now 6 years old, out of date, and PHP6 is still not released. Maybe 6 is just an unlucky number with Perl unable to make that goal as well, but either way I'm not holding my breath.

I've since moved on to more well thought out languages, though PHP keeps pulling me back in. I'm currently having to support a CI app that hasn't had a line of code added to it since 2008, and the only thing I can say, even though I appreciate the language and how far it's pushed the web, I'm glad it's no longer my go-to language of choice. Keep PHP5 around for a while so apps like this one can continue on, but PHP6 is _LONG_ overdue.

Literally bought the same book by Larry Ulman.

I bought the same book metaphorically.

Same here. Larry's a great author. I got started with his books years ago. He definitely makes Web dev feel more approachable, which is invaluable to a newbie. I believe Patrick Collison from Stripe also got started on Larry's books (for some reason I recall a conversion on Twitter or the like about this).

Figuratively I bought the same book

The goal for PHP6 is basically to provide good unicode support (strings internally as unicode etc.)

However due to problems and internal conflicts the effort was stopped a few years ago and there has been no progress since.

If this goal hadn't been stated PHP 5.3+5.4 would probably have been PHP 6 (they have some major new features). Core API cleanup never has been (and it doesn't look like it will soon be) a goal for a future release, unfortunately.

Sounds like if PHP6 is going to be cleaned up and break backwards compatibility then it really needs to be named PHP+ or named differently so that the less informed nonfollowing developers understand it's not just PHP5 plus some more stuff and therefore it's not backwards compatible.

I realize the PHP API is a mess compared to highly curated and standardized offerings like Java, but growing up with it, it was very like C standard lib and other things of the time. I could often even guess functions without looking them up even though they had weird names and abbreviations.

...and you could guess wrong (because consistency is for suckers) and have things blow up in entertaining ways.

That being sort of the problem.

There's some discussion on the RFCs and mailing lists about creating new backwards-incompatible OO APIs for the core libraries which would eventually replace some of the legacy mess.

I think this is the way to go about it. And if earlier versions want those kinds of APIs they can implement them in packages.

Can you link the RFC's/Threads? When you're not familiar with the PHP dev ecosystem it can be hard to find the meaningful stuff.

Cleaning up main API or similar vast changes may and probably will be a disaster for PHP. We all know a bunch of examples from other languages.

It's a weird problem. A 6 major release may be the only time to do such things, and people here think it would be a disaster. I don't know if it's possible at all to retrofit language improvements into the stdlib.. do you write a parallel one or do you write books hoping people will catch on the latest way to write good code ?

Yeah, that's a huge issue with Perl 6. The language is nowhere near backwards-compatible with Perl 5, and it can't be easily retrofitted to be. So perl 6 is basically becoming its own language in parallel rather than the successor as was originally planned.

It will be interesting to see if PHP goes that route or not.

PHP already kinda did that once, for the PHP6 effort, which was abandoned after many years of being in development. So it's probably not the way to go.

they should introduce a robust "clean" api in PHP6 and remove the old stuff in PHP7. that will let sometime to rewrite libs.They should move to C++ too,it's a pain to OO write extensions in C.

Reply on news.ycombinator.com