7 ms·

This is great news for the PHP community, and I for one applaud their effort. Contrary to what many HN hipsters seems to believe, PHP is quite a capable languag

This is great news for the PHP community, and I for one applaud their effort. Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward. * Hack introduces type hinting, imo the major lacking part in PHP. * HHVM introduces speed to php. On a personal project calculating perlin noise, I got about 8x speedup on HHVM. * The specification helps pave the way for more implementations of PHP.

TazeTSchnitzel 12y ago
>Hack introduces type hinting, imo the major lacking part in PHP. Hack extends PHP's type hints, it doesn't add them. It also makes PHP statically typed.
- birkbork 12y ago
  I stand corrected. PHP does not have type hint for their internal datatypes (int, float, string). Only array is supported. Type hinting for your custom datatypes is supported, when used as function arguments. Also hack introduces type hint for function return type.
  - TazeTSchnitzel 12y ago
    Scalar (int, float, string) type hinting may be added in a future PHP version, and there's currently an RFC for return types (I expect it'll pass myself). PHP already let you type hint for classses.
    - birkbork 12y ago
      Cool! I wasn't aware of the RFC. Must be this one then? https://wiki.php.net/rfc/returntypehinting https://wiki.php.net/rfc/returntypehinting
      - TazeTSchnitzel 12y ago
        Yep.
    - spaux 12y ago
      You can also hint on interfaces. If strict typing is important, I use the SPL primitive wrapper classes like SplString or SplInt http://php.net/manual/en/class.spltype.php http://php.net/manual/en/class.spltype.php
- SaraMG 12y ago
  nit: It makes it gradually typed. The types are only as static as you choose to make them.
  - TazeTSchnitzel 12y ago
    It does have a fully statically and strictly-typed mode, though, and regardless of its strictness, it makes PHP fully static in strict mode, to my understanding.
- chriswarbo 12y ago
  > It also makes PHP statically typed. I disagree. PHP finds this perfectly acceptable: class Foo {} class Bar {} function foo(Foo $x) {} function bar(Bar $x) { foo($x); } PHP is clearly checking types (actually, class tags) at runtime, every time a function/method is called. That's dynamic typing, not static typing. Crucially, static types can be erased before execution without affecting the behaviour of a program: http://en.wikipedia.org/wiki/Type_erasure http://en.wikipedia.org/wiki/Type_erasure
  - TazeTSchnitzel 12y ago
    I meant that Hack is statically-typed, not PHP. PHP is obviously dynamically-typed.
    - chriswarbo 12y ago
      Hmm. Looks like Hack still includes files based on strings: https://github.com/hhvm/hack-example-site/blob/master/index.php https://github.com/hhvm/hack-example-site/blob/master/index.... How can a language be statically typed when the instructions telling it what code to use are dynamic?
      - TazeTSchnitzel 12y ago
        include "foobar.php", IIRC, is executed at compile-time, and I assume must be in Hack's type checker too. Also, I don't see how pausing execution and re-invoking the compiler at run-time to load the rest of the code base (which you can do in PHP with a conditional include, don't know about Hack) can't be done with static typing.
        chriswarbo 12y ago
        Let's say we have the following: file1.hh: <?hh $giveMeAnArray = (time() > 1)? function(array $x) {} : function(stdClass $x) {}; $anArray = []; file2.hh: <?hh $giveMeAnArray($anArray); file3.hh: <?hh list($f1, $f2) = (time() > 1)? ['file1.hh', 'file2.hh'] : ['/dev/random', '/dev/random']; include $f1; if (time() > 1) $anArray = new stdClass; include $f2; As far as I understand it, the following will happen when we run file3.hh: - HHVM will compile file3.hh. This phase doesn't know what $f1 or $f2 will be, or whether $anArray will become a new stdClass, since they depend on the output of time(). - HHVM finishes compiling file3.hh - HHVM will execute file3.hh, setting $f1 to 'file1.hh' and $f2 to 'file2.hh'. - HHVM will compile file1.hh. This phase doesn't know what $giveMeAnArray will be, since it depends on the output of time(). - HHVM will finish compiling file1.hh - HHVM will run file1.hh, defining $giveMeAnArray = function(array $x) {} and $anArray = [] - HHVM will resume running file3.hh and set $anArray = new stdClass - HHVM will compile file2.hh, which contains a type error. How does it know? The most likely answer is that type information is stored in values and checked during usage. That is not static typing, it's 'dynamic typing' (tag-checking). There is an alternative possibility: the state of the compiler could be preserved between files, so type information from file3.hh and file1.hh is available when compiling file2.hh. However, this information wouldn't include knowledge that "$my_account = new stdClass" has been executed, since that's dynamic run-time information which is only knowable after file3.hh and file1.hh have finished compiling. There is no way (to my knowledge) that interleaving static type-checking with dynamic execution can produce a type-error when file2.hh is compiled. The type-checking must have access to the execution state of the program, ie. it must be dynamic. If type-checking happens during/alongside/interleaved-with execution, the compilation phase (which must be done prior to execution) cannot know the types of the code it's compiling. Without this knowledge, the first unit of code it produces is forced to use dynamic types (AKA a unitype). Once that unit is type-checked/executed, the runtime information gained may be used to partially-inform subsequent compilation, somewhat like a JIT, but there would always need to be dynamic fallbacks. Of course, a dynamic fallback defeats the main point of using static types: being informed when there's an error. There may be incidental benefits from doing this though, like faster code.
jgrowl 12y ago
I don't think many would claim that PHP isn't capable. It's that some of us just don't enjoy it and find it to ugly. Especially given how mature competing languages have become.
- hoka 12y ago
  I work at a PHP shop, coming from a Python background. I chose to come here for the team, certainly not the language. When I asked about why some things are inconsistent in PHP compared to other languages, its age was a common defense. I was shocked to find that Python is older than PHP, and Ruby is the same age!
  - girvo 12y ago
    However, Ruby didn't see the uptake of usage that PHP did. It was popular -- one of the first languages that you could use as an alternative to CGI! However, age isn't why it's got so many sharp edges. That's Rasmus' fault, and the core team's.
- ademarre 12y ago
  I agree, but there are many with a large investment in PHP, and since it isn't going away, it's very much worthwhile to make it better.
- birkbork 12y ago
  Perhaps time to revisit PHP some time then? It also has become more mature :) Much of PHP's old built-in functions are crap (side effects, inconsistent parameter order, wierd naming), but you can't really (and shouldn't) compare those parts with another language as there is no correlation.
- ChikkaChiChi 12y ago
  All due respect it is easy to write shitty code in PHP but you can also craft elegant design patterns that are easy to grok. I can't think of a language that has out of box adoption for web development similar to PHP.
revscat 12y ago
> Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward. This attitude really frustrates me. I'm a developer with over 20 years of experience. I don't use PHP because (a) I have had poor experiences with it in the past, (b) I am enjoying my current stack (Java8/Clojure/Groovy), and (c) would go with stacks like RoR over PHP if I had to choose, simply because I've had good experiences with Rails. You're implication that this has something to do with trendiness is frankly insulting.
- wdewind 12y ago
  Not parent, but if you make those (completely reasonable) points when you criticize PHP he's not talking about you when he says "HN Hipsters." He's talking about the "What kind of idiot uses php?" crowd, which unfortunately hangs out here too much, and frankly doesn't understand which parts of php actually are good or bad because their entire opinion is based off blog posts not experience. I don't think you're one of those.
- birkbork 12y ago
  Sorry if i offended you. I really did not try to imply this has to do with trendiness, but it was a frustrated outbreak from my end. I've seen way too many poisonous hater comments against everything PHP here since I started visiting. I myself use (besides PHP) C#, Javascript, Python, and recently revisited C++ to check out C++11 (I am thrilled). I have been working developing in mainly PHP since 1999 so I have seen most of it's ugly sides. This thread however was about PHP, not wether Java is good or bad.
- vorg 12y ago
  > I am enjoying my current stack (Java8/Clojure/Groovy) Not just trendiness, but also whether a spec exists, from which alternative implementations can be reliably built. Some language despots (e.g. Python's) have even had moritorium periods of no new features specifically to help other implementations catch up. The spec announcement is a step forward for PHP. Your current stack is at widely varying extremes along the spec continuum: * Java 8 is fully spec'd to intricate detail, and Java has implementations other than Oracle's. Anyone can build an implementation as long as they don't call it Java. * Clojure is informally spec'd by the comments in the functions, and what little grammar there is is explained on the clojure.org website. Alternative implementations exist to varying degrees of compatibility, e.g. ClojureScript doesn't have native macros. * Groovy has virtually no spec at all after 11 yrs. Despite it being spec-driven at first, its JSR was inactive for 7 yrs, then changed to dormant status 3 yrs ago. My personal experience is the Codehaus project management actively prevent other implementations being built.
duaneb 12y ago
> PHP is quite a capable language I don't think anyone is complaining that it's not turing complete (or whatever), it's all the times php has dropped the ball in the std library, both with respect to being consistent with itself and just being plain broken. I don't think any sane person would switch from a language INTO php, given how many languages that are just as capable as php without having all of its various historical burdens (sigils, stdlib, mediocre type system).
- secstate 12y ago
  Amen. I think this thread could use a little: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ It has never been about whether PHP can get shit done, it's that given languages that actually had formal design processes and make your days as a coder a joy, why would you move TO PHP. There are simply so many other options.
  - thathonkey 12y ago
    There are many other options, none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts). The barrier to entry is higher if you want to run a site on something else. That is the sole reason PHP is as popular as it is and part of the reason why it stays popular and powers so many of the internet's top websites. Other reasons why it stays popular is that they really have improved it a lot over the years and knowledge on how to run PHP at scale is quite easily available. The community is improving along with the language. Yes, the standard library is frustrating but that is a pretty minor inconvenience honestly. Every language has a frustrating part of its design. This wart on PHP can be fixed and there are some great recommendations on how to transition to a better std lib in other comments on this OP.
    - dragonwriter 12y ago
      > There are many other options, none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts). What is this really an issue for? I mean, sure, there may be more choices of low-cost low-feature shared hosts that support PHP than other languages, but its hardly as if there aren't a sufficient quantity of low-cost (even, in some cases, with free tiers) platforms for apps in a wide variety of languages. Unless you are literally compelled to choose a host at random, the fact that a randomly-chosen shared host is more likely to support PHP shouldn't really matter.
ihsw 12y ago
PHP the language and the development environment around it is quite capable, however the unwashed masses of "developers" and the plethora of code spewed forth from them would cause you to avoid PHP like the plague.

TazeTSchnitzel 12y ago

>Hack introduces type hinting, imo the major lacking part in PHP. Hack extends PHP's type hints, it doesn't add them. It also makes PHP statically typed.

birkbork 12y ago
I stand corrected. PHP does not have type hint for their internal datatypes (int, float, string). Only array is supported. Type hinting for your custom datatypes is supported, when used as function arguments. Also hack introduces type hint for function return type.
- TazeTSchnitzel 12y ago
  Scalar (int, float, string) type hinting may be added in a future PHP version, and there's currently an RFC for return types (I expect it'll pass myself). PHP already let you type hint for classses.
  - birkbork 12y ago
    Cool! I wasn't aware of the RFC. Must be this one then? https://wiki.php.net/rfc/returntypehinting https://wiki.php.net/rfc/returntypehinting
    - TazeTSchnitzel 12y ago
      Yep.
  - spaux 12y ago
    You can also hint on interfaces. If strict typing is important, I use the SPL primitive wrapper classes like SplString or SplInt http://php.net/manual/en/class.spltype.php http://php.net/manual/en/class.spltype.php
SaraMG 12y ago
nit: It makes it gradually typed. The types are only as static as you choose to make them.
- TazeTSchnitzel 12y ago
  It does have a fully statically and strictly-typed mode, though, and regardless of its strictness, it makes PHP fully static in strict mode, to my understanding.
chriswarbo 12y ago
> It also makes PHP statically typed. I disagree. PHP finds this perfectly acceptable: class Foo {} class Bar {} function foo(Foo $x) {} function bar(Bar $x) { foo($x); } PHP is clearly checking types (actually, class tags) at runtime, every time a function/method is called. That's dynamic typing, not static typing. Crucially, static types can be erased before execution without affecting the behaviour of a program: http://en.wikipedia.org/wiki/Type_erasure http://en.wikipedia.org/wiki/Type_erasure
- TazeTSchnitzel 12y ago
  I meant that Hack is statically-typed, not PHP. PHP is obviously dynamically-typed.
  - chriswarbo 12y ago
    Hmm. Looks like Hack still includes files based on strings: https://github.com/hhvm/hack-example-site/blob/master/index.php https://github.com/hhvm/hack-example-site/blob/master/index.... How can a language be statically typed when the instructions telling it what code to use are dynamic?
    - TazeTSchnitzel 12y ago
      include "foobar.php", IIRC, is executed at compile-time, and I assume must be in Hack's type checker too. Also, I don't see how pausing execution and re-invoking the compiler at run-time to load the rest of the code base (which you can do in PHP with a conditional include, don't know about Hack) can't be done with static typing.
      - chriswarbo 12y ago
        Let's say we have the following: file1.hh: <?hh $giveMeAnArray = (time() > 1)? function(array $x) {} : function(stdClass $x) {}; $anArray = []; file2.hh: <?hh $giveMeAnArray($anArray); file3.hh: <?hh list($f1, $f2) = (time() > 1)? ['file1.hh', 'file2.hh'] : ['/dev/random', '/dev/random']; include $f1; if (time() > 1) $anArray = new stdClass; include $f2; As far as I understand it, the following will happen when we run file3.hh: - HHVM will compile file3.hh. This phase doesn't know what $f1 or $f2 will be, or whether $anArray will become a new stdClass, since they depend on the output of time(). - HHVM finishes compiling file3.hh - HHVM will execute file3.hh, setting $f1 to 'file1.hh' and $f2 to 'file2.hh'. - HHVM will compile file1.hh. This phase doesn't know what $giveMeAnArray will be, since it depends on the output of time(). - HHVM will finish compiling file1.hh - HHVM will run file1.hh, defining $giveMeAnArray = function(array $x) {} and $anArray = [] - HHVM will resume running file3.hh and set $anArray = new stdClass - HHVM will compile file2.hh, which contains a type error. How does it know? The most likely answer is that type information is stored in values and checked during usage. That is not static typing, it's 'dynamic typing' (tag-checking). There is an alternative possibility: the state of the compiler could be preserved between files, so type information from file3.hh and file1.hh is available when compiling file2.hh. However, this information wouldn't include knowledge that "$my_account = new stdClass" has been executed, since that's dynamic run-time information which is only knowable after file3.hh and file1.hh have finished compiling. There is no way (to my knowledge) that interleaving static type-checking with dynamic execution can produce a type-error when file2.hh is compiled. The type-checking must have access to the execution state of the program, ie. it must be dynamic. If type-checking happens during/alongside/interleaved-with execution, the compilation phase (which must be done prior to execution) cannot know the types of the code it's compiling. Without this knowledge, the first unit of code it produces is forced to use dynamic types (AKA a unitype). Once that unit is type-checked/executed, the runtime information gained may be used to partially-inform subsequent compilation, somewhat like a JIT, but there would always need to be dynamic fallbacks. Of course, a dynamic fallback defeats the main point of using static types: being informed when there's an error. There may be incidental benefits from doing this though, like faster code.

jgrowl 12y ago

I don't think many would claim that PHP isn't capable. It's that some of us just don't enjoy it and find it to ugly. Especially given how mature competing languages have become.

hoka 12y ago
I work at a PHP shop, coming from a Python background. I chose to come here for the team, certainly not the language. When I asked about why some things are inconsistent in PHP compared to other languages, its age was a common defense. I was shocked to find that Python is older than PHP, and Ruby is the same age!
- girvo 12y ago
  However, Ruby didn't see the uptake of usage that PHP did. It was popular -- one of the first languages that you could use as an alternative to CGI! However, age isn't why it's got so many sharp edges. That's Rasmus' fault, and the core team's.
ademarre 12y ago
I agree, but there are many with a large investment in PHP, and since it isn't going away, it's very much worthwhile to make it better.
birkbork 12y ago
Perhaps time to revisit PHP some time then? It also has become more mature :) Much of PHP's old built-in functions are crap (side effects, inconsistent parameter order, wierd naming), but you can't really (and shouldn't) compare those parts with another language as there is no correlation.
ChikkaChiChi 12y ago
All due respect it is easy to write shitty code in PHP but you can also craft elegant design patterns that are easy to grok. I can't think of a language that has out of box adoption for web development similar to PHP.

revscat 12y ago

> Contrary to what many HN hipsters seems to believe, PHP is quite a capable language, and HHVM / Hack is really pushing things forward. This attitude really frustrates me. I'm a developer with over 20 years of experience. I don't use PHP because (a) I have had poor experiences with it in the past, (b) I am enjoying my current stack (Java8/Clojure/Groovy), and (c) would go with stacks like RoR over PHP if I had to choose, simply because I've had good experiences with Rails. You're implication that this has something to do with trendiness is frankly insulting.

wdewind 12y ago
Not parent, but if you make those (completely reasonable) points when you criticize PHP he's not talking about you when he says "HN Hipsters." He's talking about the "What kind of idiot uses php?" crowd, which unfortunately hangs out here too much, and frankly doesn't understand which parts of php actually are good or bad because their entire opinion is based off blog posts not experience. I don't think you're one of those.
birkbork 12y ago
Sorry if i offended you. I really did not try to imply this has to do with trendiness, but it was a frustrated outbreak from my end. I've seen way too many poisonous hater comments against everything PHP here since I started visiting. I myself use (besides PHP) C#, Javascript, Python, and recently revisited C++ to check out C++11 (I am thrilled). I have been working developing in mainly PHP since 1999 so I have seen most of it's ugly sides. This thread however was about PHP, not wether Java is good or bad.
vorg 12y ago
> I am enjoying my current stack (Java8/Clojure/Groovy) Not just trendiness, but also whether a spec exists, from which alternative implementations can be reliably built. Some language despots (e.g. Python's) have even had moritorium periods of no new features specifically to help other implementations catch up. The spec announcement is a step forward for PHP. Your current stack is at widely varying extremes along the spec continuum: * Java 8 is fully spec'd to intricate detail, and Java has implementations other than Oracle's. Anyone can build an implementation as long as they don't call it Java. * Clojure is informally spec'd by the comments in the functions, and what little grammar there is is explained on the clojure.org website. Alternative implementations exist to varying degrees of compatibility, e.g. ClojureScript doesn't have native macros. * Groovy has virtually no spec at all after 11 yrs. Despite it being spec-driven at first, its JSR was inactive for 7 yrs, then changed to dormant status 3 yrs ago. My personal experience is the Codehaus project management actively prevent other implementations being built.

duaneb 12y ago

> PHP is quite a capable language I don't think anyone is complaining that it's not turing complete (or whatever), it's all the times php has dropped the ball in the std library, both with respect to being consistent with itself and just being plain broken. I don't think any sane person would switch from a language INTO php, given how many languages that are just as capable as php without having all of its various historical burdens (sigils, stdlib, mediocre type system).

secstate 12y ago
Amen. I think this thread could use a little: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ It has never been about whether PHP can get shit done, it's that given languages that actually had formal design processes and make your days as a coder a joy, why would you move TO PHP. There are simply so many other options.
- thathonkey 12y ago
  There are many other options, none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts). The barrier to entry is higher if you want to run a site on something else. That is the sole reason PHP is as popular as it is and part of the reason why it stays popular and powers so many of the internet's top websites. Other reasons why it stays popular is that they really have improved it a lot over the years and knowledge on how to run PHP at scale is quite easily available. The community is improving along with the language. Yes, the standard library is frustrating but that is a pretty minor inconvenience honestly. Every language has a frustrating part of its design. This wart on PHP can be fixed and there are some great recommendations on how to transition to a better std lib in other comments on this OP.
  - dragonwriter 12y ago
    > There are many other options, none of which enjoy the ubiquity of PHP (as far as being installed on such a vast majority of hosts). What is this really an issue for? I mean, sure, there may be more choices of low-cost low-feature shared hosts that support PHP than other languages, but its hardly as if there aren't a sufficient quantity of low-cost (even, in some cases, with free tiers) platforms for apps in a wide variety of languages. Unless you are literally compelled to choose a host at random, the fact that a randomly-chosen shared host is more likely to support PHP shouldn't really matter.

ihsw 12y ago

PHP the language and the development environment around it is quite capable, however the unwashed masses of "developers" and the plethora of code spewed forth from them would cause you to avoid PHP like the plague.