Stop writing PHP like it's 2009(florianlaplantif.wordpress.com)
florianlaplantif.wordpress.com
Stop writing PHP like it's 2009
https://florianlaplantif.wordpress.com/2017/07/18/stop-writing-php-like-its-2009/
108 comments
Good 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.
82% of the websites on the Internet are powered by PHP, not Java.
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...
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...
82% of business applications used to be written with COBOL or FORTRAN. What's your point? Things change, sometimes dramatically.
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.
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.
> 82% of business applications used to be written with COBOL or FORTRAN.
'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.
'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.
Are you aware of what the PHP ecosystem provides? There is some pretty great stuff in PHP land.
2 of my favorites are https://getcomposer.org/ and https://laravel.com/
2 of my favorites are https://getcomposer.org/ and https://laravel.com/
Havent worked in PHP in a few years but when I did both composer and laravel were amazing.
Honestly, that's like a cup of ice water in hell. Composer is a finally thing, and Laravel is a "at least it's not garbage" framework. The things you have to make do with in the PHP world are absurd. Find something in an array? Ugh.
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.
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.
> Composer is a finally thing
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.
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.
Yeah, JavaScript in 2017 is so much better to read and write than it was in the past. https://medium.com/@sAbakumoff/es6-is-great-until-its-not-f3...
It is. Those are valid complaints, every language has issues, but with each iteration the number of complaints the average user has tends to drop because convenience features are introduced.
> There's been absolutely zero effort to overhaul the core PHP API which is, on the whole, absolute junk.
If you were involved with the internals team at all, you would know this is not true.
If you were involved with the internals team at all, you would know this is not true.
Give me a call when case-sensitive string comparisons don't involve basically writing C code.
Laravel looks just like a well structured Java program assuming you use strong types as the rest of the framework does. :P
Edit: that's not to refute what you've said or anything.
Edit: that's not to refute what you've said or anything.
It really does. Java was the language I learned on, and it's super great that I can use all of those patterns nowadays. PHP is the typical expectation for clients that need a CMS, and it no longer feels like quite the cesspool it was five years ago.
Composer and the PSR initiatives have totally changed the feel of working in this ecosystem for the better.
Composer and the PSR initiatives have totally changed the feel of working in this ecosystem for the better.
Because they wish to leverage PHP's ecosystem and Java requires more boilerplate code and tends to be more verbose.
And Java is notorious for...
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.
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.
> 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.
Definitely true. Laravel has this issue with the added bonus of magic methods and Facades all over the place.
Also nobody wants to set up Tomcat.
And because PHP scales DOWN better than Java making it tremendously cheaper to host for low traffic sites (aka - most sites).
- Too much boilerplate
- 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)
- 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)
As someone whose parent company is a Java shop....Plz no.
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 amount of boilerplate in "good" Java code is substantial (like 20-30% more lines) compared to "good" PHP in practice. At least imho/experience.
Great comment. PHP has evolved, just avoid old comments on stackoverflow and questionable tutorials, they usually evangelise bad practice and are full of security vulnerabilities.
[deleted]
Async 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.
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.
It'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.
Great 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.
Why 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?
The 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.
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.
I think you overestimate the readability of C-based syntax in general. A human that has no programming experience would have to start with parsing what !== means (and it's not at all obvious that ! is negation, or why = is doubled), and then move onto &&, although that's slightly more obvious. Nor is "int" obvious as a shortening of "integer" outside of CS - I've seen people interpret it as "internal", for example.
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.
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.
Just for fun, if you didn't know what "?int $var = null;" meant, how would you explain that to someone verbally, or better [like most programmers would] how would you search for this online?
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.
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.
[deleted]
I picked up on this straight away. Regarding some of the other things in the article:
- 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.
- 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.
Yeah, i wrote a PHP MySQL module that uses multi-exec curl as a means of creating parallel queries. I have been meaning to open source this for a while now, might try do it later this week...i don't see a better way to do it in PHP 7 as it stands today. My biggest holdback has been that it's just dangerous, essentially HTTP becomes the protocol for connecting to the DB, which means you need to ensure those requests are locked down and i suspect most people will mess that up and create a world of hurt for themselves.
I'm a little confused and am seeing conflicting information everywhere. How can I use async queries in PHP right now? It looks like the code the author wrote is in Hack. Can Hack code be injected like that into the PHP file, or does it require me to write a separate file and somehow link it to PHP?
That that I know of, but [after a brief stint using Hack] I wrote up a custom module that supports this functionality using curl in PHP 7 to spawn up multiple threads. It's a touch messy to implement, but totally possible if you want it.
I'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.
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.
Here's a better version of that link: 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.
You 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
One 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).
Between 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.
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.
Wouldn't the same criticisms apply to React then?
In that analogy, what's PHP to React's HVVM?
React 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)
"...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)
This blog entry starts off with "I'm a former Facebook employee, and all you PHP devs need to git gud." Pass.
Another 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.
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.
So the answer to "Stop writing PHP like it's 2009" is to not write PHP at all, and write Hack instead?
Seems that way. Unfortunately, this kills the #1 reason to use PHP: Easy deployment on almost any web host.
It would seem deploying on cloud infrastructure is more popular now than traditional web hosts. I would suggest that perhaps it's no longer that "the #1 reason to use PHP == deployment" but that "the #1 reason to KEEP using PHP == huge but stable codebase + fear of forgetting important things in a reimplementation".
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.
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.
* It would seem deploying on cloud infrastructure is more popular now than traditional web hosts.*
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 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.)
> Since they kicked that to the curb and said "fuck yeah CMS, baby,"
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
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
Yeah, I really like Hack as a language, it's basically everything I want PHP to be, but finding a free host for test projects has been a pain.
[deleted]
[deleted]
An argument could be made that we need a new law of programming languages:
> Given enough time, all languages converge to become Java.
> Given enough time, all languages converge to become Java.
I 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.
Here'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
> 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
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
It 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?
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?
SF will make a great looking crater.
Since 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?
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?
It'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.
After a long stint on php I'm now using jackson inside of play framework to work with json from java. It's quite easy to use.
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.)
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.)
Other dynamically typed languages have already been pointed out, but one that might surprise you is C#. For starters, because it supports [] overloading, you can do:
foo["bar"]["baz"]
dynamic obj = JObject.Parse(json);
int x = obj[0].foo["bar"].baz;
Ruby, Python, etc all do this fairly well if you're talking about dict/assoc.array literals and ease of serialization/deserialization.
Yeah 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 :)
This 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.
You could implement an object that does it this way - it would basically implement __getitem__ and __getattr__ identically.
> 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.
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.
Hmmm... 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.
In 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.
I'm not sure if HHVM changed the threading model to run multiple requests simultaneously in one interpreter.
Right, 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.
For example, ASP.NET has a small number of threads and each async call allows one thread to process another request.
That'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.
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.
It 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.
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.
But 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).
This 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.
If the thing you're making in PHP requires asynchronous calls to a DB then perhaps you shouldn't be writing that thing in PHP?
#1 issue is lack of strong typing.
I don't understand the appeal of dynamic languages. Worse performance, more overhead, harder to read...
I don't understand the appeal of dynamic languages. Worse performance, more overhead, harder to read...
As someone who writes java every day for work but deep down loves dynamic languages:
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.
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.
you 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.
Good 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.
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.
I've spent years on both sides of the fence, PHP and Java. In my experience php wins out for prototyping and smaller or short-lived projects, because you can type up something quickly without boilerplate, but java is better for large long-lived codebases. The improved maintainability that a strictly typed language gives you becomes the dominant factor when 80% of time is spent maintaining or extending existing code.
Some fair points, but strict typing doesn't mean the codebase is bullet-proof. I've seen upgrades take months on both PHP and Java projects due to poorly maintained and poorly tested code. It's the operators not the tool that have the biggest impact on maintainability regardless of the language.
PHP has a sort of middle-ground now, which is runtime-enforced type declarations, which you can check offline with a separate utility or an IDE if you like.
I 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)
What are examples of modern PHP code currently in production (open source obv.)? Except obv. frameworks like Laravel.
[deleted]
s/ like.*//i
Mods truncate title to "Stop writing PHP" TIA
It'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.
At least on the server there is an option, but agreed! Also, PHP is bad.
Would have answered a JS post the same way..
Everything should be written in Typescript if you need Javascript.
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://planet.nomadphp.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.