1. 20
  1.  

  2. 10

    It is trendy to throw hate on PHP but to be honest I really like it. Yes, I can see it’s flaws, it is impossible not to see them but just like that “WAT” talk is a disservice to JS, so is the “a fractal of bad design” for PHP, it makes people focus on the bad stuff, apparently it is cool to hate on stuff.

    One of my favorite things about PHP is not exactly the language but how easy it is to deploy stuff. The idea of copying some files and then being done with it is very easy to grasp for new developers and very comfortable. Compare that with modern best practices of other runtimes where you need to keep stuff like pm2 running, then add something else to monitor the monitor, all in name of a scalability that you might actually not need.

    PHP is approachable and easy, you don’t need to learn a ton of tooling to start doing useful stuff that you can actually ship. I with more languages will copy that.

    1. 7

      I’ve been a PHP developer for the last eight years or so and I send every green PHP developer to Fractal of Bad Design. I think its super important for people to know the weaknesses in the languages they use. I also show them PHP The Right Way which is a valuable resource for how a lot of modern PHP applications are built these days.

      1. 1

        @dsh, I think that is a great approach. My criticism is when people just pick a “fractal of bad design” and then are never exposed to the good things.

        1. 1

          I agree, I’m not a fan of being one sided. Fractal is easily the best criticism of PHP on the internet but I wouldn’t take it as gospel to language en masse - especially if I’ve never programmed in PHP.

      2. 3

        just like that “WAT” talk is a disservice to JS

        Can you elaborate on that a bit? I’ve seen a few unpleasant bugs relating to JS’s … peculiar … type coercion behaviour.

        1. 3

          @duncan_bayne, well, that is only my personal opinion, so please take it as it is and not as a proclamation of truth. Also, this is not a direct commentary on you, please, don’t take this personally. This is a generalized commentary on my experiences dealing with other people.

          Most type coercion problems in JS and other weird behaviors are widely recognized as either real problems or misunderstandings on the part of the developer who doesn’t understand the spec being implemented in the language (for example: missteps when dealing with floats because people don’t understand the spec). Both cases are acknowledged but they can’t be fixed because JS must maintain backwards compatibility with itself lest the web breaks.

          The JS of today was not what was envisioned for the language in its humble beginnings. The fact that it can course correct but cannot erase its tortuous path is a feature. People focusing on the WAT problems foster mobs of “JS is horrible” when it isn’t. It is just not allowed to forget its mistakes like other languages are.

          If people released a new ECMAScript version that broke backwards compatibility and did away with all the WAT problems that are real mistakes, then the web would break and people would be saying “we should have never bet in a language as unstable as JS to develop the web.”. We all want the Web to work, we want to be able to at the same time browse an unmodified website from 1999 and a crazy WASM + Workers direct port of a console Rust app to the web from 2020. There is a price to pay when maintaining such retrocompatibility, Windows knows that too.

          So, my own problem with WAT is that it is often brought up by people who sees the little funny top of the iceberg and throws hate at it, completely ignoring the massive submersed chunk of reasons why something is the way it is, and why that is a feature not a bug.

          1. 1

            No offense taken :)

            I spent around five years doing a mix of JavaScript and Ruby programming, so I definitely get where you’re coming from. Agreed also that there’s no easy way of fixing the problem without hosing backwards compatibility. (Although I never used it myself, I hear that Google had a stab at the problem with Dart).

        2. 2

          Whether or not it is ‘trendy’ to criticize this aside, PHP and JS are taught (often exclusively) to young developers and then serve as platforms for spaghetti-coded monsters. Perhaps PHP can be done well, but I’ve always seen it abused in practice. We might rightly blame bad management, capitalism, or whatever else but the association of PHP and a certain kind of ‘monkey-coding’ is seared into my mind—as are 4GLs like Progress and the film ‘Office Space’.

          1. 2

            Perhaps PHP can be done well, but I’ve always seen it abused in practice.

            I think you could replace “PHP” in this sentence with “software” and have nearly as true a statement.

            I never set out to become a PHP programmer, but I’ve spent a majority of my working life either writing the stuff directly or dealing with its care & feeding in production environments. For years after I first started grappling with a legacy monstrosity in PHP, I felt that the language itself was one of the major sources of my problems. At some point that shifted: For all of PHP’s nontrivial defects, it was hard not to notice that my real problems were generally located elsewhere. In data models, the travails of human communication, the dysfunctions of business, and a thoroughly corrupt & predatory technical industry / culture, for example.

            Later, when I stepped away from PHP entirely for a while and started to survey the landscape, I had a secondary realization: A lot of my assumptions about its overall technical inferiority were on shaky ground. It’s not that PHP isn’t variously terrible. It’s that languages and environments widely held up as a superior contrast are also in fact pretty terrible.

            I haven’t started anything from scratch in PHP for ages, and maybe I wouldn’t these days, but then again… It might be fine. I probably wouldn’t hate the experience of writing it and I’d probably be confident in it still working 5 or 10 years down the line without too hideous a set of contortions in the meanwhile. Which is more than I can say for an alarmingly high percentage of the application code being churned out at present.

          2. 1

            Completely agree that the criticisms of PHP aren’t generally justifiable. Most people think PHP hasn’t evolved since v5.4. The language is fantastic and the OOP is excellent. However, I ended up switching to NodeJS for the ease of using JavaScript both client-side and server-side.

            1. 1

              PHP is approachable and easy, you don’t need to learn a ton of tooling to start doing useful stuff that you can actually ship. I with more languages will copy that.

              FWIW this is why I think “developer experience” is of supreme importance to languages and frameworks. It trumps almost everything, in terms of importance. I’ve been thinking about this recently, a lot, as I mull over a Lisp based dev stack for mobile.

              You can have the best language in the world, and if your dev experience is like pulling teeth, a language like PHP (no offense ;) ) will beat you every time.

            2. 4

              Imagine an internet without Wikipedia and WordPress, Yahoo, Flickr and Slack. For its many flaws PHP has made a lot of wonderful things possible. Worse is better at its best.

              1. 4

                Given the plethora of overlapping programming languages/environments, I don’t think it’s reasonable to claim that these things wouldn’t exist without PHP.

                1. 7

                  I think that’s not entirely fair. Back in 2001, I’m not sure a project like Wikipedia would have even been started without something like PHP being available, given the difficulty and inefficiency of deploying a web application using any other language/platform available at that time…

                  1. 6

                    Yep - shared PHP hosting was an economic wonder not replicated since.

                    I was looking for hosting around 2006, and I recall the cheapest price to deploy a PHP site (shared hosting) was roughly 200x cheaper (not a typo!) than the cheapest VPS I could find.

                    1. 1

                      Yep - shared PHP hosting was an economic wonder not replicated since.

                      Many VPS providers have free tiers these days, though, which in essentially gives you a space to deploy your thing for $0 – at least if you can pick your tools to optimize for that. But yeah, PHP was hard to beat for a long time, economically.

                      1. 2

                        Many? Which other than amazon and GCP? Honest question.

                        There was thousands of web hosting companies offering free hosting with PHP support. Even locally. It was what every 20 year old internet geek would do, starting a web hosting company. Granted, most of them were a security nightmare and had hours-long downtimes, or even days-long. But it was still a wonder world.

                        I recently talked to an old friend, and he mentioned that a website that I had put together back in 2002 was still up. I went and check, and there it was, almost two decades later, that website, along with two other that I hosted at the same hosting provider. Realistically speaking, I doubt any VPS instance I spin nowadays will be up 10 years from now.

                        1. 1

                          Many? Which other than amazon and GCP? Honest question.

                          … Azure? :) Good points though.

                    2. 4

                      I think that’s not entirely fair. Back in 2001, I’m not sure a project like Wikipedia would have even been started without something like PHP being available, given the difficulty and inefficiency of deploying a web application using any other language/platform available at that time…

                      To put this in perspective, Slashdot was written in Perl and predates Wikipedia. A lot of the early web sites were. Server-side Java was pretty mature by 2001. GNUstepWeb, a complete reimplementation of WebObjects 4.5 (depending on who you ask, WebObjects was either the first or second WebApp development framework and was first released in 1996) was pretty mature by 2001.

                      There were quite a lot of alternatives by 2001. CGI was standardised in 1993 and most web servers supported FastCGI by the late ’90s. Most scripting languages had CGI / FastCGI plugins and many compiled languages had libraries for writing [Fast]CGI programs.

                      PHP was available on a lot of shared-hosting platforms, but so were a few alternatives. If PHP hadn’t been around, one of the other alternatives would have taken its place as the dominant server-side scripting language.

                      1. 5

                        You’re doing an apples to oranges comparison. PHP’s design, both easy and tightly integrated with web, allowed people with little to no programming experience to quickly get websites together. Another thing technical folks rarely bring up is that this appeals to people that want to focus on their project/product, not the language or stack.

                        The alternatives you mention didn’t do that. On top of it, PHP got into all the cheap, web hosts. That combo made it dominate for this segment of users.

                        1. 4

                          PHP’s design, both easy and tightly integrated with web, allowed people with little to no programming experience to quickly get websites together

                          PHP was not the only language that allowed interleaved text and markup. Even the oldest systems had templating infrastructure that let you embed scripts in HTML, though typically they’d then interact with more complex components. Most users; however, did not need to write those components, they just treated them as things that were built into the language.

                          As to ‘little to no programming experience’, that’s quite a subjective thing. You needed to understand conditionals and loops to write non-trivial PHP. You needed to understand logical operators, string concatenation (what a string is!) and for non-trivial things you needed to understand structured data. We’re talking about a level of programming competence of someone who grew up in the ’90s with 8-bit BASIC, not the level of someone who is just doing HTML markup. Again, a lot of other systems required a similar level of competence. Quite a few had much simpler learning curves for people with no programming experience.

                          On top of it, PHP got into all the cheap, web hosts

                          I mentioned that, but you’re right. That is why PHP succeeded. If PHP hadn’t existed, do you think these hosts would not have offered something else? Most of them offered PHP + one or two other things, but PHP was the common platform. Most of the providers I remember from back then are out of business now. NearlyFreeSpeech is still around and, according to the Wayback machine, they offered C, C++, LISP, Perl, Python, PHP, Ruby, and TCL + MySQL hosting in 2006, the first time they offered server-side scripting support at all.

                          I was on the executive committee and admin team for a student computer society around 2000 and, back then, the fact that we offered free web hosting with server-side scripting was a massive incentive for members (we charged £3/year initially and put it up to £5/year and it was still vastly cheaper just for the hosting than any alternatives that offered PHP or other languages). Email hosting was also a big thing: most people only had a university account and maybe one tied to their ISP (which went away at the end of the year when they moved house). Hotmail was still slowly taking off as an alternative.

                          It wasn’t until around 2005 that alternatives for web hosting became cheap enough that students considered using them and even then we were a lot cheaper. PHP was convenient but mostly because there were big marketing pushes behind it and it was what everyone else was using, so it was easy to get help. People doing computer science degrees were often asking for help with PHP (we had a talker and a support mailing list for helping people with PHP), so it definitely wasn’t as easy as you are claiming (especially a few years later once people learned about SQL injection attacks and discovered that their ‘simple’ PHP gave random Internet people full access to their databases). If PHP hadn’t been around, we’d have done exactly the same thing for some other scripting language.

                          1. 3

                            Couldn’t agree more. My first big “project” was a car-pool sharing site in the late 90s. I was inspired by reading Greenspun’s “Database backed web sites” (great book, btw) and managed to get basic functionality going without much trouble using PHP and MySQL.

                          2. 2

                            To run servlets, you would need to spend an order of magnitude or two more money on servers. And most likely manage the server yourself. Shared PHP hosting allowed you to drop a php file on a designated folder using an ftp client and you were good to go. We have a zillion choices nowadays. But things were not as ubiquitous back then. How many people do you know that had rented a server for personal projects back in the 90s?

                            Many of these shared hosting providers offered CGI in up till 2000~2002, but that was a resource drain when compared to PHP. You wouldn’t realistically spawn 1000 processes on the server if a 1000 requests came in one second. PHP could handle this without blinking. And included a super intuitive template system, a mysql client and extensive functionality for string manipulation. This is what people wanted and they could get it to work in seconds.

                            I think that the fact that it was a language too helped because it was, and still is, a language that tries to be approachable, as opposed to say perl or java, which make much more assumptions about the programmer. A complete beginner could open php.net, read the first chapters and be ready to build something. Probably filled with bugs and security holes, but from the cheer amount of ghetto php programmers, the web of dynamic content flourished. That said, I do believe that the platform is what primarily made PHP huge. Upload a file and visit the url. There was even people writing websites in HTML, and then just sprinkling a couple of PHP snippets inside their html files.

                            If I may make a tangent, I think the crowd of current PHP programmers claiming that the language has improved, is missing the point. You cannot make the language theoretically sound without turning it into something completely different. I even think the whole java-like OOP that they do these days in PHP is a mistake. It was a quick and dirty language. The array() constructor is an a aberration from a theoretical point of view, but for a complete beginner it would provide them with a data structure that could be used as: an array, a list, a queue, a map, and a couple of others probably. This was empowering. Of course, when you reach the point that you need to push these data structures to the limits of their design, PHP wouldn’t deliver.

                            It certainly allowed many people to experiment and build something. Myself included. How things would be had it not seen the light of day, it’s just something left for us to speculate.

                            1. 1

                              Many of these shared hosting providers offered CGI in up till 2000~2002, but that was a resource drain when compared to PHP

                              That’s not my experience (from running a shared-hosting server around 2001-2004). Back then, PHP either used CGI, or the Apache plugin. The Apache plugin did not offer user separation, so was not appropriate for shared hosting. You paid the PHP interpreter start-up cost for every PHP page fetch.

                              PHP+Apache didn’t get reliable FastCGI (which let you spawn one copy of the PHP interpreter per user, so you got useful isolation between users) until later. I think we deployed it around 2003 / 2004 and it was quite flaky at the start. Today, it works very reliably and once the Zend accelerator stuff was merged it gave a big performance win (you weren’t parsing the entire PHP script every page fetch, it was parsed once, compiled to bytecode, and interpreted on each invocation).

                              In terms of system load, we saw much higher overheads from PHP than stateful web-app development frameworks because every PHP request needed multiple round trips to the database (we were using PostgreSQL instead of MySQL, because we liked our data and wanted to keep it), whereas alternatives (my favourite from that era was Seaside) kept it in memory, where it could be swapped out when the site was idle but then much cheaper to access when the side was under load. Java was a bit of a beast back then, but Perl was lighweight and offered FastCGI at about the same time (slightly earlier? Not sure, I didn’t use Perl).

                              I’d agree that PHP coincided with a growth in shared hosting and server-side scripting, but I disagree with the jump from there to that it caused this growth. There was a huge, thriving, ecosystem of people trying to solve the same problems. Once one player became slightly dominant in that market, it snowballed because people focused teaching resources on that language, optimised the interpreters, and gave discounts to people using it to try to attract a large customer base from competitors. That player happened to be PHP but it could easily have been one of hundreds of other frameworks that have since died out. And we’d probably now have long blog posts about how it sucks and doesn’t deserve to be successful.

                              1. 1

                                I don’t know how the Apache plugin worked, but it was what everyone was using to run away from the CGI. CGI was quickly deprecated or discouraged in many shared hosting providers as far as I remember.

                                For example,.many perl programmers switched because the platform was just more convenient and trivial to deploy in a properly scalable way.out of the box.

                                1. 1

                                  The Apache plugin ran everything as the same user. That meant that you had to make all of your PHP files readable by the www user and anyone who could run PHP via Apache could then read them. Lots of people put things like database passwords in their PHP files. Things like MySQL let you authenticate per user (didn’t work with mod_php because everyone was the same user, so would get the same connection credentials) or with a username and password (which required storing the username and password somewhere where the user executing the PHP scripts could see them). Another PHP script running from a different user would still be executed as the www user and so could read your PHP files and pull passwords out of them.

                                  We hit a bunch of security issues like this and moved back to CGI for PHP. A bunch of less scrupulous shared hosting providers kept using mod_php and blaming compromises from their inherently insecure configuration on their customers. As I recall, the docs for mod_php back then explicitly told you not to use it for shared hosting where the users did not all trust each other.

                                  I think Apache 2.0 came with a security model, but by the time 2.x was stable everyone I knew had moved to lighttpd and was using FastCGI for PHP and for everything else. With FastCGI, you’d need a process per (scripting language, user) pair, but that would be swapped out for idle users and so didn’t impose much penalty.

                                  1. 1

                                    I agree that it was a mess security wise and all the holes that occurred in shared hosting were kind of expected. If you were anything else than a tiny company or a personal blog, you would run your own server for this reason.

                                    But the last sentence in the first paragraph is not true. You would have a Unix account and place your php files inside your home folder. But other users could naturally not access them.

                                    But I digress. Your timeline is a bit off, Apache 2 was huge before lighttpd gain prevalence. Either way, I think we all can agree that PHP aced easy of deployment for the hobbist to an extent that no other stack even came close at the time.

                                    1. 2

                                      But the last sentence in the first paragraph is not true. You would have a Unix account and place your php files inside your home folder. But other users could naturally not access them.

                                      They had to be readable by the user that Apache ran as, because all PHP scripts ran as that user. Apache would run every PHP script as that user and so any script, written by any user, could read the text of any other script.

                                      Your timeline is a bit off, Apache 2 was huge before lighttpd gain prevalence

                                      You might be right. We didn’t move to Apache 2 until 2.2.something (must have been some time after 2005). The 2.0.x series was a mess and was the thing that pushed a lot of people I knew to explore alternatives. We used Lighttpd 1.4.0, but the Lighttpd web site doesn’t seem to have version history that far back. It only goes back to 1.4.15, which was 2007. Lighttpd was an odd flash in the pan, it displaced Apache everywhere I knew about very quickly and was then replaced by Nginx within a few years. It looks as if it’s still actively developed, but I’ve no idea who’s using it.

                                      1. 1

                                        Since we are in the middle of a trip down the memory lane. There are also these two webservers that also played their part. Although eventually nginx would win the race, so to speak.

                                        They introduced new ways of thinking of a webserver into the world, and it is cool to see these projects are still alive today.

                          3. 2

                            Wikipedia initially ran on UseModWiki, a Perl CGI application (like most of the wiki engines in use at the time).

                            1. 2

                              Wikipedia was written in Perl originally and was rewritten in PHP by a student over the summer mostly because the Perl version used a flat file database. As near as I can determine, there was no particular reason to prefer PHP over Perl at the time, other than that’s what the author decided to use.

                              No one really liked the PHP version from the outset btw, but they decided to go with it anyway because the flat-file performance problem were pressing. This eventually turned in to MediaWiki.

                              How would things have gone down if they had decided to stick with Perl instead? Who knows…

                              1. 1

                                I was coding web sites in Perl in about 1997. It wasn’t perhaps fun in many ways, and in fact I fantasized about porting the code to PHP. I won’t completely dismiss the idea that PHP was the enabling factor for many of those early web sites – darwinism clearly points to some underlying truths in tech. But I also believe that there were plenty of “something like PHP” besides PHP itself.

                            2. 6

                              Imagine an internet without (…) Slack.

                              It would be a way better place than now, as Slack mostly destroyed the landscape of instant messages one more time, but this time it thrown it into a web browser.

                              Just like someone thought the hypertext document viewer is a great place to use as a canvas for “applications” if you refresh the document contents fast enough so no one notices

                            Stories with similar links:

                            1. Work in progress: Idris 2 via ehamberg 2 years ago | 44 points | 1 comment
                            2. Golang Modules Mirror now available in alpha via UkiahSmith 2 years ago | 3 points | 1 comment
                            3. Unix in East Germany (1990) via fcambus 3 years ago | 46 points | 13 comments
                            4. Firefox: Using clang-cl to ship Windows builds via colin 3 years ago | 3 points | no comments
                            5. Mercurial 4.6 sprint report via Sietsebb 3 years ago | 5 points | no comments
                            6. PCID is now a critical performance/security feature on x86 via akpoff 3 years ago | 26 points | 7 comments
                            7. Go 1.8 RC 1 released via fkr 4 years ago | 8 points | 4 comments
                            8. Rust required to build Gecko via chadski 4 years ago | 30 points | no comments
                            9. boringcc via jcs 5 years ago | 29 points | 10 comments
                            10. Go as a teaching language for young programmers via zem 6 years ago | 19 points | 11 comments
                            11. Go 1.5 Beta 1 is released via journeysquid 6 years ago | 12 points | 1 comment
                            12. Go is moving to GitHub via nathany 7 years ago | 20 points | 1 comment