Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing a specification for PHP

hhvm.com

Post reply on HN
Print view View original

211–220 of 263 posts

Re: Announcing a specification for PHP

#211

Post by Illotus »

secstate wrote: post #47
duaneb wrote: post #42

Earlier quoted context omitted.

> 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 hi…

Amen. I think this thread could use a little: 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.

If you slog through that, might as well read the rebuttal http://forums.devshed.com/php-development-5/php-fractal-bad-...

Re: Announcing a specification for PHP

#212

Post by aruggirello »

chriswarbo wrote: post #195
jfoutz wrote: post #136

Earlier quoted context omitted.

or just distribute an upgrader with the next release. I'm sure it's more complicated than just find and replace, but the interpreter has a perfectly good parser right there. eval is impossible (or very hard), but it's pretty legit to error out in that case.

It's not legit to error-out for eval, since PHP has all kinds of eval-like things. For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example: $my_anon = function() {}; function my_named() {} // Valid array_map($my_anon, []…

You're talking about the very things that make PHP flexible. I don't see how 'swapping out' things like these would make PHP any safer, faster, or easier to read. C/C++ function decorators, or dynamic programming constructs are not exactly that clearer.

Re: Announcing a specification for PHP

#213

Post by jules »

teh_klev wrote: post #149
debaserab2 wrote: post #137

Earlier quoted context omitted.

If you like it because it's like rails, why not just use rails? The rails ecosystem is undoubtedly stronger than laravel's, and it's a more mature framework. I don't see where laravel fits in the spectrum of PHP frameworks.

> "If you like it because it's like rails, why not just use rails?" PHP is ubiquitous on shared hosting platforms, there aren't that many "shared" Rails hosters out there. Morts still use shared hosters.

This was already an outdated argument 5 years ago.

Re: Announcing a specification for PHP

#214

Post by jules »

surreal wrote: post #187
chatmasta wrote: post #172

Earlier quoted context omitted.

This was a much more compelling argument when shared hosting was still cheaper than a VPS with root access. But now you can get a VPS from any slew of providers, like digitalocean, for $5 a month. Root access computing has never been more accessible, and shared hosting is rapidly losing any value proposition it once had. So targeting PHP purely because it's more ubiquitous on shared hosting than Rails, is making less…

That's still $60 a year, which is at least double the price of a simple reliable shared hosting package. The shared hosting has other conveniences too. I'm not saying it's without downsides, but there are cases for choosing it, and therefore for choosing PHP.

You must value your time and sanity really low if you are willing to put up with PHP instead of Ruby for $30/year.

Re: Announcing a specification for PHP

#217

Post by will_work4tears »

Kiro wrote: post #209
chatmasta wrote: post #185

Earlier quoted context omitted.

... which you can also do on platforms like digitalocean. Just spin up a preconfigured dokku droplet and git push.

> Just spin up a preconfigured dokku droplet and git push. Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.

That workflow is pretty outdated, you know. It's about akin to using tables for layout, and about as much of a no no. I know, git can be pretty confusing, but using version control, even in a one man shop, is a huge boon.

Re: Announcing a specification for PHP

#218

Post by ben0x539 »

chatmasta wrote: post #185
Kiro wrote: post #184

Earlier quoted context omitted.

I don't want root access. I want to sign up, upload my files through FTP and have it working instantly without having to worry about anything else.

... which you can also do on platforms like digitalocean. Just spin up a preconfigured dokku droplet and git push.

Compared to the php workflow, this is pure technobabble.

Re: Announcing a specification for PHP

#219

Post by chriswarbo »

aruggirello wrote: post #212
chriswarbo wrote: post #195

Earlier quoted context omitted.

It's not legit to error-out for eval, since PHP has all kinds of eval-like things. For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example: $my_anon = function() {}; function my_named() {} // Valid array_map($my_anon, []…

You're talking about the very things that make PHP flexible. I don't see how 'swapping out' things like these would make PHP any safer, faster, or easier to read. C/C++ function decorators, or dynamic programming constructs are not exactly that clearer.

Nobody's talking about "swapping out" the eval-like features.

The parent was saying we could swap out all usages of 'old fashioned' functions like str_replace for some 'new fashioned' alternative, like String::replace, using some kind of upgrader tool.

I was pointing out that the PHP's eval-like features make it difficult for any such tool to exist. In particular, with Python or Javascript we might spit out a warning "Eval spotted; this upgrade might not work!". If we did the same in PHP, everyone would get a warning! "String used as function detected; this upgrade might not work!", "Variable variable detected; this upgrade might not work!", and so on.

Re: Announcing a specification for PHP

#220

Post by chriswarbo »

TazeTSchnitzel wrote: post #11
birkbork wrote: post #10

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 pa…

>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.

> 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

Post reply on HN