8 ms·

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".

by flebron 13y ago

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 :)

camus2 13y ago
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.
- debaserab2 13y ago
  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.
- tibbon 13y ago
  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.
  - rev_null 13y ago
    Yes. Waiting for a major release number to break everything is a terrible design strategy.
- coldtea 13y ago
  >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.
  - codygman 13y ago
    I thought the perl 6 implementation was actually complete.
    - coldtea 13y ago
      When an implementation is complete in the forest, and nobody cares and even fewer use it for production code, is it complete?
    - chromatic 13y ago
      It isn't.
      - dogweather 13y ago
        Ouch. Sorry to hear it. But good to hear you weigh in.
  - wylee 13y ago
    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.
kbenson 13y ago
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.
- iagooar 13y ago
  The Ruby source code is also a DSL build on top of a bunch of macros.
- justincormack 13y ago
  Lua is proper C code, and readable too. Macros are not necessary.
  - seabee 13y ago
    Lua has a much smaller codebase and is simpler than PHP, so I'm not sure the comparison is apt.
dcc1 13y ago
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!
workhere-io 13y ago
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.

by flebron 13y ago

camus2 13y ago

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.

debaserab2 13y ago
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.
tibbon 13y ago
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.
- rev_null 13y ago
  Yes. Waiting for a major release number to break everything is a terrible design strategy.
coldtea 13y ago
>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.
- codygman 13y ago
  I thought the perl 6 implementation was actually complete.
  - coldtea 13y ago
    When an implementation is complete in the forest, and nobody cares and even fewer use it for production code, is it complete?
  - chromatic 13y ago
    It isn't.
    - dogweather 13y ago
      Ouch. Sorry to hear it. But good to hear you weigh in.
- wylee 13y ago
  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.

kbenson 13y ago

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.

iagooar 13y ago
The Ruby source code is also a DSL build on top of a bunch of macros.
justincormack 13y ago
Lua is proper C code, and readable too. Macros are not necessary.
- seabee 13y ago
  Lua has a much smaller codebase and is simpler than PHP, so I'm not sure the comparison is apt.

dcc1 13y ago

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!

workhere-io 13y ago

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.