Eeeek. That code would've been terrible practice in 2000 when I first started writing Perl :(
The Mysql module was deprecated in favour of the unified DBI interface, cgi-lib.pl was a perl4 library that was replaced by a module called CGI (shipped with perl5 itself from 5.4+).
Calling functions with & is a perl4-ism and almost always the wrong thing to do in perl5, and C-style for is silly in most cases in Perl - for example; the loops in there would likely be better redone as foreach loops, or possibly just a grep.
And, of course, YAY not using placeholders in the SQL.
And that's exactly what I didn't mean. It's a sample of one, and offers no information whatsoever about how much code quality can contribute to success, except that rubbish code doesn't totally preclude the hope that a product might be successful.
Let's say things had turned out a little differently, and someone had used one of those SQL injections to irreversibly erase all of early Facebook's data. We'd probably never have heard of it again.
Code quality is a good thing - like scalability, and security. Ultimately, you might succeed without it. But it'll probably be easier if you do.
My problem with this code is not aesthetics. This logic is too deeply nested, by the time you hit the last conditional there is way too much going on[1].
Perl makes it especially nice to flatten logic due to RHS conditionals, eg "x++ if y;". Here is my two minute flattening job[2], it prob has syntactic errors but you get the gist.
Seriously though, I use maps and greps a lot now, often chained to transform a data structure from one type to another. I'm annoyed when I have to drop to a for(each) loop.
Looking at that code they probably didn't actually have a professional Perl developer on staff. The code isn't terrible, but certainly a far cry from good. It doesn't help that back in 2005 all the books for learning Perl were still teaching a code style from the early 90s.
Edit: I revise the terrible bit, it's a little terrible, as it has SQL injections.
It's full of SQL injections, to start. (I really like using the subdomain name from the HTTP_HOST environment variable in a SQL query. That's a new attack vector I hadn't considered.)
It's full of silly inefficiencies, such as iterating over an array and preparing distinct but trivially parametric queries for each element.
It has a strange mix of effectively package global lexical variables and block-scoped lexical variables, which means that running this in any sort of persistent service model would be very buggy.
It looks like it ignores parts of the CGI standard.
It looks like it takes database connection information from cookies (except it never uses that code).
The `find_node` function looks like it's using the wrong data structure entirely, but that's okay, because that pattern's repeated a few times. That's doubly suspect, because this seems like the sort of thing a WHERE clause in the SQL query could handle (though to be fair, it might require a subquery, and the version of Mysql Facebook had deployed in 2005 might not have supported those very well; I don't remember).
What's funny is the kind of interview questions they ask at Facebook. They act is if they are rocket scientists creating major breakthrough algorithms.
It's surprising to me how "old school" this code is for 2005. It looks similar to Perl code from the late 90's when CGI scripts and form mailers were all the rage.
Maybe some sort of strange hash function? It looks like it spreads the values fairly evenly from 0-23, while keeping nearby numbers separate. Here's what it looks like from 0-5:
It's a really poor hash function. The only possible values are: 0,3,6,10,13,17,19. You can quickly see that only 7 distinct values are possible because of the initial $number % 7.
I have to agree. I still have Facebook (as it's one of the ways I can communicate with people who I don't have numbers for) but if I scroll down it in their mobile application a LOT of the content is adverts. Another big percentage is terrible videos/pictures from 9gag-esque accounts that people have liked.
After you get passed all of that you are left with very little information that actually matters (status updates/pictures etc.) It's a combination of a problem with both the userbase and the platform.
The Mysql module was deprecated in favour of the unified DBI interface, cgi-lib.pl was a perl4 library that was replaced by a module called CGI (shipped with perl5 itself from 5.4+).
Calling functions with & is a perl4-ism and almost always the wrong thing to do in perl5, and C-style for is silly in most cases in Perl - for example; the loops in there would likely be better redone as foreach loops, or possibly just a grep.
And, of course, YAY not using placeholders in the SQL.
sigh