Are there any plans for a Hack -> PHP transpiler? Or is that impossible? It would be nice to develop on Hack, transpile back to vanilla PHP where we still have to use the PHP.net runtime (shared hosts, Google app engine, Engine Yard, etc)
Hack: a new programming language for HHVM
71–80 of 422 posts
Re: Hack: a new programming language for HHVM
#72I'm the manager of the team that developed Hack, and I'm sitting here with some of the language designers. Happy to answer your questions.
Why use public string $x = ''; instead of public $x:string = ''; It seems inconsistent to me, probably because I've used AS3/Haxe.
PHP is based on C. It's way more consistent with C, Java, C# , etc to do the former. So the real question is why
function foobar() : int { .. }
function int foobar() { .. }Re: Hack: a new programming language for HHVM
#73I'm the manager of the team that developed Hack, and I'm sitting here with some of the language designers. Happy to answer your questions.
Pretty star-studded cast you have on the core team, there.
What's your motivation, aside from modernizing Facebook's code base? What language niche does Hack serve which is not served by other languages? Why Facebook at all (aside from the rarity of finding a company to pay you to write a compiler :))?
Re: Hack: a new programming language for HHVM
#74I'm the manager of the team that developed Hack, and I'm sitting here with some of the language designers. Happy to answer your questions.
Why use public string $x = ''; instead of public $x:string = ''; It seems inconsistent to me, probably because I've used AS3/Haxe.
Its not just inconsistent with other languages, its consistent with their own language.
Property types are declared before the property name, while function return types are declared after (and with a colon).
Very strange.
Re: Hack: a new programming language for HHVM
#75It looks promising, I highly dislike writing PHP and this seems like it might ease the pain, but they could've gotten rid of the damn dollar sign in front of variables, how ugly is this? "return ($y) ==> { return $y + 1; }"
Re: Hack: a new programming language for HHVM
#76I 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 mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…
> 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
Re: Hack: a new programming language for HHVM
#77I'm the manager of the team that developed Hack, and I'm sitting here with some of the language designers. Happy to answer your questions.
Hi Bryan, How do you protect from type errors when a value crosses from the untyped to typed fragment? Do you use contracts?
Not Bryan, but I am an engineer who works on Hack :)
We don't (statically) protect against type errors when you cross from untyped into typed code. If you call an untyped function, we assume the programmer knows what they are doing -- just like PHP does. You might get a runtime exception if you are calling a method on null, for example.
This is actually a pretty important part of the conversion process. You don't have to convert all your code all at once. Typed code can be verified statically; untyped code is assumed to work just as before.
Parameter and return type annotations are enforced at runtime by HHVM (just like you can add a class type annotations to a parameter in PHP). This will protect against some inconsistencies -- again, just as if you weren't using Hack.
Re: Hack: a new programming language for HHVM
#78PhpStorm support issue
http://youtrack.jetbrains.com/issue/WI-21737
Re: Hack: a new programming language for HHVM
#79Facebook is always pushing PHP to new places. Would it be too broad to say PHP is the worst thing that ever happened to Facebook's engineering but Facebook's engineering is the best thing that ever happened to PHP?
I'd rephrase the question to be "Would Facebook be Facebook without PHP?"
I don't see why not. It's possible to have done it any any mainstream language.