PHP was my first language when I was starting out professionally, and before I went into university and learned "proper programming". Back in 2007-2008, I remember the mess it was, with the internals list being a permanent struggle to implement anything by consensus (no lambdas or JS array notation because it wasn't easy to google, for example), and it really did look like a dead end. The internal source code of PHP was often a mess of macros everywhere, and the whole PHP6 unicode fiasco really did paint a grim picture of its future.
Facebook seems to have given it a bit of fresh air, implementing some pretty interesting stuff (Hindley-Milner with subclasses, for instance), and it really seems like the "feel" of programming in PHP has changed. I'm not going to say "Screw C++ and Haskell, _this_ is a serious language!", but on the other hand I feel I can say with a straight face to someone who is starting programming, "You could check this language out", without a guilty conscience that I'll be ruining their mind.
I'm unsure of PHP's future - if it'll be tied to Facebook (and thus Facebook's future, which I am equally unsure of), for example - but as of now, it seems to be a reasonable, if idiosyncratic, language.
Being "tied" to Facebook is the best thing that can happen to PHP. I stopped taking PHP core devs seriously since the PHP6 fiasco. PHP is doomed with these guys, trust me, no matter how much effort is put into Doctrine, Laravele ,Symfony or other libs.
At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
Being "tied" to Facebook is the best thing that can happen to PHP. I stopped taking PHP core devs seriously since the PHP6 fiasco.
The "PHP6 fiasco"? A major featured release was too much, and had to be scoped down. Since then most stuff has been released as 5.4, 5.5 etc.
Did it break anybody's code? No. Did it divided the community? No. Did it halted PHP development? No. At worst, it make some prematurely released PHP6 books obsolete. Big fucking deal.
Compared to Perl 6 (still MIA for actual production development) and Python 3 (only 10% adoption or less after 5 years for an update that doesn't even offer that much), I'll take the PHP6 fiasco anytime.
At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
Python 6 did it badly, Ruby didn't do much, and NodeJS will have the ES6 modules "update" happen automatically by virtue of them being based on V8.
Not sure about PHP6, but previous versions did - in unnecessary ways. Like "deprecated" warnings you couldn't really turn off, "safe mode" which let administrators decide which functions developers needed,...
But all in all PHP is still... quite OK language. We've seen better and we've seen many worse. It has lots of weird features (I would call them bugs), but it is useable once you learn to live with them.
Oh, and after many years I still HATE that dollar sign in front of each variable. Just hate it. :)
PHP 5.4 broke code. In more ways than documented in the help (where a list of breaking changes exists, but is incomplete). For good codebases that adhere closely to how good PHP code should be written it's probably not much of a problem, but the ancient and horrible code base I had to coax into working with 5.4 had a few places that broke.
I love how often the same people that are those complaining about 5.4 breaking code, throwing deprecated messages etc, and on the other hand still wailing about the weird artifacts and inconsistent function naming.
http://php.net/manual/en/migration54.incompatible.php lists very few removed functions and no renames. One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given. I'm not sure that falls into »We're removing weird artifacts from the language«.
No those changes would be reserved for major releases.
But the removal of the likes of safe_mode, magic quotes and register_globals have been long overdue.
The only reason why they have been in there for so long is because it would break code.
Backwards compatibility has always been this cute silly idiom of PHP. Which has its good parts and bad parts. I'm glad that it has gotten more mature in that sense. 5.3+ have been a statement of such.
One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given
I agree that encoding in PHP has been a consistent PITA, and making this move and not mentioning it, is not really helping.
But again I must say, It's actually a really great thing, and again long overdue.
I think Python 3 offers more than you think it does. I'm not going to try to convince you, but having used it steadily for the last month or so, I really think it does.
It does offer some things, but does it offer a "divide the community, halt the old version and still go nowhere much adoption-wise after 5 whole years" worth of things?
I started using Python when "Python 3000" (as 3 was called then) was just a pipe dream for the distant future. For all the trouble with the migration, it doesn't really offer much groundbreaking things.
Removal of GIL, a JIT, a few times or an order of magnitude faster, an integrated new async model etc would have been great. UTF-8 and a few tricks that could just as easily be added in 2.8? Not so much.
The GIL and a JIT are low level implementation issues though, right? E.g., Python 3 can be implemented in PyPy (and it looks like that's in the works).
Most of the Python 3 changes are design and feature related, and it's a lot more than just "UTF-8 and a few tricks".
I couldn't agree more. The PHP internals group struggles still occur to this day as new ideas and fresh thinking run up against the old guard and more often than not are discarded.
I don't necessarily blame the "old guard" - they've been around a long time and they've seen a lot of failed ideas - and it's been them who dealt with the cleanup and had to maintain those broken features long past the founders of those features had moved on.
This isn't a bad thing: PHP is rooted in many businesses both small and enterprise: it will be around for a long time. Projects like HHVM are going to ensure that.
However, I no longer think that PHP is going to "turn it around" and will ever be a model of innovation. It lost it's opportunity to do that.
The internal source code of PHP was often a mess of macros everywhere
My understanding, from people here that seemed to know what they are talking about, is that generally macros are how these languages are implemented when done in C, for various reasons. So much so in fact, that you are really writing a DSL layered over C. I doubt Python, Ruby or Perl are any different (actually I know Perl relies heavily on macros in the source for its interpreter).
I'm unsure of PHP's future - if it'll be tied to Facebook
I don't think it'll be tied to Facebook at all. What the PHP community has is a huge ecosystem of programmers (good ones and bad ones), frameworks, libraries, etc. That bodes well for PHP's future.
Comments
I really liked this talk.
PHP was my first language when I was starting out professionally, and before I went into university and learned "proper programming". Back in 2007-2008, I remember the mess it was, with the internals list being a permanent struggle to implement anything by consensus (no lambdas or JS array notation because it wasn't easy to google, for example), and it really did look like a dead end. The internal source code of PHP was often a mess of macros everywhere, and the whole PHP6 unicode fiasco really did paint a grim picture of its future.
Facebook seems to have given it a bit of fresh air, implementing some pretty interesting stuff (Hindley-Milner with subclasses, for instance), and it really seems like the "feel" of programming in PHP has changed. I'm not going to say "Screw C++ and Haskell, _this_ is a serious language!", but on the other hand I feel I can say with a straight face to someone who is starting programming, "You could check this language out", without a guilty conscience that I'll be ruining their mind.
I'm unsure of PHP's future - if it'll be tied to Facebook (and thus Facebook's future, which I am equally unsure of), for example - but as of now, it seems to be a reasonable, if idiosyncratic, language.
So yeah, good talk :)
Being "tied" to Facebook is the best thing that can happen to PHP. I stopped taking PHP core devs seriously since the PHP6 fiasco. PHP is doomed with these guys, trust me, no matter how much effort is put into Doctrine, Laravele ,Symfony or other libs.
At some point , every big open source project team must make tough choices to make the project "future proof". Python team did it, Ruby is doing it,NodeJS will to be compliant with ES6 modules.
They did not.
The "PHP6 fiasco"? A major featured release was too much, and had to be scoped down. Since then most stuff has been released as 5.4, 5.5 etc.
Did it break anybody's code? No. Did it divided the community? No. Did it halted PHP development? No. At worst, it make some prematurely released PHP6 books obsolete. Big fucking deal.
Compared to Perl 6 (still MIA for actual production development) and Python 3 (only 10% adoption or less after 5 years for an update that doesn't even offer that much), I'll take the PHP6 fiasco anytime.
Python 6 did it badly, Ruby didn't do much, and NodeJS will have the ES6 modules "update" happen automatically by virtue of them being based on V8.
Not sure about PHP6, but previous versions did - in unnecessary ways. Like "deprecated" warnings you couldn't really turn off, "safe mode" which let administrators decide which functions developers needed,...
But all in all PHP is still... quite OK language. We've seen better and we've seen many worse. It has lots of weird features (I would call them bugs), but it is useable once you learn to live with them.
Oh, and after many years I still HATE that dollar sign in front of each variable. Just hate it. :)
PHP 5.4 broke code. In more ways than documented in the help (where a list of breaking changes exists, but is incomplete). For good codebases that adhere closely to how good PHP code should be written it's probably not much of a problem, but the ancient and horrible code base I had to coax into working with 5.4 had a few places that broke.
I love how often the same people that are those complaining about 5.4 breaking code, throwing deprecated messages etc, and on the other hand still wailing about the weird artifacts and inconsistent function naming.
http://php.net/manual/en/migration54.incompatible.php lists very few removed functions and no renames. One case I had (which isn't even mentioned on that page) is htmlspecialchars assuming UTF-8 instead of ISO-8859-1 if no encoding parameter is given. I'm not sure that falls into »We're removing weird artifacts from the language«.
No those changes would be reserved for major releases. But the removal of the likes of safe_mode, magic quotes and register_globals have been long overdue. The only reason why they have been in there for so long is because it would break code. Backwards compatibility has always been this cute silly idiom of PHP. Which has its good parts and bad parts. I'm glad that it has gotten more mature in that sense. 5.3+ have been a statement of such.
I agree that encoding in PHP has been a consistent PITA, and making this move and not mentioning it, is not really helping. But again I must say, It's actually a really great thing, and again long overdue.
I think Python 3 offers more than you think it does. I'm not going to try to convince you, but having used it steadily for the last month or so, I really think it does.
It does offer some things, but does it offer a "divide the community, halt the old version and still go nowhere much adoption-wise after 5 whole years" worth of things?
I started using Python when "Python 3000" (as 3 was called then) was just a pipe dream for the distant future. For all the trouble with the migration, it doesn't really offer much groundbreaking things.
Removal of GIL, a JIT, a few times or an order of magnitude faster, an integrated new async model etc would have been great. UTF-8 and a few tricks that could just as easily be added in 2.8? Not so much.
The GIL and a JIT are low level implementation issues though, right? E.g., Python 3 can be implemented in PyPy (and it looks like that's in the works).
Most of the Python 3 changes are design and feature related, and it's a lot more than just "UTF-8 and a few tricks".
For example, Python 3.4 is adding asyncio (http://www.python.org/dev/peps/pep-3156/).
And if you look at the _What's New In Python 3.x pages_, there's a ton of new stuff.
edit: forgot a word
I am starting to hope for a PyPy 2.8 or a PyPy 3000 that removes the GIL. Will have to wait and see how STM plays out.
I thought the perl 6 implementation was actually complete.
When an implementation is complete in the forest, and nobody cares and even fewer use it for production code, is it complete?
It isn't.
Ouch. Sorry to hear it. But good to hear you weigh in.
I'd agree with you, except for Python... that whole Python 3 mess just seems to have been a terribly turn of events when stared at from Ruby-land.
Yes. Waiting for a major release number to break everything is a terrible design strategy.
I couldn't agree more. The PHP internals group struggles still occur to this day as new ideas and fresh thinking run up against the old guard and more often than not are discarded.
I don't necessarily blame the "old guard" - they've been around a long time and they've seen a lot of failed ideas - and it's been them who dealt with the cleanup and had to maintain those broken features long past the founders of those features had moved on.
This isn't a bad thing: PHP is rooted in many businesses both small and enterprise: it will be around for a long time. Projects like HHVM are going to ensure that.
However, I no longer think that PHP is going to "turn it around" and will ever be a model of innovation. It lost it's opportunity to do that.
I went university, learned and used C for years, then Java in final years, then .NET on first job
Over a decade later I almost exclusively use PHP, and it has put plenty of bread and wine on the table :) over the years.
It just gets the job done!
The internal source code of PHP was often a mess of macros everywhere
My understanding, from people here that seemed to know what they are talking about, is that generally macros are how these languages are implemented when done in C, for various reasons. So much so in fact, that you are really writing a DSL layered over C. I doubt Python, Ruby or Perl are any different (actually I know Perl relies heavily on macros in the source for its interpreter).
Edit: s/Rudy/Ruby/. duh.
Lua is proper C code, and readable too. Macros are not necessary.
Lua has a much smaller codebase and is simpler than PHP, so I'm not sure the comparison is apt.
The Ruby source code is also a DSL build on top of a bunch of macros.
I'm unsure of PHP's future - if it'll be tied to Facebook
I don't think it'll be tied to Facebook at all. What the PHP community has is a huge ecosystem of programmers (good ones and bad ones), frameworks, libraries, etc. That bodes well for PHP's future.