13 ms·
Stop writing PHP like it's 2009
- pram 9y agoMods truncate title to "Stop writing PHP" TIA
- chasing 9y agoIt's funny to me that so many people on the "PHP is bad" bandwagon are apparently perfectly cool with writing every damned thing in Javascript.
- kokeshi 9y agoAt least on the server there is an option, but agreed! Also, PHP is bad.
- linopolus 9y agoWould have answered a JS post the same way..
- coding123 9y agoEverything should be written in Typescript if you need Javascript.
- felixschl 9y agoI hope not, purescript is a much more sensible option.
- galeaspablo 9y agoElm
- bpicolo 9y agoSo the answer to "Stop writing PHP like it's 2009" is to not write PHP at all, and write Hack instead?
- deleted 9y ago[deleted]
- kuschku 9y agoAn argument could be made that we need a new law of programming languages: > Given enough time, all languages converge to become Java.
- throwaway7645 9y agoI don't think that is true at all. Can you clarify what you mean by that as quite a few languages (some that are old) off the top of my head share little with Java: APL, Perl, OCaml, Rebol, Nim, Common Lisp...etc.
- madsbuch 9y agoExcept that it is far from true.
- kuschku 9y agoLook at the JS world, or the PHP world, and it certainly seems true for them.
- paulredmond 9y agoHere's a side-by-side with Java and the PHP RFC for Generics. https://pbs.twimg.com/media/DBYQXlYUwAAZt9t.jpg https://pbs.twimg.com/media/DBYQXlYUwAAZt9t.jpg
- ChrisLTD 9y agoSeems that way. Unfortunately, this kills the #1 reason to use PHP: Easy deployment on almost any web host.
- treve 9y agoI'm a big proponent of using PHP where it's appropriate, and I've found lots of good usecases for it. 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.
- linopolus 9y agos/ like.*//i
- The_Sponge 9y agoBetween PHP7, PSR4, and generally good development strategies, 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. 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.
- bdcravens 9y agoWouldn't the same criticisms apply to React then?
- CharlesW 9y agoIn that analogy, what's PHP to React's HVVM?
- bdcravens 9y agoReact IS the HHVM in that example; there was no React prior to Facebook creating it. "...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)
- kyberias 9y agoHmmm... I'm curious about the async explanation. I don't think that's the main benefit. The main benefit, at least on other platforms, is that while your function is await'n for your db, the thread can service other requests. It doesn't have to be stuck on waiting for I/O. This can dramatically improve scalability. I don't know, maybe PHP/hack doesn't really support this somehow.
- toast0 9y agoIn a traditional PHP installation, the interpreter is single threaded, and you run multiple instances of them. If all the instances are waiting on I/O, you just run more instances until you run out of ram. If you're not linking in crazy c libraries, your php instances shouldn't get too big, so you can run a lot of them. (Ex: on my well traveled site at work, the biggest php takes up 24M, elastic search for maybe 1000 documents (documents 128M on disc) takes up 5G; I can run a lot of php for parallelism, if needed) I'm not sure if HHVM changed the threading model to run multiple requests simultaneously in one interpreter.
- kyberias 9y agoRight, it's just that the thread that is kept waiting for database could serve other clients meanwhile. While keeping the thread sleeping, it's wasting system resources. For example, ASP.NET has a small number of threads and each async call allows one thread to process another request.
- toast0 9y agoThat's true in a thread oriented environment; but it's not the case in a traditional PHP environment, with one OS process per client. A PHP process does not know how to context switch between many requests; if the process is waiting for I/O the OS will schedule a different process. In this model, sending multiple backend requests concurrently, regardless of how, is of value when it lowers the total request time and lets it accept another request sooner. 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.
- CiPHPerCoder 9y ago"Don't write PHP, write Hack instead" is probably a better title for this post. 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/ http://www.phptherightway.com/ https://planet.nomadphp.com/ https://planet.nomadphp.com/ https://www.reddit.com/r/phpsec/ 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.
- kyriakos 9y agoGreat comment. PHP has evolved, just avoid old comments on stackoverflow and questionable tutorials, they usually evangelise bad practice and are full of security vulnerabilities.
- astrodust 9y agoGood PHP code tends to look like well structured Java code, but with a rash of $ characters in it. I have to wonder why you don't just write Java and be able to leverage what the JVM ecosystem provides.
- TallGuyShort 9y agoSince I'm sure this will quickly be a debate about PHP, these are the reasons I liked PHP at the time: 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?
- Avshalom 9y agoIt's not the ubiquity of php per se so much as mod_php meaning deployment is literally 'drop in' there's no setting paths or configs or even a little friction it's just write and save your php file.
- WaxProlix 9y agoRuby, Python, etc all do this fairly well if you're talking about dict/assoc.array literals and ease of serialization/deserialization.
- TallGuyShort 9y agoYeah Python does well, but boy I wish dynamic properties were smoother sometimes, e.g.: a[b][c] == a.b.c. But I'd rather Python be Python than compromise correctness for PHP-like flexibility :)
- int_19h 9y agoYou could implement an object that does it this way - it would basically implement __getitem__ and __getattr__ identically.
- WaxProlix 9y agoThis causes all sorts of problems, though. If you conflate the language's symbol table with a data structure managed by the language (ie, a hash or dict) then suddenly you have the same problems as JS did for ages. I can't put a '__init__' or ' ' in my key names anymore, or any of the other special cases. Best to leave them as hash keys.
- Rjevski 9y agoHere's a better version of that link: http://www.phptherightway.com http://www.phptherightway.com - using a different runtime is not going to make someone who doesn't know anything besides mysql_query or include write better PHP. You need to start with the basics instead. Your post is what I would call premature optimisation.
- olegkikin 9y agoYou can't use mysql_query anymore. It's removed from PHP 7. And the docs warn you about it: http://php.net/manual/en/function.mysql-query.php http://php.net/manual/en/function.mysql-query.php
- Rjevski 9y agoOne of the issues I noticed in a lot of beginner PHP developers is that the official docs is the last thing they look at. They'd rather copy/paste some crap from W3Schools or a 10 year old blog post, and given that they put it on shared hosting with a prehistoric version of PHP the "mysql_query" garbage will work as expected (as in, allow their site to be exploited).
- verelo 9y agoAsync queries, great advice..do that. The rest meh... 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.
- cnowacek 9y agoIt's not just a question about style. ?int can be enforced at compile-time while the null and type check would be caught at runtime.
- verelo 9y agoGreat point, and for that reason I really like it, but generally my view is: "for most situations, humans are more expensive than the compute costs, so do the thing that is easy for a human to understand and pay the tax on your compute power". Obviously that doesn't always hold true, so place your bets accordingly.
- int_19h 9y agoWhy would it be hard for a human to understand a type declaration using a syntax that has been well established in some of the most popular programming languages (C, C++, Java, C#) for several decades now?
- verelo 9y agoThe longer [if based] format can almost be interpreted by any human that has no programming experience but a good grasp of logic, the other is just inherently more complex and less verbose. 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.
- tomphoolery 9y agoIt doesn't seem surprising to me that smaller companies are cautious when adopting tech solely supported by a large company like Facebook. Plenty of projects in the open-source graveyard were created and (somewhat) supported by the likes of Google, Facebook, and Twitter...only to change technology stacks a few years later and abandon maintenance of their libraries. Having to rewrite your code using different libraries is pretty bad, but it's way worse to have to rewrite your whole app because the platform you wrote it on isn't supported anymore. 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.
- exabrial 9y ago#1 issue is lack of strong typing. I don't understand the appeal of dynamic languages. Worse performance, more overhead, harder to read...
- gnaritas 9y agoGood enough performance, overhead is fine, easier to read, faster development time, vastly easier exploratory prototyping abilities, dynamic patterns available that can't be done at all in static languages like meta classes and dynamic message interpretation via late bound message passing. If you don't understand the appeal of dynamic languages, it's likely because you still program like you do in a static language while in them and you're ignoring the new things you can do that you couldn't in a static language. Static types are handcuffs, they prevent all kinds of perfectly valid code that work fine in dynamic languages. Static types ensure you don't make certain kinds of mistakes, but the cost of doing that is forbidding valid code that can't be verified at compile time to be correct, even though it'd work fine at runtime. 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.
- wootness 9y agoDefinitely not faster development time. At all. For larger projects, dynamically typed languages fail very quickly. And modern statically typed languages have dynamic features, making dynamic languages obsolete.
- z3t4 9y agoyou dont have to wait ten hours to see if it works, you just hit "refresh" and you see the changes you did instantly. most obvious errors that a strongly typed language protects you from are caught by the vm at runtime. then you rely on testing, both automatic testing and manual testing. in a dynamic language you dont have to decide between float or int. your code gets less verbose and you can concentrate on good naming and making the code easy to understand, instead of choosing the right type. also you can have functions that accept many types, which gives you more flexibility and freedom.
- cosinetau 9y agoThis blog entry starts off with "I'm a former Facebook employee, and all you PHP devs need to git gud." Pass.
- philplckthun 9y ago> It boggles my mind having left engineering at Facebook only 2 months ago that the outside world still largely seems to write PHP like it’s 2009. 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
- cosinetau 9y agoIt really does. I find it insightful as to potentially how these "Big Boys" view the development community outside of their Palo Alto bubbles. 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?
- wcummings 9y agoSF will make a great looking crater.
- goshx 9y ago"People still largely seem to use require() and include() statements everywhere in their code." What should they do? Asking for a friend
- kronos29296 9y agoAnother article that talks about the scalability and benefits for wikipedia and facebook when the websites that most people create will never be either. You are not going to save millions on server costs and just doesn't make sense for some personal blog on wordpress. For most cases something like php7 might make as much sense. 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.
- Neil44 9y agoI liked HHVM vs PHP-FPM because you don't have to one fat process per concurrent request. But disliked it because not much actually ran on it without tweaking. If you just have a bunch of random CMS sites to host then forget it. (this was about 2 years ago)
- toast0 9y ago> People still largely seem to use require() and include() statements everywhere in their code. What. The. Fudge. 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.
- AndyMcConachie 9y agoIf the thing you're making in PHP requires asynchronous calls to a DB then perhaps you shouldn't be writing that thing in PHP?
- deleted 9y ago[deleted]
- dabernathy89 9y agoBut the author has no problem writing this blog post using WordPress.com, built on a PHP codebase that goes back 14 years and still largely resembles 2009-era PHP. (This is not a knock on WordPress at all - it paid my bills for years).
- mnm1 9y agoThis is Hack, not PHP. I considered Hack and HHVM a few years back, but with PHP 7, they really have little to nothing to offer PHP development and last time I checked, there were still serious incompatibilities. The speed gains for both HHVM and PHP 7 are very similar over PHP 5. I really cannot see using Hack or HHVM, or even considering them, unless they get another 2x or more speed improvement over PHP 7. In my testing, they're head to head and that in no way justifies the migration. Hack is NOT PHP, sorry.
- diimdeep 9y agoWhat are examples of modern PHP code currently in production (open source obv.)? Except obv. frameworks like Laravel.
- diimdeep 9y agonvm: https://github.com/uhub/awesome-php https://github.com/uhub/awesome-php https://github.com/ziadoz/awesome-php https://github.com/ziadoz/awesome-php