Hacker News Reader

Comment by dijit | Hacker News Reader

I don't doubt that PHP is becoming (has become?) a decent language. Especially with frameworks such as laravel which are mature and clean.

But PHP has a legacy, lots of bad PHP code exists already, bad practices are usually the first result on google and very "lazy" developers who never learned anything else exist and this muddies the waters very much when talking to people who prefer to build new things in PHP.

There's also the nitpicky fact that the old way of running PHP was that every page request runs the code from scratch, meaning you have to build state each time which is profoundly expensive and inefficient, although I believe people rarely do this anymore it's still definitely the default for most PHP projects I've seen. (both FOSS and proprietary).

I don't like your overgeneralisation about junior/mid/senior developers, the lines are super blurred in the real world. (I say this as a non-developer who works with developers)

View on HN

> There's also the nitpicky fact that the old way of running PHP was that every page request runs the code from scratch, meaning you have to build state each time which is profoundly expensive and inefficient,

This also means that you always have a clean state and makes horizontal scaling super easy. Also simplifies the code significantly, async code is much harder to debug and to reason about. Unless you really need top performance, and for most of use-cases you don't, running code through fast-cgi (especially with php-fpm) does the job just fine.

Statelessness allows you to press the back key and expect to go back to the previous page without any surprise. Shift-click, ctrl-click on any link and open the page in different tab. Work on the main tab for some time and then jump back to the old tab and still find everything works as expected.

Plus you can have 10 servers for load sharing and users can hit any server at random and still expect the site to work perfectly.

"There's also the nitpicky fact that the old way of running PHP was that every page request runs the code from scratch, meaning you have to build state each time which is profoundly expensive and inefficient"

It doesn't mitigate this perfectly, but using something like apcu or redis to store startup state is pretty common and often makes this a non-issue.

Literally the same thing can be said about any language that is not niche tho.

Also, wee nitpick of mine; you don't have to build any state on your own, the interpreter does that for you as one of the core principles of the system.

Pardon me, but how would you know as a non-dev?

Fair question, I suppose.

I'm in SRE, so I work closely with developers and programmers who build business logic, in fact I am surrounded by pretty much exclusively that except for a small supplement of testers and technical managers.

So, I have some exposure.

That and the very plain fact that the mindsets that you would use to delineate between "senior" and "mid" bands are just traits that could be apparent in varying degrees between people of any level.

I've had mid-level developers identifying business needs on a macro level with a well broken down bite-sized methods of achieving what they set out to.

I've had senior developers "informing" me about operating system semantics which were just not true.

You can be senior in some areas and mid-level/junior in others. This is true across the whole spectrum.

Precisely, people should refrain from informing on topics outside their area of expertise. Pretty rife in western companies, "too many cooks" etc, must be the democratic mindset that every voice counts equally.

If this is a comment about me suggesting that your overgeneralisation is unwarranted because it is outside of my direct field then let me just say it this way: It is always true that trying to define behaviours of seniority is an overgeneralisation. It does not depend on the field unless there are formal qualifications, and even then it's tricky.

That would probably rule out about 90% of the discussion on HN.

Reply on news.ycombinator.com