Facebook PHP Source Code from August 2007 • Hacker News Board

Re: Facebook PHP Source Code from August 2007

#31

Post by lelf » Sat, Oct 12, 2013, 1:22 PM UTC

Blahah wrote: post #25

logicallee wrote: post #22

Earlier quoted context omitted.

all of computer science was created by an undocumented spaghetti code that evolved over a few hundred million years: DNA is 700 MB or so of uncompressed undocumented base pairs. We seem to be doing all right.

Yeah, and because the code is completely undocumented and obfuscated it's taking us biologists a few hundred thousand man-years to figure out what the hell it means. The only time spaghetti is a good thing is when it's covered in sauce.

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

// TODO:

Re: Facebook PHP Source Code from August 2007

#32

Post by TazeTSchnitzel » Sat, Oct 12, 2013, 1:22 PM UTC

alecsmart1 wrote: post #21

This looks weird in search.php (line 89): if($user 0 && !is_unregistered($user)) { return $user; }

I'd hazard a guess that should be:

  $user  0

Which, of course, would not display if someone had originally pasted this code straight into an HTML page without escaping it.

EDIT: Looks like it would show up. I wonder, then, if the s has been stripped. Some poorly written websites do that.

Re: Facebook PHP Source Code from August 2007

#33

Post by nwh » Sat, Oct 12, 2013, 1:22 PM UTC

Kiro wrote: post #14

iand wrote: post #12

Earlier quoted context omitted.

A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)

It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?

I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?

Re: Facebook PHP Source Code from August 2007

#34

Post by m0th87 » Sat, Oct 12, 2013, 1:25 PM UTC

Does anyone else remember the friend graph visualization feature facebook used to have? It was an oddity, both because it seemed like a strange but useful feature, but also because it was a perl script.

One time I clicked it and got the source code to the file instead of the graph. It's somewhere on one of my hard drives, but it seems wrong to leak, especially since it has database credentials hard-coded into it.

Re: Facebook PHP Source Code from August 2007

#35

Post by camus » Sat, Oct 12, 2013, 1:25 PM UTC

EGreg wrote: post #23

This is why I was saying evented webserver code is better. Look at how much I/O is happening one after the other. The latency could be greatly reduced by doing things in paralel and waiting until all the promises resolve.

requiring scripts in PHP in not "IO". There is not much IO happening in these script.

Re: Facebook PHP Source Code from August 2007

#36

Post by moconnor » Sat, Oct 12, 2013, 1:26 PM UTC

Kiro wrote: post #13

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.

In my experience code become unitelligable not because it's fine tuned and advanced but because it's messy and rushed.

Or over-generalized with the logic split up and hidden in the interactions between a dozen (sub)classes.

Re: Facebook PHP Source Code from August 2007

#37

Post by nilliams » Sat, Oct 12, 2013, 1:26 PM UTC

sergiotapia wrote: post #19

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.

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.

That approach only works in the short-term though. When you've got an already large code-base you just 'made work' but with no tests (code-coverage), how do you 'make it faster' or 'make it readable' without breaking things? Especially as you are likely under pressure to be adding new features.

Re: Facebook PHP Source Code from August 2007

#38

Post by [deleted] » Sat, Oct 12, 2013, 1:28 PM UTC

Blahah wrote: post #25

logicallee wrote: post #22

Earlier quoted context omitted.

all of computer science was created by an undocumented spaghetti code that evolved over a few hundred million years: DNA is 700 MB or so of uncompressed undocumented base pairs. We seem to be doing all right.

Yeah, and because the code is completely undocumented and obfuscated it's taking us biologists a few hundred thousand man-years to figure out what the hell it means. The only time spaghetti is a good thing is when it's covered in sauce.

[deleted]

Re: Facebook PHP Source Code from August 2007

#39

Post by moconnor » Sat, Oct 12, 2013, 1:28 PM UTC

nwh wrote: post #28

Kiro wrote: post #13

Earlier quoted context omitted.

In my experience code become unitelligable not because it's fine tuned and advanced but because it's messy and rushed.

Doesn't quite hold true once you get done to hand written and optimised binaries though. There's no way of making assembly easily readable to everyone, no matter how relaxed the developer.

Hand-written assembly can be just as readable as any other language. See https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/m... for a good example!

Re: Facebook PHP Source Code from August 2007

#40

Post by Keyframe » Sat, Oct 12, 2013, 1:29 PM UTC

sergiotapia wrote: post #19

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.

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.

Shipped code > Well architected incomplete features.

Actually there is more wisdom hidden in this dogma. I'd argue you can't really well architect anything without iterating running code. So, it's more of a cycle. At least in my case. Proto, use, profile, refactor, proto new stuff into it, use, profile, refactor...