Another Facebook contribution to PHP

#todo finish editing

It's possible that nothing fires up a fierce debate among computing programming geeks more than a discussion of the pros and cons of the PHP programming language.

PHP may be the favorite language to hate, yet it continues to be one of the most used web programming languages. And PHP continues to power some of the most heavily-trafficked sites. Plenty of job openings exist for PHP programmers.

https://code.facebook.com/posts/264544830379293/hack-a-new-programming-language-for-hhvm/

https://news.ycombinator.com/item?id=7436401

> What major accomplishments in computing that have been built atop crumbling foundations can claim anything even close to the scale of success of these examples?

Wikipedia and Facebook?

Another HN comment:

> I am baffled as to why you'd build your castle atop a crumbling foundation.
> I have wondered why FB didn't use a proper language with proper typing to begin with.

I would suggest watching Keith Adams's talk, "Taking PHP Seriously": http://www.infoq.com/presentations/php-history

He goes through why Facebook uses PHP and decided to build upon it to create Hack. I highly recommend watching the whole thing, but the main three things he points to are:

1. Frictionless programmer workflow with a short feedback cycle
2. All PHP requests start out with the same consistent state by default
3. Rigid style of concurrency

HN comment:

The HN crowd seems to dislike (or despise perhaps?) PHP, but it's really not that bad. Yes it has a lot of warts, but it has a lot of things that make it nice for web development.

a) try your new code by saving in your editor, and hitting reload in your web browser.

b) it's very approachable. People who only know HTML and CSS can be expected to do a little bit of PHP work to integrate their changes. If you setup the right network mounts, they just need to edit files and reload (see a)

c) it's not super high overhead at runtime. If you're not using a framework, and you don't build up a crazy object hierarchy, it's not too hard to get your page out with about 10 ms of overhead beyond data fetching. For very simple webservices (fetch data, possibly from multiple sources, and do a little formatting for the consumer), I was able to get the overhead down to 2ms. You can certainly do better with other languages, but you can usually get better throughput improvement by working on getting data quickly. Btw, all the frameworks are terrible; many of them add 100 ms to the page just for the privilege of loading the includes; PHP is a framework for web programming thank you very much.

d) cleanup; you don't have to worry about it. If you don't do anything weird (c extensions, with non-preferred malloc), at the end of the request, everything is thrown away.

That said, there are plenty of things PHP isn't good at: I wouldn't run a long running process in PHP; and multithreaded PHP sounds like a bad idea.

Every computer language will have warts and be disliked by someone.

If a programmer can solve a problem or make someone's life easier, then the language choice should be irrelevant.

If every programmer or team or company can see into the future, then they may make different decisions at the start of a project.

Make it work, make it work correctly, and then make it work fast.

Maintenance should not be an afterthought, but if the project becomes design by committee, then the project may never see an alpha release.

This month, March 2014, marks a 15-year anniversary for one of my programming projects.

One of my former employers is still using a program that I wrote in three weeks in March 1999.

It's called Merge N Mail, something like that. We called MnM for short. It merges data into a template and hands it off to a mail server.

I wrote the command-line Java piece in one week. This was the guts or brains of the MnM app. It did all the work. But I did not expect the end users, the Interactive Department, to log into a Linux box, edit in Vi, submit to batch, etc. from the command prompt.

So I wrote a web-based interface wrapper. I wrote this CGI app in the C language. Obviously an odd language choice for Common Gateway Interface programming, but I learned Perl and TCL later.

It took me two weeks to create the C-CGI web app. This allowed the Interactive Department to manage the MnM app entirely through a browser from any PC. I think the only non-browser option may have been an FTP action, but maybe MnM handled that too. I don't remember.

The web interface managed the control file, submitting to batch, monitoring progress, and many other actions. I wish that I had a printed screen shot of the home page of actions.

Several years ago, I was surprised to learn that my old company still used the program. And now in 2014, it's still in progress, cranking out e-mail.

The idea for the app either originated in one of our weekly Interactive meetings that involved multiple departments, or it was one of those impromptu ideas that popped up when I ran into BK in the hallway.

In the mid to late 1990s, we moved fast with getting more work on the Web. In late 1996, I started to learn web programming on my own. The company had a "webmaster," but I was one of the few who could create web apps, and I worked in the Systems Department and not Programming.

In the late 1990s, many of our programmers were involved with Y2K changes with legacy and critical Cobol and Fortran programs.

New programmes hired in 1999 focused on web development. After the year 2000, then the other programmers learned more web and desktop programming.

It's possible that MnM came from a hallway meeting with BK where he said something like, "What about this?" It was hard to say no to BK. I'm sure I probably said, "No problem." and then I over-promised.

Since I was Systems, I worked on MnM after hours. I don't think this was an assigned project. Maybe I was permitted some time during normal hours to build it. I don't remember. But I remember working on it in the evenings or even early in the morning.

The design or development process was simply build it as fast as possible because it was needed long ago. In the 1990s, we didn't have time for a long, drawn-out planning process. I think that's how I got the nickname Cowboy Coder.

I just know that within a month, I went from nothing to a working program that the Interactive Department could use. I had no help with development.

MnM used Sendmail, which was too slow. Someone found the Lyris e-mail system, a commercial app. We bought it. It's multithreaded capabilities enabled it to push more e-mail through our Internet pipe.

But I had to change the Java app to take advantage of Lyris. I made the Java app multithreaded. These changes dramatically increased the amount of e-mail that we sent out to panelists who agreed to participate in our market research studies for our clients.

Later, I enabled the Java app to pull panelist/sample data from an Oracle database instead of only from flat, ASCII files.

The multithreaded and Oracle changes were the big mods that I remember occurring after March 1999. I'm sure that I made some other changes, especially to the web interface part.

I would have never guessed that a three-week project that was probably built in under 60 hours would still be grinding away 15 years later.

I'm guessing that I spent time on the weekends building the app. Whenever I could find some time. My first priority was still Sys-Admin duties for the various Nix boxes (Linux, SCO, Solaris) and the Vax/VMS machines. Writing Java and C was secondary.

HN comment:

> Which mainstream language would you have chosen in 2003 that you think would have had similar success?

Bingo. In 2003 PHP was the best option to get from zero to hero.

HN comment:

As much as I'm not a PHP fan these days, you are completely correct. In 2003, you had CFM (which MySpace actually used at first), Java (and probably some overly complex framework like Jakarta Struts to go with it), CGI, or the new ASP.net. For a college student to do a quick HTML doc with some code interspersed here and there, PHP sounds like the ONLY viable option that didn't have you spending money on licensing, or setting up some huge infrastructure.

I used PHP/MySQL too as it was just dead simple for most things.

HN comment:

Any. Really, any. Facebook is throwing a lot of engineering effort into fixing things that now matter to them, but didn't when they started (and were small).

They could have picked Perl CGI's and it'd still have happened (perhaps Perl 6 would be a success these days).

I don't think PHP has played any role in bringing FB to the size it is today (programming language does not translate to number of users signing up). So yes, any mainstream language available in 2003 would do it.

multiple HN comments:

I believe Python might have worked. It's grown well as a web development language since then by itself. It may have forced several rewrites before WSGI came about. It is a relatively easy language to learn, to hire for, and has few massive warts. (Ruby is roughly in this category too, in my opinion.)

I believe Perl probably would not have worked. It hasn't grown much as a web development language since then (although it has some great web frameworks). The language itself has languished in both development and community growth, and it fairly esoteric and certainly harder to learn than Python and PHP, and would have been harder to hire for. It seems unlikely that pre-2010 Facebook to meaningfully have changed the trajectory of the language (ie, Perl 6 being a success).

I don't think Java, C++ (or C), Cold Fusion, ASP, Haskell, Ocaml, and many other languages would have worked, for a bunch of reasons. Harder to hire for, harder to iterate with, more costly in terms of infrastructure, harder to teach/learn, and so forth.
PHP isn't a totally insignificant part of Facebook being as successful as it has been. A good-enough language choice was necessary, at least, and PHP it seems was a good-enough choice.
reply

thinkpad20 1 hour ago | link

Do you think perl would have been much better? Either way, the point that he was making was that there were pretty slim pickings back then. Certainly the dominant languages/frameworks of WD these days (python, ruby, node) didn't exist. Or by another token, the only dominant one that was also strong back then is PHP, the one they chose.
reply

elwell 1 hour ago | link

I disagree. Perl would have likely crippled them, due primarily to the lack of Perl engineers.
reply

Lack of Perl engineers in 2003-2004? I doubt it.

Perl dominated web development in the 1990s. PHP then took over, but plenty of experienced Perl programmers would have existed in 2003-2004.

Perl would have been better than Python in 2003-2004 because of Perl's large group of modules that existed even then at CPAN.

PHP like Active Server Pages and Cold Fusion allowed programmers to combine HTML with their programming code. That might be viewed as a No-No today, but 10 to 15 years ago, or even longer in the case of Cold Fusion, that type of programming led to fast development.

In 2001-2002, I did ASP programming for Windows IIS by using PerlScript instead of the Basic-type of language. I could combine Perl within HTML pages. I used Perl ASP programming to create modules or plugins for the Plumtree Portal Server.

Too many people use the programming methods of 2014 when discussing what was done 10 to 15 years ago, especially regarding web development.

Elsewhere:

http://www.marco.org/2014/03/21/hack

http://www.marco.org/2014/03/23/owning-a-programming-language

#programming - #php - #history - #blog_jr