Comment by epicgiga | Hacker News Reader

Comment by epicgiga | Hacker News Reader

PHP is a fantastic language, and my personal favourite. It was the first language written with web serving in mind. It is packed with features due to all the adding to it over the years, meaning you can write code how you want, no how they want.

What it also acts as is a good barometer of dev mentality. When a dev declares PHP is a [expletive] language, he's telling me how he's going to be to work with, how he's going to engineer his work, and how concerned with adding value to the business he's going to be versus playing with "hot new tech". Even if it's for a .NET role.

The plurality of the internet is PHP back, html/css/js front. Those who thumb their nose at that are profoundly arrogant, and probably currently experimenting with their 8th new framework for the year.

Junior devs do as they're told and don't form opinions.

Mid devs know enough to be dangerous, run their mouth on everything, and bad mouth anything that isn't precisely their opinion or something they personally like.

Senior devs see the big picture, have realised the folly of their earlier ways, have a healthy respect for practical reality, and are more concerned with codebase integrity than in if it contains "hot new tech" (fuckarounds).

This is why it's critical to have truly senior devs at the top of the hierarchy, as otherwise there's no one to suppress the mid level devs, who will in turn mislead the juniors.

Which other languages besides php do you know well? I'm asking this because of your outlandish claim that php is fantastic.

Also the rest of your comment seems highly defensive. You seem to imply that people who agree with you must be senior, while people who disagree must be junior or even worse, something in between. It sounds like you have been bitten by discussion where facts against your conviction were presented, and you were unable to factor that into your views. Am I at all close or completely off the target?

I get the impression he/she is saying that someone who uses explitives to describe a programming language is someone who has a higher likelihood of not having objective reasons for disliking it.

Even if I prefer tool A over tool B I can still find merit in tool B. By using explitives I demonstrate I may be unwilling to use tool B if it's requested of me.

As for the junior employee comment- I think the point was that someone with less experience is either repeating what they've heard or they don't yet have an opinion due to lack of experince.

After years of working with PHP, my take away was similar to C++: There's a great language in there, somewhere. Limit yourself to a subset of the language which is sane, follow all of the PSR standards, and the result is quite nice.

After all of that, you look at your coworkers' code and realize they either (1) picked a different subset than you did, or (2) PHP is their first language and they have no idea what they're doing.

I mostly stay away from web development now, but if I were to do a new web project, I might still choose PHP if I knew I'd be working with a small, experienced team. It's a highly productive language.

This is why I think dev needs way stronger hierarchy. The typical flat hierarchies are trash for maintaining long term quality code and thus productivity.

All juniors should have to PR everything through seniors. All mids should have to PR at least a portion to seniors. All seniors should be vetted by the best dev the business can afford. That's the age old master-journeyman-apprentice structure, tried and tested.

At my firm, attempting to weasel out of that mentorship responsibility, such as seniors just clicking through trash PRs, or much much worse: trying to falsely automate it with git hook stuff, gets a "are you asking me to put you on a performance improvement plan?".

Your comment on the other hand comes off as very hostile - essentially, if you like PHP it's because you don't know better - it's because you only know that language.

Yes, that is exactly what I am claiming. I base the claim on my knowledge of programming languages, and also on my previous experiences with php teams.

To combat this claim, please provide us with data or anecdotes instead of false accusations of hostility.

When it comes to programming languages, I am hostile towards falsehood only, not towards any individual or group of people.

BASIC, then C and C++ with some ASM (embedded systems), then Java (android apps), then Python, then node & PHP & js/html/css, as proficiencies. Smattering of other things as "have useds", inc. clojure, R.

Interestly, it's the contrary to what you've inferred. Last time I talked about this topic in person, one of the typical mid level language snobs loudly and obnoxiously declared "PHP is a shit language, a really shit language", with the typical arrogant dismissive tone.

But as all experienced devs know, you program _into_ the language, not with the language. The more opinionated the language, e.g. Java and it's traditionally zealous adhesion to OOP and obstruction of other paradigms like functional, the harder it is to do that.

Hence the reason I like PHP is because it's the opposite of the weak minded (who make up their mind of "the one true way", based on little, and stick to it come hell or high water), and instead it leaves it up to you, to program _into_ as is fit for the project.

Plus the fact that it's interpreted, which acts as a good barrier to the premature optimizers. And the fact it's been around so long that it dominates the internet so there's no shortage of work in it.

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)

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.

> 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.

Reply on news.ycombinator.com