Comment by rpeden | Hacker News Reader

Comment by rpeden | Hacker News Reader

I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages).

I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major updates, and they've proven to be far less painful than I had expected based on the amount of PHP attacks I'd read online.

Maybe the snobbery toward PHP is a good thing? There are some really big PHP-based communities out there, Wordpress being probably the largest. And in these communities, there appears to be a large demand for paid consulting and plugins. Sure, there's a ton of competition on the low end, but it's an area where a really great developer could stand out from the crowd and do very well financially, especially for more complex consulting and dev work since so many good developers turn their noses up at PHP.

The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Python, Ruby and even Node.

The Wordpress codebase [plugin api included], though, is utter garbage.

[1] http://www.phpsadness.com/

[2] http://php.net/manual/en/language.expressions.php

[3] https://www.mail-archive.com/internals@lists.php.net/msg7196... (yes, i asked for this in 2014)

> The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C.

It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?

> The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3])

You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.

On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.

> The Wordpress codebase [plugin api included], though, is utter garbage.

Yes, yes it is. That's not the language's fault.

> On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it.

If you read the thread, no one could actually recall having ever seen code that relies on the current behavior. It has been discouraged in the docs for years. The stop-gap proposal was to have PHP7 deprecate it with a warning rather than silently changing the behavior. Then change the behavior in a future version (say php 8).

Disregarding any of that, this is an admitted language bug. It was not ever meant to work this way. Do you have a list of languages where ternary works backwards? PHP devs don't just work in PHP. Having one C-style language work this way and another C-style language (js) in another editor tab work the opposite way is a major PITA.

I'd rather they don't change it. I like my code to not stop working (python3, perl 6) when upgrading.

Also it's not a bug, more like a design oversight that doesn't cause any problem if you rtfm

> doesn't cause any problem if you rtfm

unfortunately, that's PHP's mantra for unexpected/inconsistent behavior (of which there is a plethora)

> It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?

It is also internally inconsistent in so many ways.

Half the array functions take arrays as the first arg, the other half the last.

explode and implode have different argument order requirements (one is strict, the other works either way).

Functions have a grab-bag of errors from returning null to false to 0 to strings to requiring error\_get\_last to even requiring an object specific error function (DateTime::getLastErrors).

Functions were named to make them have more randomly distributed hashes (http://news.php.net/php.internals/70691). Functions randomly do or don't have underscores, sane order, etc.

Some apis are in terms of objects (DateTime), some are not (getdate).

The whole thing is far less consistent than C. Some inconsistencies are from C. Most are PHP shit layered on top.

> You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.

It's a C-like language. Every c-like language does it the other way. I will totally judge a language that makes a decision that makes programmer's lives terrible with no justification. In this case, it's different in a way that often leaves to bugs and surprises.

C++ is a C-like language but C++ muddies up the difference between some operators due to operator overloading. This is an inconsistency.

Do you support that? No one will ever be able to convince me that "<<" and ">>" make sense to be read and write.

That's not the same thing and you know it. C++ didn't just randomly change the associativity of one of the operators. PHP screwed up ternery in a way that makes zero sense (ie, it's wrong in 99.99999% of use cases). It still catches me (and my colleagues) off guard even though we have years of collective PHP experience.

It doesn't matter, we're talking about php not C++. But yeah, "<<" and ">>" are at fairly internally consistent within C++ and don't generally confuse programmers or cause significant bugs in my experience, so I don't find them problematic. They did seem a bit weird at first, but they didn't cause significant problems.

Perhaps they do for you, and I accept your complaint about those operators as valid actually, but it's on a whole different level of badness than php, and again, we're talking about php. Just because "other languages suck" doesn't mean php doesn't, so that's not a valid argument against anything I said.

I'm saying neither of them suck. They both have small things "Wrong" with them that are only "Wrong" because I don't like them.

>they didn't cause significant problems

That's not a valid criticism of any feature. I'd say that the worst feature of any programming language yet has been pre and post -- and ++. Some of the nastiest bugs I've seen have come from there.

In both cases I avoid them. I only really use -- and ++ if I need to, just like ternary operators.

> Just because "other languages suck" doesn't mean php doesn't,

Ok what about other languages that are good? Python's ternary operator isn't the same as C-style languages but I still think of Python as being good.

If what it inherited from was inconsistent, why wouldn't it be too?

> The devs are ultra-conservative and stubborn to cause BC even at major version bumps

Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.

> The Wordpress codebase [plugin api included], though, is utter garbage.

I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?

Popularity.

WordPress is popular, php is accessible (you need notepad and an ftp client to start hacking) - combine the two, and you get a lot of "scratches my itch"-code.

It probably doesn't help that WordPress is an ancient code Base with a goal of running on the cheapest webhosts (who are slow to update to newer php releases).

So you get a lot of beginners that learn from messy old code, that generate more of the same.

It's a mess of global and file-wide variables, an unholy mix of poorly structured procedural code married with the odd "OO" abstraction.

There are good, even great php code bases - WordPress - and its plugins are not that.

To be fair, WordPress itself, and the core plugins are at least somewhat consistent, and after years of security holes follow a somewhat reasonable defensive coding practice. The terror lurks in popular third-party plugins, inspired/forked from older hacks. As is evidenced by a quick look at full-disclosure where seemingly every week someone's managed to make a plugin that's broken in some novel manner.

I've not been following closely lately, but for a plain php cms, one could do worse that cmsmadesimple. It's (was) pretty old-school simple php, but much simpler than something like Drupal.

The part that I didn't really understand is people accepting pull requests should be gate keepers for code quality, so amateur or not hopefully this shouldn't pollute the codebase. But you've touched on the core being reasonably decent and the real mess being with third party plugins so that makes more sense.

One of the responses to your mailing list post hits the PHP nail on the head: "Don't piss off users for purety."

As long as you don't mind working on "boring" projects, there is TONS of small businesses in need of custom work to be done. It's very lucrative, because most people like you said, turn their noses up at the thought of it.

Not-so-small businesses, too.

Boring isn't always bad. Last time I tried to create an interesting project, I ended up with a couple hundred MB of node modules before I'd even done much. :)

That's a fair criticism in node... I wouldn't want to work on it without an SSD (deployment is a different story)... the spinup and even npm install time on an HDD is dramatically slower than SSD.

It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express... And by the time you get to Hapi with a few addon modules for your needs, it'll get pretty big.

All of that said, I still prefer it to just about everything else I've worked in... though I haven't done anything on Go or rust, but would like to.

Yeah, the size of my node_modules directory doesn't bother me that much. I've worked on some large Node projects in the past, and didn't care too much about how many modules I had installed because I wasn't exactly running out of disk space.

It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.

Yeah, the migration to ES6-style modules, Webpack2 etc will help a lot. There's still some bits to work out... about ready to do a new version of a few module in NPM and just declare that said module need to be used with babel+es6, async functions and decorator transforms... I'm tired of waiting, and it'll make the modules themselves cleaner not having to transform before publishing to npm in the end.

It's funny that a lot of this stuff is finally making it into the browsers and platform, when I've been using it for almost 2 years now. Looks like async is going in behind a flag in node 7.

Reply on news.ycombinator.com