3 ms·
What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php http://docs.hhvm.com/manual/en/hack.unsuppo
by nnq 13y ago
What worries me is the large list of 'unsupported PHP features': http://docs.hhvm.com/manual/en/hack.unsupported.php http://docs.hhvm.com/manual/en/hack.unsupported.php .
I know they can be considered bad practice, but in practice you use at at least a couple of them at least once in every project! And you use it because the alternative would be even uglier. (Also, what's the point in having a language with a separate namespace for functions and variables - Perl and Common Lisp being the only other ones I know of - if you can't at least have fun with variable variables and using a string directly as a function :) )
...also, they've "downgraded" PHP's closures mechanism. I mean, with:
return function foo($a, $b) use ($outer1, $outer2) { ... }
...PHP managed to do things better then all other dynamic languages - finally a way of being explicit about what variables from the outer scope you drag into a closure! The Hack guys totally missed the point - they've made everything stricter, but they relaxed this constraint and reverted one of the few good ideas in PHP.
Their VM may be awesome, but their language is horrid - they take away the "fun" features of PHP but don't fix any of the bad language design issues. It's like throwing away the baby and keeping the bath water - yeah, the water will keep you alive for a few more days in the desset, but the baby can actually be fun to play with.
- stephenr 13y agoThe list of "unsupported" features is attrocious but not suprising. When a language makes dick jokes in syntax, you shouldn't expect much.
- nnq 13y ago==> jokes aside, they are pulling in a very different direction from the one of the core PHP devs... this alone makes me expect less from the entire PHP system as a whole. They just made the PHP equivalent of Perl 6 vs Perl 5. But at least they are using their "Perl 6" and it works fine for them. If we could at least start to see shared hosts offering support for Hack and XHP it would seem more hopeful. (btw, you think PHP devs would like this? I was kinda pondering over it as a business idea...)
- thefreeman 13y agoThey have a heroku buildpack https://github.com/hhvm/heroku-buildpack-hhvm https://github.com/hhvm/heroku-buildpack-hhvm That's not quite "shared host easy", but it's still pretty easy to get up and running on heroku if you know what you are doing.
- stephenr 13y ago> they are pulling in a very different direction from the one of the core PHP devs when a sole company creates its own modified "version" of an existing language, and that company has a stated motto of "move fast and break things" why would you possibly trust them to maintain any features/compatibility longer than they themselves see a use for it?
- jules 13y agoWhy would you want to be explicit about that? The information is already there in the body of the closure. It's Foo x = new Foo(); all over again.
- nnq 13y agoTo know that the returned function can keep state? And if it does, to easily scan for side-effects via modified state? And to do this without carefully reading the entire body of the closure? It's a little bit like a "poor man's replacement for what a monad can be useful at" or `[Pure]` in C#. True, not much use in code you have written, but great for working with and even refactoring other people's code that you don't fully understand. ...to be honest, it's the kind of feature that I'd like to see in Javascript, not in PHP, to help me easily scan through callback hells in other people's code. It's true that callbacks don't tend to be abused in PHP and we don't have event labyrinths and long running event driven apps that can grow in memory usage, but these things will crop up, and when they do we'll have one less tool to make code more explicit and easier to read. I guess the fate of all good ideas that land in PHP is to be ignored, hated and then forgotten :)