Live data from Hacker News

Taking PHP Seriously

slack.engineering

621–630 of 673 posts

Re: Taking PHP Seriously

#621
post #4

Earlier quoted context omitted.

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 Py…

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

Re: Taking PHP Seriously

#622
post #619

Earlier quoted context omitted.

I know of CGI scripts (and the newer faster alternatives), I was wondering why more languages don't specifically target that kind of setup, playing to its benefits and trying to minimize the downsides.

Oh, sorry. I guess it's two-fold then: a) it's not as popular and cool, and then b) not much needs to be done to target it anyways, as most often being a good unix citizen suffices, you get the input and write the output to stdout, what's in between is application realm and whatever you do is up to you.

No worries!

I completely understand the "trendy" part. Sadly even language/frameworks need marketing, and doing things in a "wasteful" and "slower" way but simpler is gonna be a tough sell even if it might be the best move.

I just feel that there is a space for a "better PHP". One that uses a better base language, but still keeps the benefits from the language like the simplicity of the "think edit reload" cycle, the shared nothing architecture that makes programs easier to write and simpler to test, and the horizontal scaling.

Re: Taking PHP Seriously

#623
post #619

Earlier quoted context omitted.

Oh, sorry. I guess it's two-fold then: a) it's not as popular and cool, and then b) not much needs to be done to target it anyways, as most often being a good unix citizen suffices, you get the input and write the output to stdout, what's in between is application realm and whatever you do is up to you.

No worries! I completely understand the "trendy" part. Sadly even language/frameworks need marketing, and doing things in a "wasteful" and "slower" way but simpler is gonna be a tough sell even if it might be the best move. I just feel that there is a space for a "better PHP". One that uses a better base language, but still keeps the benefits from the language like the simplicity of the "think edit reload" cycle, the…

I've not worked on many CGI stuff (other than little things I use myself) but Python has all the housekeeping done. See this other post of mine that has an example of an interactive hello-world: https://news.ycombinator.com/item?id=12712067 . And then, Perl is used for all sorts of CGI stuff. Both have good database support. CGit [1] is a git web interface written in C.

[1] https://git.zx2c4.com/cgit/about/

P.S. An important thing that contributes to the success of PHP is the amount of hosting services that support it.

Re: Taking PHP Seriously

#624

There have been huge improvements made with PHP over the past few years. PHP 7 is great and I would choose it over Hack. Modern PHP using autoloading (Packagist & Composer) and an MVC structure allows for rapid development. With frameworks such as Laravel, you can get something up quickly or just pull in Packagist libraries you need if you don't want the bloat of a framework. I recently finished up a fairly complex w…

What was the web app you made?

Re: Taking PHP Seriously

#625
post #488

Earlier quoted context omitted.

C#: windows or mono-on-linux Java: keyboard wear Scala: not enough programmers Python: not bad Ruby: too slow Haskell: math grad required

The .NET CORE is now open source and cross platform. Cross platform compatibility with the exact same source code, and the killer features/speed of C# makes its my personal choice for a server-side language. I would like to add that C# devs are not cheap and also seem to be slightly more limited in today's market compared to PHP devs.

If you are running .NET code in production on a non-Windows platform today, then you and your team are probably braver and more willing to work around issues than most. I hope that running .NET code on Linux becomes the common case, but I suspect that we are still a couple of years away from that.

Re: Taking PHP Seriously

#626
Language matters too less, What matters is how it is being used. A Java project may be meanly architected, while PHP code may be architected with good quality. Its is the quality of architecture and code what makes projects sustainable(i.e technically).

Re: Taking PHP Seriously

#627
post #353

Earlier quoted context omitted.

But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.

At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).

[deleted]

Re: Taking PHP Seriously

#628
post #255

Earlier quoted context omitted.

IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"

> IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there. Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there.…

Except you still need autoloading configured for most libraries in the ecosystem to work, unless you want to manually chain absolutely huge quantities of requires.

Re: Taking PHP Seriously

#629
A lot of projects do a rewrite from PHP to Ruby on Rails or some equivalent migration. What the project really needs is a rewrite/refactor/cleanup however it's much easier to frame that in the context of going to a "better" choice than it is explaining it just needs a rewrite with better practices/engineers (ie maybe more and easier tests or using the prior prior/current architectural lessons to create a better architecture). The reality is one could just rewrite it in the original language/stack but that is apparently harder to sell even though it's less risky.

So if the first language/stack is less respected, it makes it easier to sell that rewrite to non-technical/management. Thus PHP is a great choice for the first stack.

The one huge trap here is if the second team isn't experienced enough in the holy grail (next) stack. I've seen that and been relieved to walk away from those projects/companies.

Re: Taking PHP Seriously

#630

Earlier quoted context omitted.

Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.

It's worth noting that it's compiled JavaScript vs. interpreted PHP. With something like HHVM the PHP version would likely be a lot faster.

Compiled JavaScript?
Post reply on HN