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

PHP 8: Before and After

stitcher.io

Post reply on HN
Print view View original

151–160 of 346 posts

Re: PHP 8: Before and After

#151

Post by xd »

codeulike wrote: post #141
codegeek wrote: post #137

Earlier quoted context omitted.

"he answered that 100-200 request per second is more than enough for most use cases" Exactly this. If you already know PHP and can produce results (mostly CRUD apps) and it doesn't need millions of rps, why do we need to use another language because they are so much better ? So much better at what ? It is like saying "I have a hammer, so everything looks like a nail to me". Not every web app has to be written in Lua/…

Reminds me of "PHP Hammer" I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there. You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes. You pull out the hammer, but to your dismay, it has the claw part on both sides. Sti…

As yes, the 2012 fractal of bad design, being peddled out yet again - your post is just pure hate, it adds no valid argument whatsoever.

Re: PHP 8: Before and After

#152

Post by simion314 »

cute_boi wrote: post #114
simion314 wrote: post #29

Earlier quoted context omitted.

Most of the bugs or spaghetti code I have to fix this days are not caused by the language, the issue is most of the time the requirements that changed or the developer was not experienced with that certain problem so he created a monster.

its like saying most of the seg fault caused is not due to use of C. Common langauge pattern / design choices made php to have bugs/ spaghetti code. At the end developer control many thing but that doesn't mean language don't have any fault.

It is not fair to bring C into this, C is an old language and when all the kernels and core libraries were created it was the best tool for the job. You hate C please go and contribute to the many rewrites and one day 25 years from now maybe we will have an OS written in some language that is cool now but would be outdated then.

My advice is use the best tool for the job when possible, if you don't have a choice then learn to accept that most of us work with less cool languages/frameworks/projects ... the skill we bring is to find solutions for our customers and implement this solutions as best we can with the tools we have, most of the time a developer should be spending reading stuff(documentation,articles, code), thinking and the least time should be spent on typing code or tooling.

Re: PHP 8: Before and After

#153

Post by ai_ja_nai »

I don't understand as of 2020 the use case for PHP. It's verbose as Java without its speed. Seriously, can anybody help here?

It made sense to use PHP EXACLTLY in the good bad old days because it was just leaner to bang out applications in PHP than with other languages.

Nowadays, I feel that PHP cake has been largely eaten by Python and Ruby.

Why using PHP with such a level of verbosity?

Re: PHP 8: Before and After

#154

Post by jrumbut »

Shish2k wrote: post #139
TheHemric wrote: post #112

I don't really understand why in 2020 there's still this kind of blind hatred against this language. It often comes from horrible bad memories from previous versions or old frameworks. Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications. I've been working on a SaaS API…

People keep saying “PHP in ${current_year} is actually great, it only sucked in ${current_year-5}!” - I feel like it still sucks[1] today, but it’ll take 5 more years for the fans to realise it, when they have the PHP from ${current_year+5} to compare against :P [1] Being slightly hyperbolic - I won’t deny that you can do good things with PHP, as you can do good things with any tool; and AFAIK it’s still unmatched wh…

The key to becoming a person who thinks PHP is great now is to primarily use features that have existed for more than 5 years. For me, PHP 7 was PHP 5 that was faster and had some nice little bits of new syntax. They started down the type system road but I avoided it then.

Now it seems like the basic type system is in place, great. This new stuff in the article I'll probably start using it when 8.4 drops.

5 years is an exaggeration, but staying a version or two behind really helps you stay sane.

By the way I found Hack/HHVM thoroughly disappointing. Tried running some fairly complex apps on it and it felt like they reimagined the legacy baggage. Seems like PHP itself borrowed a lot of ideas from it though.

Re: PHP 8: Before and After

#155

Post by iDemonix »

ai_ja_nai wrote: post #153

I don't understand as of 2020 the use case for PHP. It's verbose as Java without its speed. Seriously, can anybody help here? It made sense to use PHP EXACLTLY in the good bad old days because it was just leaner to bang out applications in PHP than with other languages. Nowadays, I feel that PHP cake has been largely eaten by Python and Ruby. Why using PHP with such a level of verbosity?

See the comment by TheHemric, it's a bit more informed than you seem to be.

Re: PHP 8: Before and After

#156

Post by Cthulhu_ »

js4ever wrote: post #134

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compared to Go, node.js, C# and others, he answered that 100-200 request per second is more than enough for most use cases. I'm working on systems with 25K RPS at peaks, but for simple projects and small companies he is right ... But why should anyone start a new pr…

200-500 requests per second? I'm sure it can do a ton more. Here's some benchmark numbers: https://www.techempower.com/benchmarks/#section=data-r19&hw=...

I don't believe the constraint would be the language itself, not with accellerators, opcode caches, JIT compilers, etc. I've always been told that PHP's performance is more down to the database than anything else.

Re: PHP 8: Before and After

#157

Post by Mikushi »

js4ever wrote: post #134

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compared to Go, node.js, C# and others, he answered that 100-200 request per second is more than enough for most use cases. I'm working on systems with 25K RPS at peaks, but for simple projects and small companies he is right ... But why should anyone start a new pr…

> my point was php is slow and max throughput is 200-500 rps

Absolutely not, you could already go to 5k rps 10 years ago and PHP has massively improved since.

Re: PHP 8: Before and After

#158

Post by tannhaeuser »

shawnz wrote: post #123
tannhaeuser wrote: post #91

Earlier quoted context omitted.

That's what baffles me with PHP. Instead of building on PHP's unique capabilities, they try to become more like Java. When PHP was and is quite successful as server-side language for HTML templating, rooted in embedded PHP triggered from SGMLish processing instructions in otherwise static HTML. It's only that they made such a hack job without context-dependent, HTML-aware escaping, making it a primary vector for inje…

It would be impossible to maintain backward compatibility if they made the language HTML context aware. It would make it more difficult to output any non-HTML content type from a PHP script. It would require many new syntaxes (e.g. for outputting variable data in the attribute values of elements, selectively outputting elements or attributes, looping through them, etc). It would also mean the language is tied to spec…

Backward-compat and syntax doesn't have to be a problem. The `` processing instruction can stay as it is, only to be augmented with a new opt-in mechanism based on entity expansion (the fully context-aware templating mechanism built-in to SGML/XML). Eg roughly

    bla
    whatever
"?>
    &x
where x is bound to markup checked against permissible elements in the first context (eg rejecting ) and escaped into <p>whatever<p> in the second. Rejecting script elements in user or other dynamic content as well as escaping comes for free with regular SGML parsing.

Re: PHP 8: Before and After

#159

Post by mknx »

ai_ja_nai wrote: post #153

I don't understand as of 2020 the use case for PHP. It's verbose as Java without its speed. Seriously, can anybody help here? It made sense to use PHP EXACLTLY in the good bad old days because it was just leaner to bang out applications in PHP than with other languages. Nowadays, I feel that PHP cake has been largely eaten by Python and Ruby. Why using PHP with such a level of verbosity?

I converted about two dozens Ruby and Python apps to PHP in the last 7-8 years.

Re: PHP 8: Before and After

#160

Post by fetbaffe »

js4ever wrote: post #134

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compared to Go, node.js, C# and others, he answered that 100-200 request per second is more than enough for most use cases. I'm working on systems with 25K RPS at peaks, but for simple projects and small companies he is right ... But why should anyone start a new pr…

Because the alternatives is actually not good, it just a fallacy.

There will always be something negative regardless of what you pick, problem is to decide what your core values are when writing different types of software. If you don't, you are just comparing apples to oranges.

When it comes to PHP, core values are usually things that has to do with tooling, server architecture & deployment, not much the language (syntax, expressions, lambdas, classes etc) it self, except maybe it is easy to learn & use.

This means that developers who comes from a background of that the language itself is the most important part of a project will most of the time just get confused what PHP is about.

Post reply on HN