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

151–160 of 673 posts

Re: Taking PHP Seriously

#151

Post by pcwalton »

nostrademons wrote: post #137
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…

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…

Yes, I know what the idea is. I highly suspect it won't be practical due to the reasons given in my other reply. We tried this with JavaScript in a very similar domain and the memory usage was unacceptable.

Re: Taking PHP Seriously

#152

Post by brian-armstrong »

chris_wot wrote: post #138
wyager wrote: post #110

Earlier quoted context omitted.

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

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

Re: Taking PHP Seriously

#153

Post by wyager »

chris_wot wrote: post #138
wyager wrote: post #110

Earlier quoted context omitted.

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

It's not just about the obvious "warts"; it's about the fact that PHP is not a well-designed language on the first place. A wart-free pig is still a pig.

Re: Taking PHP Seriously

#154

Post by skippyta »

bpicolo wrote: post #150

Really, the worst part of PHP in my experience has been the debugging facilities. Print-line debugging just doesn't cut it anymore, and things like xdebug and phpdbg just aren't elegant, are hard to configure properly, and don't work for all the relevant scenarios (trying to debug PHP running in a docker container is not a fun task). The quality of open-source libraries in the ecosystem is also pretty below what I've…

PHP has xdebug. You can debug interactively using an IDE like IntelliJ / PHPStorm or whatever floats your boat. Is that not enough?

Edit: I commented on this post before the OP edited the original with a longer form explanation. Originally it just said he didn't like the debugging and left it at that.

Re: Taking PHP Seriously

#155

Post by throwaway729 »

badminton1 wrote: post #122
throwaway729 wrote: post #101

Earlier quoted context omitted.

> But suddenly because you are an "engineer" this is acceptable? No, it's acceptable precisely because you aren't an engineer. We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legal…

No. And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY. Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted. You don't, because you have you keep this to yourself because you know it is wrong and not in t…

> Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.

Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT:

> because you know it is wrong and not in the best interest of your employer

Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employer. There is no prior obligation (aside from not literally breaking the law).

And within the structure of the company, the engineer has no legal or professional obligation prior to manangement. So, if parent's boss tells him "get this shit out the door ASAP maintainability and quality be damned", and then parent does exactly that, I think he'd probably be OK from an employment perspective. In fact, insisting on some modicum of security or readability might even get him in trouble!

Contrast that with the situation of a PE, who would be much more likely to answer "no" on the basis of professional ethical obligations which are prior to his obligations to his employer/immediate manager. And, when answering no, would be much more likely to have the leverage and respect necessary to survive an encounter with middle management.

Re: Taking PHP Seriously

#156

Post by tracker1 »

OhHeyItsE wrote: post #123

Much of this is valid in spirit. But to me, is irrelevant with the advent of Node. Node does all the good things the author describes. It does some terrible things too, but generally does them much less terribly than PHP.

I think one of the things that made node great, is standardizing on CommonJS modules, and error-first callbacks... That alone makes it much easier to build everything else on top of. JS does have some "bad parts" but they're easy enough to avoid via linting/testing.

NPM is another great/horrible thing in JS... people get hung up on the size of some packages, it's worth noting that a lot of that size doesn't go into your application, mainly because those packaging don't always know enough to exclude their samples, tests and documentation from the module as packaged in npm. Which is a mixed blessing.

You do get a lot of file bloat as it's not pre-build/bundled in npm (usually), and as such there is a lot of file-system access at startup (SSD strongly encouraged).

Through all its' warts, I'd still take it over almost everything else I've ever worked with.

Re: Taking PHP Seriously

#157

Post by toast0 »

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…

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request.

Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.

Re: Taking PHP Seriously

#158

Post by bpicolo »

skippyta wrote: post #154
bpicolo wrote: post #150

Really, the worst part of PHP in my experience has been the debugging facilities. Print-line debugging just doesn't cut it anymore, and things like xdebug and phpdbg just aren't elegant, are hard to configure properly, and don't work for all the relevant scenarios (trying to debug PHP running in a docker container is not a fun task). The quality of open-source libraries in the ecosystem is also pretty below what I've…

PHP has xdebug. You can debug interactively using an IDE like IntelliJ / PHPStorm or whatever floats your boat. Is that not enough? Edit: I commented on this post before the OP edited the original with a longer form explanation. Originally it just said he didn't like the debugging and left it at that.

I mentioned that in my post. Needing a full-fledged IDE for some baseline debugging isn't what I look for. And, like I said, doesn't "just work" in all scenarios.

Plus, you can't do inline code execution (the interactive part) if you are using xdebug for PHPUnit tests (even in PHPstorm). It's a really flawed experience, where getting it to half-work is a frequently frustrating experience.

Even the baseline REPL is flawed. PHP went again and forgot the P, so you have to figure out the correct-of-many-variant print statements and remember to put it before the code you want to run when using the 'REPL'

Re: Taking PHP Seriously

#159

Post by bbcbasic »

badminton1 wrote: post #142
bbcbasic wrote: post #135

Earlier quoted context omitted.

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

Sure. But if she does the same at age 10, it would be time to have a conversation. Unless you are not very engaged in your parenting.

Of course. Horses for courses.

Re: Taking PHP Seriously

#160

Post by jacobsenscott »

My experience is that programming is fun no matter what language you use. I've used C, C++, Python, VB6, C#, Java, Ruby, elisp, PHP and a little clojure and some others. I don't get all the language hate.
Post reply on HN