Facebook PHP Source Code from August 2007 • Hacker News Board

Re: Facebook PHP Source Code from August 2007

#81

Post by jeff_facebook » Sat, Oct 12, 2013, 5:30 PM UTC

TelmoMenezes wrote: post #18

a1a wrote: post #11

I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.

This piece of code is doing something very simple and sequential in nature: putting together the (then) Facebook front page. I'm not sure I agree it's spaghetti. Are there any complex relationships that become hard to follow because of an inadequate level of abstraction? It doesn't look that way to me. Many programming methodologies are proposed these days, but the entire "field" smells of pseudo-science. Unless stud…

I agree about programming methodologies being pseudo-science, so I'll defer to something much simpler and less cynical -- the vague wisdoms of Unix Philosophy:

"Rule of Representation: Fold knowledge into data so program logic can be stupid and robust."

This code violates this rule horribly and is quite deserving of the label "spaghetti code".

Re: Facebook PHP Source Code from August 2007

#82

Post by Killswitch » Sat, Oct 12, 2013, 5:35 PM UTC

nilved wrote: post #48

troels wrote: post #41

Earlier quoted context omitted.

I'm pleasantly surprised. It's actually fairly well structured in my opinion.

Are you a PHP programmer?

I'm a PHP programmer, but I haven't done much in terms of procedural code in a long time, I'm more or less OOP all the way using modern libs like Composer... This code although not bad per say, does make me twitch because of how it is.

Re: Facebook PHP Source Code from August 2007

#83

Post by Killswitch » Sat, Oct 12, 2013, 5:36 PM UTC

kaolinite wrote: post #51

sergiotapia wrote: post #19

Earlier quoted context omitted.

My mantra: Shipped code > Well architected incomplete features. Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.

You might ship faster but this can easily lead to poorly written, hard to maintain and insecure spaghetti code. In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.

Bingo. Do it right the first time. I'd rather take an extra hour on a bit of code the first time then go back and spend 2 hours refactoring it later on.

Re: Facebook PHP Source Code from August 2007

#84

Post by wmil » Sat, Oct 12, 2013, 5:36 PM UTC

javis wrote: post #8

When I see code like this, I'm always amazed that I can actually read it and (kinda) understand what it's doing. I always expect code like Facebook's to be so finely tuned and advanced that it'd be completely uninteligable to those outside the company and not an expert in the language.

You shouldn't be. Ultra minimalist code using every language feature tends to be difficult to understand and maintain. It's usually written by young coders eager to show how clever they are.

Re: Facebook PHP Source Code from August 2007

#85

Post by Killswitch » Sat, Oct 12, 2013, 5:40 PM UTC

asdasf wrote: post #62

Kiro wrote: post #58

Earlier quoted context omitted.

It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.

It is certainly not still there given that facebook doesn't run PHP any more. They wrote a compiler to translate a subset of PHP to C++, which they then compiled into a massive executable. The compiler is open source and called hiphop, and it does not implement the PHP memory limits.

Facebook still uses PHP bro...

Re: Facebook PHP Source Code from August 2007

#86

Post by vezzy-fnord » Sat, Oct 12, 2013, 5:43 PM UTC

lifeformed wrote: post #60

How did someone "expose the PHP source code"? Did they actually find a way to make the code show up client-side, or was it just someone who managed to get access to the backend stuff? The way it's worded makes it sound like the former, but that seems unlikely...

Another possibility is some quirk in the file permissions, .htaccess or some other configuration file, which could lead to vulnerabilities like HTTP verb tampering.

It may have been more subtle, but of a similar nature.

Re: Facebook PHP Source Code from August 2007

#87

Post by PhineasRex » Sat, Oct 12, 2013, 5:55 PM UTC

Blahah wrote: post #54

lelf wrote: post #31

Earlier quoted context omitted.

It'd be somewhat weird to stumble across comments in that code. // TODO:

I quite often see words (or nearly-words) in protein sequences. The best I've seen are (when reading DNA translated in all frames): EVQLVE LAMARCK ELVISISGAY SALTYSATAN

Is SALTYSATAN a metal band or a sex act?

Re: Facebook PHP Source Code from August 2007

#88

Post by ErikAugust » Sat, Oct 12, 2013, 6:02 PM UTC

Pre-PHP 5.3 -> Right off the bat: no namespace support, no closures, no surprises there

I am a bit surprised about the lack of OO though...

Re: Facebook PHP Source Code from August 2007

#89

Post by g8oz » Sat, Oct 12, 2013, 6:03 PM UTC

kaolinite wrote: post #51

sergiotapia wrote: post #19

Earlier quoted context omitted.

My mantra: Shipped code > Well architected incomplete features. Your user does not care in the slightest if you're using a design pattern, or if you are using dependancy injection, or if there is 100% code coverage. Just make it work! Then make it faster! Then make it more readable! In that order.

You might ship faster but this can easily lead to poorly written, hard to maintain and insecure spaghetti code. In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.

Ship too late and none of it will matter.

Re: Facebook PHP Source Code from August 2007

#90

Post by kaolinite » Sat, Oct 12, 2013, 6:10 PM UTC

g8oz wrote: post #89

kaolinite wrote: post #51

Earlier quoted context omitted.

You might ship faster but this can easily lead to poorly written, hard to maintain and insecure spaghetti code. In fact, rushing to ship / meet deadlines is probably responsible for most of the vulnerabilities in software.

Ship too late and none of it will matter.

I guess shipping is more important to you than the possibility of losing user details (or worse). Christ, I hope I never give my details to a company you found.

Shipping quickly is important but it's also important to write quality code. Small bugs that can easily be fixed are fine but security problems or bugs related to payments, for example, are not.