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

131–140 of 673 posts

Re: Taking PHP Seriously

#131

Post by gravypod »

leeoniya wrote: post #4
rpeden wrote: post #2

I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages). I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major u…

The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Py…

> 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 language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.

On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.

> The Wordpress codebase [plugin api included], though, is utter garbage.

Yes, yes it is. That's not the language's fault.

Re: Taking PHP Seriously

#132

Post by bkanber »

anindha wrote: post #51

Doesn't Slack use Java for its messaging system? That's not mentioned in the blog why they didn't use PHP for this.

PHP is great for HTTP requests. It's not that good for listening on sockets, running an event loop, etc, which is what you're likely going to do with real time messaging.

Re: Taking PHP Seriously

#133

Post by bbcbasic »

JohnnyConatus wrote: post #38
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…

But what about all of the successful Haskell startups? /s

There are some.

But business success is largely orthogonal to language choice. I.e. when you buy a paid Github plan do you check what language they write the site in?

Of course a strongly typed languages should tend to have less bugs and that will save money. But saving money is only useful for those with revenue to being with.

Re: Taking PHP Seriously

#134

Post by dom0 »

merb wrote: post #57

> a typical Python application server, e.g., the debugging > cycle will look something like “think; edit; restart the > server; send some test requests.” the "most typical" Python stack (wouldn't call it a application server) is probably built with Django where you don't reason about the Server restart, it's as fast as changing something in PHP. P.S.: I don't use Python that much anymore. Other people would say that…

The typical Python Web app debug cycle is "think; write regression test; fix test[; confirm fix manually as well]".

And the subcycles are literally "Change -> [run test | send test request]".

Re: Taking PHP Seriously

#135

Post by bbcbasic »

badminton1 wrote: post #99
piotrkubisa wrote: post #83

Earlier quoted context omitted.

I can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like th…

People that have that mentality, is like: - You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife... - When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands). "get shit done"... use spoon as a knife and knife as a fork, or try to…

Works for my 1 year old. Guess what: She hasn't starved.

Re: Taking PHP Seriously

#136

Post by tracker1 »

orf wrote: post #126
rrdharan wrote: post #7

Earlier quoted context omitted.

Zero startup time and a serious JIT aren't actually available in Python or Ruby even after all these years. I would be hesitant to dismiss the significance of those - although I'm admittedly biased, having worked with Keith previously as well as on an erstwhile "competitor" to HHVM (talariatech.com).

> Zero startup time My pretty heavy Django app takes about half a second for Gunicorn to boot 6 workers then it's off to the races. That might as well be zero startup time.

Similarly many of the node apps I've worked with have about a half second or less of startup (unless pre-warming database connections, that takes more time).

Re: Taking PHP Seriously

#137

Post by nostrademons »

pcwalton wrote: post #61
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…

> You wouldn't need much of a GC when the process is killed every time Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me… Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually reque…

The idea here is that the webserver forks & execs a new process for every request, allocates a bunch of pages, and then runs to completion, at which point the process finishes and the memory is returned to the OS. It's essentially using the OS as an arena, where you can allocate memory at will just by bumping a pointer and then the whole thing is freed at once at the end of the request.

It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.

Re: Taking PHP Seriously

#138

Post by chris_wot »

wyager wrote: post #110
brian-armstrong wrote: post #98

Earlier quoted context omitted.

I'll offer an alternate hypothesis. Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum. It's easy to cherry-pick the winners and miss all of the t…

Precisely. This is classic base rate fallacy. If tons of people use PHP because PHP devs are cheap, there are bound to be a ton of successes despite the fact that it's a horrible technology in many respects.

Perhaps. But that rather begs the question. PHP has horrible bits, but in fact from what I've observed in the last year or so is that whilst it has in the past been fairly horrible, much of what made it awful can be entirely avoided.

If you aren't following the PHP Framework Interop Group (http://www.php-fig.org) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altogether, and those that can't quite possibly can be worked around through configuration.

Re: Taking PHP Seriously

#139

Post by Siyo »

sciurus wrote: post #68
Siyo wrote: post #24

Earlier quoted context omitted.

There are plenty of competitors in this space, they just don't use the CGI model of spawning a new _OS_ process for every request. You have Erlang/Elixir that have their own lightweight processes that don't share memory and have independent GC. And you can build similar systems on Java/Go. The difference is that in those language you have a choice. There are certain types of applications that you just can't reasonabl…

"they just don't use the CGI model of spawning a new _OS_ process for every request" Which isn't what PHP does, fwiw.

What do you mean exactly? I mean yeah, it's a bit different with FastCGI when you have a pool of persistent processes. But you still basically boot up your whole application every time a request comes in. Opcode caching helps with loading code, but not execution. And you're still working with OS processes for concurrency, which is not ideal.

Re: Taking PHP Seriously

#140

Post by dendory »

I don't consider myself a programmer, just someone working in IT that writes a lot of code, and to this day when I want to write any type of web page or web based "app" PHP is my goto tool. I can write my HTML and add PHP logic directly inline whenever I need it, and get the job done in no time. Sure I could spin up a node.js framework, use routing, create classes and objects, etc.. But to 99% of my needs it's just not worth the extra time.
Post reply on HN