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

Taking PHP Seriously

slack.engineering

Post reply on HN
Print view View original

191–200 of 673 posts

Re: Taking PHP Seriously

#191

Post by calsy »

swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

So people who don't care make successful projects and PHP is a garbage language that is responsible for more successful projects than any other server side scripting language. LOGIC.

Re: Taking PHP Seriously

#192

Post by totony »

leeoniya wrote: post #149
gravypod wrote: post #131

Earlier quoted context omitted.

> The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent? > The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]) You shouldn't be judging the way operators work in one lang…

> On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. If you read the thread, no one could actually recall having ever seen code that relies on the current behavior. It has been discouraged in the docs for years . The stop-gap proposal was to have PHP7 deprecate it with a warning rather than silently changing the behavior. Then change the behavior in a future ver…

I'd rather they don't change it. I like my code to not stop working (python3, perl 6) when upgrading.

Also it's not a bug, more like a design oversight that doesn't cause any problem if you rtfm

Re: Taking PHP Seriously

#193

Post by tyingq »

weberc2 wrote: post #145
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

The real question is why does PHP depend on globals or thread locals for request state at all? PHP's "new process per request" is a solution to a problem that PHP created for itself. In other languages, the request handler receives the request state as an argument, so when the request completes there is no state to reset. > It seems like it would be easier for everyone involved. You wouldn't need much of a GC when th…

>>PHP's "new process per request" is a solution to a problem that PHP created for itself

True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.

Re: Taking PHP Seriously

#194

Post by astrodust »

krapp wrote: post #177
astrodust wrote: post #172

Earlier quoted context omitted.

Node's intrinsic ability to "speak" JSON makes for some very clean code when dealing with that sort of data. If you're doing a simple API back-end in Express with JSON in, JSON out, it's extremely light-weight. PHP, Ruby and Python here are at a disadvantage. JSON is JavaScript's home turf.

PHP isn't at much of a disadvantage - it has its own native JSON encode and decode functions. Granted, actually using javascript is better but it's not as if you have to import a library or write your own JSON parser.

It's not the decoding and encoding stuff, every language has that, but the difference in accessing the data.

$data['key']['value'][0] is a lot messier than data.key.value[0]. Ruby has ways of mitigating this, but you pay a performance penalty.

Re: Taking PHP Seriously

#195

Post by igravious »

astrodust wrote: post #164
swalsh wrote: post #16

I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…

PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you . If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.

Not quick as in execution speed, quick as in time from idea in head to working code.

Re: Taking PHP Seriously

#196

Post by SolarUpNote »

mikey_p wrote: post #72
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialize…

Doesn't Opcache take care of that? Using a large framework isn't really a problem because all of the classes, configuration, etc is all kept in ram.

Re: Taking PHP Seriously

#197

Post by Jach »

wvenable wrote: post #23
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

The startup time can be pretty extreme -- although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything. And even if you cache everything, you still have the code necessary to setup the runtime environment of you applicati…

Still often faster than for whatever unholy filter chain of jetty services to get through the stack to the code I care about.

Re: Taking PHP Seriously

#198

Post by bkanber »

tonyarkles wrote: post #106

I've been doing consulting for several years now, as well as a MSc thesis that involved me looking at a number of open source codebases. I am generally in the "PHP is garbage" camp, but I keep hearing people say that nice codebases in PHP are possible. I've never seen one, but I am perpetually open to the idea that they exist. Does anyone have a good example of an open-source PHP project that will enlighten me?

Symfony, Aura, Laravel, Guzzle, Composer, Zend Framework, Lithium, SwiftMailer

Re: Taking PHP Seriously

#199

Post by chc »

jamroom wrote: post #166
chc wrote: post #143

Earlier quoted context omitted.

Your template is far less interesting than the original statement. PHP spent a pretty long time as basically the lingua franca outside the enterprise world (and even some places in it), and there are still domains where it holds that title (e.g. WordPress alone outweighs many languages' ecosystems), so the phenomenon the parent was describing applies more to PHP than to some arbitrary language you could insert into t…

I actually agree with the original statement. PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail. "and miss all of the tremendous losers who picked php and got nothing for it" certainly applies equally across all languages in my opinion.

That's not what was being discussed, though.

The grandparent of your comment suggested that, yes, these projects were lifted up by PHP's un-fancy nature giving them focus. The parent of your comment was suggesting that, basically, the companies that have succeeded using PHP aren't any more numerous than we would expect to have come out of the massive PHP userbase even if PHP doesn't offer any advantages at all.

The observation that "PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail" seems to be responding to a nonexistent conversation in which people were positing that startups based on other languages don't fail. Nobody here is saying that other languages magically make your business succeed.

Re: Taking PHP Seriously

#200

Post by [deleted] »

Nullabillity wrote: post #31
Klathmon wrote: post #11

The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…

Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT. You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.

[deleted]
Post reply on HN