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

221–230 of 673 posts

Re: Taking PHP Seriously

#221

Post by wyager »

Aldo_MX wrote: post #202
wyager wrote: post #153

Earlier quoted context omitted.

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.

Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.

Re: Taking PHP Seriously

#222

Post by williamgb »

davidw wrote: post #181
williamgb wrote: post #176

Earlier quoted context omitted.

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.

Fair enough. I never claimed my dislike of "reasoning about" things was rational! 'Grok' definitely has a context, that likely does not include talking to non-hacker types like clients, board members, or whatever.

I understand your situation :) I keep a long list of seemingly innocuous words which, through no fault of their own, are repugnant to my ears. It's utterly irrational.

Re: Taking PHP Seriously

#223

Post by peteretep »

ux-app wrote: post #183
brian-armstrong wrote: post #152

Earlier quoted context omitted.

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

and miss out on all the awesome aspects of the language/environment?

What are "all the awesome aspects"? The being embedded in the web server and the benefits that brings I understand. The rest?

Re: Taking PHP Seriously

#224

Post by TazeTSchnitzel »

SolarUpNote wrote: post #196
mikey_p wrote: post #72

Earlier quoted context omitted.

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…

Doesn't Opcache take care of that? Using a large framework isn't really a problem because all of the classes, configuration, etc is all kept in ram.

The code itself is held in shared memory, so it doesn't need to be recompiled. However, you still have the application startup time to worry about.

Re: Taking PHP Seriously

#225

Post by calsy »

Come on, PHP is the 'Justin Bieber' of languages, everyone knows it. Its the most successful and widely used web server language in use and with anything so popular it has a large group of haters.

If anyone wants to come off like a 'serious' programmer, all they need to do is denounce PHP as a horrible aberration, a frankenstein of a language. Most don't even know about the changes in the language over the last decade, they just hate it to stay inline with their peers.

However, those opinions dont line up with the facts. PHP goes beyond semantics of language, it's a complete service for delivering dynamic HTML from the server. Why is it so successful? It is one of the most robust, well supported, battle tested languages to appear in the last 15 years. Its support is guaranteed on any hosting platform or cloud solution available. It has a large array of libraries capable of integrating with most any service whether that be databases, web apis etc. It has the ability to scale for high demand, as demonstrated by the many large corps that use it.

If you want to rip on PHP because it's cool, I think you're simply shooting yourself in the foot and ignoring a tool capable of performing almost any task you would require of it on the server side.

Re: Taking PHP Seriously

#226

Post by peteretep »

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.

If she does it at age 10, she still won't starve.

Re: Taking PHP Seriously

#227

Post by TazeTSchnitzel »

Nullabillity wrote: post #31
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…

Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT. You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.

> Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.

You are running it from RAM. PHP's OPcache, and HHVM, will both compile the code only once (well, HHVM will compile it multiple times due to JIT, but it only touches the disk once) and cache it.

Re: Taking PHP Seriously

#228

Post by bpicolo »

securingsincity wrote: post #208
bpicolo wrote: post #158

Earlier quoted context omitted.

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

Step by step with the ability to execute arbitrary expressions in the middle of it? That's the important bit. What VSCode extensions are useful here?

Re: Taking PHP Seriously

#229

Post by bpicolo »

bkanber wrote: post #220
bpicolo wrote: post #187

Earlier quoted context omitted.

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

Session cookies were basically invented for transient statefulness over HTTP.

I'm not referring to per-user sorts of things. You can't cache those locally in a sane way in any language. I'm talking about what would usually be memoizable sorts of things.

Re: Taking PHP Seriously

#230

Post by qaq »

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.

well nicer syntax vs not dealing with event loop for me it's nicer to use more verbose syntax. (I guess I am getting tired of Node too :) all thanx to getting spoiled by Elixir.
Post reply on HN