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

201–210 of 673 posts

Re: Taking PHP Seriously

#201

Post by krapp »

astrodust wrote: post #194
krapp wrote: post #177

Earlier quoted context omitted.

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.

that's fair - your only options in PHP are array notation or arrows for objects, dots are much easier.

Re: Taking PHP Seriously

#202

Post by Aldo_MX »

wyager wrote: post #153
chris_wot wrote: post #138

Earlier quoted context omitted.

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.

Which of the top languages is actually well designed? All of them have their area of opportunity.

Re: Taking PHP Seriously

#204

Post by bkanber »

astrodust wrote: post #165
bkanber wrote: post #132

Earlier quoted context omitted.

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.

This really depends on your definition of "great".

Who does it better?

Re: Taking PHP Seriously

#206

Post by Klathmon »

bpicolo wrote: post #187
leeoniya wrote: post #179

Earlier quoted context omitted.

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

There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens. In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

But in most languages http requests should be stateless. Even in node or Java you should be hitting the db to pull that info anyway, as sharing the last info in the process leads to scaling issues as well as big problems if the application crashes.

The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"

Re: Taking PHP Seriously

#208

Post by securingsincity »

bpicolo wrote: post #158
skippyta wrote: post #154

Earlier quoted context omitted.

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

You should definitely try vscode. I've found it to be the easiest to set up step debugger for PHP and it's not a heavy ide like intellij

Re: Taking PHP Seriously

#209

Post by urbanxs »

paulddraper wrote: post #89

> Virtues of PHP > First, state. Every web request starts from a completely blank slate. > Second, concurrency. An individual web request runs in a single PHP thread. > Finally, the fact that PHP programs operate at a request level Isn't this just "virtues of Apache modules"? There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global requests virtues of these languages too? --- Even if you do some…

Laravel is a collection of bad design

Re: Taking PHP Seriously

#210

Post by rpeden »

tracker1 wrote: post #129
rpeden wrote: post #9

Earlier quoted context omitted.

Boring isn't always bad. Last time I tried to create an interesting project, I ended up with a couple hundred MB of node modules before I'd even done much. :)

That's a fair criticism in node... I wouldn't want to work on it without an SSD (deployment is a different story)... the spinup and even npm install time on an HDD is dramatically slower than SSD. It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express..…

Yeah, the size of my node_modules directory doesn't bother me that much. I've worked on some large Node projects in the past, and didn't care too much about how many modules I had installed because I wasn't exactly running out of disk space.

It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.

Post reply on HN