Live data from Hacker News

Taking PHP Seriously (2016)

slack.engineering

111–120 of 150 posts

Re: Taking PHP Seriously (2016)

#111

Earlier quoted context omitted.

I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.

I've worked at PHP shops - working on a PHP project for a consultancy right now - and there's 0 issues about 'shortcomings of the language'. "past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from…

As I read this I'm upgrading an old Python 2.4 app to 3.8. It isn't just PHP.

Re: Taking PHP Seriously (2016)

#112

Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures.

According to who? PHP is still behind ~70% of public websites: https://w3techs.com/technologies/details/pl-php

Re: Taking PHP Seriously (2016)

#113
post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

No, really no, as someone who has worked on code bases where people followed the path of least resistance (PHP in this case) things turned into a giant mess of human suffering. Pick a language that has tooling for what you want to achieve otherwise everyone reinvents it or just makes a mess.

Re: Taking PHP Seriously (2016)

#114

Earlier quoted context omitted.

I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.

I've worked at PHP shops - working on a PHP project for a consultancy right now - and there's 0 issues about 'shortcomings of the language'. "past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from…

Can you elaborate on the failed node project?

Re: Taking PHP Seriously (2016)

#115

Anyone here want to share their opinion's on Magento? The small time I spent with it left me with a feeling it was the most over engineering piece of software I've ever worked with. It's made to build a market for modules to buy and isn't made to run an e-commerce site. All written in PHP.

Dumpster fire filled with toxic waste.

Re: Taking PHP Seriously (2016)

#116
post #10

This seems to be an unpopular opinion in the tech world, but I honestly enjoy working with PHP. It's such a simple, robust language, and you can use it in many different ways, depending on what you're building (OOP, scripting, microservices, etc).

20 years for me, for sure. Maybe a touch longer.

I love it. My professional career moved to .NET and Python over the last decade, but if I'm building for myself, I build in PHP.

Whatever foibles people claim are in PHP are really just personal gripes about features they don't like, while ignoring all the other pieces that are ideal for web API development. Frankly, I believe first-class duck-typing and nearly-zero impedance with JSON make PHP a first-class citizen of the web. Duck-typing pairs so well with dynamic typing that I don't know why so many languages abuse themselves with the alternatives.

I remember the Docker switchover being very confusing. Why do all these people need such elaborate instrumentation around their development environments? With PHP, the kitchen sink is always there, and always consistent (we'll ignore money_format() for now). Once I really started using other language environments, the pain points that necessitated Docker cropped up, and of course the deployment benefits are excellent. It was just a very confusing couple years trying to figure out why the Node and Python guys were living like animals.

Anyways, cheers to another 20.

Re: Taking PHP Seriously (2016)

#117
I've ended up treating PHP like shell scripting, with that mind set it becomes much more bearable for writing new code in... much like bash, you don't dare write anything too complex, yet can appreciate it for being a well positioned language for the specific type of task (and I say that having written lots of quite long but well composed bash scripts).

Unfortunately PHP is more capable as a language than shells while still having all those poorly thought out parts that will make you hate it if you try to exploit it to it's full capability.

Of course this mind set doesn't help much for existing massive code bases where all of the application logic is written in PHP.

Re: Taking PHP Seriously (2016)

#118

Long live PHP. 15 years of PHP dev work. Games, mobile apps, health care, etc. I have been unemployed for 2 days in 15 years. PHP runs %80 of the internet. Talk to anyone at facebook that wears a suit on friday -- they code PHP (and it seems to scale for them). I think I will be 90 years old hacking on PHP.If you really don't like how the arguments are passed just use an IDE. Or get stuck with real problems like a tr…

I'm old enough to remember GoPHP5 and the shit storm that transition was

Kinda funny having php devs shit on python backwards-compat

Re: Taking PHP Seriously (2016)

#119
post #18

The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.

I often hear engineers rave about lisp. Is that really such a superior language?

Superior at what?

Meta-programming? Yes. Object-oriented programming? Meh. CLOS is nice, but not vastly superior to anything else. Something else? Depends on what that something is.

Re: Taking PHP Seriously (2016)

#120
post #77

Earlier quoted context omitted.

Really depends on what the business is doing. Chewing through TBs of data every hour? Probably not a good idea to use Ruby. Doing a bunch of really heavy math? Probably not a good idea to choose PHP. Doing a SaaS service? C++ probably isn't a good choice. There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply…

I hate to be "that guy" but I see no reason not to use PHP for all three of those things. PHP is faster than Ruby. [1] PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2] PHP is an extremely popular language as the backend for SaaS,…

> PHP from a local script does math just fine

It depends on the definition of "just fine" really, not to be argumentative. I've written quite a few algorithms processing big numbers (e.g. numbers with digits in the megabytes) and PHP struggles, where other languages like GO are several times faster and often far more easy to parallelise whereas with PHP if I want to try and use the multiple cores my CPU has, I need to look into pthreads or worse, write worker scripts that I execute with backticks or curl, it's clunky for that use-case. I wouldn't even know where to start thinking about how to run my algorithms in the GPU with PHP.

I say this as primarily a PHP developer in my paid profession, and PHP is my go-to for any kind of web development or if I want to prototype an idea - it's a very expressive and intuitive language but there are always use-cases that any language is decidedly unsuited to, even if it's "technically" capable. I wouldn't build a website in native C, even though I know it's "technically" possible for example.

Post reply on HN