3 ms·

I'm always astounded at just how much effort Facebook puts into trying to keep PHP usable compared to switching to really almost anything else.

by fournm 13y ago

bbillings 13y ago
http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html Is a pretty good explanation of why we don't rewrite the whole site. A rewrite would involve every product dev stopping what they are doing and probably spending at least 18 months reimplementing their product in a different language. During that time all forward progress on products would be halted. I am absolutely certain it would be an unmitigated disaster for the company to try to rewrite the site in another language. Instead we have a small team of people making PHP really nice work work in. HipHop gives us full control over the language and lets us add in any constructs we like. We make sure stock PHP runs, but also the additions we need to the language can be added as well. I don't really understand devs who think reimplementing in another language is easy or the right thing to do. It's almost always the wrong thing from my experience and always lot harder and takes a lot longer than expected.
slinkyavenger 13y ago
I'm sure it has to do with a perception of 'sunk cost.' Everyone there knows PHP. They've developed tons of PHP libraries. They've set up their servers to run PHP. They have probably also ported some of the more complex code to PHP extensions. They probably should've moved to a different language a while back, but those kinds of changes require a lot of effort that don't seem economically expedient at the time.
twic 13y ago
Porting the site would be a pretty crazy plan. Substantially crazier than writing your own VM for PHP, which is pretty WTF already. However, i am really surprised that there doesn't seem to be a plan to gradually migrate off PHP and on to something decent. This would involve creating a viable new platform of some sort (Sinatra on JRuby, Scalatra, Node.js, whatever's cool now), working out how to do the interoperation with PHP that was necessary (decoding PHP cookies or whatever), building or porting some minimal feature onto it, getting it into production, and getting it stable. Further features could then be developed on it or ported onto it one by one. Establishing this platform should be much less effort than writing a high-performance PHP VM. There would remain effort in actually porting bits of the site, but that can be applied incrementally. New features could be developed on the new platform at no extra cost. The new platform would probably be based on the JVM (unless it's Node), and i would expect it to be faster than HHVM. I would confidently expect it to require less maintenance. Given that the old platform is PHP, i would also expect it to be more secure, and to afford better quality code. My company (a tiny operation in financial services that you've never heard of) is currently going through something a bit like this. We have a monolithic legacy app written in Java on a homebrew platform made of servlets, XSLT, and cheap gin. All our substantial new features are being developed in Scala on the Play framework. Whilst i'm not certain Scala/Play was the right choice, the plan is working: we are shipping, we are moving faster when developing the new features, and we are crying less.
- fournm 13y ago
  This is more what surprises me--the lack of some slow, calculated migration off of PHP and to something like Node, almost anything JVM based, etc (since yeah, a full rewrite of any codebase is almost always crazy). I'm in a similar legacy Java boat at my own work and doing quite a bit of the "okay, what small piece can we handle" at a time style replacement.

I'm always astounded at just how much effort Facebook puts into trying to keep PHP usable compared to switching to really almost anything else.

by fournm 13y ago

I'm always astounded at just how much effort Facebook puts into trying to keep PHP usable compared to switching to really almost anything else.

bbillings 13y ago

http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html Is a pretty good explanation of why we don't rewrite the whole site. A rewrite would involve every product dev stopping what they are doing and probably spending at least 18 months reimplementing their product in a different language. During that time all forward progress on products would be halted. I am absolutely certain it would be an unmitigated disaster for the company to try to rewrite the site in another language. Instead we have a small team of people making PHP really nice work work in. HipHop gives us full control over the language and lets us add in any constructs we like. We make sure stock PHP runs, but also the additions we need to the language can be added as well. I don't really understand devs who think reimplementing in another language is easy or the right thing to do. It's almost always the wrong thing from my experience and always lot harder and takes a lot longer than expected.

slinkyavenger 13y ago

I'm sure it has to do with a perception of 'sunk cost.' Everyone there knows PHP. They've developed tons of PHP libraries. They've set up their servers to run PHP. They have probably also ported some of the more complex code to PHP extensions. They probably should've moved to a different language a while back, but those kinds of changes require a lot of effort that don't seem economically expedient at the time.

twic 13y ago

Porting the site would be a pretty crazy plan. Substantially crazier than writing your own VM for PHP, which is pretty WTF already. However, i am really surprised that there doesn't seem to be a plan to gradually migrate off PHP and on to something decent. This would involve creating a viable new platform of some sort (Sinatra on JRuby, Scalatra, Node.js, whatever's cool now), working out how to do the interoperation with PHP that was necessary (decoding PHP cookies or whatever), building or porting some minimal feature onto it, getting it into production, and getting it stable. Further features could then be developed on it or ported onto it one by one. Establishing this platform should be much less effort than writing a high-performance PHP VM. There would remain effort in actually porting bits of the site, but that can be applied incrementally. New features could be developed on the new platform at no extra cost. The new platform would probably be based on the JVM (unless it's Node), and i would expect it to be faster than HHVM. I would confidently expect it to require less maintenance. Given that the old platform is PHP, i would also expect it to be more secure, and to afford better quality code. My company (a tiny operation in financial services that you've never heard of) is currently going through something a bit like this. We have a monolithic legacy app written in Java on a homebrew platform made of servlets, XSLT, and cheap gin. All our substantial new features are being developed in Scala on the Play framework. Whilst i'm not certain Scala/Play was the right choice, the plan is working: we are shipping, we are moving faster when developing the new features, and we are crying less.

fournm 13y ago
This is more what surprises me--the lack of some slow, calculated migration off of PHP and to something like Node, almost anything JVM based, etc (since yeah, a full rewrite of any codebase is almost always crazy). I'm in a similar legacy Java boat at my own work and doing quite a bit of the "okay, what small piece can we handle" at a time style replacement.