Another Facebook contribution to PHP

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.

I just know that within a month,

#programming - #php