Stop writing PHP like it's 2009
florianlaplantif.wordpress.com
florianlaplantif.wordpress.com
The author could have chosen to write about PHP best practices that are ignored in the ecosystem at large, but instead chose to evangelize HHVM features.
For anyone who currently writes PHP like it's 2009 and wants to learn a better way (without dropping PHP entirely):
http://www.phptherightway.com/
https://www.reddit.com/r/phpsec/
If anyone prefers to drop PHP entirely, that's fine too, but that's not the only good answer and pretending that all PHP is bad (like many of the comments on this thread already do) is very disingenuous.
1) highly complex (and long!) build processes
2) memory issues: I have yet to see a reasonably complex Java application, both desktop and web, use a reasonable amount of RAM. Also, the fact that the JRE is long-running inevitably leads to memory leaks whereas in PHP every request and its environment get torn down at its end
3) overabstraction and literally hundred-lines-long stack traces which make debugging next to impossible. However, the trend seems to be heading this way in PHP too, so I don't know how long that advantage still holds.
Definitely true. Laravel has this issue with the added bonus of magic methods and Facades all over the place.
2 of my favorites are https://getcomposer.org/ and https://laravel.com/
Edit: that's not to refute what you've said or anything.
Composer and the PSR initiatives have totally changed the feel of working in this ecosystem for the better.
PHP is catching up to what other languages have enjoyed as a given for over a decade. It's very confused. There's been absolutely zero effort to overhaul the core PHP API which is, on the whole, absolute junk. Frameworks like Laravel do their utmost to insulate you from having to use it too much for the ugly things.
As an example of what could happen, JavaScript has gone from this ugly, useless language that would crash your browser if used too much to something that's now widely deployed and powers significant web properties both client-side and server. The improvements to the language have been dramatic, ES6 code is words apart from JavaScript 1.
In another 5 years JavaScript will hit another milestone, Java will evolve, and PHP will still be PHP.
If you were involved with the internals team at all, you would know this is not true.
Was released in 2013.
> Laravel is a "at least it's not garbage" framework.
How many PHP frameworks do you actually know?
> Find something in an array?
One function call(PHP 4 >=): http://php.net/manual/en/function.array-search.php
> PHP is catching up to what other languages have enjoyed as a given for over a decade.
Can you list the things that Java and JavaScript had for over a decade before PHP?
> which is, on the whole, absolute junk.
Do you have proof of this?
> Frameworks like Laravel do their utmost to insulate you from having to use it too much for the ugly things.
Just like frameworks in any other languages.
> JavaScript has gone from this ugly, useless language that would crash your browser
Have you seen the amount of JavaScript modern JS frameworks generate? We are now in the megabytes.
> deployed and powers significant web properties both client-side and server
PHP powers the worlds biggest social network, what's your point?
> The improvements to the language have been dramatic, ES6 code is words apart from JavaScript 1.
There was also a decade of inactivity: https://en.wikipedia.org/wiki/ECMAScript#Versions
You have to use transpilers if you are planning on running it in the popular browsers even for ES6.
Even the latest versions of JS retain the brain damage from older versions(for backwards compatibility).
> In another 5 years JavaScript will hit another milestone, Java will evolve, and PHP will still be PHP.
It took JS more than a decade for it to get support for classes, I wouldn't hold my breath.
A lot of these decisions are based on "what will pay the bills today and in the immediate future?" rather than purist idealism.
A lot of businesses use Java. Java experience is more useful for getting into mobile app development with Android. There's value to be had in learning and writing Java. But the demand for PHP doesn't cease to exist because Java is cool or useful.
https://w3techs.com/technologies/overview/programming_langua...
PHP has vastly out-lived its welcome. I'm not saying Java is immeasurably better, it's got a whole different set of problems, but it's an example of a language that's got a better tool-set than PHP ever will.
The debugging tools for Java are really amazing because writing good, threaded Java code can be wickedly hard. The tools for PHP are absolutely anemic by comparison because it's never had the same exposure to enterprise environments.
I'm no fan of Java, but if you're writing Java, you may as well write Java.
'used to be' being the key words here. PHP is __still__ being used.
> PHP has vastly out-lived its welcome.
Care to explain why you believe that? C is older than PHP and is still around.
> but it's an example of a language that's got a better tool-set than PHP ever will.
Don't know about the PHP toolset you have been using, but I take Composer over Maven any day. If you are talking about IDE support, PHP7 IDE support is as good as Java IDE support. Can you give me examples of tools that are better in Java?
> The debugging tools for Java are really amazing because writing good, threaded Java code can be wickedly hard. The tools for PHP are absolutely anemic by comparison because it's never had the same exposure to enterprise environments.
PHP web applications use a process-based model, therefore debugging threads is irrelevant.
> I'm no fan of Java, but if you're writing Java, you may as well write Java.
I recommend you try out the latest Spring framework(Java) and then go try out the latest Symfony(PHP) and you'll see why you would want to use PHP in some cases despite it having similar OOisms.
- Existing Java frameworks and libraries are difficult to obtain and maintain and difficult to work with (PHP libraries/frameworks are available in central repository - packagist, and are on github)
- Not much difference in performance - because most operations are IO bound in web context - also, PHP extensions are implemented in C - so you could implement your performance-critical parts as a C extension (or if your architecture allows it, in any other language and run as a different service communicating async with your application)
The amount of boilerplate in "good" Java code is substantial (like 20-30% more lines) compared to "good" PHP in practice. At least imho/experience.
The bad:
"Use HHVM". Do not do this, just upgrade to PHP 7. HHVM does have better performance [in some cases, not all], but it also has many unsupported modules [such as Memcache based sessions]. It's difficult to get improvements added and you're going to get frustrated by something people in the mainsteam PHP branch can do that you cannot do.
?int $var = null;
This is a question of style. Personally, i can read it, but it is a little odd and I've seen people get confused over it. I'd personally avoid it. The null check and type check is much clearer.
Edit: And my point here is basically that less experienced programmers will get it, which makes the barrier to entry lower. Going back to my previous statement, without a better reason, I'd encourage self documenting code and less abstract approaches. This is a pretty mild one, easily looked up...and probably a great thing for people to learn, but still more complex at the end of the day. Language is almost irrelevant here, it's a general statement.
Going further, to even figure out why you need to do all this, that human would need to know such concepts as variables, data types, and nullability. The notion that variables can have designated types is a pretty obvious takeaway from the first two.
Finding the definition of "!==" is easy, simply searching that [including quotes] gives me the answer. Looking for something like "?int =" just gives me useless responses upon first glance.
- http://php.net/manual/en/function.curl-multi-exec.php will at least allow you to make multiple curl calls in parallel
- Regarding typed arrays, writing a wrapper class that throws an exception is trivial, although it won't solve the editor problem.
I found the article to be a little condescending to be honest. As you rightly point out HHVM is more or less ignored by the wider PHP community now PHP7 is out, and the majority of other points are solved one way or another.
But suggesting that writing good PHP implies using a different runtime and different language, why not go to a different strictly typed C-like language altogether, like Java? It's certainly maintained better.
Hack/hhvm were great visions of the future and definitely motivated the PHP7 WG to move at a more brisk pace, but tying yourself to something like that is not a great idea, imo.
"...the only thing hack/hhvm offers in the near future is being tied to the hip with a single large company that both consumes and produces it."
Both projects are of course open source so "tied to the hip" may not be applicable (though they of course have difference licenses with the nuances that go with)
But the author believes that what solved facebook and wikipedia's problems will solve everybody's. If HHVM and Hack are really the tools that solve your probably use it but don't go that route if you absolutely need it. Don't get burned by hype because every use case is unique. What fixes facebook's problems probably will not fix yours. But php 7 is another viable option and from what I read it performs pretty well compare to HHVM for the most common things you would use it for. Also the language got a lost of fixes for its warts (I'm not a php expert but looks like it did).
tl;dr - don't blindly use tools where they are not needed and use the right tool for the job.
> Given enough time, all languages converge to become Java.
A few years ago I considered HHVM because it could give us a big performance boost with little effort while we worked on longer term migration. Switching the runtime really was a viable and valuable option to consider.
This depends on who your target audience is. I've been toying around with the idea of writing a modern blogging engine[1] and have come to the conclusion that if I actually wanted to do that and wanted to be able to target the same kinds of folks who would otherwise be installing WordPress, I probably need to stick to PHP. Not only are there still more people on traditional web hosts than you might think (I'm always surprised by this when I talk to friends outside, and even sometimes inside, the technosphere), there's an awful lot of people who use cloud infrastructure by clicking the "install Ubuntu with a LAMP stack" button.
I suppose technically I could provide a Docker image and include instructions on how to install that, like Discourse does, but that sounds...fraught.
[1] Yes, yes, I know, but I always liked Ghost's original "we want to focus on being a great blogging platform, not a CMS like WordPress has become" manifesto. Since they kicked that to the curb and said "fuck yeah CMS, baby," I'd kinda like someone else to pick up the baton. (Static web site generators are awesome if they fit your use case, but that use case isn't everyone's.)
This literally never happened, but ok?
> have come to the conclusion that if I actually wanted to do that and wanted to be able to target the same kinds of folks who would otherwise be installing WordPress, I probably need to stick to PHP
I'd agree with that. But plenty of people already doing it, eg. https://craftcms.com
I don't know the author so I don't want to make any quick assumptions, but even if it was just a bad joke calling a community "the outside world" sounds extremely conceited
Perhaps they fail to realize that their attitudes matter? I think this lends context as to why so many cultural problems persist through that bubble.
What up SF?
1. Ubiquity across web hosts. 2. Native support for JSON-esque associative arrays. 3. Integration with HTTP seemed amazing compared to other languages used for CGI.
1's not an issue anymore thanks to the cloud and other improvements in hosting services. 3's not an issue either thanks for good web frameworks in better languages. But 2?
Flex / JavaScript / PHP really are a pleasure to write some things in because of the flexibility of those data structures. Working with JSON, etc. in Java and friends is really painful and boiler-platey. Anyone aware of really good implementations that feel like PHP / JS in more widely respected languages?
https://www.playframework.com/documentation/2.5.x/JavaJsonAc...
I don't miss php much. I'd like to have instant browser reloads back. Play's incremental compilation does give you an edit-reload cycle, but it can be sluggish.
(Incidentally, the reason I use java now is because this web app is the front-end to a hadoop platform, and php's hadoop integration is less than ideal.)
foo["bar"]["baz"]
dynamic obj = JObject.Parse(json);
int x = obj[0].foo["bar"].baz;
What should they do? Asking for a friend
I'm one of the people who like to have require (with full paths too, if we can). Looking at the code, I can see what it needs and where it gets it; I don't have to reverse engineer what the autoloader will do; I don't have to wonder how many system calls it's going to take for it to do it.
Async can be nice, but the language contortions you need to go through to get it are painful. If you can stuff your database calls into webservices, you can use curl_multi to do parallel fetches everything you need and let the database webservices run the queries single threaded in lots of different processes. It adds a layer, but it's easy to understand.
In my opinion the right way to write PHP is embrace the PHP serving model: at the beginning, you get a request, you return back something (html, whatever), and then everything in memory is thrown away. Because everything is going to be thrown away in a little bit, it doesn't make sense to invest in a delightful hierarchy of classes; just parse the input, grab the right data, and stuff it together in as little code as possible.
I'm not sure if HHVM changed the threading model to run multiple requests simultaneously in one interpreter.
For example, ASP.NET has a small number of threads and each async call allows one thread to process another request.
You can send requests to the backend through async/await language features, or more simply by using apis that separate sending a request from waiting for a response, assuming network buffers are large enough to enqueue the request(s) without blocking.
Don't get me wrong, I love all these technologies and (although we're beating a dead horse here with the Java references!) Hack really feels like the "Scala of PHP" in the sense that it provides a lot of great features, but you can always "drop down" to PHP whenever it's necessary. That said, I think it could use some more adoption and articles like this are the first step toward getting people interested.
I don't understand the appeal of dynamic languages. Worse performance, more overhead, harder to read...
I want to tell the computer what to do in the simplest form possible, I don't want the computer telling me what to do, and I don't want to have to decorate my intentions with a bunch of unnecessary type fluff to make a compiler happy, and I certainly don't want the compiler telling me I can't do something I know will work perfectly fine just because it can't be statically verified.
Static typing has value, but it's massively overstated IMO. Type-checking will only catch the most obvious bugs. Type-checking is mostly redundant with the tests I'm writing anyway, its pretty unlikely that a type error would ever make it to prod, so the benefits seem pretty questionable to me personally.