Live data from Hacker News

Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

phoronix.com

21–30 of 144 posts

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#21
post #3

Honest, sincere, question here: How is programming in PHP these days? I haven't used the language since 4.x-5.2 or so. I wrote it off completely when Hack and HHVM came out due to the nuances between it and PHP proper (not to say either is bad, it was just another barrier, and set of choices I didn't care to deal with). I typically write Ruby, Elixir, and some JVM based languages these days. Any new features or langu…

It's not a terrible experience, but it is truly baffling that anyone would start a project in it today. A good static type system is too useful and important.

That's the last thing I look for when evaluating a new language.

Well, actually I came to dislike static typing so much that's a big point against languages IMHO. I concede that it would have saved me time with data occasionally going to the wrong argument/method/function but every time I understand that I'll have to type almost useless stuff like Map(,) I hit back and return to HN home page. Moving to dynamic typing was as liberating as moving away from malloc/free to garbage collection.

I think I could stand languages with implicit typing. All I want is not to have to annotate my code. I'm happily paying some time and tests for that.

Btw, I don't like people downvoting to express disagreement so I'm upvoting you. My +1.

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#22

Earlier quoted context omitted.

> A good static type system is too useful and important. What? A whole lot of web apps these days are built in Python, Ruby, or JavaScript, none of which are statically typed languages. Do you mean a strong type system?

I assume mean strongly typed and I can agree with them to an extent. While it does add slight overhead when writing code (not enough to matter I think) it does help eliminate a bunch of errors/edge cases you'd have to unit test for in an dynamically typed language. Though as I always say: use the right tool for the job. And for a lot of jobs dynamically typed languages and framework offer a lot to the developer.

There's no concrete definition of strongly typed, either.

https://stackoverflow.com/questions/2690544/what-is-the-diff...

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#23
post #19

Earlier quoted context omitted.

>There are almost always better tools for the job than PHP, like Django, Rails, Go's net/http, etc. depending on the kind of thing you're writing. Except for the time when you are 10 times more proficient in PHP but none of those languages. Then no, none of those languages are better for the job.

That sounds more like all you know how to use is a hammer, so everything is a nail.

More like, all you need is a Swiss army knife, and there are dozens of different Swiss army knives that can all get the job done. So use the one you are most familiar with.

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#24
post #15

Earlier quoted context omitted.

There's one thing none of those have that PHP has: Work with off-the-shelf managed hosting.

This is something programmers will never appreciate, and every small business on earth has already encountered Go build your client's new website in go, and then spend 80 hours trying to make it work with their $5/month hosting

And then after you move on, be cursed for all eternity when they have to find and hire someone with go experience to fix that tiny bug. Costing them 3x as much as if it was just PHP where anyone and their brother can work on it.

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#25
post #7

Honest, sincere, question here: How is programming in PHP these days? I haven't used the language since 4.x-5.2 or so. I wrote it off completely when Hack and HHVM came out due to the nuances between it and PHP proper (not to say either is bad, it was just another barrier, and set of choices I didn't care to deal with). I typically write Ruby, Elixir, and some JVM based languages these days. Any new features or langu…

i think PHP has the opposite problem of JavaScript - a build-in function library that's too big and very inconsistent. much of http://phpsadness.com/ remains in v7+. i tried to get them to change their long-standing, self-admitted improper ternary associativity [1] or at least deprecate it in v7 but it resulted in a huge bikeshed (despite no one actually encountering code that depended on the wrong behavior which has…

At least their reluctance to implement your feature requests for native formdata parsing seems to address your criticism that the built-in function library is too big.

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#26
post #3

Honest, sincere, question here: How is programming in PHP these days? I haven't used the language since 4.x-5.2 or so. I wrote it off completely when Hack and HHVM came out due to the nuances between it and PHP proper (not to say either is bad, it was just another barrier, and set of choices I didn't care to deal with). I typically write Ruby, Elixir, and some JVM based languages these days. Any new features or langu…

It's not a terrible experience, but it is truly baffling that anyone would start a project in it today. A good static type system is too useful and important.

I still do my saas projects all in PHP. I mean, I'm not building NASA control software it anything, but I have incurred very few problems due to dynamic typing. Not to mention the fact that I can hire php devs for half of what a ruby dev wants these days.

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#27
post #25
post #7

Earlier quoted context omitted.

i think PHP has the opposite problem of JavaScript - a build-in function library that's too big and very inconsistent. much of http://phpsadness.com/ remains in v7+. i tried to get them to change their long-standing, self-admitted improper ternary associativity [1] or at least deprecate it in v7 but it resulted in a huge bikeshed (despite no one actually encountering code that depended on the wrong behavior which has…

At least their reluctance to implement your feature requests for native formdata parsing seems to address your criticism that the built-in function library is too big.

they don't need to be functions. PUT/PATCH/etc bodies should be decoded automatically into new superglobals to match the existing $_GET, $_POST and $_FILES. if you're gonna have a shitty API, at least have a uniform shitty API ;)

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#28

Honest, sincere, question here: How is programming in PHP these days? I haven't used the language since 4.x-5.2 or so. I wrote it off completely when Hack and HHVM came out due to the nuances between it and PHP proper (not to say either is bad, it was just another barrier, and set of choices I didn't care to deal with). I typically write Ruby, Elixir, and some JVM based languages these days. Any new features or langu…

It's weird for me. I used to write both Java and PHP in the past.

Custom PHP framework we built took into account the way PHP is executed: you are stateless and need to setup everything on every request (runtime is fast to start with FPM and opcode cache). Namespaces based cheap autoloader worked great. No composer. We used singletons for getting the configuration and connections to DBs. There was almost no setup code that needed to be run every time other than loading .ini based configuration and connecting to the DB. Our webapp responded under 20ms (DB and Sphinx included), and I could get it to respond in 1 ms for things where we needed to be quick and didn't have to output HTML with Forms. I was really small and you could read the whole framework code in 1-2 hours. It worked with SQL in a reasonable way. You didn't have to write your SQL for simple CRUD, but for larger things involving joining multiple tables and more complex expressions we wrote native SQL.

I switched jobs, and started with Symfony 3. The thing felt like some Java framework, but poorly documented and harder to use than it should be. It had lots and lots of setup code done before handling every request. There's a whole DI framework with it's own tons of setup code for every component. And you have to do setup even though you don't use the component in that particular request. There's ways of doing lazy setup, but you still waste time to wire that up. Framework overhead can be 30-100ms. Other modern PHP frameworks have similar overhead. I know that there's PHP-PM, to save some of that work that isn't really $_REQUEST specific.

Everybody is using type hints wherever they can, and it feels as verbose as Java, but without compile time type safety, and you can't really put type information everywhere (class members for example). Even though PHP runtime has made great progress (it's probably the fastest interpreted language, and it's great it has reference counted garbage collection), it feels like language is struggling to find it's identity, with it taking a lot from Java and still coping with ugly legacy ($, having to use $this inside a class function, php.ini, features for supporting templating even though it's rarely used as a templating lang in modern frameworks).

Doctrine and it's verbosity feels very ugly to me.

Learning Python and Flask (as an example) was much more enjoyable than switching from a nimble custom PHP framework to Symfony.

I'd argue you can write fast, simple and maintainable PHP, using state PHP runtime has setup for you ($_POST, $_GET, $_SERVER etc), namespaces and a namespace based autoloader, trying to use pure functions when you can (using static classes shouldn't be a sin - just to split your code in sensible parts), and using general good practices for writing readable and maintainable code (avoid long functions, huge classes, too much block nesting, decoupling, naming things in a good way). With some conventions you can write a decent and productive framework quickly, but you could do that with a nicer language too, so what's the point?

Re: Benchmarks of PHP 7.2 Beta: PHP Is Still Getting Faster

#30
post #4

Earlier quoted context omitted.

PHP7 has improved life when dealing with legacy systems, but I think all in all you're better off not building new stuff in it. There are almost always better tools for the job than PHP, like Django, Rails, Go's net/http, etc. depending on the kind of thing you're writing.

>There are almost always better tools for the job than PHP, like Django, Rails, Go's net/http, etc. depending on the kind of thing you're writing. Except for the time when you are 10 times more proficient in PHP but none of those languages. Then no, none of those languages are better for the job.

If you don't do very much stuff, then sure. But most people end up coding long enough that learning new things is well worth the time. It's not like it takes more than a few months to learn a new framework or language, and you get benefits beyond just the new tools.

Visual Basic is still a language that many people know better than other languages, but I'd not advise those people to stay on VB just because they know VB. And PHP is getting a fresh coat of paint but that doesn't mean it isn't antiquated - what other web based programming environments provide a CGI model where scripts are in the public directory? How many of them are HTML with directions for the actual programming language?

If PHP is intended to stand on its own as a web development language, they've missed a few bits of low hanging fruit already. Like, take HTML out of the language. Package PHP with Composer. Allow for a new app base model where apps have their own FCGI servers and routing is done in PHP. I mean why not? These are things that modern users of PHP already try to accomplish, sometimes with [ugly hacks that are prone to security issues](https://www.acunetix.com/vulnerabilities/web/nginx-php-code-...).

I don't care if people think I'm just being a hater for the sake of it. I really think PHP is a dead end, and I think that because it seems the focus for PHP development has been toward making older software like MediaWiki run better rather than make PHP a better platform overall. As far as scripting languages go, it has a history of confusing, non orthogonal behaviors, legacy cruft, bad documentation, and designs that promote or directly cause security problems. And it has such a problem with memory management that the gold standard is to simply kill the PHP instance every N requests.

Post reply on HN