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

171–180 of 673 posts

Re: Taking PHP Seriously

#171

Post by biesnecker »

kmavm wrote: post #55
phreack wrote: post #8

Well this is seriously making me rethink my opinion on the PHP workflow, if Hack is as much of a game changer as the article claims? Could anyone here comment on their experiences with it, and its pitfalls?

You're asking about Hack, and the only response I see so far is about HHVM. So! I've seen Hack used in a multi-tens-of-MLOC codebase to gradually insert types. It made huge differences in the kinds of changes that were possible; you can, e.g., rename a class or method, or change the order of its arguments, with confidence comparable to that in a C++ codebase. Most developers hack-ified everything they could get their…

Yup, this. I work on (the original?) multi-tens-of-MLOC PHP-cum-Hack codebase, and writing new code is every bit as safe type-wise as C++, with none of the compile time. It's pretty great.

Dealing with the parts that aren't Hackified, though, is horrific. Complex codebases with no types are just ridiculous.

Re: Taking PHP Seriously

#172

Post by astrodust »

qaq wrote: post #29
kowdermeister wrote: post #15

Earlier quoted context omitted.

I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.

Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.

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.

Re: Taking PHP Seriously

#173

Post by rb808 »

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…

Amen. The ironic thing is most people believe that the fashionable language/framework du jour they're using in their project is "high quality code" that will be maintained like that forever, while turning their nose up at PHP code that is "disposable" but in reality more likely to outlast.

Re: Taking PHP Seriously

#174

Post by [deleted] »

tracker1 wrote: post #92
pcwalton wrote: post #61

Earlier quoted context omitted.

> 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…

Sorry, but GP is right here... you really don't need GC if the entire process ends and the memory is completely freed at the end of the request. Not that I feel cgi is the most efficient way to handle requests... but not needing the complexity of GC could be one advantage of that approach...

[deleted]

Re: Taking PHP Seriously

#175

Post by bkanber »

awinder wrote: post #163
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…

I may be waaay off base here, but wouldn't amazon's lambda function architecture sort of mirror the benefits of shared-nothing? It doesn't necessarily work like that under the hood, at least if I remember correctly your lambda function may live on past one request, but you must code as if that were the case

It does, but it comes with deep tie-in to AWS as well.

But also, you don't typically use lambda to serve pages or a full application, more commonly it's used for specific processing tasks, individual endpoints, and generally code that can run standalone.

Re: Taking PHP Seriously

#176

Post by williamgb »

davidw wrote: post #112
jandrese wrote: post #44

Earlier quoted context omitted.

I like the old hacker term for "reasoning about". Grok. It's much easier to grok a program when everything just runs from top to bottom and doesn't jump to a different third party library every 3 lines or have 15 layers of indirection and frameworks.

"Grok" is good. Perhaps it's that it sounds less pretentious, somehow?

Interesting! I have somehow developed the opposite opinion. The phrase "to reason" is plain English and uncomplicated. Grok, by comparison, is arcane and to the uninitiated is semantically opaque. The latter strikes me as a more suitable vehicle for demonstrating pretension.

Re: Taking PHP Seriously

#177

Post by krapp »

astrodust wrote: post #172
qaq wrote: post #29

Earlier quoted context omitted.

Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.

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.

Re: Taking PHP Seriously

#178

Post by teilo »

I would add one other big negative in the language design: The automatic import of the entire SPL.

Back when I was a green web programmer, I loved this feature. After working with Python for a good many years, I now abhor it.

Re: Taking PHP Seriously

#179

Post by leeoniya »

anarazel wrote: post #114
leeoniya wrote: post #62

Earlier quoted context omitted.

> the amount of repeated parsing Which should be near 0 if you can be bothered to enable OPcache in php.ini. Not only parsing/disk reading but also bytecode generation are bypassed.

Sure. But that doesn't really address the problem, just makes it smaller. You still need to reinstantiate a lot of runtime state.

I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into PHP7.

Re: Taking PHP Seriously

#180

Post by tracker1 »

pcwalton wrote: post #147
tracker1 wrote: post #92

Earlier quoted context omitted.

Sorry, but GP is right here... you really don't need GC if the entire process ends and the memory is completely freed at the end of the request. Not that I feel cgi is the most efficient way to handle requests... but not needing the complexity of GC could be one advantage of that approach...

It may seem that way at first, but space leaks during individual requests are way too easy otherwise. Think about something as simple as, say, parsing Mustache templates. The parser is probably internally making lots of little substrings to record the names of directives as it comes to them. You would think that this is O(1) in space, since you only need one (or a small number) of strings at a time, but without a GC…

I'm not completely disagreeing... I've worked on pipeline transformers in node where I exposed gc and ran it after each item in the pipeline was done. It would grow insane without it... likewise I can see that if you're transforming a lot of records for delivery in PHP it could bloat as well.

However, if you're handling requests well within a given memory threshold, it isn't always something you should worry about until it becomes a problem. In which case, you'll probably want to look at something like go, rust, erlang or others to handle improvements, or break off heavy parts into sub/micro-services.

Post reply on HN