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

551–560 of 673 posts

Re: Taking PHP Seriously

#551

Post by kccqzy »

codedokode wrote: post #425
vatotemking wrote: post #411

Earlier quoted context omitted.

> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"? I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all

Try console.log([] * {}) and be surprised. At least in PHP you cannot multiply array by object. Type casting in PHP gets fixed gradually: https://wiki.php.net/rfc/invalid_strings_in_arithmetic .

Or compare

    [] + {}
and

    {} + []
The first one is "[object Object]" and the second one is 0.

Re: Taking PHP Seriously

#552

Post by weberc2 »

codedokode wrote: post #547
weberc2 wrote: post #505

Earlier quoted context omitted.

This is only true if your framework depends on global variables to manage request state. If your framework passes request state in as an argument to the request handler, then there is no state to reset. Don't use global variables and you don't have any of these problems.

How do you know whether other components (objects, modules) do not keep state between requests? Unless you 1) use language with pure stateless functions like Haskell or 2) delete everything after each request you cannot guarantee that. PHP uses latter approach. With PHP you can see your program as a pure function whose result depends only on arguments. You don't have to care about memory leaks like you don't have to…

Programming 101: scope your objects appropriately. If you have an object whose state is bound to the scope of the request handler, initialize it in that context ("don't use global vars" is just a special case of this rule). In other words, everything initialized outside your request handler's scope should have its state reused across requests. The PHP community never entirely learned this, so you guys are building workarounds. This isn't intended to be PHP bashing; just objective criticism.

Re: Taking PHP Seriously

#553

Post by mi100hael »

> Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost.

Python now has type hints that allow a similar migration for existing code.

https://docs.python.org/3/library/typing.html

Re: Taking PHP Seriously

#554

Post by toast0 »

arpa wrote: post #541
pc86 wrote: post #494

Earlier quoted context omitted.

I work in C# every day. I love the language, I love Visual Studio, I love the application lifecycle management features of the ecosystem. There's very little I don't like, or at least understand. I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.

And any PHP thing could be easily prototyped in C# using MVC framework or such. 0 to http-response time is easily comparable if not even faster to what you'd have with PHP. You don't even need IIS. C# is a fine language and I have enjoyed it thoroughly before returning to PHP after some years, but you also can breed monsters with it. Cheers!

touch public_html/foo.php gets me to a http 200 with a valid php file (with the assumption that i already have a public_html directory with mod_php or the like enabled), how fast can you get a C# to http 200 ? :)

Re: Taking PHP Seriously

#555

Post by justinhj »

nrser wrote: post #406
justinhj wrote: post #366

Earlier quoted context omitted.

It is easy if you are just willing to spend more money on servers. Often it's worth it.

it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be. i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale. everyone is tearing away adding features, and t…

I feel your pain, I also worked on a large MMO style mobile game backend, but my situation was a lot better because as you say AWS is a lot more mature at this point.

Dealing with limited resources such as MySQL and Redis is a problem you still have to fix when you move away from PHP though.

As for the Facebook runtime, for us it was a case of drop in HHVM, fix a handful of issues and get a 4x or 6x speed increase for free. You only need to change the way you write if you move to Hack, but I think I agree with you that's probably getting to the limit of the effort reward tradeoff before you rewrite in a different language.

Re: Taking PHP Seriously

#556

Post by incogitomode »

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…

Most of the cited successes were savvy early movers — every company mentioned aside from Slack itself is at least 10 years old. In the more mature, more varied tech space of today PHP seems like a non-starter.

Re: Taking PHP Seriously

#557

Post by foolinaround »

vatotemking wrote: post #398
bbcbasic wrote: post #380

Earlier quoted context omitted.

Dynamic content.

Underrated comment. To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.

> It falls apart when you have a large often-changing content.

Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?

Re: Taking PHP Seriously

#558

Post by foolinaround »

anexprogrammer wrote: post #244
brian-armstrong wrote: post #152

Earlier quoted context omitted.

An easier way to avoid those warts would be to pick a different language

PHP devs aren't expensive. Even good ones. It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier. PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintaina…

> PHP devs aren't expensive. Even good ones.

Would'nt the good ones logically move to a different language ( JS/Ruby etc ) where they could bill more?

Re: Taking PHP Seriously

#559

Post by bigtunacan »

nrser wrote: post #523
bigtunacan wrote: post #469

Earlier quoted context omitted.

In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails. I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core. So comparing PHP to Rails is a bit apples…

it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.

In this case it was a technical comparison; the original poster stated, "php's performance was an order-to-two or magnitude better than rails".

If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.

If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.

I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.

Re: Taking PHP Seriously

#560

Post by riprowan »

ddw wrote: post #353
increment_i wrote: post #336

Earlier quoted context omitted.

It would be an outlier company indeed who held an 'all hands on deck' meeting and said, "We're succeeding in spite of PHP everyone!" Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favour…

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right?

Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.

I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"

Post reply on HN