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

281–290 of 673 posts

Re: Taking PHP Seriously

#281

Post by bkanber »

aikah wrote: post #265
bkanber wrote: post #186

Earlier quoted context omitted.

PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness.

> PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness. PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it'…

I would argue that PHP is more stateless than Node, for instance. Things that happen in previous requests do not affect following requests in PHP, unless you're explicitly using shared state. That's not the case in node, it isn't the case with most Java HTTP server implementations, and it wasn't the case in Rails back in the day (don't know how it is now).

Re: Taking PHP Seriously

#282

Post by wyager »

brassic wrote: post #275
wyager wrote: post #221

Earlier quoted context omitted.

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.

Haskell is also more than 20 years old.

Which is why I fault PHP at least a little bit :)

Re: Taking PHP Seriously

#283

Post by bkanber »

aikah wrote: post #274
bkanber wrote: post #204

Earlier quoted context omitted.

Who does it better?

Unless you are using ReactPHP, PHP doesn't handle Http requests in any serious production configuration, the server fronting PHP does( Apache ,Nginx). But PHP wasn't design with Async programming in mind so using ReactPHP is more than tricky since most operations are blocking.

That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP, and with php-fpm and mod_php it has first class support with Apache and Nginx. Node isn't very good at HTTP, Python doesn't have first class support with HTTP servers, Java has great HTTP libraries but is stateful, etc.

If you want to handle HTTP requests quickly, reliably, repeatably, with minimal setup and maintenance, I still argue that PHP is one of the best. And yes, because of Apache and Nginx, but that doesn't nullify the point.

Re: Taking PHP Seriously

#284

Post by Aldo_MX »

wyager wrote: post #221
Aldo_MX wrote: post #202

Earlier quoted context omitted.

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.

> we should definitely stop using them

That will never happen, you can't write code like this in Rust:

  
  
    
    Customers
Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low.

The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the last years, fail to appreciate the effort behind projects like Symfony, and become completely foreign to the current best practices.

[1] https://leanpub.com/cleanphp

Re: Taking PHP Seriously

#285

Post by codedokode »

qwertyuiop924 wrote: post #266
codedokode wrote: post #236

Earlier quoted context omitted.

I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?

Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system. There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.

I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class.

And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.

Re: Taking PHP Seriously

#286

Post by antjanus »

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…

Now hang on, doesn't Go do that?

Re: Taking PHP Seriously

#287

Post by minitech »

bkanber wrote: post #281
aikah wrote: post #265

Earlier quoted context omitted.

> PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness. PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it'…

I would argue that PHP is more stateless than Node, for instance. Things that happen in previous requests do not affect following requests in PHP, unless you're explicitly using shared state. That's not the case in node, it isn't the case with most Java HTTP server implementations, and it wasn't the case in Rails back in the day (don't know how it is now).

Any language is stateless until you explicitly share state; the other languages just make it easier to share state. It’s not a bad design decision – makes them more versatile, or at least more cleanly usable outside of serving webpages – but is something to avoid in similar applications for sure.

Re: Taking PHP Seriously

#288

Post by hondo77 »

toast0 wrote: post #120
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…

> If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a…

If I wanted to embrace garbage every day I would have skipped college and went straight to being a bum. Life is too short to "embrace the garbage" every day.

Re: Taking PHP Seriously

#289

Post by wyager »

Aldo_MX wrote: post #284
wyager wrote: post #221

Earlier quoted context omitted.

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.

> we should definitely stop using them That will never happen, you can't write code like this in Rust: Customers Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low. The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the la…

I don't know if you can do that in Rust (I suspect you can with some effort), but you can certainly do it in Haskell (with slightly different syntax, of course) using a library like Blaze-HTML5.

Your argument is a bit spurious; you're right insofar as you can't write PHP in a language that's not PHP.

Re: Taking PHP Seriously

#290

Post by qwertyuiop924 »

codedokode wrote: post #285
qwertyuiop924 wrote: post #266

Earlier quoted context omitted.

Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system. There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.

I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class. And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fie…

That's because many dislike prototypical inheritance. It's perfectly usable.

As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.

Post reply on HN