[kmavm]

All engineers, those who work on HHVM like me included, spend their lives in a run-debug cycle trying to "make this darned thing work," whether "this darned thing" is a language runtime or the new photo uploader. The tighter you can make that loop, the more productive the engineer is, because she has less time to keep all the items she's mentally juggling pinned in volatile short-term memory.

[lansing]

Sure, we all go through life via a form of trial and error, learning from our mistakes.

Personally, I think the fewer times you have to go around that wheel, the better.

I don't want to diminish the technical excellence of the achievements touted, and as a coder of primarily compiled languages, I would welcome any such improvements in the compilers I use.

However, my larger point stands-- which is that if a few seconds shaved on the run-debug loop is really a big deal for your total productivity, it means you're looping too much.

Trial and error is a fine way to learn a language, or to debug truly mysterious issues, such as those that exist outside of the abstraction layer you're working in. But in my opinion it's a poor way to work. It means that you don't understand the code you're writing.

[jhferris3]

Other fb employee here.

One of the other annoyances we had (I think its addressed in the note?) is that until now the interpreter (on our dev machines) and the compiler (hphpc in production) occasionally differ in small, occasionally painful ways. Unifying our development and production environments will eliminate another potential source of bugs.

Also: Tight loops don't imply a lack of understanding. Often times when you're trying to get the CSS on a page just right (across all browsers) it requires quick iteration, even if you do understand CSS well.

[campnic]

I disagree. My anecdotal evidence as a person who prefers to meditate on code is that many times the person who does quick iterations even beats people that understand the language. A deep understanding of the language, in fact, can sometimes be a hinderance to getting things done. I realize thats anecdotal, but if you have an organization (say 1000 people or whatever facebook has) and they are doing these iterations all day and you can shave 5 minutes more out of each persons day, that 5000 mins per day :)

[sokoloff]

At many companies, those 5000 minutes "saved" will be later squandered on Facebook. :)

[z0r]

As much as I enjoy developing in dynamic, interpreted languages with a repl, I think this is a perfectly valid perspective. If a few seconds savings per compile is really multiplying out to a significant chunk of time, maybe it wouldn't hurt to take a more meditative approach to the code.