I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that.
I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.
Some companies are succeeding in spite of php. There are many, many users of php, and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked php and got nothing for it.
It would be an outlier company indeed who held an 'all hands on deck' meeting and said, "We're succeeding in spite of PHP everyone!"
Only engineers care about programming languages. Seriously. That's it. No one else cares about them. I work in a large public university alongside a revolving door of student interns who are always 19. In 10+ years of work, I've still yet to meet the person who talked about their favourite website or app, but lamented that it was written in Php or JavaScript or Go or Java. It's only us (the HN'ers) who fret about this.
Don't believe me? Imagine the look on everyone's faces at the tech publishing houses around 2009 when books about Objective-C sold a few hundred copies a year to doing tens of thousands per month when the iPhone rocked the world. This happened without a proper language hot stove on Hacker News, no?
People care about outcomes. People care about products. People care about being dazzled. People care about showing their friends this incredible thing they saw on the web/this new app.
But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right? Let's not pretend that these don't matter once you've gone past the "users actually care about our app" phase, because they do and they affect the bottom line of a company. And IMHO PHP falters in these regards.
At this point, I would have no problem arguing with a straight face that your choice of technology stack might be the least important factor in whether your business succeeds or fails. I don't mind if I get torched for this, it's just my current, non-Silicon Valley, non-substantiated opinion at this time (though I don't think it's without merit).
> But program managers and CTOs and other non-engineers at a company care about scalability, performance, technical debt and quality, right?
Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
I'm currently maintaining an app stack for a Fortune-100 company that, if I told you what it was, you simply wouldn't believe I was telling the truth. That's how out of date it is. "Scalability, performance, technical debt and quality" never entered into it. All anyone ever cared about was "does it get the job done and what does it cost to keep it running for another year as-is?"
I'd upvote this many time if I could. I am in the same boat--my team helps maintain a ten year old web application that is used by the largest companies in our ___domain. The application is literally the backbone of data used by these companies to make money. We have reliability issues, and sometimes clients get a little upset, but every year it is the same thing: how much do we need to budget for support?
> Rarely. Mostly they care about meeting quarterly goals and budgets; and ease of finding inexpensive, more-or-less competent talent. In both of these, PHP excels.
This. In my previous job, I was literally told by my boss, that they'd consider switching from PHP to something like Ruby or whatever, but PHP programmers are cheaper so that's why they stick with it.
Performance? You need to update your act. PHP7 is 3x faster than python and now faster than Java 8 . The only people that can call php slow are masochistic c++ web hacks.
It's probably worth mentioning that the regex-dna test time is kind of incorrect and provides an inaccurate view of what's happening.
Java-8 is using java.util.regex which is written in Java, PHP is passing the regex requests to it's own regex process which is actually a C package and performs a lot faster.
What we're actually comparing here is:
time(java.util.regex) > time(php compilation + c regex package)
PHP's execution performance is highly dependent on whether you are piggybacking the C implementations, or pure-PHP ones. That said, this is still a correct benchmark, if your use case involves a lot of regex.
Perhaps the problems are with the way the Java program is written and run?
Back in 2012:
"5) The idea is to help you understand that you aren't comparing what you say you're comparing.
If your intention is to compare time taken to grow a list, then shouldn't you start with lists that are the same size, and start with program heap that's the same size, and use the same max heap size?
user+sys for your Java program = 20.56s
But change
ArrayList<Integer> s = new ArrayList<Integer>();
to
ArrayList<Integer> s = new ArrayList<Integer>(8192);
I don't care about performance.
Unless we are speaking about orders of magnitude and my use case has an absolute need for performance.
If I only cared about performance I would write everything in assembly optimised for every specific architecture.
But strangely I'm much, much, much more productive writing in c#, Java, groovy, f#, ruby and whatever language is appropriate for what I need to do at a certain time.
For sure I won't start a new project using a language in which writing such abominations as accessing the database in the presentation layer is not even discouraged, but it is actually encouraged and taken as an example on HN in this thread.
Enjoy your marvellous php.
But please stop the bullshit that pushed a lot of people to use that franken-language rather than using a better approach.
Most professional PHP developers I've anecdotally worked with use a Model-View-Controller pattern these days, where the SQL is abstracted away in the model under something like Doctrine2-DBAL, Propel2 or PDO. If I was hiring for a developer and they suggested putting raw SQL in the view layer, I would reject them. If I received a pull request from my team which did the same, I would reject it.
You seem unnecessarily argumentative about this, almost like you're angry and I really don't understand why. There really isn't that much difference between languages like Ruby and PHP to warrant this and almost anything can be expressed in almost the same way, the only real differences are syntactic sugars and the "flexible" type system.
This exactly. Never been a PHP developer, but I did get handed a PHP webapp to copy some functionality out of for a replacement C# webapp. I was a little surprised to find out that it was written in a rather Rails-like architecture using some PHP MVC library, I think it was CakePHP. Rails was a hit, and a great step forward in web development, so naturally every other language copied as much of it as possible, including PHP. There may be plenty of weird quirks about the language still, but at least the architecture is much improved.
Many/most PHP platforms these days do claim to be either MVC or Rails-based or both. CakePHP is not a bad example there. There are however a few other very large projects whose take on MVC is lacking to some degree. Drupal is not bad, Joomla is worse, and of WordPress the less said the better. Note also that those projects are listed in order of increasing popularity.
Modern PHP frameworks and tools are good, perhaps even excellent. Composer and the PSR-# efforts have spurred a renaissance in code quality and interoperability, and PHP7 brings some truly impressive speed improvements. For those of us who aren't stuck supporting legacy code, that is. One of these days I will be working with a language whose syntax I enjoy, but until then the language that puts the "sin" in "syntax" will (for better or worse) keep getting the job done.
plus like you say PHP might be faster to get started with but becomes much slower on larger projects due to inconsistent error handling and language design.
Funny that people complain about js performance. In this benchmark it was 3 times as fast as php7 and about 7 times as fast as java 8. Have not checked the details of the benchmark yet.
Looks like you're reading that wrong? Java 8 is listed twice. Java 8, when using the non-standard library version of the program is second only to C++. This is pretty much as expected.
Don't trust everything you read on the internet, run the benchmark yourself and see if that result is actually reproducible. (Depends on the heap size.) There is also a "non-std lib" java test case, which doesn't generate as much garbage and, of course, performs much better.
Managers caring about technical debt? You must live in a parallel universe. They may care about maintenance costs, but that is not really the same thing.
They don't until things break, your app can't handle the amount of requests coming in, can't insert and fetch data in a reasonable amount of time, etc.
It's at this point that shit falls apart and the manager starts to care about these technical choices and all of the time and money that will be needed to be spent to rewrite.
Call it maintenance costs if you want but those costs are directly affected by the technology decisions you make.
Looking at things from the other side: being a manager and trying to sell projects to reduce technical debt is really freaking hard in a world of short-term outlooks and revolving door of CEOs that want to improve numbers this quarter or the next, not a few years down the road.
This is entirely true, but I have never worked with someone beyond the leader of my immediate who though the same. Most managers don't care what cruft is in there when it ships.
The scalability of PHP is great, because each request is fully independent. This is like the Amazon lambda model.
You /have/ to put your state in some storage back end, network attached RAM or such. This is a scalability best practice!
Yeah, but you also have to fork a whole process per request to do it.
Process fork, CoW overhead every time you mutate a page, and a full OS thread per request. Oh, and let's not forget negotiating a new database connection per request.
I think by the time you've added up all those overheads, you're not off to a scalable start. It's possible to work around the limitations, but it's not easy.
"fork" is not a major problem in PHP. In Drupal, every single request compiles a file "common.inc", of several thousands of lines of PHP code. That is what slows it down. It's remarkable that PHP still manages to do that in just 100ms.
In Zend Framework it's slightly better because it includes an autoload option, which implies only PHP files that are actually used by athe request, get loaded. That way the overhead is "only" 50ms.
The whole reason your Apache was (kind of) expensive to fork was PHP. You've only moved that forking to the PHP-FPM process.
But that said, forking processes is not really a problem unless you do really long lived connections (such as longpoll handlers). Many other languages do that. Not many other languages have kept the CGI-like request model that PHP has, though.
It encourages things like parsing code or even opening database connections on every request, unless you cache them. (Which you probably do if you are a PHP developer. But it's not always as automatic as one would hope. Have you checked your application still fits in the cache you set up?)
And even whey they were not over yet there was no fork for each request. A pool of workers was forked beforehand, and each worker could handle requests one by one without restarting (only PHP environment is cleared, OS level process is not restarted).
Only if you extract a ton of value per user or can serve a huge number of users per machine. Otherwise, upping the number of servers by an order of magnitude will start requiring an operations team to maintain.
That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
it's the "good problem". and the good problem can always be solved, though lack of reliability can seriously hurt your growth. but that doesn't mean that it's as easy as people make it out to be.
i wrote and ran a big php app (Zynga's Mafia Wars). this is just about the app server (apache + php side), single-master MySQL will give you far greater problems at that scale.
everyone is tearing away adding features, and the code just keeps getting bigger. everything includes everything else. so you can't just start fresh with every request, it takes way too long. so you use APC or whatever. now you have global shared state (and people start using it), but as long as no one really fucks it up that's ok.
php processes are always erring and dying in weird ways that no one can figure out, especially if anyone uses the half-baked OO stuff (circa 2008-9), and tracking down obscure php state errors ranges from difficult to impossible since you're never quite sure when or where something went wrong, but it works for most people most the time, as long as you remember to clear out the error logs so they don't get big enough to crash the box.
memory use still sucks at around 30M a process, meaning you can only have around 500 workers on at 16G RAM server, but it's workable. at least it's not rails.
because it takes a while to talk to even Memcache (go forbid you talk to MySQL) and do all your silly user updates (games are really write-heavy) you are taking a few hundred ms per request, so 16G mem servers (it's 2008) safely top out at around 500-600 req/sec, and i think would melt close to 1000 or so. remember, your throwing everything you have at growth and features so you're not really optimizing shit.
cool, just need more hardware. which is no problem. if you can get hardware. when you're co-located it takes forever to get new hardware online. not really an option. and even the F5 load balancers can only take so much. and there are issue with getting too many app servers talking to too many memcache servers. or something like that. after i left i think they saturated the data drops, which really puts you in a bind.
but that's not a problem now, with cloud services, right? except that those are not limitless either. i think FarmVille ran into a wall where AWS wouldn't / couldn't supply more instances (again, this was around 2009-10 so prob a lot better now). and those are still physical machines in physical datacenters somewhere that will have all the same problems and limitations and then some.
but you're going to have problems with any app runtime at that scale. and php's performance was an order-to-two or magnitude better than rails, and we never figured out how to get significantly complex and traffic-heavy java apps to stop leaking memory. though i'm sure you can. and you will! like i said, it's all solvable. hell, even MySpace didn't fail because of tech infrastructure.
what i'm saying is that php wasn't (and maybe still isn't?) particularly fun when throwing hardware at it doesn't work, and you end up losing a lot of the purity / simplicity of the model because it's too damn expensive. ffs, Facebook re-wrote the runtime. that's what it took for them. and my friends there tell me it's pretty much like writing java at this point. it's a fine choice, but i'd rather not use it again. had a much better time with python before javascript ate the world.
PHP is a framework. True it's not a particularly nice one, and some people build even more layers on top, but it comes with all manner of HTTP/url/DB/etc. stuff out of the box. It's also a templating language (that's what the "<?php" tags are for); although, again, not particularly great, and some people layer more abstractions on top.
In the sense of comparing PHP and Rails, then no PHP is not a framework. Codeignitor, Laraval, Cake, Yii; those are PHP frameworks and fair comparisons to Rails.
I can (and have) just grabbed Rack and rolled most everything myself in Ruby and it has way less overhead and is much more performant than Rails. Ruby also has it's own templating language; ERB is part of Ruby core.
So comparing PHP to Rails is a bit apples and oranges.
it's a business decision comparison, not a technical categorical comparison. you need something to receive http request and return http responses, and you're comparing different popular (because hiring, training, and available community / support resources) ways to do that. they might be apples and oranges but at that level you're concerned with comparing fruits.
In this case it was a technical comparison; the original poster stated, "php's performance was an order-to-two or magnitude better than rails".
If you are making a technical comparison then it needs to be at the correct layer of abstraction. If we were to compare performance of Laraval and Rails that would be a fair comparison.
If we are comparing on performance then PHP should be probably be compared to Ruby+Rack since that is sort of the lowest common denominator.
I'm not dogging on PHP here either. Even comparing at the correct level; PHP is still faster, but lets make sure we are making the right comparisons.
as the other commenter said, php is a web framework... and it's what we were using. it's actually more of a web framework than a language in my opinion (or at least was at that point). it's centered around receiving http requests and writing http responses. the article mentions this in fact.
it was a huge pain to try and get php to do anything else. it was totally unpractical to do the kinds of back end processing that we needed (since the database was pretty much off limits during a http request)... long running processes with hundreds of millions of objects were a no-go. believe me, we tried. which meant you had to sync all your logic into Java or something else that could handle the job. which is really error prone when you have a bunch of people moving fast on something.
one of the greatest things about php is that it's a super minimal focused framework. it's also one of it's major short-comings when that model no longer suffices.
you can layer something else on top of it, but the stuff available at the time certainly didn't help the performance or memory characteristics.
I feel your pain, I also worked on a large MMO style mobile game backend, but my situation was a lot better because as you say AWS is a lot more mature at this point.
Dealing with limited resources such as MySQL and Redis is a problem you still have to fix when you move away from PHP though.
As for the Facebook runtime, for us it was a case of drop in HHVM, fix a handful of issues and get a 4x or 6x speed increase for free. You only need to change the way you write if you move to Hack, but I think I agree with you that's probably getting to the limit of the effort reward tradeoff before you rewrite in a different language.
Developers care about cognitive load, and people care about security.
Sure, they'll be some guy who's memorised all of PHPs quirks, but for most of us the inconsistencies make it hell to program, because you're always looking up stuff. As a result, writing secure PHP is possible, but far harder than it should be.
IMO the laughable security track record of e.g. Wordpress have damaged PHP's reputation more than anything else.
As a counterpoint, Facebook, one of the most secure companies in the world, is also the largest single PHP deployment in the world.
C is also a language with a frankly horrific security track record; at least an order of magnitude more so than PHP. But C continues to be used because it is a useful and relatively simple language despite its warts and pitfalls.[1]
Security is just as much a business process as it is a technical feature.
______________________
1. Granted, one of the major design goals of Rust is replacing C, but you get the point.
I think your comment about C is right, however in many cases mercifully the C code isn't facing the internet :) When it does, it can go very wrong, e.g. OpenSSL.
The extra cognitive load doesn't guarantee failure, it just makes it easier to slip up. Even with Python or Rust, you can put insecure code in there (e.g. with Python's subprocess.call(..., shell=True)). Realistically, strict modes and linters are always a good idea and can catch most of these pitfalls.
At which point did you decide not to read the comments properly?
The gist was that PHP was designed for web use, so it's almost always facing the internet. C on the other hand is very much multi-purpose. Both can be made secure, but maybe it's less effort using something that helps you with security (Hack, Rust, etc.).
(BTW, your comment contains a huge fallacy: Just because a majority of packets touches something written in C, that doesn't mean a majority of C code written is exposed to the internet. This is arguably the entire point of e.g. iptables.)
Doesn't it stand to reason that the people that actually know how things work under the hood are the people that care about such things.
You could say the same thing about cars people don't care about what sort of engine is under the hood or how it works they just want to go places! It doesn't then follow that all cars are the same and you are just as well getting any one of the millions of cars or even any one of the models out there.
You have a logical point for sure. I think it might be an apples to oranges comparison in this case though. I just don't know that building cars is the same as building websites and apps. I know Php and JavaScript can respond to an HTTP request. I don't know how to optimize an internal combustion engine. There's probably parallels in terms of expertise with software developers, but I can't be sure.
> I just don't know that building cars is the same as building websites and apps.
Indeed it isn't. "Maintenance" has opposite meanings in those worlds: maintaining a car means keeping its original functionalities still available; maintaining an application means letting it evolve.
> Only engineers care about programming languages. Seriously. That's it. No one else cares about them.
So what? Who else could care for something apart from those professionals using it?
Maintenance is the biggest part of software development. A wrong technological choice can turn my nice job into my worst nightmare. Why shouldn't I care?
I think the intention is: While they are important to us, languages are frequently distorted to the point that we believe that company success as a whole is dependent on it. Companies like Facebook flatly contradict that. I agree with you in spirit: Facebook would obviously prefer not PHP. But if the choice is: Learn something other than PHP or use language I know to test some idea, I think the latter is an obvious choice.
Runaway successes like FB are outliers. Failed businesses OTOH are quite common and usually have a number of causes where bad technology choices can be at least a factor.
You call it poor management in retrospect, but it's succeeding in spite of the tools when you're still doing ok. There's a lot of companies that exist in between failure and "Facebook" who don't have hockey stick growth curves who also can't afford needlessly higher technology costs, whether that's in infrastructure or staffing or opportunity costs in getting features to market. If PHP does't incur a higher cost personally, go for it, but it might be a strategic disadvantage later if you don't hit it big.
"Only engineers care about programming languages."
It's sadly quite common for non-engineers to make technical decisions such as what language, tool, or hardware will be used, and everyone else just has to live with it.
Brian, do you have any examples of companies that failed using PHP that you think would have succeeded with another interpreted language, and what problems did they run into that gave you this judgment?
Asking as I've developed in a slew of languages and never found the PHP-bashing credible. Most of the complaints seem to come from Rails people, but there are no shortage of MVC frameworks in PHP, including at least one that is a direct clone of Rails.
I to have seen plenty of companies flail and get bogged down because of technical debt and a just get it done culture. It's really hard to begin with a "yes it's a mess, but it works" culture and transition to anything else.
Plenty of A rounds have been spent trying to make a sand castle taller.
This is not unique to php - I'm sure you can do it right - but it's more common to it.
I've seen plenty of companies fail (or at least stall) because of technical debt. PHP certainly isn't to blame for that but it doesn't exactly lead by example either.
I think it would be hard to provide such an example. Mostly because most companies that fail don't do it because of technology but rather because of the nature of their product itself, people, or money. And language plays a part in it but not a particularly noticeable one. Another reason is that failures tend to be silent and we don't pay attention to silent things.
True. But they might have failed with any other choice. Technology is overrated. Yeah, it matters, Yeah it helps. But the right foundation won't save a shite product.
A truly good idea will generally find a way to succeed despite the technology it is built on, though. Look at Facebook, Slack, and countless others running PHP or Minecraft running Java and its apparently horrible code base (I've never seen it, so that is secondhand)
A number of things actually follow more logically than tech doesn't matter which is counter intuitive and counter to most other endeavors in life.
- We aren't very good at judging the relative virtues of tech
- Most tech is good enough to express most concepts even if not equally well. If its possible to express it even if it takes 3 times as much work and is only 70% as good you wont notice from the outside how much the tech mattered.
- Good ideas are worth enough money to throw enough time/money at them to be moderately successful
Delivering enough value to users, faster and cheaper than the competition, wins.
The language you use pay second- and third order dividends, but most battles are fought and won on first order.
I'm a C++ developer, have shipped Java and C# and Haskell and Python and a bunch of other code in production.
If a friend asks me to spin up a website for him/her quickly, I'd still do it in PHP.
What does PHP offer, now, that a static site generator doesn't? I'm going to guess Wordpress, WYSIWYG editor, simple uploads. But if that's not it, I'm genuinely curious.
For many use cases, this is not relevant to the end result.
For many use cases where it is relevant, static site generators like Jekyll can actually imitate "dynamic content" from the perspective of the people running the site.
The most important use cases for dynamic content these days are web applications, as distinct from "websites". On the other hand, web applications are also the most important use cases for better development ecosystems than are easily attained with PHP.
In my experience and observations, the cases where PHP's easy provision of dynamic content capabilities make the most difference are websites (as distinct from "web applications") on shared hosting platforms or bootstrapped by existing content management systems like WordPress and Drupal (which are, in turn, often easily used because of either hosting platforms specifically for those CMSes or shared hosting providers).
NOTE: I'm not sneering at "websites", as distinct from "web applications", as many people who draw such distinctions do. I'm just pointing out there is a distinction to be made between two different types of projects involving deployment of a codebase to a web server. Speaking only of the technology's proximate purpose: in one of these, the primary purpose of it is to make content accessible to the public; in the other, the primary purpose is to make functionality accessible to a userbase.
To expand on this, static website generators are best for generating documentation and small blogs. It falls apart when you have a large often-changing content. This is where PHP is still king of the web.
> It falls apart when you have a large often-changing content.
Today, when one can have workflows via jekyll/git/Continuous deployment, at what frequency of "often-changing" should one move away from static websites to a php based solution?
I haven't tried jekyll so I can't really comment on it. Im guessing it only generates the changed files everytime you push to git, no? As for your question, it depends on other factors too. Who are your users, what is your web app, is it an ecommerce site? Is the jekyll/git/CI workflow easier than just pressing a few buttons on the screen everyday? Those are the questions you should ask. jekyll might be obvious for us devs but we are a minority compared to the rest of the population.
Take HN as an example. This can't be done as a static site.
Or a simple guestbook or hit counter.
Where the lines may blur is JS front end talking to a BaaS... This may make it possible to glue up impressive sites using just HTML and JS with no custom backend requirement.
> large often-changing content. This is where PHP is still king of the web.
PHP is still widely used, but there's a myriad of other contenders: Java, ASP.NET, Python (Django,Flask,etc), Ruby (Rails), Perl, Javascript (Node,etc) and others.
I'm not sure about PHP being the "king". PHP might be the most widely deployed thanks to either FB or the huge number of legacy bulletin boards and wordpress sites, but in terms of new deployments does it still dominate? Probably not. (For novices, a static site generator is definitely the way to go, until you run into it's limitations.)
All of the languages you listed have a way steeper learning curve than PHP. PHP creates a lot of really small steps you can take getting from "I roughly understand HTML" to "I can build a full 3-tier MVC buzzword-of-the-day app.". For anyone not intending to become a full-fledged programmer, but instead just to add a little bit of interactivity/dynamism to their website, it's still the path of least resistance.
I'd argue that Javascript (sans all the frameworks and bullshit) will also get you there quicker, because of the intrinsic DOM connection. But yes, backend JS sucks.
I also made a start with PHP. Still, PHP has been slow to learn from other languages and frustratingly refused to change established behaviour. I found PHP to be far more "dangerous" for the amateur programmer than other languages. Finally, I switched and never looked back.
From teaching beginners, I actually think Python + Flask has a similarly shallow learning curve, but more room to grow and to "do it correctly" (e.g. the templating is much cleaner and the routing much more powerful). I recommend it.
echo "<h1>hello</h1>" vs... damn, how do you even print a line in Javascript (Node, to be fair)? console.log()? Wait no, that prints to a terminal. Response.write? Oh, wait, I have to implement the http.createServer callback? Yeah ok, oh and it's ... response.print? No, no it's response.write. Oh what it's not working? Oh I need response.end() as well.
Hopefully you get the point.
(I do agree that PHP without something like Symfony, Yii, ... Laravel, even Cake could be very dangerous, or at least, counter-productive for amateurs trying to learn though)
I've gone one step further and created a template:
Some companies are succeeding in spite of [insert language]. There are many, many users of [insert language], and we'd expect that there would be considerable variance, with some users doing awful (no traction, buggy sites, etc) and some hitting home runs (facebook). Because it's such a popular language, it will have users across this entire spectrum.
It's easy to cherry-pick the winners and miss all of the tremendous losers who picked [insert language] and got nothing for it.
I know you're making a parody, but I think I agree with your parody.
I mean, essentially all you're saying is "startup success is largely uncorrelated with the programming language used to implement those startups' products". That seems like not at all an unreasonable position.
(It's not, by the way, equivalent to the statement "choice of language doesn't matter".)
Mind, I agree with you, but given the Holy Documents Handed Down By Our Lord and Savior, Paul Graham, HN... might not be the safest place to say it.
Edit: so, I'm clearly getting a lot of downs on this... maybe sarcasm in reference to PG was going a bit too far. Oh well. I'm not deleting or editing any of it, because that's sort of dishonest.
All three of the above communities (PHP, Ruby, and FnProg) are diverse enough that a PHP meetup in ___location A could be culturally similar to an FnProg meetup in ___location B, and so on.
you could definitely argue that a company using PHP nowadays would find it harder to find good engineers because the best ones who care about quality, performance etc don't want to work on a PHP app
I completely agree with this. There were a host of similar services when Facebook appeared in my radar, I was signed up to a couple of them. Its only because more friends signed up for facebook that it seemed to have a snowballing effect. It didn't seem in any way superior (well except compared to myspace).
In Germany, we used to have a VK-like social network aimed exclusively at university students that was big before Facebook even appeared. To this day I have no idea how that died so fast and hard, and how Facebook managed to overtake it when it hadn't even translated the interface. Ze English izn't zecond nature to all ze Germans.
Ah yes, the * VZs. From my perspective, there's a few reasons. One, my friends were very privacy conscious and would often either not sign up or use a weird name (like some people do). This made it hard to find people. Two, the user experience sucked hard. Third, they had different domains for different subgroups (I remember one for school children and one for students).
Finally, if you went travelling to any other country (except Austria or Switzerland maybe), the rest of the world had Facebook. So to keep in touch, you also needed Facebook, which had a better user experience. Why bother with both?
It's a testament to the poor state of the art in user experience for early social networking sites that Facebook had a (relatively) "good" user experience. It has always been horrible, except relative to most of its competitors.
Your template is far less interesting than the original statement. PHP spent a pretty long time as basically the lingua franca outside the enterprise world (and even some places in it), and there are still domains where it holds that title (e.g. WordPress alone outweighs many languages' ecosystems), so the phenomenon the parent was describing applies more to PHP than to some arbitrary language you could insert into this template.
I actually agree with the original statement. PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail.
"and miss all of the tremendous losers who picked php and got nothing for it"
certainly applies equally across all languages in my opinion.
The grandparent of your comment suggested that, yes, these projects were lifted up by PHP's un-fancy nature giving them focus. The parent of your comment was suggesting that, basically, the companies that have succeeded using PHP aren't any more numerous than we would expect to have come out of the massive PHP userbase even if PHP doesn't offer any advantages at all.
The observation that "PHP, for quite a few years now certainly has NOT been the language of choice for most startups, yet we still see the majority of them fail" seems to be responding to a nonexistent conversation in which people were positing that startups based on other languages don't fail. Nobody here is saying that other languages magically make your business succeed.
Precisely. This is classic base rate fallacy. If tons of people use PHP because PHP devs are cheap, there are bound to be a ton of successes despite the fact that it's a horrible technology in many respects.
Perhaps. But that rather begs the question. PHP has horrible bits, but in fact from what I've observed in the last year or so is that whilst it has in the past been fairly horrible, much of what made it awful can be entirely avoided.
If you aren't following the PHP Framework Interop Group (http://www.php-fig.org) then you really should. I'd hazard that most of the warts in PHP can now be avoided pretty much altogether, and those that can't quite possibly can be worked around through configuration.
It's easier to reroll in another language and retrain or recruit? No. So you probably mean for a new project. So now you've more maintenance and learning curve unless you just happen to have enough skilled in $NEWTHING. Not really easier.
PHP is an inconsistent mess, everyone knows that, but it's cheap, widely understood, and it's perfectly possible to write decent maintainable code. There's ways to mitigate the chaos.
True, I have seen one startup fail early because he couldn't find any (cheap) Django devs. He might have stayed around another year with the funding he had if he had gone PHP.
Lesson Learned: If you can't do it yourself, start with PHP (or something else with incredibly cheap devs, I suppose) until you get VC funding, then rewrite it using something other than PHP.
Money past a certain point is not an incentive. Retraining takes time. It's harder to land jobs for which one does not have relevant work experience. The PHP job market is larger than most other web programming segments, so work is easier to find. But sure, if you're hiring, I'd certainly prefer working with Ruby.
There are plenty of great server-side languages and environments. C#,Java,Scala,Python,Ruby,Haskell.
If this was about JavaScript and Front-End I might've agreed with you (there are transpilers but interoperability with JS modules can be tricky), however in the realm of servers there's so much freedom.. so why choose PHP out of them all?
> plenty of great server-side languages and environments
Depending on the type of project, I would choose PHP over at least some of the languages you mentioned; I guess "great" is not a significant quality when making architectural choices.
Just to be clear: I was thinking about factors like performance, choice of servers, how easy it is to hire good developers, library ecosystem etc.
EDIT: obviously the "awesome aspects" mentioned by GP are a similarly unsubstantiated claim ;-)
The .NET CORE is now open source and cross platform. Cross platform compatibility with the exact same source code, and the killer features/speed of C# makes its my personal choice for a server-side language. I would like to add that C# devs are not cheap and also seem to be slightly more limited in today's market compared to PHP devs.
If you are running .NET code in production on a non-Windows platform today, then you and your team are probably braver and more willing to work around issues than most. I hope that running .NET code on Linux becomes the common case, but I suspect that we are still a couple of years away from that.
It might not be exactly what you had in mind as 'in production', but it's probably worth noting that Unity uses Mono as a core component, and it seems to be fairly popular on non-Windows platforms.
If you are building software that will be deployed by a large number of users, having PHP provided by every $3.99 & up hosting company can't be underestimated. Languages like Haskell are nonstarters.
Disclaimer I worked on a large php app server that ran on about 50 servers and I miss it.
The documentation is really good. A model for programming language documentation.
Process per request is really simple to understand and scale. Your servers almost never crash completely, you don't get threads silently dying or run out of memory or thrash the CPU doing garbage collection.
It runs like a tank. It will, for better or worse, just keep running when more fussy languages would have seg faulted or shut down
The tooling, framework and libraries are very advanced and in active development
It's easy to train a programmer in php
It's close to the c library
The combination of a very flexible array/map and functional programming tools like map and reduce let you write pretty declarative code and development can be very fast
Php storm
Facebooks replacement runtime
I work with Java and Scala now which I also love but development is much slower and more expensive, whilst deployment is cheaper (less hardware for same request throughout)
Can you describe for me how the tooling, framework(s), and libraries are so advanced and excellent?
How easy is it to train a programmer to use PHP in a way that results in fairly secure, reliable, bug-free code? (Note my use of the word "fairly", knowing that there's no such thing as perfect security, reliability, or freedom from bugs.)
I do know that, for instance, TDD is possible with PHP. In my experience and observation, though, the available developer tooling does not even come close to that of (for instance) Ruby, so I figure I must be missing something if "the tooling, framwork[s,] and libraries" constitute a major advantage to PHP over other options.
Well firstly phpstorm is a very high quality. I can work with php code in various contexts such as running test suites, normal development and connecting to a live server. It definitely has good support for running and debugging test suites including unit, integration and functional. There is support for vagrant and docker as well.
The tooling is good because there are lot of users willing to pay for good tooling, but at the same time it can only exist if the underlying language supports the features needed.
I wouldn't say the libraries and tools give it a significant advantage over other languages actually, but it's a notable factor of php development that there is likely a framework and library for your needs.
Regarding training, once we had a reliable application and we'd figured out as a team some best practises regarding avoiding php's bad parts, how to avoid or detect and handle runtime errors and how to organize and layout code, it's a fairly simple matter to point a new programmer at these documents and code samples.
There's really not much to the language and a smart and/or experienced programmer can be productive in days. I'm not sure that's the case if you move someone from say c to Python or from Ruby to Scala.
PHP is about 1/3rd of my day job. Java 1/3rd, and support languages for ops (mainly Python and shell scripting) 1/3rd. Find myself commenting a lot on PHP threads in the last few days...
In my earlier days I did quite a bit of developer tutoring, and I have trained developers in PHP codebases on quite a few occasions, so I can speak to the training aspect first hand. I actually find PHP is fine to train developers in - certainly to produce simple code that is reasonably bug free, if not particularly high performance. The 'everyday' use of the language is usually quite straightforward - most projects don't deal with concurrency primitives, long running code, or low level interop. Scoping is quite straightforward. The only real gotchas are type coersion (use === for primitives or write comparator functions) and superglobals (use a library).
To be honest, JavaScript causes just as much confusion in my experience with scoping. Heck, a scarily high number of developers I know would struggle to implement a bug-free equals() method in Java.
As for tooling - here are some examples of good tooling in PHP:
- TDD and testing:
- PHPUnit (ubiquitous, fairly well featured - built in fakes, code coverage)
- Behat (BDD-style testing a la Cucumber)
- Codeception (DSL-based)
- All three tools have decent integrations with IDEs, can be run easily through Composer's CLI, can be combined with stuff like Grunt/gulp easily for file watchers.
- I haven't needed the really esoteric features in my Ruby projects so I'm probably not the best to judge, but I can't say that I find PHP testing tools all that lacking compared to rspec, cucumber etc. I don't feel like you need complex tools for good testing...
- Frameworks such as Laravel provide bootstrapping on top of e.g. PHPUnit that provide integration test componentry
- PHPDoc - ubiquitous, well documented, well supported by IDEs, linters, docgens
- PhpStorm (on par with the best IDEs out there), Zend Studio (very good IDE in its own right, eclipse-based), and Eclipse PDT are definitely servicable IDEs with good integration, good code inspections, good support for refactoring (especially now with PHP7 and it's further push into gradual typing).
- PDO - something most other languages have to be fair, but a language-supported SQL database engine abstraction layer is a must for working with SQL databases these days
- Gearman for task queues
Libraries and frameworks available in PHP are much the same as other languages in my experience, when it comes to stuff for the web. Not really much point going through them, suffice to say that there are some poor choices (Wordpress), and some good choices (Flysystem).
It has everything I need to know about the function clearly laid out. The behaviour of sort when elements are the same. A list at the side of related functions that I may want to look at instead.
I also like documentation that includes user contributions as these often add useful caveats and usage examples that don't fit well in the general documentation.
Php documentation is the worst. Some of the reasons..
1. They have exactly one set of documentation pages for all the php versions.
2. Another thing is that documentation can be quite wrong for even the fundamental stuff. I have seen a core developer blast out in reddit that "The documentation is wrong!", when the other party pointed them towards a piece of documentation.
3. Incomplete or shallow description. Go check out the documentation page for Exceptions in php and try to find information regarding the behavior of return statements in a 'finally' block. Now go an see the respective page in Python documentation and see how in depth the documentation is.
And having code samples is not exclusive to Php's documentation..
It's not just about the obvious "warts"; it's about the fact that PHP is not a well-designed language on the first place. A wart-free pig is still a pig.
Rust and Haskell are both extremely well designed. Most of the "top languages" by percentage usage are 20+ years old, so I can't fault them that much for being badly designed, but we should definitely stop using them.
That will never happen, you can't write code like this in Rust:
<!-- Snippet taken from an example of tightly-coupled and unmaintainable code in the Clean Architecture in PHP book[1] -->
<body>
<?php $results = mysql_query('SELECT * FROM customers ORDER BY name'); ?>
<h2>Customers</h2>
<ul>
<?php while ($customer = mysql_fetch_assoc($results)): ?>
<li><?= $customer['name'] ?></li>
<?php endwhile; ?>
</ul>
</body>
Even when the previous code is an abomination, it is absolutely easy to write, this is why languages like PHP are a success, the barrier to entry is definitely low.
The issue comes when the whole industry buys the idea that PHP equals bad code, fail to appreciate the progress the language has had in the last years, fail to appreciate the effort behind projects like Symfony, and become completely foreign to the current best practices.
Why would I ever want to access the database from the presentation layer?
That you cannot write that abomination in rust for me it is a clear advantage, not a disadvantage.
And still I can't understand how can you compare php with rust.
A much more apple to apple comparison would have been with WebSharper.
Because when you're just some guy that wants an answer to the question "how do I get some things from a database into a web page", the answer that starts "Well first go set up a VPS..." and hits "There's this thing called MVC" somewhere in the middle is not something someone who just wants to put a list of things into a web page is going to listen to.
Then a month later that guy that pulled those couple things into a web page is going to go "Hey, maybe I could make a thing to manage those.". And he's going to learn more.
Then a month later he's going to have another bright idea.
And suddenly someone with no programming background is a PHP programmer, and he's putting together ugly but functional websites and everyone is looking and going "MAN PHP IS AN AWFUL LANGUAGE".
There's a huge contingent of people that are maybe moderately technically savvy but are not programmers and are not necessarily interested in deliberately becoming one. These are the people that end up setting up entire businesses in some Lovecraftian Excel sheet. PHP is a language with a learning curve (even for a non-programmer), not a learning cliff, and it makes it really easy for these people.
I don't know if you can do that in Rust (I suspect you can with some effort), but you can certainly do it in Haskell (with slightly different syntax, of course) using a library like Blaze-HTML5.
Your argument is a bit spurious; you're right insofar as you can't write PHP in a language that's not PHP.
That is my point. You require effort in an order of magnitude greater than with PHP in order to achieve the same result, which in the case of a beginner, is the difference between continuing their journey in programming or abandoning the ship.
You are failing to see the big picture and are taking for granted the plethora of initial setup you have to do to begin working with a language like Rust (ex. generating bindings for a database driver written in C if it doesn't exist in cargo), you were just nitpicking in the syntax of the previous example (which BTW, I took care to clarify it was an example of bad code to avoid people not familiar with PHP from getting the wrong idea).
It was my fault to say "you can't" in my previous message (see Atwood's Law), I really meant "it requires too much effort".
>You require effort in an order of magnitude greater than with PHP in order to achieve the same result..
An order of magnitude? Really? I don't think so.
Rust has a library (probably among others) called Horrorshow[1], that exports macros to do html templating.
You claim that it is easy in Php to do html templating. But you miss the fact that it provide zero sanity/security checks while doing so. You need to sanitize every one of those variables before inserting into the html stream.
You see, Php just trades off every bit of sanity and security for a little bit of ease of use. It is that simple.
Yes, an order of magnitude, in PHP we're talking about _minutes_ in Rust we're talking about _hours_ or even _days_ for a beginner programmer, ever tried to install Homebrew in a Mac to name an example? It adds at least a few hours to the equation with its dependency on Xcode unless you already know to just install the command line tools.
Remember that a beginner programmer doesn't always have a background in Computer Science, maybe it's a child, maybe a graphic designer, maybe an elder person or a housewife. Are you really expecting from a person foreign to CS to stop tinkering just because they can't write secure and performant code in your favorite language?
Again, stop taking for granted the initial process setup and all the gotchas that you already know, stop nitpicking in the example of templating and see the big picture: A beginner programmer being able to get instant feedback with little effort in their browser of choice. No initial project or repository set-up, no install for external libraries, no huge development environments (like Xcode or Visual Studio), no build process or compilation, no command line, just an app like WAMP (on Windows) or MAMP (which people accustomed to homebrew avoid) and a browser pointing to http://localhost.
PHP is not a perfect language, but it's neither the abomination people like you describe, too many people judge PHP by its former state of the art and are unaware of the progress it has had in the last years, many of the most popular issues are already gone or at least are too difficult to trigger, to name an example, PHP stopped having register_globals since version 5.4, and PHP 7 added strict type hinting, which throws an error instead of doing unexpected type coercions.
That doesn't mean that PHP is a better choice than properly-designed alternatives, just that it's less worse than before. I agree with the sentiment of using a well-designed language like Rust, but only when a project really requires that degree of security and performance (ex. writing a browser like Servo).
A bakery website written by the kid of a patissier doesn't require that degree of security and performance... Or are you really going to demand that child to use your favorite language just because you despise PHP?
So, you are saying Php is like LEGO and BASIC for web development. I have got no problem with that. Problem is that people using that in a professional setting and uses it to put stuff online.
>A bakery website written by the kid of a patissier doesn't require that degree of security and performance...
I don't think so. Everything that is put online need to be secure. One day it is just a bakery website. Next day it is accepting credit card numbers. And the kid who did this can get employed as a php developer based on this experience, and might build stuff like that for years, with out a clue in the world that they are using a toy language.
When I say "with some effort" I mean "with a bit of initial effort to create a combinator library and zero effort after that". I'm not familiar enough with Rust to be confident of that though. It's certainly the case with Haskell.
> I don't know if you can do that in Rust (I suspect you can with some effort)
You can, using some web framework crates, but PHP is many many years ahead from Rust in making web apps. And I'm not sure if its the right language for the web. You'd probably be fighting with the borrow checker and type system most of the time while the php dev is busy cranking out new features for his/her web app. There is also the problem of compiling huge websites.
Rust looks very complicated to me because there are "lifetimes" and you need to think where to put those single quotes properly. Not a language for a beginner.
Haskell doesn't support OOP if I remember correctly. And it is complicated too.
I never said it was for a beginner, just that it was well designed. Lifetimes are no more complicated than stuff you regularly run into in C++, though.
Python is a great beginner-friendly language, but that doesn't mean it's well-designed in other respects or appropriate for large software projects.
It wouldn't really make sense for Haskell to "support OOP" in the usual since. The OOP paradigm is mostly useful when you have mutability. Another way of looking at it is that you don't need OOP in Haskell because it exposes better ways of interacting with data that aren't present in most OO languages, like ADTs and Typeclasses.
Due to lifetime elision, you rarely need to explicitly write lifetimes. I participated in the last Ludum Dare game competition, my game never used an explicit lifetime.
That said, it is true that Rust has tricky parts. The ___domain is inherently complex.
> If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it.
This is exactly right. The right philosophy for PHP is to embrace the garbage. When you're done with a request, and have spit out all the HTML to the client, the server is going to throw everything away. So don't build a beautiful object tree to describe everything, just do the minimum amount of work to take the garbage input and generate the garbage output, and be done. Don't worry too much about your code being beautiful, because it lives in a dump.
This may sound negative, but working in a dump means you don't have to worry about appearances while you do what you came to do. You can always take a shower on the way out :)
If I wanted to embrace garbage every day I would have skipped college and went straight to being a bum. Life is too short to "embrace the garbage" every day.
Not sure about that. Most companies biggest problem is finding talent employees and most experienced engineers will not want to work on a Php codebase especially one full of technical debt due to the variety of other options in languages which compile and miss out on a huge percentage of php problems before you even run basic tests.
> It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick.
PHP didn't succeed because of the "language" part. It succeeded because it was limited and focussed to just being a tool to write small web-apps in a short time.
It did one thing and did it better than anything else of the same era (I built CGI apps in C, Perl and Python before discovering PHP).
It was just files, that you ftp-d in and it just worked.
99% of the friction is in writing the first thousand lines of code and PHP meant that nearly all of those lines was business logic, not unescaping POST data or parsing GET parameters.
PHP doesn't remove your ability to think clearly. It is true that it does not provide helpful additions for algorithmic work, but it does not put challenges in your way when writing web-apps. And yet, it does not force you into too much magic about how it works - just enough abstraction for a messy coder.
I'd argue it succeeded because it didn't require you to run a server. All those cpanel lamp ISPs mean sign in and upload code.
All other solutions, java, .net, node, python, Haskell, etc require you to run and maintain your own servers. A minor exception for CGI based solutions but those were all too heavy.
This comment just nails it. It is perfectly possible to have a well written code base in php. I don't understand whatever written in php is shit.
Some good programmers genuinely point out some of the pain points of php, but most programmers paint php as shit just to show off as a good programmer.
Most definitely you can write good code in soho like anything it is a language which you are free to write in however you like.
However Php allows for really sloppy code (not failing on index misses, undefined variables still running, each core part of the language handling errors completely differently) which unfortunately often gets pushed out when not ready because of business pressures. This often creates insurmountable technical debt later on. The amount of confuaing, messy code I've seen in PHP that would not even run on other languages is shocking.
The fact it has a super easy initial learning curve but progressively harder is not a benefit on big apps it just hides how many headaches it will cause you later trying to figure out the inconsistent core library once you are trying to do more than hack WordPress templates together
> It did one thing and did it better than anything else of the same era
I would argue that it still does. It's not a great language, but to just get something working I still can't think of anything better that doesn't require lots of planning or infrastructure
So much time wasted talking about the "right" way to build software, and the best technologies to use, taking positions to bolster your CV or make a name for yourself, and nowhere near enough emphasis on shipping useful, working software.
It drives me slightly nuts. Many people don't realise that technical debt is often a great problem to have because it means you've succeeded. They also want to live in this reality distortion field where they ignore the fact that the code they write today is tomorrow's technical debt because, for reasons I don't fully grasp, they think they're going to do it "right" this time. To quote from Garth Marenghi's Darkplace: "Uh-huh? Bye." In 5 years' time our successors will be wandering around moaning about the crappy code we wrote today, but only if we succeed.
If PHP is the fastest route you know to releasing something worthwhile then more power to you.
(Just to be clear though: I'm not advocating an end justifies means approach to all areas of life.)
Eh, you can do rapid prototyping-type garbage code in any language you are proficient in, as you can do the endless-architeture-meeting, special snowflake beautiful code, enterprise-level everything documented and automatically tested continuos integration and deployment to the most popular containerized/virtualized environment for a reasonable price of $millions in PHP or even bash or powershell.
V1 is usually shit in any language and if it does what it's supposed to do, it remains shit forever. I've seen shit in C#, Java, and ROR. I've seen stored procedures stringed together inside MSSQL Server vomiting HTML snippets and PS shells giving birth to Excel files to be consumed via network share by some poor soul pressing a button in Excel. I've seen systems written in "enterprise" style, by "enterprise" developers without a single automated test and 20+ levels of abstraction with cross-dependencies running like spider web among 10-some "sub-projects".
I'm not even talking about time-tested shell scripts you can find included by default in your favorite distro or the widely beloved ./configure.
I guess the point is, the language has nothing to do with the attitude of the developer / project manager / product owner. It's easy and convenient to just dump your problems on the tool you're using, but the reality is more deeply rooted in the whole approach to software development (just get shit done), project management (the requirements have just changed, dude!) and the general "i need it done last week" attitude of the product owners.
But sure, let's collectively shit on PHP, just because it's easier. Just like writing shit code is.
I work in C# every day. I love the language, I love Visual Studio, I love the application lifecycle management features of the ecosystem. There's very little I don't like, or at least understand.
I started my career as a PHP developer. Any web project you prototype in C# could be prototyped in PHP in a small fraction of the time.
And any PHP thing could be easily prototyped in C# using MVC framework or such. 0 to http-response time is easily comparable if not even faster to what you'd have with PHP. You don't even need IIS. C# is a fine language and I have enjoyed it thoroughly before returning to PHP after some years, but you also can breed monsters with it. Cheers!
touch public_html/foo.php gets me to a http 200 with a valid php file (with the assumption that i already have a public_html directory with mod_php or the like enabled), how fast can you get a C# to http 200 ? :)
I have IIS running with c:\inetpub online (just like you have apache with mod_php). I put a valid foo.ashx up there and voila - the field is level. Okay, the invocation is a bit heavier,
<%@ WebHandler Language="C#" Class="Handler" %>
using System;
using System.Web;
public class Handler : IHttpHandler {
public void ProcessRequest (HttpContext context) {
... code ...
versus just
<?php
but, come on, it's not that bad/difficult, is it?
on an tangential note - I never had imagined i'd be defending the point that C# is as simple as any other language... Funny how life sometimes takes you to unexpected places.
After I use both php and ruby for the same employer over more than a year. I would rather say Ruby is more like a garbage language -- 1) twist syntax to allow people write the same function into different ways is not a cool feature, it is disaster feature which causes more for a team to sync. 2) Duck typing is not interface, don't kidding yourself. they are totally two different thing. 3) ruby attract a lot of master level people try to make the community better, however, the whole community filled with mediocre developers who cannot even understand Rail != Ruby, and also they believe ActiveRecord is the only persistence layer they can use, and stop learning write native database query script.
Finally, good luck with writing a unit test against an API not created by you because, you have to go through deep into the source code just for figuring out what data structure return and give.
I have worked on both (among many other languages) and I too prefer PHP, but I guess my opinion on Ruby is unfairly distorted by Rails, which I dislike a lot. I hear that Sinatra is nice, for example.
Yes, Django is in some ways similar to Rails but, at least, in Django I know how to exclude some parts of the framework (e.g. if I don't want to use Django forms, I'll just go on and use vanilla HTML forms, if I need raw SQL, I'll go for that rather than Django queries). I suspect that the same kind of thing is, at least to a certain degree, possible in Rails as well, however it seems harder to achieve because in Rails the components that make up the framework seem very tightly coupled. Obviously the opinion that I have formed may be distorted by the fact that I know Django/Python quite well, whereas I know little about Rails/Ruby.
EDIT: obviously I agree with you that, if you want more freedom and if you are not using many of the features that Django offers, then it would make more sense to use something light-weight like Flask, which is a very nice framework.
I think you are expressing some legitimate opinions about what kind of languages you like. Ruby, like Perl, embraces more than one way to do it. Some people like that, others find it irritating. Neither reaction is wrong. I think the same thing goes for your reaction to Ruby's lack of explicit interfaces. I find it liberating, you may not.
However what I find incorrect is the claim that Ruby is a garbage language.
Then again, maybe that is best treated as hyperbole, as an exaggerated expression of your dislike for it.
I agree with this as well, although this is about Rails. I still have a legacy project to maintain in Rails (a big project) but that is (hopefully) the last I see of it up close in my life time.
I don't like the term "garbage language". People use to praise languages like Ruby or Python which don't even have private fields or type hinting the PHP has. Ruby libraries use approaches like monkey-patching classes in other modules. And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
Javascript actually has less problems than PHP. It also has proper lambdas, true lexical scope, and a shockingly good (if slightly confusing) OO system.
There's a reason that people claim (incorrectly, but still) that somewhere inside of Javascript there's a Scheme dialect, desparately trying to get out. This isn't true, but the proper lambdas and scoping are very scheme-esque.
I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class.
And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fields's name and learn about it only when undefined value will cause an error somewhere in another module.
That's because many dislike prototypical inheritance. It's perfectly usable.
As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
> Something a fair amount of projects require you to turn off. You know what else throws an E_NOTICE?
That is true only for low quality legacy code. I have always developed with all kinds of errors enabled and converted to exceptions (that means single E_NOTICE terminates the program with exception as it is done in Java).
Modern frameworks like Symfony 3 or Slim use the same approach. If you write a project using Symfony you won't miss a notice.
I think default PHP error handling system is wrong - there should be no warnings or notices, only exceptions. Sadly OOP was not very popular among PHP devs in the beginning.
I would imagine your doSomething JS function will fail and produce an error in the logging console because doSomething is probably not expecting to receive an undefined. Unless you've written it to handle that scenario and fail gracefully which is probably a good thing to do anyway.
Your whole example is silly. Stuff like this is why you write your PHP/JS/Python/Ruby code in a tool like WebStorm/PyCharm/RubyMine which does enough code analysis to realise you've made a typo and flag it.
In fact what's the difference between prototypical and conventional inheritances? I think python has exactly the inheritance model of JavaScript, and statically typed languages differ only in that they make the class=type, object=value distinction (so you can't dynamically change classes).
It's not. In python, classes are entities like any other object. In JS, classes literally don't exist. Yes, even in ES6. I know there's a class keyword, but it doesn't actually create a class. What the class keyword creates is a constructor function which then initializes new objects with a set of properties, and also sets a prototype, when called with the new keyword.
JS objects don't have a superclass, they have a prototype. A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype. But there's nothing special about these objects. If you wrote, say:
var Person = function(){};
Person.prototype = {name:"bill", addr:"foo"};
var charlie = new Person();
charlie.name = "charlie";
charlie.addr = "baz";
var NewPerson = function(){};
NewPerson.prototype = charlie;
var bill = new NewPerson();
This code is totally valid. bill's prototype chain looks like this:
bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype
> A prototype isn't a class: it's another object. When a method is called, or a variable is looked up on a JS object, JS scans up the prototype chain, all the way to Object.protype.
A type in Python is also just another object. When a method is called, or a variable is looked up on an object, Python scans the MRO (effectively the same thing as the prototype chain, except it supports multiple inheritance too) all the way up to `object`.
Python's type system is very similar, if not nearly a superset (though probably not exactly), of JavaScript's. I struggle to see the real material differences in them.
Consider your example, translated:
class Person:
name = 'bill'
addr = 'foo'
class Charlie(Person):
name = 'charlie'
addr = 'baz'
class NewPerson(Charlie):
pass
bill = NewPerson()
That looks the same, but conceptually (and actually, code-wise), that's not what JS is doing. Here's what's actually happening, in psudo-python:
class Person({name:"bill", addr:"foo"}):
#there's no syntax for object literals in Python
#such a thing doesn't even make sense: so I'm improvising.
pass
charlie = Person()
charlie.name = "charlie"
charlie.addr = "baz"
class NewPerson(charlie):
#note charlie is an object, not a class
pass
bill = NewPerson()
In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
Classless object literals actually don't make sense in the Python model. It seems like you're the one who needs to brush up.
In any case you're not actually providing any links or facts, so unless I dig through long articles on metaclasses in python, I can't verify anything you say. Please prove your point, or at least provide I link so I can verify.
> In JS, charlie isn't a class, charlie is an object: you can change all its properties and everything, just like any other object. It's not a class, because there aren't any.
Right; this is actually why I like Python's way a bit better: it makes a more formal distinction between the two. In Python, Charlie is also an object, and you can change all its properties and everything, just like most¹ other objects.
Most of what you try to use to distinguish JS from Python applies just as well to Python. No, it isn't exactly the same, and I think the semantically equivalent code in Python will often contain more information than the JS. E.g., in my conversion of your JS, the class is an instance of `type`, whereas — as you correctly note — it's "just" an object in JS. It's not really though; in most JS that devs will write, the object is a type, but that distinction isn't explicit in the code. It's implicit in the dev's intentions, expressed only in the general sense that the code is being used.
e.g., if I saw, in JS,
var Person = function(){};
Person.prototype = {name:"bill", addr:"foo"};
var charlie = new Person();
while it is true, technically, that `Person` is a function and `Person.prototype` is an object, the semantic meaning being expressed in this manner by the author of this setup is that `Person` is a type, and that charlie is an instance of that type. It's just explicit in Python. (To some degree, JS is aware of this fact too; `charlie instanceof Person` is `true`, after all.)
In a single-inheritance class in Python, during attribute lookup, Python will attempt to look the attribute up on the object's __dict__; if it doesn't exist, then it looks up the parent type (by looking at __class__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".²
In JS, during attribute lookup, JS will attempt to look the attribute up on the object's internal list of attribute (I don't believe this is exposed like __dict__ in Python); if it doesn't exist, then it looks up the parent type (by looking at __proto__) and then recurses, trying to look the attribute up there, and proceeding up the "chain".
What material difference exists here?
¹objects in Python can forbid attributes from being set, or limit the available attributes. I'm not sure to what extend JS lets you do that. e.g., `object` in Python is very restrictive about allowing additional objects.
²I'm explicitly ignoring multiple inheritance here, so I'm vastly simplifying. Python will actually use the MRO for this procedure, but in the case of simple inheritance, that's equivalent to following __class__. I'm also ignoring __slots__ for simplicity.
Yes, but it's (roughly speaking) an instance of a "Class" class. In the "Person" example, the prototype of a "Person" object is another "Person" object (until the chain reaches an "Object", at least).
This code doesn't look good to me. What is the benefit of inheriting objects from objects instead of inheriting classes?
When we have distinct functions, classes and objects we can easily understand how they are supposed to be used: you can call a function, create an instance of a class, call a method of an object. With Javascript you cannot easily see whether you have a plain function or a constructor and how you should use it. And interpreter won't tell you anything if you forget to put a `new` keyword.
(And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Your code can easily cause a bug. Imagine Person's constructor looks like this:
function Person() {
this.friends = [];
}
...
var NewPerson = function() {};
NewPerson.prototype = charlie;
Do you see the problem here? To fix the problem you have to rewrite the code using Object.create() and call parent constructor with Person.call(...).
I have written applications in Javascript and I think that Java-style classes are the best for readable and maintainable code. All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications. Your code example proves that because adding a single field to a Person's constructor requires you to find and modify all of the objects inherited from it and this task is not easy too.
It sounds like you're trying to write Javascript as if it were Java. I've worked with developers who did this (e.g. http://chriswarbo.net/blog/2014-03-12-trolled.html ) and I would advise that you instead try to write more idiomatic Javascript, or else use some kind of Java-to-Javascript compiler.
Your critique of Javascript is basically "it's not Java". I could make a similar critique of Java not being StandardML, but it would be about as meaningless:
When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used: you can open a structure, create an implementation of a signature, apply a functor to a structure.
> (And by the way why do you write 'var Person = function' instead of just 'function Person'? The latter is shorter and more readable)
Personally, I prefer "var Person = function Person(...) {...}" since it makes the code more symmetric (the second "Person" makes stack traces more informative). The "function Person(...) {...}" style makes an artificial dinstinction between functions and everything else.
> All these tricks with prototypes and dynamic objects (where you can add or patch properties in objects in runtime) might look good in short samples of code but they are only the source of bugs and cause waste of time to understand what the author meant in real world applications.
Javascript is a dynamic language; there is no ahead-of-time compilation. Things can only be done at runtime, including adding properties to objects. If you mean that mutating values should be avoided, then I would emphatically agree. That's certainly not a Javascript-specific issue though, and Java is just as riddled with mutability as anything else.
I haven't had enough experience with prototypical inheritance to comment on it vs class-based inheritance; I've been burned enough by class-based inheritance that I tend to avoid inheritance in all forms (and OO too, these days).
I am trying to write a code that is readable and maintainable instead of building complex abstractions. That is where Java classes fit perfectly (unless you are a beginner who had just read a book on patterns and tries to use every one).
I do not see any benefit in prototypes. It just makes code more complicated and buggy. I would happily use them if I knew a way to do it while keeping code simple.
> When we have distinct structures, signatures and functors we can easily understand how they are supposed to be used
Yet Javascript has neither of those.
> If you mean that mutating values should be avoided
> I am trying to write a code that is readable and maintainable instead of building complex abstractions.
My point is that what's "readable and maintainable" depends on the language; especially on what facilities it provides, and to some extent community consensus (what's 'idiomatic').
Javascript's main facilities are first-class functions with lexical scope, lightweight key/value mappings (which it calls "objects") and prototypical inheritance between those objects.
Java's main facilities are classes with properties and methods; whilst it's recently gained first-class functions, most Java code has been written without them, and they'll always be in competition with classes+methods (e.g. look at all of the APIs which use single-method classes, like "Comparator").
These are very different, so what's readable/maintainable will differ in each. For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
In idiomatic Java, such objects should be instances of a class, which should either be global or else implement a global interface. Since global class/interface declarations require standalone files, our declarations end up very far away from the use site; this prevents us accessing the use-site's scope and puts us under more pressure to make it descriptive, generic, reusable, etc.
> Yet Javascript has neither of those.
ES6 has a module system, Java has its "package" system. Trying to apply SML practices to either is a bad idea, just as trying to apply Java OO practices to JS is a bad idea, or trying to apply Lisp macro practices to C is a bad idea.
> For example, Javascript's objects are so lightweight that it's idiomatic to write them inline exactly where they're needed, like 'foo({bar: function() { ... }, ...})'.
Idiomatic doesn't mean maintainable and scalable. Imagine you are working on a project in a team, not alone. How do you understand what kind of "lightweight" object you should pass to this function:
function foo(data) { .. }
When you have thousands of such functions you'll spend most time reading through their code to understand what type of argument they need. This means "idiomatic" javascript code works only when it is small in size. Once it gets larger you'll have to resort to old school non-idiomatic Java-like classes and a static typing system.
Regarding prototypal inheritance I don't understand how it is supposed to be used. Let's say we have constructors for objects User(name) and SuperUser(name, privileges). I understand if `SuperUser` is inherited from `User` (class-based ineritance), but I don't understand what is the meaning of SuperUser being inherited from some user charlie. Why `charlie` and not `john`? Why do I need an instance of common `User` to create a `SuperUser`? And as I haven't seen the explanation in above comments I guess you don't understand it too yet evangelize about it.
I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all. As an argument I can say that a helper method `Object.create()` that is required for object inheritance was only added in ES5 [1] and haven't existed in earlier versions. This is how you create objects from objects without classes and even without constructors:
var person = { name: null, greet: function () { ... } };
var john = Object.create(person, { name: 'John' });
var charlie = Object.create(person, { name: 'Charlie' });
var superCharlie = Object.create(charlie, { isSuperUser: true });
I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
>How do you understand what kind of "lightweight" object you should pass to this function
...and this is where well-documented interfaces come in.
>but I don't understand what is the meaning of SuperUser being inherited from some user charlie.
That was merely an example to express the difference: the idea is, instead of writing a class and doing things that way, objects are cloned from one another. If you want to create a user with special powers, you clone the user object (usually running a constructor function along the way) and give it whatever new functions you want. If you want to create more of these special users, you make them all have that one as a prototype. Typically, the prototype object is never actually used or altered from the defaults, as this would be confusing, and is given a constructor function to instantiate state. But it doesn't have to be.
>I think JS was supposed not to have any inheritance at all. The objects were supposed to be created with constructors and that is all.
Wrong. Object.create may be new, but prototypical inhertance is an important par of how the constructors you claim to be the way objects were meant to be created work. Function.prototype, the property which determines the prototype of objects created by a constructor, dates back to ES1.
>I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.I also guess JS doesn't have classes because it was designed for writing simple form validation scripts and not large applications.
Also complete nonsense. Prototypical inheritance was originally implemented in Self, a system developed my Sun Microsystems, and a descendant of Smalltalk-80, which certainly was designed for large applications. JS may have been built for writing simple for validation scripts, and it may be a deeply flawed language in some respects, but the fundamentals of the language, prototypical inheritance, true first-class functions, and lexical scoping, are all things that Eich got right. And given first class functions and lexical scope are still things that language designers have trouble getting right (I've got nothing against class-based OO, so I'm not including it here), it's even more remarkable that Eich did it properly in 1997.
It doesn't help to find a misspelled property (and doesn't prevent you from dividing by zero too). You need a static typing system like TypeScript to detect such kind of bugs.
> And if we look at Javascript, it is even worse than Ruby. How do you call Javascript if PHP is "garbage"?
I think JS is better than PHP, at least when it comes to: 1.) consistency of std lib and 2.) type casting. There are many surprises with PHP's type casting. See /r/lolphp sorted from top all-time: https://www.reddit.com/r/lolphp/top/?sort=top&t=all
Why would that be surprising? NaN as a result definitely means that you cannot multiply array by object in JS either.
JavaScript uses IEEE 754 special values, not exceptions on arithmetic errors (eg 1/0 returns Infinity instead of throwing). If you bother to learn the language, it doesn't surprise you.
The problems start when you notice that your untyped key-value store has a bunch of NaNs where you were expecting a number. At this point, all you can do is pray that those numbers weren't very important, in the grand scheme of things.
So when you do calculations with important numbers, you just push the results to the store without checking them and hope for the best?
NaNs can happen in any language with floats, it's just that some languages also use exceptions in some situations.
I can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like the PHP-MessDetector (one of the rarest tool used by PHP programmers), PHP-CodeBeautifier (phpcbf) or PHP-CodeSniffer - Hopefully some open-source projects started using a StyleCI. Another things is database-related code. PHP developers tends to use ORM lately, but on five projects with Doctrine in 4 developers used it improperly messing with a 1000+-lined classes and storing annotation above the fields instead of file or even using Doctrine to get native database-connection via PDO driver to use query db with SQL only instead of DQL for any case. In google there is enormous list of articles about PHP optimization - the interesting thing is, that almost any touches the fact the PHP application should be "compiled" (cached) (e.g. for Laravel [1]).
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
To be fair, as a Python dev, I have inherited some real crap in Python as well. Though recently I had to import some data from a PHP website we have - boy that was another level of crapness (though the main problem was the database design, or lack of it).
- You sit in a dining table with 50 different utensils. White wine glass, red wine glass, water cup, salad fork, dinner fork, dinner knife, teaspoon, soup spoon, bread plate with knife...
- When the food is served, you take the food, drop it on the floor, eat it with your face (not even using your hands).
"get shit done"... use spoon as a knife and knife as a fork, or try to sniff your food through your nose instead of eating it.
This sounds like to me you are mistaking the popularity of PHP with the proficiency of the developers. PHP has been around a long time and is used by lots of people. Even if PHP projects only have a 1% success rate and haskell projects have a 20% success rate, guess which one will have more "successful projects".
But that assumes this is the goal. The real goal is to get a nice looking CV with all the "advanced" entries, not to actually have a useful product or -god save us from this evil- an actual business.
Right, but the point I was making is that it isn't necessarily true that PHP is any better at getting to MVP based on number of successful projects alone.
Accumulating bad code is like pushing your company from a plane without a parachute and hoping that the next guy creates enough cushion in time before the landing destroys the company (not the fall that kills you)--you survive because you are likely moved on and are busy pushing some other company to its doom.
It is probably ok if you work for a startup that does not survive long enough for the quality of your code to matter anyway. But in a regular company, your attitude creates a time bomb when eventually any apparently simple change may destroy the codebase (and at best, it just takes too long to make any change).
When someone (maybe me) comes and rips out my bad code later, they're going to have the benefit of future knowledge. I don't know how my code will be used in 2 years and what the requirements are, but they will, because they'll be there.
I do my part today by acknowledging all of my code is bad, therefore I don't invest a lot of time or ego in it. I try to make it in reasonably sized pieces so it's easier to rip out later (this may make it slightly less bad). If someone comes and tells me my code is terrible, I say yes it is, you might want to consider these things when you replace it.
EDIT: my opinions on this would change if I were shipping code to run on other people's machines: it's generally easy and quick to fix my code on machines I run, but updating code on other people may never update, you need to try harder to get it right the first time.
Amen. The ironic thing is most people believe that the fashionable language/framework du jour they're using in their project is "high quality code" that will be maintained like that forever, while turning their nose up at PHP code that is "disposable" but in reality more likely to outlast.
I can agree that php might not be the nicest or the fastest language, and I like to say choose the right tool for the job, but writing it off just because it's php is stupid.
A couple of months back there was this php sucks article about being looked down upon because you do php for a living. Php is the language people bitch about to feel better about themselves. Even within the php community symfony developers don't take drupal developers seriously. It's sad really and even I'm guilty of doing that. A little more respect for your fellow developers is all we need. It's like judging a book by it's cover. How would you feel if <insert your fav lang> was treated that way.
Php has a lot going for it. The community is very active and passionate, new things come out at a rate you can keep up with. You can easily get passionate about it if you engage in it.
A lot of interesting projects are (being) build with it and it is obvious that php won't disappear anytime soon.
If you have to work with php and bitch about it, make the effort and solve the problem you have with it. Contribute back to the community and experience the gratitude. You'll enjoy your work more.
So there are php people that care and they try to make the best of it. I don't think they consider it to be a garbage language. They are the ones that made php what it is today which is something totally different compared to what it was years ago.
But business success is largely orthogonal to language choice. I.e. when you buy a paid Github plan do you check what language they write the site in?
Of course a strongly typed languages should tend to have less bugs and that will save money. But saving money is only useful for those with revenue to being with.
There are a number of successful startups and very large companies using Haskell. It's understandable why it isn't a common choice, of course; the potential employee base is fairly small.
Not everything can or should be well engineered. People that always chase this are worshipping false gods. Does anyone have experience working on something that at one point actually met with the high ideals a certain mindset strives for?
I've worked on enough projects to have covered both sides of the equation. The pristine codebase that belonged on a museum yet took way too much time to ship a feature. The other side of the coin with the codebase that somehow worked (no one knew how) and brought in millions because people would keep piling stuff on top of it. Have also worked with a codebase that started off awfully and was cleaned up enough to reduce the amount of time lost on stupid bugs and and thus increased how effective the team was delivering new features (with a direct financial improvement as a result because sales picked up significantly). It all boils down to finding a balance. Sadly, people confuse technical perfection with a product that works.
PHP also has IDEs, tons of tools, tests, and gets deployed with many services and scripts. It's an inconsistent language, it's used by newbies in a very bad manner without even understanding the bare fundamentals of HTTP, but I really wouldn't call it a garbage language. If it were, it would have been dropped ages ago.
But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.
This seems to assume that a developer necessarily hits an MVP in PHP faster than in other languages. This might be true when comparing with the tooling/dependency nightmares of JS/NPM, but a half decent Python dev can get a Flask app up and running in about 15 minutes.
I read the post as saying that PHP self-selects the kind of developer that is great at making an MVP, thus why so many companies and projects are written in this garbage language. I don't think the post intends to implies that other languages are slow to develop, just that their developers are.
You can have the same mentality in many languages that suck less than PHP, though. Python, for example, tends to get out of your way and just let you write your algorithm. Go, as well. Or various JVM languages, particularly Java 8 and Kotlin.
The one thing you want to avoid are communities that argue about "the best" way to do things. Even then, you can use the fruits of their labors, as long as they're willing to package it up in something that gets out of your way and lets you get work done. You just need to take the language but not the community.
I do think certain languages are more conducive to the "just write it quick" mindset. I find it easier to enter this mindset when I write a bash script.
I find this interesting because I feel that is true and if it is true, then there must be some definable reason for it. So what is it? I have this with Perl, PHP, Bash, C(!), Lua and pure (browser) JS with Jquery (not npm, CSS and HTML though => those keep me from even starting something when I think too long about them).
I would think I like Lua & C to just write it quick because they are so limited; I remember their syntax, core functions and core libs, so I can, without internet or documentation, write things in it immediately.
I'm not sure why those others give me that feeling; probably because it's easy to just start instead of having to set up dev environments etc. Most is already on your computer and they are forgiving (a bit too much I agree) about sloppy coding.
It would be interesting to try to dive into details of why the brain finds some languages more conductive to 'just write it quick' and try to mix that with languages which do not have that feeling at all.
Opportunity cost - mental energy you spend thinking about which frameworks you're going to string together or how you're going to make the perfect abstractions or how you can make your life as a programmer easy is mental energy that doesn't go in to solving your problem.
There's a balance, too - if you spend zero mental energy thinking about how to make your life easier, you tend to get spaghetti-code monstrosities that PHP (and Visual Basic before it) are known for. The trick is to live with some discomfort and some suboptimal solutions so that you can finish the job you set out to do, and only worry about how to do it better when it becomes apparent that you're going to be doing it a lot.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
My first language was Pascal.
The concept of combining strings and integers in PHP without any conversion was scary and magical to me at first, but the damn thing worked, as long as you were careful. I still get mad at people who complain about type coercion because they expect their programming language of choice to read their minds and wipe their ass.
And Dijkstra was kidding. As is Rasmus when he says he'll restart Apache every 10 requests. Hyperbole. Learn languages instead of a language and it'll click. It has to.
I think this is great comment, and I can really relate to a lot of it.
I especially liked this:
> Learn languages instead of a language and it'll click.
I started at 5 or 6 with Basic, then progressed to Object Pascal early on, then C, C++, PHP, Java and finally Javascript and C# - I believe this wide experience has served me well over my almost 30 years' of programming (Christmas I'm getting old!).
I think there is a time and a place for 'just get shit done, fast', as well as spending time building 'elegant' code. But, if anything, the compromise between these 2 is possibly the thing I struggle with most.
Me too. My first language was PHP, I wonder what that's done to me. :) I still appreciate it, and kind of wish other languages had a "from webdevstuff import *" feature that would just bring everything I might need for the purpose of web dev into the namespace, rather than many lines of imports from sometimes obscure paths. I can't get on the hate wagon with the rest of the community. I'll avoid using it to start anything new, of course, but I'd take it over any other mainstream option. Give me Clojure or Lisp and I'll be happiest though.
Scores of developers that were raised on BASIC assert that knowledge of BASIC gives you brain damage. Presumably, they do not consider themselves to be brain-damaged. Similar things happen with, say, products of public schooling.
Which isn't to advance an, "I was spanked and I turned out fine..." kind of argument. Even if that's true, we can establish higher floors than "fine." It's the self-defeating hysterics around the presentation that make it come off the wrong way to me.
PHP got traction because it was easier for hosting companies to set up shared PHP hosting and it was easier for non developers to add basic code to HTML pages. PHP was also at the right moment at the right time,just like MySQL and some people made it easy to install it on Windows, a platform too often ignored by language maintainers (try to write Ruby on windows, a (slow) pain in the ass).
Uh, the early versions of PHP was written in Perl running under mod_perl, which was not CGI.
Also, e.g. fastcgi was around the same time frame.
(In order not to end up in a flame war regarding the first point I checked wikipedia -- see second paragraph of the intro here. :-) https://en.wikipedia.org/wiki/Mod_perl )
Products fail. Languages solve problems. Business domains have different problems. PHP won't solve a telecommunication challenge at scale. I believe in polyglot development. Choose the language and framework that suits the challenge. Not all shoes fit.
I think this overly dismissive/elitist approach is part of the reason why alternatives failed. Couple that with the ridiculous claim that a developers' time does not matter.
Up until the mid-2000s, if you wanted an easy up-and running web application environment without paying Microsoft, PHP plus MySQL was the only game in town. There were alternatives, but they invariably involved maintaining your own server and doing quite a bit of legwork yourself. The was no Heroku, no AWS, and tooling for python, ruby, and other environments required much more expertise to simply get an app responding on port 80.
Almost any big app you can point to that is built in PHP today was bootstrapped in this environment.
I did a lot of PHP from the late '90s up until 2008. Maybe things have changed in the intervening eight years, but I cant say I miss it.
I would never have agreed with you before, but I just came from a place where the fear of using something that was not sexy just paralyzed most of the developers at the company. They spent more time talking about new tech than implementing it. I've sworn off PHP, but at one point there I would almost have preferred they suggest we use it, if only to get something shipped.
Now I don't fret as much about unsexy tech. I do still advocate for new things when they make the team more productive, but I hope I never have to work at a place again where the latest and greatest stuff is used and people get nothing done.
> I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
My perception of the Clojure crowd is the exact opposite. They seem to be a bit too in love with the process and craft and not enough with the end results. That being said, I'd much rather code Clojure as a day job (I promise to be market focused!) than PHP. Right now I am almost all Python. There are definitely a lot of Python folks who are too much enamored with the craft, but the crowd is so big there's plenty of room for the GTD folks.
So people who don't care make successful projects and PHP is a garbage language that is responsible for more successful projects than any other server side scripting language. LOGIC.
My point is that the people don't care about the tech. They're worrying about the problem they're trying to solve. New companies that priotitize tech over finding and pleasing their customers don't live long enough to see the benefits. Just my observation. I've been through the "but if you don't build it right today you'll have to build it again tomorrow... that makes no sense" phase. I made some great code, but very few people are running it. My worst code is the code the most amount of people are running... it's because I got it done, and I got it rught before my budget ran out.
The primary objective of programming is to 'provide a solution to a given problem'. Everything else is secondary. If PHP is capable of providing that solution faster and cheaper than its competitors, it will always be the winner. PHP is a practical language and its success demonstrates that fact.
This is so true from my experience working for companies using PHP. You can advocate all you want to clean up code, but in the end, if it doesn't create a new feature its not going to happen.
I used to be this guy, ie, who cares but not too much. A big reason why I switched to node. Let's me think less about code (JS everywhere), and more about the problem at hand.
I like to call myself a "biztech" entrepreneur and these are the reasons I stick with PHP. Specifically using Yii2 I've been able to whip up MVP's and simply just focus on getting traction. In my experience that is all that matters for a startup.
Most of the cited successes were savvy early movers — every company mentioned aside from Slack itself is at least 10 years old. In the more mature, more varied tech space of today PHP seems like a non-starter.
Maybe it's just me but I do find a certain elegance in PHP. It's not beautiful by any stretch but it's extremely functional. You get the impression the Borg would use PHP. It's not pretty and it's not shiny but it works every time and it's extremely easy to work with.
I think this also could be that founders don't care about tech and Php developers are relatively cheap. Engineer experienced with different technology could easily get MVP of high standard in comparable amount of time but that costs money.
PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you.
If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.
Compared to Ruby, sure, but pretty much everything is at this point. Compared to Node JavaScript? Not even close.
They've made some impressive gains in PHP7 that others should take note of. Ruby's particularly out of shape here compared to the competition, though Python isn't exactly a speed demon either.
Yes it is comparable to Node. Most benchmarks show PHP with blocking calls against async Node calls. PHP has the tools to do async no problem. I use ReactPHP all the time to do this stuff; it works great for fast scraping.
See an older counter-point with the much slower PHP 5.5:
For anything with a server-side component, PHP might be fast if you know a lot about how to get PHP up and running properly.
Node, as a counter-example, runs on Windows and POSIX systems indifferently, and with very little effort can be a self-hosted web server for development that can be deployed to production almost effortlessly.
If you have a favorite hosting provider which better supports some tools than others, certain things will be faster, but that's because of preference and familiarity rather than any factual differences.
I think you're overestimating how much effort it is to get a PHP dev or deploy environment up and running. This isn't preference and familiarity, it's 20 years more knocking the corners off to lower the barrier to entry.
There's zero work involved in getting a static page up and running. There's minimal effort in getting Node up and running, and I'd put it forward as the new "path of least resistance" especially because of the heroic work done to make Node run properly on Windows.
Getting WAMP or whatever configured and installed, or loading the PHP module into Apache or Nginx and getting that working is a giant pain in the ass compared to either of those two things, even if you've done it a dozen times before.
> "The next guy to join the company will clean up your shit"
Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter.
Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately.
The world of difference between balancing trade-offs in technical debt, tradeoffs in long-term/short-term goals, and deliberatively sabotaging the company by leaving technical debt for other people to clean.
You are a liability to the company and its culture. And you want people like you and your language to be taken seriously? that's why nobody wants to work with people like you.
The next sentence tells you where I'm coming from, but to expand a bit... here's my theory of software development in the point of view of a new company. If you have an existing product, you're already in phase 3...and sometimes phase 3 rebuilds the product. This does not apply... you already know what the software is.
There are 3 phases:
Phase 1: Initial development - Your goal here is to find the value to your user. Any code you write here should be considered disposable. If it's not valuable to your customer, it's not worth building right... if it takes time before you know it's valuable to your customer, it's not worth your time. If you're writing it to support millions of users, and you only have 100, you're wasting your time. In phase 1 you're concerned about creating revenue, and nothing else matters. Wasting time on worrying about what is going to happen in Phase 2 might take time away from you before you reach it.
Phase 2: surge development - This happens after you've discovered some value for your user. Now the code you write is worth something. You should consider making phase 3's job easier. Proper design patterns etc. But your main concern is replacing the shitty parts from phase 1 with better code (if it's something you touch a lot) and getting it to scale for your now growing user base. You have to make strategic investments here. If you're spending your time making an ugly file that never gets touched better, you're wasting your time. If you're worried about making your code more efficient so you can support more users when another $100/month server would solve the problem, you're probably wasting your time. In phase 2 the company is still mostly worried about revenue, but you have a decent chance of making it into phase 3, so it makes sense to think about it.
Phase 3: maintenance. - In this phase, you're no longer searching for the value for the customer, but rather searching how to shore it up, how to be the best at providing it. Now tech debt is less okay. Crap quality software will lose money, so you should spend time making it bullet proof. Your revenue isn't growing like it used to, so you have to extract as much from it as you can.
That's what I said: there's a difference between calculated trade-offs between short term and long term and "I got no time for that, let the next guy clean it up, haha!!".
If you are rational you will understand that technical debt is a cost, and unless you are sabotaging the project you won't add cost without a good reason.
Prototyping and iteration is fine. Throwing away prototypes might be fine. But selling a functional prototype as a finished product IS NOT FINE. It's morally wrong. And unless you want to be lynched like the Theranos people you better not get caught doing this.
> But suddenly because you are an "engineer" this is acceptable?
No, it's acceptable precisely because you aren't an engineer.
We software engineers in the US are not bound by a formal code of ethics like more traditional engineering disciplines. We're not required to invest a certain amount of effort in the security or accessibility or maintainability implications of our work. And, most importantly, we are not legally responsible -- independent of our employers -- for defects in our product that arise from incompetence or otherwise failing to follow best practices.
So, you're wrong and your parent is right. He's not independently responsible for his work, and he has no formal ethical obligations prior to his employment contract.
And software engineers in the US, are actively losing their jobs to H-1Bs precisely due to this reason. Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.
Say that aloud in an interview or in a 1:1 with your manager and let's see how quickly they make you a job offer or get you promoted.
You don't, because you have you keep this to yourself because you know it is wrong and not in the best interest of your employer... Who is wrong now?
> Because people with this mindset are UNHIREABLE as well as an EXPENSIVE LIABILITY.
Yes, I agree with you, and I work at places where the label "engineer" reflects this sort of individual responsibility... BUT:
> because you know it is wrong and not in the best interest of your employer
Look, the way you even phrased that statement is exactly the problem. A US software engineer's primary legal duty is to his employer. There is no prior obligation (aside from not literally breaking the law).
And within the structure of the company, the engineer has no legal or professional obligation prior to manangement. So, if parent's boss tells him "get this shit out the door ASAP maintainability and quality be damned", and then parent does exactly that, I think he'd probably be OK from an employment perspective. In fact, insisting on some modicum of security or readability might even get him in trouble!
Contrast that with the situation of a PE, who would be much more likely to answer "no" on the basis of professional ethical obligations which are prior to his obligations to his employer/immediate manager. And, when answering no, would be much more likely to have the leverage and respect necessary to survive an encounter with middle management.
Do your job in the interest of your employer, to the best of your ability, without ripping off your customer.
That's the meaning of professionalism. That's the meaning of living in a society. If you need to say no, then do it. Your job is not to say yes to everything.
What if everyone ripped off everyone all the time? It would be a world of shit.
Ripping off the customer is not in the best interest of the employer, and is being hostile towards society. Think about contributing to society not taking what you can.
Adding customer value is different to adding apparent value with no real substance.
Your responses seem to boil down to "but I believe everyone has a moral responsibility to act like an engineer."
When is perfectly fine, and I agree with you. As I've said multiple times.
But realize that, in the US, programmers have no such legal obligation. They also have no formally codified and enforced professional ethical obligation.
Any such obligation is purely within the realm of personal ethics. Particularly obligations to the customer which go beyond or contradict with obligations to management (the latter are at least captured in the form of a contract).
So your moral stance, while admirable, isn't representative of actual enforced social norms among programmers.
Finance has a bad rep, but there are actually lots of rules and regs surrounding ethics in finance and a practitioner can easily end up with massive fines or in jail for failing to follow those rules. Even if his boss told him to do it.
Those rules may not be the right ones and they may not be enforced well enough, but there's at least some nominal level of assumed professional responsibility.
The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier.
Why are there no other "competitors" in this space? Why do most other languages go with the alternative route of using an event loop or daemonizing your "server" to serve up requests? I can understand why Node.js does it (otherwise the async nature would just be an annoyance for no gain), but why haven't there been any other server-side languages that not only work well like this, but actively target it?
It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
>>Why are there no other "competitors" in this space?
There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples.
Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexity down, but at scale, the applications I've worked with have to use a shared cache (like acpu) to avoid that rework and meet performance goals.
I mean more of languages that actually "target" this kind of setup.
I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime.
Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing that work for each request?
It just seems like there are better ways of solving this problem, because an event loop is such a "hammer" solution to the problem.
I think python has exactly that with WSGI. With this protocol you make a module containg an "application" function object which is called by the server when a request arrives. On module load time you can do any required setup work.
(On my systems, by default there is some reuse of the loaded module, so you can leak state between requests. However it should be possible to avoid reused processes).
Yeah, I run new django apps right alongside my php5 code. It does definitely take a bit more "muss and fuss" than php5 to configure (mod_wsgi, etc) but is just as easy.
You also need to restart apache or change the wsgi loader file, (or set up explicit hoooks to do so) to get your new code to appear when debugging / after uploading changes. This is where I'd say php is superior (upload file, refresh browser).
Back in the day, mod_python also supported PSP (Python Server Pages), which was similar to PHP/ASP in that it allowed you to write a file as a mix of HTML and Python code inside delimiting tags.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialized before a request starts. Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. You can cache that stuff, but it's still overhead that isn't central to handling a request.
There's actually work being done to build PHP frameworks that get around this with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as well, by at least keeping your compiled bytecodes in memory (similar to APC/eAccelarator/ZendOptimizer, etc).
Is machine computation mostly responsible for your revenue? If so, would it make more sense to measure web server responses in terms of cpu cycles and such instead of time?
>Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc.
All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler.
>Code paths, auto-loaders, database connections, config files, etc.
Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done.
I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.
> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request.
Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.
IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"
> IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires.
Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there.
Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there. I bet you spend more time on social media during office hours than you'd ever save from not having to type out those import statements.
Except you still need autoloading configured for most libraries in the ecosystem to work, unless you want to manually chain absolutely huge quantities of requires.
> I don't want or need to have to write out all of those requires. That's the job of the autoloader.
Or the IDE. IntelliJ or ReSharper does that for me. And I like dealing with any naming conflicts right then and there, which those tools allow me to do.
> IMHO, developer time is more expensive than CPU time
I see that you've never worked on a project where the CPU time needed to handle the traffic with crappy code is much more expensive than developer time to write efficient software.
I have. And one of my first steps after starting to clean things up is to switch to composer and autoload; because then I can start ripping things out much more easily, and still make improvements to both code quality and performance.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request.
Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means.
There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.
The real question is why does PHP depend on globals or thread locals for request state at all? PHP's "new process per request" is a solution to a problem that PHP created for itself. In other languages, the request handler receives the request state as an argument, so when the request completes there is no state to reset.
> It seems like it would be easier for everyone involved. You wouldn't need much of a GC when the process is killed every time, you don't need to worry about async IO or multi-threading or catching errors or any of the other annoyances that come with most of the traditional "event loop" way of doing things.
Firing up a new process (or even a new thread) for each request is very expensive--much more so than a generational GC. Async IO also mitigates this (why have 10K parked threads consuming memory all your memory if all of them are stalled, waiting for database)? Services that spawn a thread for each request run into the C10K problem--they can only serve 10K simultaneous clients. Regardless of your concurrency model, you can't ignore errors--you still need to dispatch the right status codes and error information (not to mention logging, etc).
You should check out Go. You write concurrent code and the runtime effectively manages a thread pool under the covers so you get all of the performance benefits of async programming with the developer-friendliness of synchronous programming. In the case of a web app, you just need to write your request handlers--the web server manages the request concurrency for you, and the language's runtime manages the parallelism.
>>PHP's "new process per request" is a solution to a problem that PHP created for itself
True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out. PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process. Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
> True, but I'm not aware of any notable language that did it differently in the mid 1990's when PHP was rolled out.
The OP's question wasn't scoped to the mid-90s.
> PHP does not spawn a new OS process per request these days. It does spawn a new interpreter, but not a new OS process.
Like I said, the same holds true even for an OS thread. Anyway, if it's not a new OS process, then some sort of GC is needed, contrary to the OP's statement.
> Combined with the now bundled opcache, the re-work per request is limited to the developer's own initialization code if they don't choose to use a user-space shared cache.
Again, these are all solutions to problems PHP invented for itself. Other languages don't require special caching mechanisms; they get by on normal scoping rules and shared memory.
I don't think so. You either keep state between requests and therefore get problems like memory leaks (which often happen in large Ruby or NodeJS apps written by not very experienced developers) or you keep no state and have to do initialization on every request.
This is only true if your framework depends on global variables to manage request state. If your framework passes request state in as an argument to the request handler, then there is no state to reset. Don't use global variables and you don't have any of these problems.
How do you know whether other components (objects, modules) do not keep state between requests? Unless you 1) use language with pure stateless functions like Haskell or 2) delete everything after each request you cannot guarantee that. PHP uses latter approach.
With PHP you can see your program as a pure function whose result depends only on arguments. You don't have to care about memory leaks like you don't have to do memory management when you have a GC. And if you want more performance and less convenience you can always opt into running your own web server.
> Don't use global variables
If you have an object that is persisted between requests you already have some state that is saved.
Programming 101: scope your objects appropriately. If you have an object whose state is bound to the scope of the request handler, initialize it in that context ("don't use global vars" is just a special case of this rule). In other words, everything initialized outside your request handler's scope should have its state reused across requests. The PHP community never entirely learned this, so you guys are building workarounds. This isn't intended to be PHP bashing; just objective criticism.
I do not see how scopes are related to a problem of memory leak. Let's say you have a Django middleware that is initialized outside the scope of a request. Let's say you decided to add some stats counter in that middleware and wrote a code like this:
This code follows your scoping rules but still leaks memory. So it looks like you don't understand why memory leaks occur. I explained somewhere in ancestor comment that to prevent leaks you either need a language with pure functions or reset environment on each request, none of which is possible in Python yet the latter is available for PHP users.
With Django processing model any array can become the source of a memory leak. I have heard that Ruby and NodeJS developers often have to restart their applications every several hours because they even have no tools to find the source of a leak. The problem that does not exist in PHP by design.
You're conflating application state with request state. Updating application state based on a request is a perfectly reasonable thing to do, but it necessarily invites the possibility of a memory (or database, file, etc) leak. Either PHP can't update application state at all or it can and necessarily suffers from the same potential to leak memory (I suspect the latter, since an application without side-effects would be worthless).
To clarify, I didn't say that no GC would be needed, just that it can be much less robust, use quicker algorithms, and in many cases is simpler to actually implement.
This isn't true. A shared memory server doesn't require special, complex garbage collection algorithms--any generational GC will due, because request state lives in the youngest generation where collection is virtually free.
There are plenty of competitors in this space, they just don't use the CGI model of spawning a new _OS_ process for every request. You have Erlang/Elixir that have their own lightweight processes that don't share memory and have independent GC. And you can build similar systems on Java/Go. The difference is that in those language you have a choice. There are certain types of applications that you just can't reasonably make in PHP.
What do you mean exactly? I mean yeah, it's a bit different with FastCGI when you have a pool of persistent processes. But you still basically boot up your whole application every time a request comes in. Opcode caching helps with loading code, but not execution. And you're still working with OS processes for concurrency, which is not ideal.
In fact you can create a "daemonized" webserver in PHP and handle each request in a special handler function. For async case there is ReactPHP (http://reactphp.org/), don't know any product for sync case, but creating one is certainly possible.
And you can also set up Ruby, Python, Rust, Haskell, Java, etc to create a new interpreter/vm/whatever for every request. All of those languages have libraries to support CGI. Using the same OS process but restarting the interpreter/vm will be a bit more complex, but absolutely possible. You can even implement the "every file is an entry point" approach for at least Python and Ruby.
The difference is what is the intended use for each platform. E.g. creating a new OS process, loading the PHP interpreter, bootstrapping Wordpress, getting some data from the DB and rendering a page is possible under 600ms while creating a new OS process, loading the CPython, bootstrapping Django, getting some data from the DB and rendering a page will easily take you 4 seconds. This is because Django developers didn't expect you'll be doing that, so they put a lot of stuff in the initialization step (system checks, creating db connections, setting up logging, ...).
I worked on a large-scale (30m+ users, tons of concurrent sessions and high request rates) site + online service + native client setup in PHP for years.
This was never actually an asset. Startup times were huge, lack of shared state meant extra requests to database servers (and to memcache instances to avoid database round trips) to get the same data per-request. Each request got longer and a given page or api call might issue many duplicate requests in a short period of time.
Plus since PHP doesn't have viable threading or async (definitely didn't at the time) each memcache or sql request had to be synchronous, resulting in even more wasted time. At the very least memcache had good support for batch operations so we could manually batch our queries.
Overall though this is not an asset. It's only the 'best' part of PHP if you don't want to think about writing good software that manages shared state.
To be fair, many applications don't actually benefit from being good code, so PHP is probably a good fit for those.
This is my least favorite part. As soon as your program gets more complicated the amount of repeated parsing, compilation and setup you need to do for every request causes massive speed and structural issues.
I can't tell you how much more "runtime state" exists in PHP than in say Java. In both cases you need to initialize some sort of security-aware context. Once you've eliminated parsing, disk i/o and compilation phases. You should be on pretty even ground of bytecode vs bytecode. Java has a Hotspot JIT, so it will probably win there. I think a JIT is coming to PHP as well since the architectural rework that went into PHP7.
There's more too it than that though, yeah? Say you use a service that uses oauth2 authentication. You need to do a request to pull in a oauth token. If you lose all state between requests, you waste time re-fetching tokens.
In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality
I'm not referring to per-user sorts of things. You can't cache those locally in a sane way in any language. I'm talking about what would usually be memoizable sorts of things.
There are memoization libraries for PHP but really it's just another cache implementation. Put it in RAM, put it on disk, put it in memcached or redis, I don't really see too much a difference between $cache->set($key, $value) in PHP vs cache[key] = value in node for instance.
if you need to persist some data/state between requests, php has a mature memcached extension. it's a fast memory store, but i'm not certain of the security implications since i dont think it has any kind of built-in isolation.
Sure, but that means I have to either run a memcached instance on every server (which I've actually had to do before just for the sake of PHP) or I have to make network calls for something I shouldn't have to, and then also do serialization/deserialization. That's fine for plenty of things, but certainly isn't optimal for all sorts of stuff.
Not to mention, all the other languages out there memcached just as well.
But in most languages http requests should be stateless. Even in node or Java you should be hitting the db to pull that info anyway, as sharing the last info in the process leads to scaling issues as well as big problems if the application crashes.
The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"
You can add a ReactPHP based HTTP server to your app to avoid reinitializing, but you'll have to deal with memory leaks between requests and process management yourself.
The catch is overhead. There are things you need at the start of each request - global configuration, database connections etc - that other systems do once at startup. PHP has to do this every request.
> "reasoning about" (boy do I hate that phrase...)
A bit tangential, but I find myself disliking it too, for no good reason that I can think of.
Perhaps it's something of a crutch in that it's really "I like it more, but 'reason' sounds better" ? Not sure that's quite it, either, as in the above case with a "new everything per request", it's certainly true that it's easier to think about what's happening.
I like the old hacker term for "reasoning about". Grok. It's much easier to grok a program when everything just runs from top to bottom and doesn't jump to a different third party library every 3 lines or have 15 layers of indirection and frameworks.
Interesting! I have somehow developed the opposite opinion. The phrase "to reason" is plain English and uncomplicated. Grok, by comparison, is arcane and to the uninitiated is semantically opaque. The latter strikes me as a more suitable vehicle for demonstrating pretension.
Fair enough. I never claimed my dislike of "reasoning about" things was rational! 'Grok' definitely has a context, that likely does not include talking to non-hacker types like clients, board members, or whatever.
I understand your situation :) I keep a long list of seemingly innocuous words which, through no fault of their own, are repugnant to my ears. It's utterly irrational.
It's a pretty nuanced phrase and difficult to replace. I might make the case that "easy to reason about" <=> "simple" in the sense that Rich Hickey uses it[1] but that doesn't do anything for the verb itself.
The phrase has a high correlation with subjects that are themselves highly correlated with smug proponents; functional programming is one of the greater ones of these.
Personally I like the phrase. Then again I self-identify as a (non-smug) SmugLispWeenie[2] so of course I like it.
Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.
You can get the same reasoning benefits in pretty much any language by just not using any global variables. Yes, you're still running a framework/server with internal state, but with PHP you've got the same "issue" with Apache/Nginx.
> Because it's very wasteful to keep reinterpreting the same page every time, as opposed to just running it in RAM from a warm JIT.
You are running it from RAM. PHP's OPcache, and HHVM, will both compile the code only once (well, HHVM will compile it multiple times due to JIT, but it only touches the disk once) and cache it.
The startup time can be pretty extreme -- although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.
And even if you cache everything, you still have the code necessary to setup the runtime environment of you application which runs on every request and does the same thing.
But still, I do actually like that model and it does have many advantages for development. But it's really hard to work in PHP, the language, after using something better.
> although you can mitigate much of this with various caching strategies but the typical PHP request involves reading dozens to maybe hundreds of files from disk, compiling them into byte code, and then executing that byte code, and then deallocating everything.
For the conversion to bytecode, that is what apc is for.
I may be waaay off base here, but wouldn't amazon's lambda function architecture sort of mirror the benefits of shared-nothing? It doesn't necessarily work like that under the hood, at least if I remember correctly your lambda function may live on past one request, but you must code as if that were the case
It does, but it comes with deep tie-in to AWS as well.
But also, you don't typically use lambda to serve pages or a full application, more commonly it's used for specific processing tasks, individual endpoints, and generally code that can run standalone.
Starting new, regardless of caching data/bytecode, still means you have to spend time bootstrapping the application.
Other languages, whether directly or indirectly manage cleanup via GC or recycle processes, like UWSGI for Python.
I also don't find any particular benefits over other languages with "reasoning about". As a PHP application grows and a team restructures it into something more mature it ends up looking the same minus the event loop (which just lives somewhere else).
> You wouldn't need much of a GC when the process is killed every time
Yes, you do. You'd be surprised how easily memory balloons out of control unless you regularly run a GC. Log minor collections sometime in Java or JS engines if you don't believe me…
Even worse, if you don't run GC regularly, you will suffer terrible locality as execution continually grows the heap (not to mention the overhead of continually requesting free pages from the OS).
The idea here is that the webserver forks & execs a new process for every request, allocates a bunch of pages, and then runs to completion, at which point the process finishes and the memory is returned to the OS. It's essentially using the OS as an arena, where you can allocate memory at will just by bumping a pointer and then the whole thing is freed at once at the end of the request.
It's not an insane idea - CGI worked exactly like this, as do most command-line shells. And the overhead is often less than most people expect, since most pages are COWed on fork() and the files it touches will likely be in the filesystem cache. Still, I think people found that the overhead from process creation (and in particular, keeping all those processes around & task-switching them while they make DB/network/filesystem calls) was greater than that from GC, and so most frameworks - PHP included, these days! - use a more lightweight mechanism.
Yes, I know what the idea is. I highly suspect it won't be practical due to the reasons given in my other reply. We tried this with JavaScript in a very similar ___domain and the memory usage was unacceptable.
It may seem that way at first, but space leaks during individual requests are way too easy otherwise. Think about something as simple as, say, parsing Mustache templates. The parser is probably internally making lots of little substrings to record the names of directives as it comes to them. You would think that this is O(1) in space, since you only need one (or a small number) of strings at a time, but without a GC the space requirements balloon to O(size of input). Being able to dump the memory at the end of a request doesn't help you if you keep blowing out your cache during each one.
I speak from experience: there have been many attempts to mandatorily delay collection until the end of the event loop in browsers, to achieve greater responsiveness. It has always failed. You can add heuristics to try to preferentially collect at the end of the event loop, but you really need to be able to GC anytime.
I'm not completely disagreeing... I've worked on pipeline transformers in node where I exposed gc and ran it after each item in the pipeline was done. It would grow insane without it... likewise I can see that if you're transforming a lot of records for delivery in PHP it could bloat as well.
However, if you're handling requests well within a given memory threshold, it isn't always something you should worry about until it becomes a problem. In which case, you'll probably want to look at something like go, rust, erlang or others to handle improvements, or break off heavy parts into sub/micro-services.
Probably because allocating a thread to every request is less efficient then a bunch of event loops with async. Ideally you do both, but a lot of languages choose to make concurrency something done at the process level and are event driven asynchronous web servers which are deployed as multiple processes, which adds a lot of overhead compared to threads. I think Golang has a nice balance with goroutines, as I understand things.
http://elixirforum.com is a good place to check out. There are a few excellent books out there to help you get started with OTP, which makes Elixir beastly, and Phoenix (a web framework) as well. The forums are an excellent place to find deals on books, too.
It's interesting that so little know what is Cgi here. It's the Common Gateway Interface and it uses environment variables to communicate to the Cgi scripts and thus the Cgi script can be in whatever language you wish. You don't even need a lib, reading env is enough. Its possible to write your Cgi scripts in assembly.
So this process-per-request thing is not exclusively a Php thing.
I know of CGI scripts (and the newer faster alternatives), I was wondering why more languages don't specifically target that kind of setup, playing to its benefits and trying to minimize the downsides.
Oh, sorry. I guess it's two-fold then: a) it's not as popular and cool, and then b) not much needs to be done to target it anyways, as most often being a good unix citizen suffices, you get the input and write the output to stdout, what's in between is application realm and whatever you do is up to you.
I completely understand the "trendy" part. Sadly even language/frameworks need marketing, and doing things in a "wasteful" and "slower" way but simpler is gonna be a tough sell even if it might be the best move.
I just feel that there is a space for a "better PHP". One that uses a better base language, but still keeps the benefits from the language like the simplicity of the "think edit reload" cycle, the shared nothing architecture that makes programs easier to write and simpler to test, and the horizontal scaling.
I've not worked on many CGI stuff (other than little things I use myself) but Python has all the housekeeping done. See this other post of mine that has an example of an interactive hello-world: https://news.ycombinator.com/item?id=12712067 . And then, Perl is used for all sorts of CGI stuff. Both have good database support. CGit [1] is a git web interface written in C.
About 2-3 orders of magnitude in performance. That’s the catch.
And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc.
And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framework.
Unless you're writing in pure hand-optimized assembly language, 3 orders of magnitude in performance is way more than you could claim. PHP web requests commonly execute in hundreds of ms (of course, here I generalize mercilessly, but that covers most of cases I know of and that's what most sites aim for). So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have very hard time believing it.
> And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons
You make it sound as if the idea of caching was invented by PHP programmers to address language deficiencies. Nothing can be further from the truth. Everybody uses caches, because it's faster. If you don't use DB cache, there's no way in the universe you can make you app fast under any significant load.
> And hacking those things on top of PHP make your program even worse to reason about
You have very strange view of performance design if you think using caches is "hacking something on top" and has to be avoided.
> than just using a daemonized system with actor framework.
This looks like a complete non-sequitur - you could use actor framework and still use all the things described above, and do it in PHP, and thousands of people do exactly that. On not in PHP, if you'd like - this pattern is completely orthogonal to the language used.
> So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds?
I had a side project written in Elixir/Phoenix make it onto the front page of HN and it indeed was the case that the majority of requests were in hundreds of microseconds. The default log messages actually use "µs" which is kind of cute.
I wrote about it here[0] and extracted a random sample of my logs and you'll see that most of them were in the hundreds of microseconds.
The system now used to serve GoDaddy's Website Builder content is written in node, deployed to clusters behind load balancers, and from there connecting to Cassandra clusters for the data... iirc, the average turn around time for a given request (including dynamic ones) is less than 12ms from the node server receiving the request to delivering the response, under a load of many millions of requests per second to the system.
Disclosure, I worked at GD in Website Builder when this was being developed, but haven't been there for over 2 years now.
> So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have very hard time believing it.
Yes, they do. Phoenix/Elixir is a nice way to get below the millisecond, and even with Java you can for most requests go below a few milliseconds.
And you can obviously handle far more requests at once, as you have all the code already loaded in RAM, and just need to jump into it, instead of reparsing it, or copying it back from a cache.
I think his main issue is that the cache has to operate outside of the application process, adding overhead. Languages with shared state can have much simpler and more efficient caching, no io, no de/serialisation.
That 2-3 orders of magnitude difference is in an area that runs pretty quickly however.
People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
And yet it turns out that those 2-3 orders of magnitude don't really matter for the vast majority of products you could develop. Your DB queries no matter the language are several orders of magnitude slower than the interpreting time.
If you need to process thousands of requests per second per thread then don't use PHP, but that's a rare situation. I wouldn't build RTC in PHP. But web or enterprise applications, which are by far more common, don't really suffer that issue.
And pretty much everyone caches database results...
Compared to the other offerings, it's on par or faster (Python and Ruby really have a lot to be desired). You're talking about an actor framework, which is more performant at a cost of using that model and the myriad of issues with managing a more complicated system. The market favors simplicity and less sophisticated developers, in most projects.
Compare Symfony2 with Spring, for example (~500 vs. ~22'000 responses per second).
Or if you want to only use the raw language itself, php-raw with ulib-postgres (~90'000 vs. ~300'000 responses per second)
And with PHP, the larger the codebase, the slower it always responds, because even with opcaches loading it into RAM is a major bottleneck.
That’s exactly the issue at hand here.
And compare actual performance, for example JSON serialization, that’s not even fair anymore, symfony2 reaches around ~2'000 a second, gemini, the fastest fullstack framework, reaches ~970'000 a second.
Raw PHP reaches still ~170'000, but the fastest non-PHP raw language is still at ~2'200'000 compared to that.
These are actual performance issues that will cost you actual money. Even saving 20% of hardware and server costs can be the difference between your company being cost-effective and dead.
> PHP is perhaps one of the easiest technologies to scale horizontally, because of its statelessness.
PHP is no more stateless than any other language out there. Statelessness is a design choice, not something PHP gives you for free. If your app write things on the local disk or use the default PHP session handler then it is not scalable by default. In order to write code that scales you need to make it scalable, it's not something automatic and certainly not special to PHP.
I would argue that PHP is more stateless than Node, for instance. Things that happen in previous requests do not affect following requests in PHP, unless you're explicitly using shared state. That's not the case in node, it isn't the case with most Java HTTP server implementations, and it wasn't the case in Rails back in the day (don't know how it is now).
Any language is stateless until you explicitly share state; the other languages just make it easier to share state. It’s not a bad design decision – makes them more versatile, or at least more cleanly usable outside of serving webpages – but is something to avoid in similar applications for sure.
> Why are there no other "competitors" in this space?
You can do the exact same thing with any language that supports CGI. You can compile a Go binary, put it on an Apache server and you'll get the "shared nothing lifecycle" just like PHP.
Exactly. The "shared nothing lifecycle" really lets the programmer (knowingly or unknowingly) embrace RESTful design. Too bad the language doesn't have strict typing like Java. Otherwise it'd be even more convenient and safer in my eyes.
I worked in PHP at Box for about 3 years. This article does a great job of reflecting my sentiments on the language. In particular, I'm glad to see that the author recognizes that there are some glaring issues with PHP that aren't tradeoffs in favor of something else - they're just warts.
That said, PHP is really good at what it does - providing a framework and environment for serving web requests efficiently and easily. I find developing in it very fluid once you know how to avoid the warts. A lot of the flak that PHP receives as a language revolves around the fact that it doesn't actively discourage developers from doing bad things, and sometimes the language itself does some crazy stuff (as shown in the article with the divide-by-zero behavior). I think this is a huge shortcoming of the language, especially as code bases and teams grow and your organization needs to depend on the language more and more for safety. That said, I still don't hate working with it. Sometimes I rather enjoy how quickly I can develop in PHP, and how reliable it can be if you know how to operate it.
I think in all, it was a bit of a slog to get to the point where I am with PHP today - to the point where I understand its strengths and flaws, but ultimately I think it does have a place in modern webapp development. I think Hack and HHVM are excellent spiritual successors to what PHP tried to (is trying to?) accomplish, and that they do a great job of hiding or eliminating some of the warts of their parent language.
Kudos to the Slack team for being pragmatic about their approach to the technology, and hey again to all of my former colleagues working there!
I've had to do some PHP work recently, on a fairly old school PHP codebase for a high traffic website, after spending most oy my career working in Java and C# (and I still do most of my work in those languages).
I've read a lot of PHP hate over the years, but I've found working with it in practice to be decidedly...not bad. Perhaps the codebase I inherited is better than most. But I've had to make some fairly major updates, and they've proven to be far less painful than I had expected based on the amount of PHP attacks I'd read online.
Maybe the snobbery toward PHP is a good thing? There are some really big PHP-based communities out there, Wordpress being probably the largest. And in these communities, there appears to be a large demand for paid consulting and plugins. Sure, there's a ton of competition on the low end, but it's an area where a really great developer could stand out from the crowd and do very well financially, especially for more complex consulting and dev work since so many good developers turn their noses up at PHP.
The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Python, Ruby and even Node.
The Wordpress codebase [plugin api included], though, is utter garbage.
> The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C.
It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3])
You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it. The most the PHP devs have done is deprecate methods and add features. That's great. I think that changing something, that has been there since the beginning, to a new behavior is stupid. Much much much worse then having ternary work backwards.
> The Wordpress codebase [plugin api included], though, is utter garbage.
> It was consistent with the thing it inherited most of it's syntax from so that makes it inconsistent?
It is also internally inconsistent in so many ways.
Half the array functions take arrays as the first arg, the other half the last.
explode and implode have different argument order requirements (one is strict, the other works either way).
Functions have a grab-bag of errors from returning null to false to 0 to strings to requiring error\_get\_last to even requiring an object specific error function (DateTime::getLastErrors).
Functions were named to make them have more randomly distributed hashes (http://news.php.net/php.internals/70691). Functions randomly do or don't have underscores, sane order, etc.
Some apis are in terms of objects (DateTime), some are not (getdate).
The whole thing is far less consistent than C. Some inconsistencies are from C. Most are PHP shit layered on top.
> You shouldn't be judging the way operators work in one language with the way they work in others. Is lisp inherently bad since it's operators are prefix and not infix? No I'd say not, it's just different.
It's a C-like language. Every c-like language does it the other way. I will totally judge a language that makes a decision that makes programmer's lives terrible with no justification. In this case, it's different in a way that often leaves to bugs and surprises.
It doesn't matter, we're talking about php not C++. But yeah, "<<" and ">>" are at fairly internally consistent within C++ and don't generally confuse programmers or cause significant bugs in my experience, so I don't find them problematic. They did seem a bit weird at first, but they didn't cause significant problems.
Perhaps they do for you, and I accept your complaint about those operators as valid actually, but it's on a whole different level of badness than php, and again, we're talking about php. Just because "other languages suck" doesn't mean php doesn't, so that's not a valid argument against anything I said.
I'm saying neither of them suck. They both have small things "Wrong" with them that are only "Wrong" because I don't like them.
>they didn't cause significant problems
That's not a valid criticism of any feature. I'd say that the worst feature of any programming language yet has been pre and post -- and ++. Some of the nastiest bugs I've seen have come from there.
In both cases I avoid them. I only really use -- and ++ if I need to, just like ternary operators.
> Just because "other languages suck" doesn't mean php doesn't,
Ok what about other languages that are good? Python's ternary operator isn't the same as C-style languages but I still think of Python as being good.
That's not the same thing and you know it. C++ didn't just randomly change the associativity of one of the operators. PHP screwed up ternery in a way that makes zero sense (ie, it's wrong in 99.99999% of use cases). It still catches me (and my colleagues) off guard even though we have years of collective PHP experience.
> On the other hand, the PHP devs changing the ternary would cause major problems for anything that uses it.
If you read the thread, no one could actually recall having ever seen code that relies on the current behavior. It has been discouraged in the docs for years. The stop-gap proposal was to have PHP7 deprecate it with a warning rather than silently changing the behavior. Then change the behavior in a future version (say php 8).
Disregarding any of that, this is an admitted language bug. It was not ever meant to work this way. Do you have a list of languages where ternary works backwards? PHP devs don't just work in PHP. Having one C-style language work this way and another C-style language (js) in another editor tab work the opposite way is a major PITA.
> The devs are ultra-conservative and stubborn to cause BC even at major version bumps
Well, breaking backwards-compatibility comes at a cost. Avoiding another PHP 4/5 or Python 2/3 situation is the goal. It doesn't mean nothing gets changed: PHP 7 has a long list of backwards-compatibility breaks.
> The Wordpress codebase [plugin api included], though, is utter garbage.
I've always heard this and never actually used Wordpress myself. Has anyone ever studied WHY its garbage? and how did it get to that state? is it getting better or are the latest additions and changes still garbage code?
WordPress is popular, php is accessible (you need notepad and an ftp client to start hacking) - combine the two, and you get a lot of "scratches my itch"-code.
It probably doesn't help that WordPress is an ancient code Base with a goal of running on the cheapest webhosts (who are slow to update to newer php releases).
So you get a lot of beginners that learn from messy old code, that generate more of the same.
It's a mess of global and file-wide variables, an unholy mix of poorly structured procedural code married with the odd "OO" abstraction.
There are good, even great php code bases - WordPress - and its plugins are not that.
To be fair, WordPress itself, and the core plugins are at least somewhat consistent, and after years of security holes follow a somewhat reasonable defensive coding practice. The terror lurks in popular third-party plugins, inspired/forked from older hacks. As is evidenced by a quick look at full-disclosure where seemingly every week someone's managed to make a plugin that's broken in some novel manner.
I've not been following closely lately, but for a plain php cms, one could do worse that cmsmadesimple. It's (was) pretty old-school simple php, but much simpler than something like Drupal.
The part that I didn't really understand is people accepting pull requests should be gate keepers for code quality, so amateur or not hopefully this shouldn't pollute the codebase. But you've touched on the core being reasonably decent and the real mess being with third party plugins so that makes more sense.
As long as you don't mind working on "boring" projects, there is TONS of small businesses in need of custom work to be done. It's very lucrative, because most people like you said, turn their noses up at the thought of it.
Boring isn't always bad. Last time I tried to create an interesting project, I ended up with a couple hundred MB of node modules before I'd even done much. :)
That's a fair criticism in node... I wouldn't want to work on it without an SSD (deployment is a different story)... the spinup and even npm install time on an HDD is dramatically slower than SSD.
It's also not that hard to roll your own system and avoid many of the modules and frameworks in the space. The first API I wrote using node wasn't bad at all, and in the end actually simpler than the rewrite using express... And by the time you get to Hapi with a few addon modules for your needs, it'll get pretty big.
All of that said, I still prefer it to just about everything else I've worked in... though I haven't done anything on Go or rust, but would like to.
Yeah, the size of my node_modules directory doesn't bother me that much. I've worked on some large Node projects in the past, and didn't care too much about how many modules I had installed because I wasn't exactly running out of disk space.
It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.
Yeah, the migration to ES6-style modules, Webpack2 etc will help a lot. There's still some bits to work out... about ready to do a new version of a few module in NPM and just declare that said module need to be used with babel+es6, async functions and decorator transforms... I'm tired of waiting, and it'll make the modules themselves cleaner not having to transform before publishing to npm in the end.
It's funny that a lot of this stuff is finally making it into the browsers and platform, when I've been using it for almost 2 years now. Looks like async is going in behind a flag in node 7.
It is not entirely clear if the author aka Slack chose PHP with these reasons in mind apriori or did they choose PHP first and are now justifying why their choice of PHP is not bad.
I'm going to guess they picked PHP because they knew PHP and not because of the nice reasons mentioned in the article. That is the article should be "why slack is sticking with PHP".
Almost all the major languages are actually (despite lots of HN debate and arguments) fairly good choice for developing not because the major languages are expressive/powerful but because they have very very mature tools (e.g. Java sucks but the JVM and its tools are very mature) and lots of people who know it.
Basically you could write a plethora of articles with "Taking MAJOR_BORING_LANGUAGE Seriously".
For example I'm responsible for choosing Java for my companies startup. Java historically is not a very productive language to pump something out but in recent years it has vastly improved... regardless I chose Java because thats what I knew at the time and I would pick it (or some other JVM language) again. And I could rattle off whole bunch of reasons why the JVM still kicks butt but the reality is I am biased because of my familiarity.
Agreed, and only thing I want to mention is that 'Productive' which people normally think about how fast to develop rather than measure it within the whole system development life cycle – code easy to read and maintain, tools for test/profiling, logging, deploying etc.
Come on, PHP is the 'Justin Bieber' of languages, everyone knows it. Its the most successful and widely used web server language in use and with anything so popular it has a large group of haters.
If anyone wants to come off like a 'serious' programmer, all they need to do is denounce PHP as a horrible aberration, a frankenstein of a language. Most don't even know about the changes in the language over the last decade, they just hate it to stay inline with their peers.
However, those opinions dont line up with the facts. PHP goes beyond semantics of language, it's a complete service for delivering dynamic HTML from the server. Why is it so successful? It is one of the most robust, well supported, battle tested languages to appear in the last 15 years. Its support is guaranteed on any hosting platform or cloud solution available. It has a large array of libraries capable of integrating with most any service whether that be databases, web apis etc. It has the ability to scale for high demand, as demonstrated by the many large corps that use it.
If you want to rip on PHP because it's cool, I think you're simply shooting yourself in the foot and ignoring a tool capable of performing almost any task you would require of it on the server side.
I think there is a needless air of elitism especially here that can only come when people take themselves too seriously, seek validation for their choices, and are always on 'display'. This is also now fuelling a full scale culture of complexity as nobody wants to do things simply lest they be judged as 'unsophisticated' and lose career and other opportunities.
This cannot lead to real conversations or good software. There are far too many naysayers always eager to jump in with their 2 bits of negativity with the same cliched talk points and links most of whom I am sure would never be seen near php and may not even have used it.
The criticism goes silent when HN favourites like Slack show up on discussion. Ignoring the sheer number of high traffic websites and successful startups using PHP is just another way to deny it its due.
Most PHP apps are a breeze to install and use compared to just about any Ruby or Node app. Try installing Discourse to understand just how user hostile it has become. The respect for users and simplicity comes through in PHP. NPM and Ruby with their dependency hell expect a full dev environment even on user machines and nobody thinks this is ridiculous. There is no denying PHP warts but Node, Ruby and Python I think have their fair share of issues.
I really do like Python but for a web project that needs to scale and not get mired in other issues I would choose PHP every single time. For a library or SAAS app maybe, but for an installable app I would never expose users to the Ruby or Node ecosystem.
That example of "Surprise type conversions" is crazy.
Did not know that.
While i do not think PHP is a perfect programing language. There is one think i LOVE about PHP, it is that the PHP "community's" default way of documenting code behavior is to make a small example.
When i read most other languages documentation i read it. Then i need to make a small test to verify that i understood it.
All those tests takes a long time to make and i have to make them over and over again, every time i forget the way a function behaves.
In my experience code examples as documentation are far more common than actual documentation (e.g. guides, user manuals), but perhaps I just haven't worked in a language where the opposite is true.
You can take a look at the node api docs... there are some areas (particularly in crypto), where it's really hard to understand what you need to do, as there are pretty much no examples of actually exercising said code. So you go searching via google, find a similar example, look at the docs again, and hope that you got it right.
It's harder still when you're trying to en/decrypt data from multiple programming languages... Java is particularly painful as well, since a lot of the things that are "standard" are abstracted behind class structures with naming that differs from the standards.
Hack is awesome, but we decided to go with PHP 7 and this choice was primarily made because of lack of tooling on the Hack side. Things like New Relic are not available and these type of things do matter a lot when it comes down to choosing the programming language.
I must say that PHP 7 is a great language nowadays. Most of the modern concepts are baked into a language or are about to be developed.
At some point, I wish Hack and PHP merge into a single language in the future, somewhat similar to what happened to Node and iojs. I'm not sure if Hack is going to be around in 5 years, but I'm pretty confident about PHP.
I'd definitely love to see more articles about Hack and people's experience with using it in production.
With the changes in PHP 7.0/7.1 & the powerful frameworks (Laravel & Symfony), PHP has made a dramatic turn for the better in the past ~3 years. I work with Laravel daily and it is actually an enjoyable experience using PHP.
Most of the hate for PHP comes from the PHP 4 days, but we are well past that and charging ahead with featureful yearly releases.
I find the virtues quite uncompelling, take for example
>First, state. Every web request starts from a completely blank slate.
Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once.
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound.
I cannot disagree enough with the conclusion he draws from the quick feedback loop in PHP. I do PHP in my day job, because that's what our codebase is in, but recently I finally got the opportunity to use Haskell for a side project. The feedback-loop might be slower (honestly not by much, automatic reloading is a thing in almost any framework), but I'm a zillion times more confident in my code, because you are able to encode so much logic in the type system, meaning the compiler will catch whatever. Contrast this with PHP, where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours. Particularly when refactoring code, which you often end up doing while hasing something out.
Also, PHP works at a quite coarse granularity of concurrency. A thread per web request only? As soon as you want to do something more advanced, you are forced out into the many patchwork solutions (wanna do async? queue that shit).
Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry - heck PHP was my first language and I made a CMS from scratch without even knowing much of what I was doing.
That said, it has come a long way, and something like HHVM/Hack definitely helps a bunch! I just think the pros in this blog post are quite weird and IMHO incorrect.
> Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once.
I mean, you're not reinitializing it, and it's not exactly slow. And when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere.
> where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours
I'm not really sure what you mean by that. Write a method, write tests for that method. Just because PHP has weird type coercion issues doesn't mean you can't be diligent about the types that you use. And of course tools like PhpStorm understand docblocks, annotations and PHP types and classes and basically does the same thing that a compiler does, it'll show you big honking type errors if you ask it to, it'll even stop you from committing broken code if you use that option.
> Sure, a lot of people have done a lot of quite cool projects in PHP, but I would much more benefit that to the lower barrier to entry
I don't know about that. Low barrier to entry gets you a lot of crummy projects. In my experience PHP is a lot easier to manage and maintain in production, and that's a huge advantage to companies and products with small teams.
>when your application starts scaling across many instances, many zones, many servers, you can have more faith that each request runs independently and there are no runaway processes to worry about on a single one of your random servers somewhere
It's just as easy to scale with other languages, you would keep the data that needs to be persisted in a DB. The benefit comes from things that does not need to be persisted, like resource pooling, memoization, config loading etc.
> > where I'd almost have to visit every branch of code when I alter something because of it's many weird behaviours
>Write a method, write tests for that method
Exactly, I need to write tests for things that are trivially verifiable by a compiler. And I'm not just talking about type coercion (which is a bad thing), but also missing function parameters, wrong parameters, missing initialization of variables etc etc. These are runtime errors and you either have to write tests to catch them (hence visit very code block) or manually try and reach them.
Some IDEs, like PHPStorm, can you get pretty far though.
>Low barrier to entry gets you a lot of crummy projects
As someone else mentioned in another comment, 1% of PHP projects succeeding is still a lot more than 20% of Haskell projects.
>PHP is a lot easier to manage and maintain in production
Except for when you need to scale. Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory for a PHP site to really run performant, adding quite an overhead to any production setup you'll get into.
Look, if you want to use something other than PHP, don't let me get in your way. However, if PHP is one thing, it is fast and always has been.
> Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory
We don't use any of that. We don't even use database connection pooling. Every request has to reopen the database. Every request has to reopen an LDAP connection to Active Directory for authentication. We are still on PHP 5.3 and we aren't using an opcache. We are using the memory-hungrier mod_php instead PHP-FPM, and we are using the slower, memory-hungrier Apache prefork instead of its newer event MPM. We are also running PostgreSQL on the same server. And yet PHP is connecting to the database over the slower network instead of UNIX ___domain sockets.
Every request takes just a split second. The server's processor is running at 1-2%, with about half a gigabyte of RAM in use, a lot of which is probably the database.
All those inefficient design decisions are artifacts of history that I hope eventually to revise out --- except for connection pooling, which I've read has its own problems. On my personal website I've been able to choose the newer and better things, but none of them were really more work to set up: Apache event MPM, Unix ___domain-socket connections, PHP-FPM, and PHP's OPcache.
More importantly, said virtues don't have anything to do with PHP as a language, and everything with request handling in the server and the framework. Yes, in case of PHP, the latter is basically built-in, but you can (and we do) have equivalent functionality with all other languages out there. So if these are virtues, they also apply to Python, Ruby etc. And then - again - why PHP?
PHP is wonderful as a thin layer of glue between your database and the web browser. It's when you write a thick middle layer that PHP gets unwieldy.
Business logic: Don't write it in PHP. Write it in PostgreSQL.
Authentication: Don't write it in PHP. Use Apache 2.4's mod_auth_form. Replace hundreds of lines of PHP code with a few lines of Apache config. When it gets to your PHP script, all that's left to do is read $_SERVER['REMOTE_USER'].
Authorization: Don't write it in PHP. Use one of Apache's modules (LDAP, DB, or even file) or if possible make your users all very restricted database users and use database permissions more.
Don't need a database? Then why not handle it all on client-side JavaScript?
I'll admit that my advice fits well with CRUD web apps. If you're doing something else, PHP may be gross.
But really, my goal in programming (don't always reach it) is for PHP to just make a simple database call and wrap the result in HTML. If you're doing 123 == '123foo', can you move that up into the database or down into the browser? If you're writing elaborate class hierarchies in PHP, I think you're doing too much in PHP. I write a few functions, if needed, but mostly move all data processing to the database or browser.
I always wanted to do PHP this way as I have a Perl background but since PHP5 appeared in 2005 the psuedo-Java posse took over and it was PHP Design Patterns everywhere and suddenly procedural/functional PHP was un-idiomatic. I find this odd as Java's verbosity can be forgiven as it gets compiled away. Not so PHP5's verbose OOP which has to be fed to the interpreter.
Don't hold your breath. PHP suffers too much from Java envy. PHP5 was game set and match for the PHP Design Patterns crowd and now we have PSRs advocating a coding style in which blank lines and comment-based annotations outnumber lines of real code by a factor of about 10 to 1.
I've whole-heartedly switched to ASP.NET since my productivity is increased with it and I can actually use the language (C#) for other things. I would've agreed with the author a couple of years ago but with Azure, AWS and other cloud services it is simply no longer true that php gives developers a quicker feedback loop. I can setup a node server with gulp and start working in 10 minutes or I can start a new ASP.NET project and deploy to production right after the project creation has completed. With php I still have to setup a virtual machine etc etc.
Yes I know but there is much more of an hassle when setting up the development environment. Even if it wasn't more of an hassle, why use php when the alternatives are as simple?
Even if php has it´s nice things it is still not that great of a language.
I've used both Rails and Laravel in production, and while I equally love both, the amount of hassles you face with rails in prod is an order of magnitude more.
That's not a fair comparison though. For any non-trivial app, most people deploy PHP using a CGI, PHP-FPM being the standard. Even the cheap, shared hosts provide FastCGI these days.
That being said, getting RoR or Django up and running is really no more difficult than getting Laravel setup and running via PHP-FPM.
> First, state. Every web request starts from a completely blank slate.
> Second, concurrency. An individual web request runs in a single PHP thread.
> Finally, the fact that PHP programs operate at a request level
Isn't this just "virtues of Apache modules"?
There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global requests virtues of these languages too?
---
Even if you do somehow convince me that these virtues are specific to PHP, you can't convince me it does it well. Hence, MaxRequestsPerChild.
To quote Radmus Lerdorf,
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
We are mostly (95%) a PHP company but going by trends; we did some projects in Python, NodeJS and Rails a few years ago.
Now I look back; I see the projects which have technical debt were flawed in design and did not get maintenance they needed. Most of them did not get traction to the point where scalability issue came into the picture.
So this year, we started moving that 5 % non-PHP projects to PHP counterparts. Again, we are miles away from any real-world scalability issue, but at least we are now able to maintain projects as we have a large PHP team.
At a small to mid-size organization level, it is more important to use one language for all projects.
I believe technical debt is not related to the choice of language but anticipating direction a project might take and picking up right design patterns to support that.
Which programming language is better is a highly overrated question!
There have been huge improvements made with PHP over the past few years. PHP 7 is great and I would choose it over Hack. Modern PHP using autoloading (Packagist & Composer) and an MVC structure allows for rapid development. With frameworks such as Laravel, you can get something up quickly or just pull in Packagist libraries you need if you don't want the bloat of a framework.
I recently finished up a fairly complex web app that uses PHP 7 for the back-end. Took me under 2 weeks to develop partly because I was able to leverage a lot of stable and well supported libraries through Packagist. It brought in over $4k its first month. Not bad for 2 weeks worth of work. It would have been hard to accomplish the same thing that quickly leveraging Node or Python (I use both) at lease for this app.
I've been doing consulting for several years now, as well as a MSc thesis that involved me looking at a number of open source codebases. I am generally in the "PHP is garbage" camp, but I keep hearing people say that nice codebases in PHP are possible. I've never seen one, but I am perpetually open to the idea that they exist.
Does anyone have a good example of an open-source PHP project that will enlighten me?
Sure, but most of the OSS for Python and Ruby is frameworks and libraries too... If you want an application check out phabricator, though I'm not a fan of their DB schema design.
Sorry to sound so dramatic but I don't know how to put this in better words:
After reading this thread, is there even a proper way to measure how good a language is (trade-offs, benefits down the road)? Having done web stuff in PHP and Python I think both are terrible. So, how would a programmer trying to avoid his own biases and anecdotes find what tools are right for each job? Maybe I didn't "liked" PHP and Python because I'm a terrible programmer. Or maybe I only worked with awful teams.
Is there any science involved or should I make my decisions based in what blog post I read that week? How can I actually trust the opinion of companies/engineers if they are so invested in that tech? Who would admit that after investing millions on it they didn't actually think it was worth it? There's no way that I'll be able to have deep knowledge about all the languages that are out there.
The sad thing is that I end it up choosing whatever is popular and half sane because not finding (updated/well-maintained) libs or tools you need is worse than picking a niche language that might do the job better.
> is there even a proper way to measure how good a language is?
Nope.
I mean.
They're all Turning Complete (except for the ones that deliberately aren't), and they're often good at expressing different types of problems.
So depends what you're trying to do.
Trouble is, it so often turns out you didn't really know what you were trying to do till you were nearly done doing it and then you're stuck with what you picked.
PHP is pretty good for building website prototypes, and can now handle the scale as they grow too really.
But "Good" depends on what you're trying to do, and what tools you already are running anyway.
Is there a way to measure how good a spanner is compared to a hammer?
There's no easy answer to this, but books like CTM [1] give an overview of the programming languages landscape. They can come in handy when evaluating language designs.
( Yeah I know you want to scream and say all the things about this code, but this is kind of code you would encounter with PHP, most of the time it's more horrifying than this one. )
People use it PHP for this reason, If you want to make same functionality in another language you need to setup an app and all the necessary things that protect you from garbage, some obvious security issues and bugs, not a single file like this. It's so easy and so wrong, it should be illegal to do this. Create a file and put it into directory and call it from your browser. You don't have to know anything about web or web servers and stuff. You just make shit by copying and pasting from internet, that's why Facebook made by PHP and now there are whole teams who are trying to protect company from PHP horrors. (They made a PHP VM, bunch of software to analyze PHP and optimize it etc. )
Just don't try to justify PHP, do not defend it. It's shit and you know it, accept it and move on.
(Note: do you remember Facebook's profile.php pages, they are still exists you can call it just like old times profile.php?id=YOUR_ID, yeah it's a shit once you get infected you're not gonna get out of it completely. Even if you can, it leaves traces on you just like profile.php URL's
The way you write code I wouldn't trust you with any language really. You give 6 lines of code and it has display of all the worst practices that I haven't seen since I read a 13year olds tutorial on the language back in 2003.
- Use of mysql_ functions (This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used)
- Using the user input directly in the query instead of binding, using prepared statements, or at the very least casting to an integer (don't do this)
- (besides mixing multiple layers) Possible whitespace problems in the output validation (if you're using JSON), you want most php code to be "validated" (like using json functions), to have proper headers, to output types correctly (like booleans). This is also why you should never use PHP's closing tag, except for things like pure PHP templating, it's even in the PSR-2:
> The closing ?> tag MUST be omitted from files containing only PHP.
Not really the case here but you get the idea. It's like you're using a "html view" to output JSON API stuff.
- Possible "Undefined index", or worse, at $ar["name"], $ar["___location"]
- Having to write some ugly conditionals if you have more than a single result and need to end the sequence without a comma or do any kind of transformation
- Trying to save vertical space by using expressions in the same line, sacrificing readability
- No error handling. What if the DB connection fails?
My assumption is they already knew PHP before setting out on this (if not I'd be interested in hearing about that). What you know is a huge part of these decisions. I doubt many of the sites noted truly picked PHP after sitting down and doing a comparison of all the popular languages across the board. Their systems grew out of what they knew and there was no time to rewrite or maybe there wasn't a need either. If you like PHP and can support it good for you.
Regardless of their findings I wouldn't recommend anyone learn PHP if starting out.
> Regardless of their findings I wouldn't recommend anyone learn PHP if starting out.
This is bad advice.
If you are a new programmer starting out, first of all you should learn a few languages, not just one, but also, why would you not want to learn one of the most popular and prolific languages in the industry you are trying to enter?
If you want to work in the web world, not knowing PHP will close lots of potential doors. They may not be the coolest of the cool but not everyone has the luxury of being that picky when looking for work.
Of course if you are an exceptional developer and/or you live in one of the insular startup hubs (SF, NYC, etc), then you can get away with being picky and sticking to the bleeding edge or the du-jour tech stacks and you'll probably get hired, but for the majority of people entering the web development world, that may not be the case, and they should be more pragmatic.
Even if you don't specialize or focus on PHP, knowing how to code in it will help you land jobs and advance your career.
> If you want to work in the web world, not knowing PHP will close lots of potential doors.
Not knowing language X will obviously close doors but by learning language Y instead will open others. Insert whatever language you like.
I wouldn't recommend it to someone starting out because it's use is in a limited context. You could do scripting outside of a webserver in PHP but it's not done often. Since there are mature ecosystems for other languages that are also used inside and outside the webserver I'd recommend something along those lines. In my experience developers who develop systems and can learn and understand the varying pieces have more options than someone who is a PHP or Java or whatever context limited developer. Because of that I'd recommend a more versatile language and ecosystem when starting out.
But of course do what you like. I'm not trying to bad mouth PHP. I just don't think it's the best option for someone new to the field as it would limit them to a specific context.
Wordpress succeeded because they were using PHP, because during the 2000's it was very easy to find a cheap shared hosting solution in PHP+MySQL. There was no cheap way to host Rails applications.
And their target was people who would install Wordpress themselves on a cheap shared host.
Facebook and Wikipedia probably used PHP because many developers knew it, and the reason was... That there was many cheap shared hosting solution for their pet projects.
Not only this is no longer true (it's just as easy and cheap to host Rails, Java, Scala, or anything with cloud hosting), but the availability of cheap shared hosting is not relevant for most problems.
tl;dr:
* Wordpress couldn't have succeeded without PHP, because of a context that is no longer true today
* Facebook succeeded despite using PHP, because they had the manpower to fork the language and write their own VM
The reason Wikipedia - or, rather, MediaWiki - uses PHP is because Magnus Manske was going to write something to replace UseMod, and thought he'd try this "PHP" thing he'd heard of.
It was his first PHP project.
(And why didn't Wikipedia have a visual editor until 2013, rather than 2005? Because wikitext syntax was literally defined as "whatever this series of PHP regexps does". Of small acorns, mighty oaks of technical debt can grow ...)
Anyone who claims anything even vaguely in the direction of "PHP is good 'cos Wikipedia uses it" is talking rubbish.
> Almost all languages these days let programmers compare, e.g., integers and floats with the >= operator; heck, even C allows this.
The implication that C is an especially strict language for type conversions is strange. C is actually one of the loosest languages for type conversions. It's even legal to do things like compare pointers to integers (though most compilers warn you)!
I'm a PHP programmer and it's great to see this because a lot of times I feel like PHP is limiting my ability to move forward in my career. I've been looking for jobs and it seems like having pretty much only PHP, jQuery and mySql on my resume isn't enough to get hired. I've been trying to figure out what I have to do to get noticed - is it worth cranking out a bunch of projects in PHP that won't impress anyone because it's just PHP, or or is it better to learn a language like Ruby and make a bunch of (shittier, because I'm not experienced with it) projects?
> a typical Python application server, e.g., the debugging
> cycle will look something like “think; edit; restart the
> server; send some test requests.”
the "most typical" Python stack (wouldn't call it a application server) is probably built with Django where you don't reason about the Server restart, it's as fast as changing something in PHP.
P.S.: I don't use Python that much anymore. Other people would say that the thing I'm using now takes endlessly long to compile and has some wierd operators.
Thank you for writing this - very eye-opening. One sentence doesn't seem right to me though:
> Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost.
>I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound
this is certainly what got me started with PHP and what makes its so easy for beginners
> Inconsistency around reference, value semantics.
I ran into this problem today with some code by a programmer who should have known better. The problem is not with PHP, it's with programmers who learn one version and then don't keep up and change as the language evolves and improves (ain't nobody got time for that.) One guy I work with is still programming PHP like it's year 2000. It's maddening. PHP7 is a very nice language. People decided JavaScript was cool after "The Good Parts" came out. The same is true for PHP. If you learned PHP3 in high school and are still banging out code like you did then, you're the problem, not the language.
For greenfield project main question would be why? It's not horrible but what do you exactly gain? With so many options around it's actually hard to make a case for PHP (and I have being using it since 2000).
It's extremely mature, stable, reliable, and easy to reason about.
Personally I wouldn't choose it but, for a larger company, if you already have engineers that know it - and trust me many will - it's not a bad choice.
This is especially true if you are just serving a simple website for a product or service, even basic e-commerce. 90% of websites out there don't need Rails, or Python, or Go, or Node.
Y but it's so slow to evolve it's just sad. We've being using hacked on "traits solution" since 2006 (via build script) and PHP only got traits in 2012 and on and on. A lot of things that could make it more modern get shutdown.
Modern for the sake of modern isn't needed for a good app.
Especially a web app.
Stability, availability of developers, and ease of debugging however are important. PHP has those. Granted it's not the only one, and I think there are better alternatives, but it's really easy to write a good app in PHP.
Bad coding practices and bad application design will make ANY app have bad code. PHP just historically had a lot of that.
I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.
Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.
For "real time" node def. will beat PHP :) But Elixir/Phoenix will destroy either one and thanx to BEAM it's actually can be considered soft real time system.
Node's intrinsic ability to "speak" JSON makes for some very clean code when dealing with that sort of data. If you're doing a simple API back-end in Express with JSON in, JSON out, it's extremely light-weight.
PHP, Ruby and Python here are at a disadvantage. JSON is JavaScript's home turf.
PHP isn't at much of a disadvantage - it has its own native JSON encode and decode functions. Granted, actually using javascript is better but it's not as if you have to import a library or write your own JSON parser.
well nicer syntax vs not dealing with event loop for me it's nicer to use more verbose syntax. (I guess I am getting tired of Node too :) all thanx to getting spoiled by Elixir.
Agreed, barring an outside force, or other members with experience or a strong voice/drive, experience will be what drives most technology decisions, and should.
I'd say the opposite, I can get a node project up and running pretty quick these days... as to peer comments on APIs, I don't think it's hard at all to spin up a react + node api project once you've done it before... and starting with a boilerplate for react+redux and express is very straight forward as well.
We run Nginx in front of both node and PHP so can't say it takes significantly less time to setup node then PHP for production use. Composer is a reasonable take (reapoff? :)) of npm. Yarn seams really nice though.
TLDR; Because Cal Henderson made the initial commit.
He's obviously a big fan of the language, and surely had a big hand in influencing what technology would be chosen very early on.
PHP can be like playing with dynamite. If you have an explosives expert on site (or Cal Henderson), you can get a helluva lot done with PHP in a very short amount of time.
I find it odd that nobody sees the elephant in the room: productivity is determined by the "fit" between a developer's or team's mindset and the language!
None of them matter in isolation. If you have a team of people who likes to think dynamic, functionally and meta-linguistically, just pick the best Lisp-family language for your needs. For another team who prefers to think dynamic, functionally, with actors and pattern-matching, pick Erlang or Elixir. Someone who likes to think pragmatically, likes obviousness and simple static typing should probably pick Go if he's also "minimalistic" or Java otherwise. For a "move fast and break things + fuck this functional programming bullshit" thinking team, pick the best version of PHP (Hack & HHVM) etc. Want "move fast and break things + ok with event-driven + some sprinkle of functional programming goodness", then use Nodejs.
For example, for "move fast and break shit" prototype development I pick Nodejs over PHP because my mind "works functionally" and every attempt at writing functional code in PHP is pure pain.
There is a reason why there are so many languages: people think very very very differently from one another, but at the same time they think similarly enough that they can gather in "tribes" around certain technologies and idea!
It is interesting that author does not mention the performance improvements of PHP 7. I have read with PHP 7, HHVM does not have the performances any more. I wonder author cared to test that in their codebase.
The shared nothing request model leads to laziness. And once you get to any kind of scale you'll want to run PHP in something like php-fpm with lighttpd or nginx, which actually does aggressive caching. It's painfully slow to re-evaluate for every single request. This introduces subtle problems because your code was probably shit to start with.
Of course, this is not a post about how good or bad PHP is/was. It's just a matter of personal preference at the end of the day. Your favorite language is the one you feel you're the most productive in and says a lot more about you and your experience/background than the language itself.
If people would focus more on usability, comprehensibility, clear algorithms and project structure and precise requirements we could probably skip debating over languages altogether, because programs would look beautiful in any language.
My experience is that programming is fun no matter what language you use. I've used C, C++, Python, VB6, C#, Java, Ruby, elisp, PHP and a little clojure and some others. I don't get all the language hate.
A while back I found myself doing a Laravel project and found it totally adequate and not at all painful, so I don't have the same old flinch reflex whenever someone asks about PHP these days.
That said, nobody will ever convince my that the style of structureless, start-at-the-top, run-to-the-bottom monolithic PHP pages has any merit at all for real apps. I have seen many projects fail, or slowly mire themselves, by creating these monstrosities, with the opening <html> tag 1200 lines down the file. But I assume these days that's not common.
Of the four disadvantages of PHP mentioned in the article, in my opinion, the worst by far is the first, i.e. confusing comparison rules. The article however fails to explain that clearly: the worst thing is not that comparison rules are just confusing (heck, many things are confusing at first, but eventually you work them out); the worst thing is that those rules are intransitive (!!!), as explained very well here: http://phpsadness.com/sad/52
The second disadvantage, passing by reference vs. by value, honestly can or cannot be confusing, depending on which other languages you are accustomed to. So I would say it is a debatable point.
The third point, the language being failure-adverse, is a choice made by design, this is also a debatable point, but it's in line with the fact that PHP was created as a utilitarian language as Lerdorf explained numerous times, e.g. here https://www.youtube.com/watch?v=anr7DQnMMs0
The last point, inconsistencies in the standard library, is obviously true but I would say it is very common in languages that have been around long enough to have subsequent approaches layered in the standard library. Some languages resolve this by making breaking changes and keeping consistency (think Python 2 vs Python 3), some others just show their age by having libraries that were developed at different point in time (Perl, R and Java come to mind), this is also explained by Lerdorf in the video linked above.
The biggest issues I see with the language didn't made into this list: for instance, I can think about more serious issues like accessing the wrong variable name does not returning an error, assignment and initialization being the same (thus also suffering the same issues related to wrong names), various surprising type conversions, defaults, and so on. I guess it all boils down to the mindset of the language itself, as the article says.
However, I disagree that "other languages do not work like that thus are not as easy to test". You can implement this in any way you like in any other language. You can implement your webserver by forking a new process at every call. You can even use a worker that communicates to a different hot-swappable process. It can efficient as you want - copying the whole data around, sending file descriptors, etc. The alternatives are endless.
PHP may be "interpreted and hot-swappable" by default, but that's an accident from it's design and it only works like that - if you try to use it as a long-running process, you'll run into a lot of issues. It's also terribly inefficient - have you ever developed a web interface for an embedded platform? A really embedded one,
like 32MB of memory, shared with the application itself?
I guess in the end it boils down to the duct tape analogy: it's terribly fast to prototype something with duct tape and scraps and you can join a multitude of materials in a very simple way - just put everything in place and cover with enough tape to hold it together.
I don't consider myself a programmer, just someone working in IT that writes a lot of code, and to this day when I want to write any type of web page or web based "app" PHP is my goto tool. I can write my HTML and add PHP logic directly inline whenever I need it, and get the job done in no time. Sure I could spin up a node.js framework, use routing, create classes and objects, etc.. But to 99% of my needs it's just not worth the extra time.
Really, the worst part of PHP in my experience has been the debugging facilities. Print-line debugging just doesn't cut it anymore, and things like xdebug and phpdbg just aren't elegant, are hard to configure properly, and don't work for all the relevant scenarios (trying to debug PHP running in a docker container is not a fun task).
The quality of open-source libraries in the ecosystem is also pretty below what I've come to expect from other languages, and then half of them are c-lang PHP hybrids that are more difficult to manage, update, and install.
I think the author failed to mention the downsides of no long-running processes either. Shelling out to e.g. memcached for configuration setup (especially when memcached might not live locally) isn't particularly fun. Not to mention this has made it difficult to integrate into some useful things, like GRPC[http://www.grpc.io/] which can't use PHP as a server as of yet.
Then there are all sorts of random deployment gotchas, like proper opcache configuration.
PHP is a pretty wart-filled language. It's usable, but I wouldn't make it my first choice in any situation, given a choice.
PHP has xdebug. You can debug interactively using an IDE like IntelliJ / PHPStorm or whatever floats your boat. Is that not enough?
Edit: I commented on this post before the OP edited the original with a longer form explanation. Originally it just said he didn't like the debugging and left it at that.
I mentioned that in my post. Needing a full-fledged IDE for some baseline debugging isn't what I look for. And, like I said, doesn't "just work" in all scenarios.
Plus, you can't do inline code execution (the interactive part) if you are using xdebug for PHPUnit tests (even in PHPstorm). It's a really flawed experience, where getting it to half-work is a frequently frustrating experience.
Even the baseline REPL is flawed. PHP went again and forgot the P, so you have to figure out the correct-of-many-variant print statements and remember to put it before the code you want to run when using the 'REPL'
Wrote Java code for few years and was writing php code the last 2,8 years.
While it doesn't matter that much at the end of the day, php is slow compared to java. A language which has so much hidden potential performance (from 5.6 to 7) can't be that good.
Also a lot of stuff i was used to in java is now also how php developer write code but with a language which doesn't support it properly. Annotations for example.
The worst thing was the type annotations in comments. Why do you write type annotations in your php comments? Because otherwise your ide can't protect you from those errors. and it doesn't provide you with proper code completion.
When you use tomcat and basic servlets or spring, you can write code quick and easy without any problems. Not sure why you wanna would use php.
Tooling is much better (IDE support, Profiler support) and Debugging is much better (simple to connect, can drop frames) and yes java has hot code replacement.
I can change the code while i'm debugging it and than drop the frame and test it again without reloading anything.
And at the end of the day you do know a language which you can use for android, server, games, desktop clients and it is cross platform out of the box.
What I find interesting about all this debates about programming languages is that most of the time people fail to remember that they are just that "languages"... Each one has its strong points and flawns, at the end of the day what truly matters is how competent you are at expresing on them and carrying out your goals.
For decades people have been complaining about Php, and how afwul it is, yet still, for decades successful projects have raised (and still do) having Php as its core, just today there 2 posts on the front-page about big companies (Slack, Dailymotion) talking about their Php codebase...
The argument that due the huge volume of programmers using it, it is "bound to" return a few success cases here and there is BS... if that were true we would be flooded about news about how X and Y company succeed "thanks to" using Python, Java or whatever language you deem as "superior", but that doesn't happen... because companies don't suceed "in spite of" Php, they suceed "with" Php, in the same way companies don't suceed "thanks to" X or Y language but "with" them.
When people set to built a piece of sotware they don't have in mind "I wan't to build the most technically perfect code base" or "I want to build the fastest piece of software" because nobody writes software for the sake of it, everyone has a goal... they want to build "a messaging app for teams" or a "video-sharing website" and the best programming language for that, is whichever enables them to do so on the way they need it, with the resources they have, and within the timeframe they set.
And rant as much as you wish, but Php remains king about doing exactly that "enabling people".
Most of the hate for PHP comes from the PHP4 days, when it really was a wild west, fast and dirty kind of language. And of course, wordpress has done a lot of reputational damage as the world's most popular plate of spaghetti code.
But look at the way modern php developers work, in PHP7 with frameworks like Laravel, Symfony, and even Drupal 8. Modern PHP is a pleasure to work with.
Many amazing products have been built with PHP, Python, .NET, Node.js, etc. etc.
The reality is these (above) and many other good languages/frameworks exist out there for building web apps today. we live in the time with a ton of choice, and the rest is in our hands.
I for one love the new .NET Core, but I am a little biased being a long-time .NET developer and a Microsoft employee as of late.
A lot of projects do a rewrite from PHP to Ruby on Rails or some equivalent migration. What the project really needs is a rewrite/refactor/cleanup however it's much easier to frame that in the context of going to a "better" choice than it is explaining it just needs a rewrite with better practices/engineers (ie maybe more and easier tests or using the prior prior/current architectural lessons to create a better architecture). The reality is one could just rewrite it in the original language/stack but that is apparently harder to sell even though it's less risky.
So if the first language/stack is less respected, it makes it easier to sell that rewrite to non-technical/management. Thus PHP is a great choice for the first stack.
The one huge trap here is if the second team isn't experienced enough in the holy grail (next) stack. I've seen that and been relieved to walk away from those projects/companies.
I didn't understand some of the mentioned benefits of PHP.
Progressively adding types:
This isn't PHP it's hack. How is this different than typescript or flow?
Edit/refresh vs edit/restart server.
It seems like it's been several years that there have been things like meteor or webpack that make iteration super fast on JavaScript. Is that iteration slower than PHP?
The author incorrectly states PHP stands for "Personal Home Page". It changed in 1997 with the release of 3.0 when the project changed from being called "PHP/FI" to just "PHP", a recursive acronym - "PHP: Hypertext Preprocessor".
> Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost.
JavaScript and Python both have systems that allow you to do this: JavaScript has the Google Closure Compiler, and, more recently, TypeScript. Python has a number of projects that use a common syntax [1], including PyChecker.
I say this not to "well, actually" the post, but just to be a gradual typing cheerleader. It's great! We should all be using it! All the time! Please!
The shared-nothing model works great... if either you're just one developer or you've got a semi-competent Ops/DevOps setup. My first job out of college used PHP with one of the Rails-a-likes PHP has. During our user onboarding process, we'd poll the server to see if a data import finished, but since the requests shared _nothing_ and the Ops guy didn't understand PHP, it would load/run millions of lines of framework code for every single tiny polling request. On launch our site crashed because two people used it at the same time. Bananas.
There's a way to make Apache fork after some code has already been run, but boy howdy if you don't do that and love those mega-frameworks.
We are using PHP7 at stomt. We decided to use PHP for several reasons.
- First of, it is the language i have the most experience with. It would have been stupid to start with some new fancy stuff that would postpone our MVP or getting market/idea/product validation.
Apart from that...
- PHP allows you to write good code, it just does not force you to do it. Means if i need to prototype something really fast i can do so. At stomt we are really focused on writing SOLID code.
- PHP evolves great and became really fast in the last years.
- Economically it is cheaper to find PHP developers than developers in most other languages. And if you have a nice and clean software architecture in place, it is easy to also get more unexperienced developers to write good code.
I do Java and python for my day job, but do quite a bit of PHP on the side (small consulting projects, etc.)
The main advantages of PHP are ease of deployment (no build required, just upload your files and go, use a shared web hosting or a cheap VPS) and a fast dev cycle (edit/refresh the page.) It's also simple to work with for web designers who don't have a lot of back-end knowledge. They can edit your templates and see results instantly.
For anything with complex business logic, background processing, etc. it's absolutely the wrong choice. However, for basic web apps, when combined with a good framework (such as Laravel), it is fast and productive.
Much of this is valid in spirit. But to me, is irrelevant with the advent of Node. Node does all the good things the author describes. It does some terrible things too, but generally does them much less terribly than PHP.
I think one of the things that made node great, is standardizing on CommonJS modules, and error-first callbacks... That alone makes it much easier to build everything else on top of. JS does have some "bad parts" but they're easy enough to avoid via linting/testing.
NPM is another great/horrible thing in JS... people get hung up on the size of some packages, it's worth noting that a lot of that size doesn't go into your application, mainly because those packaging don't always know enough to exclude their samples, tests and documentation from the module as packaged in npm. Which is a mixed blessing.
You do get a lot of file bloat as it's not pre-build/bundled in npm (usually), and as such there is a lot of file-system access at startup (SSD strongly encouraged).
Through all its' warts, I'd still take it over almost everything else I've ever worked with.
Well this is seriously making me rethink my opinion on the PHP workflow, if Hack is as much of a game changer as the article claims? Could anyone here comment on their experiences with it, and its pitfalls?
You're asking about Hack, and the only response I see so far is about HHVM. So!
I've seen Hack used in a multi-tens-of-MLOC codebase to gradually insert types. It made huge differences in the kinds of changes that were possible; you can, e.g., rename a class or method, or change the order of its arguments, with confidence comparable to that in a C++ codebase. Most developers hack-ified everything they could get their hands on, and did all new work in Hack, without any external encouragement.
Yup, this. I work on (the original?) multi-tens-of-MLOC PHP-cum-Hack codebase, and writing new code is every bit as safe type-wise as C++, with none of the compile time. It's pretty great.
Dealing with the parts that aren't Hackified, though, is horrific. Complex codebases with no types are just ridiculous.
Well HHVM is quickly losing ground to PHP v7 in terms of speed. I'm not sure which is "fastest" any more, but IIRC it's close enough that if you want to switch for the "speed boost" I'd argue it's not worth it.
In terms of Hack as a language, it's very similar to the JavaScript->TypeScript relationship. It's still mostly PHP, but it doesn't quite get the new PHP features as quickly, and there is the chance that there could be incompatibilities in the future which could cause new PHP code to start looking and acting differently than Hack code.
I've been playing around with Hack in Vagrant in my spare time, messing with an experimental HN clone, so all of my experience is in terms of being an amateur, and certainly not on the bleeding edge of anything, but for what it's worth:
The XHP plugin[0] (which you can include as a Composer dependency, but you have to be able to run Composer directly under the HHVM daemon and not PHP) allows XML to act like a first-class citizen. No more interpolating between HTML strings and having to escape all of your variables, you can now just do
echo <b>{$possibly_evil}</b>;
and it just works (and auto-escapes.) You can even extend the XML root object to create your own tags[1]. Combined with Hack's native autoloader[2] (which allows whitelisting constants, functions, tags and types) Hack provides a lot of the features PHP developers will find standard in most templating frameworks, without the overhead of the actual framework.
Another benefit (possibly) is that improperly formatted XML will break with an error, so it's guaranteed that if your document renders, it's correct.
Hack allows generics, type hinting and aliasing[3-5]. These only apply when running the typechecker, however, when the code is running, everything decays to basic PHP primitives. I've been bitten a couple of times by this, because you might expect that you could use an aliased type as a typehint - you can't. You can define it as a return type, though.
Collections, like Maps and Vectors (oh, it has maps and vectors), can have immutable types[6].
Hack also supports "async" functions[7], which really aren't asynchronous. I found it a bit difficult to get this to work with curl and SQL the way I want to, but anything that helps remove the bottlenecks of database and network requests is welcome.
To me, Hack just feels like a better more sane PHP. All of the strictness is optional, but it still feels very good to have it there, and it has features users of more modern languages would certainly find welcome.
My pitfalls, so far, are mostly the result of my own ignorance of Vagrant and what the best practices for a workflow should be. I'm still debugging stuff in nano because I don't know any better.
Also, it seems OpenShift has a HHVM module, but you can't run Composer through HHVM on it, and as a result can't run a Hack project with XHP, because of Composer dependencies that require being run under HHVM. I asked StackOverflow what to do three months ago and just got utter silence and a single downvote[8]. I'm assuming that means I either have to learn how to write my own OpenShift cartridge or pay for an account.
Which brings me to my biggest sort of pet peeve about Hack - there doesn't seem to be the sort of community around it that PHP has, and a dearth of information on certain topics.
PHP 7's type declarations are enforced at runtime, rather than Hack's compile-time types.
This has its pros and cons. This means these declarations are always enforced, even when calling between typed and untyped code. However, there's no compiler to catch you out, at least not just from using the interpreter. Your IDE, or an external type checker (e.g. Phan) can check them for you, though.
PHP 7 also gives you a choice between weak and strict type coercion modes, whereas Hack lets you choose between enforced type declarations and unenforced type declarations.
As for the specific things you can type in PHP 7.0, there's parameter and return type declarations for `int`, `float`, `string`, `bool`, `array`, any class or method, and `callable` (a function name, method reference or closure). PHP 7.1 brings nullable types (prefix any type name with `?`), `iterable` (an array or an object implementing `Traversable`) and the `void` return type (enforces that a function doesn't use `return` with a value).
Notable omissions are generics (even for arrays), and property types. There was a proposal for the latter, but it was rejected, for better or worse. As bkanber mentions, however, IDEs can still check property types if they're annotated using docblocks. Hack also has a few extra special types that PHP lacks.
FWIW PhpStorm handles property type hints via docblock annotations and it works quite well, I've found myself not truly caring if the language enforces it as long as my IDE does.
Having come from years of PHP development and then into Python the past year or two, there's no way I'm going back to PHP. This is the same as every other ex PHP dev I know.
Every programming language is a tool. As such it isn't good if used for the wrong job. PHP is amazing for simple services that don't need much aside from database/filesystem access. I love PDO and wish more languages had such a first-class database access implementation.
I wish more people gave PHP a chance and didn't just keep bagging on it. There are problems with the standard libs, but nothing that isn't bearable. Grab an IDE and it's not an issue.
> Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost.
Python now has type hints that allow a similar migration for existing code.
>Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism
Wait, wait, wait, wait. Is he saying that to do async work he'll send a curl request to somewhere (spawning a thread for that request), not wait on the output and carry on? Last I used curl in php it was a synchronous action. Hell of a threading model there.
You can do some decidedly hacky stuff with PHP if you are smart about it. To get background tasks to run in a popular forum software, the system would send an ajax request to the cron script. The cron script would return a 1x1 clear gif and "close" the connection. The script would then be run in "in the background". It would be easy to do the same thing there. curl another script and have it instantly return nothing while it continues to process.
As someone who has been in the industry for 6 years, I'm certainly not a rookie dev. I have simply witnessed the horrors of PHP. I don't know who in their right mind would pick PHP over Python or Go. For high volume API work you simply can't beat Go nowadays. It's fast to write, stable as hell, and the TechEmpower benchmarks make it obvious how performant it is. Python has the added bonus of all the Data Science/ML libraries with it, which seems to be the way the world is turning nowadays. Not to mention that Flask with Meinheld workers also does very well performance wise.
To me you sound like a guy who has spent most of the last decade writing PHP. I've know a couple devs who used to defend PHP vigorously, mainly because thats what they knew best. Now they all write Go and haven't looked back. PHP is a story of right place right time, thats all there is too it.
PHP is great for HTTP requests. It's not that good for listening on sockets, running an event loop, etc, which is what you're likely going to do with real time messaging.
Unless you are using ReactPHP, PHP doesn't handle Http requests in any serious production configuration, the server fronting PHP does( Apache ,Nginx). But PHP wasn't design with Async programming in mind so using ReactPHP is more than tricky since most operations are blocking.
That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP, and with php-fpm and mod_php it has first class support with Apache and Nginx. Node isn't very good at HTTP, Python doesn't have first class support with HTTP servers, Java has great HTTP libraries but is stateful, etc.
If you want to handle HTTP requests quickly, reliably, repeatably, with minimal setup and maintenance, I still argue that PHP is one of the best. And yes, because of Apache and Nginx, but that doesn't nullify the point.
"Node isn't very good at HTTP" is just blatantly false.
Most languages don't "have to do HTTP" and those that do often do a pretty terrible job. Somehow Node not only does it, but does it well, where a bare Node process behind some load balancers is often enough to get the job done. PHP on the other hand needs all sorts of hand-holding to work properly.
Node is stateful and not threaded, but yes you're right that it serves http out of the box. Http was a module in the early days but I see now it's core API and has been for a while. My mistake.
Node isn't a pure functional language, and neither is PHP. I'm not sure what you mean by "stateful" otherwise.
JavaScript does have threading facilities like WebWorkers, but they're often largely overlooked since the code complexity that comes with it isn't worth it and the multi-process model generally works fine. A single Node process can do a lot of work because of the aggressively asynchronous approach to processing it takes.
Node + Express is actually a pretty slick package.
WebWorkers have nothing to do with threading. They will not let you share memory, and this means that you waste time on seriazlizing/deserializing anything you pass to them, so from optimization point of view, they are more like processes. This makes js completely unsuitable for things that are data-heavy and cpu-bound (just cpu-bound may work, but it still not the best choice).
They do have a lot to do with concurrency, which is often what threads are used for. They do have limitations to fit in with the JavaScript model.
JavaScript is generally a lot better at compute intensive tasks than contemporaries like Ruby, Python, PHP and Perl due to the incredible performance of the V8 engine and others like it. The language is ugly, but it's more easily optimized by the JIT compiler.
If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
> If you're arguing JavaScript isn't as good as C++ or C, sure, it isn't, but few languages are, and none of those are frequently used for general-purpose web development.
Java and Go work just fine here and both are used for webdevelopment.
My point is that js in not suitable for many cpu-bound operations and neither webworkers nor multiple processes are enough to help it with that. In the browser you don't have other option, but on the server you can (and in practice people do) use other languages like java or go (not to mention C/C++). This is were things like image processing or full-text search goes.
One of the things to appreciate about PHP's ecosystem is how much you can be exposed to warnings, criticisms and cautionary tales. There's so much energy put into tearing it apart that if you aren't getting an education about coding pitfalls it's really your own fault.
Freaky coincidence. Today I just happened to twice edit some PHP, for two separate tasks... but it's the first time I've touched PHP for about 10 years!
What goes around comes around. I'm editing my LinkedIn and dusting off the old O'Reillys...
Language matters too less, What matters is how it is being used. A Java project may be meanly architected, while PHP code may be architected with good quality. Its is the quality of architecture and code what makes projects sustainable(i.e technically).
Sorry, but I'd rather take opinions on web environments from somebody that at least knows that nearly all web frameworks, on any language that you choose have those properties of no shared state, independently parallel request based execution.
I just want to use whatever tools we will be using in 5 years. While the underlying technologies of css, html, and javascript have gotten cleaner, powerful, and more cross-compatible, everything that sits on top seems to have gotten bloated.
I agree with the overall sentiments of the article but I don't know if I agree with the conclusions. One thing I don't see mentioned is the lack and overall lower quality of many php libraries.
PHP engineer of 10 years here - all things being equal, I cannot, in good faith, recommend a person use PHP for anything. General rule of thumb is, if you can, use Python. We still see folks actively choosing it though.. mostly because it's a language we already know and better to create an MVP in something folks know rather than struggle with something "better" that will take a person 5x longer to write while they learn it.
I would bet a donut that Slack is off PHP within 2 years.
What I think most people are missing about PHP is the incredible ecosystem that emerged in the recent years (especially with Laravel) that helped to speed up the development of web apps by A LOT and removed all the annoying boilerplate.
I know that nowadays there are a lot of fancier languages to write your next project, but I challenge anyone to find anyone that has a similar ecosystem that can do all the following things with just a matter of editing config files basically.
- Create a fully working app with authentication, database migrations, security checks, middlewares, route management, and much more with just one command line ("laravel new project_name") (Laravel)
- Logging in a user with an external service with one line of code. (Laravel Socialite)
- Sending real time notification with any type of channel. (email, socketio, sms, ios/android, ...) (Laravel Echo)
- Create a complete Oauth2 server with all the backend and frontend parts with just one configuration file. (Laravel Passport)
- Make text search with Elasticsearch using external services as easy as making a normal query to the local DB. (Laravel Scout)
- Super easy tu use payment system integration that handles both one time payments and subscriptions with Stipe and Braintree. (Laravel Cashier)
- Optimized and lightweight version of the full framework to get blazing fast APIs. (Laravel Lumen)
- Local web server that automatically creates .dev domains for each project and that works with most PHP projects (not just Laravel) (Laravel Valet)
- Vagrant box with everything you need for a local development web server. (Laravel Homestead)
- Easy frontend assets management (compiling, versioning, ...) built on top of Gulp and Webpack. (Laravel Elixir)
- Provision a web server with all the things you need (security, git push-to-deploy, ssl certificates, queue workers, ...) properly set up with one simple click. (Laravel Forge^)
- Zero downtime deployment with history backup and much more. (Laravel Envoyer^)
- Fully working SaaS app that handles all the boring stuff (subscriptions, invoicing, team management, emails, ...) and let you concentrate on the actually product you want to built. (Laravel Spark^)
- Tons of video tutorials/screencasts/lessons on how to use every aspect of Laravel and much more (PHP, Vuejs, Text editors, ...) (Laracasts)
As you can see from the list, almost everything is related to the incredibly good framework Laravel, that I highly recommend to anyone that is working or will work with PHP.
I especially recommend to all those people that are about to create their next SaaS project to take a look at Laravel Spark. It really puts all the pieces of the puzzle together and it makes your MVP really around the corner instead of months away.
Coming from old-school PHP where I hacked everything together, after learning and switching to Laravel my life as a developer completely changed and now I can't imagine that I'm still using the same language actually.
They feel like two completely different things and in my opinion all those people that are talking bad about PHP, they are stuck with old memories of how PHP used to be. Yes, PHP as a language still has a lot of things that needs improving, but PHP as ecosystem of libraries and frameworks is definitely still the king of the web!
The King is dead, long live the King! :)
[^]: These are commercial products but their price is definitely accessible (99$ for Spark and 10$/month for Forge and Envoyer)
You mentioned Laravel 20 times. You might want to slow down on that kool-aid. And I know you're not affiliated with them because I see this behavior all around the place, especially with unseasoned developers.
> What I think most people are missing about PHP is the incredible ecosystem that emerged in the recent years (especially with Laravel)
I would replace that last bit with: "especially with Symfony and Laravel". And composer, and all the changes made in 7.x, and lots of libraries that people build on top of it and made all of this it possible.
This is a good talk (Symfony's "creator") about the PHP ecosystem:
That thing was parroted a thousand times already and it really boils down to a personal rant about tons of legacy features rather than a properly worded criticism of the language itself.
The author is also really confused about type coercion in PHP.
It's a useful reminder that how ever far PHP has come, it still has a long way to go. Most of what's in that post still applies today, though a few things have been dealt with.
There was a time I thought Toyotas were beautiful cars and American cars were crap. Then some years later I had two occasions to rent a car. The first time I got a Toyota. Absolute crap. The transmission couldn't stay in the same gear with even slight inclines. The next time I rented a Chevy Malibu. An absolute dream. Loved that car. I learned a lesson to not let my prejudices prevent me from taking another look.
PHP was the first programming language I ever used, so it holds a special place in my heart. And I use it daily at my current job.
I have to disagree with this article. PHP is a heavily flawed language. It's very easy to get started with PHP, but there are too many pitfalls that are too easy to fall into.
Most of the "Virtues of PHP" are available in other web languages if you use the right framework. And if you use those languages you'll benefit from the consistency and predictability that come from having a clear design philosophy from the start.
I don't think PHP is a bad language. It's possible to write good software in PHP, and it's possible to work around the flaws if you really know what you're doing. If your software is already written in PHP, it's probably not worth it to throw it out and rebuild it in something else. But I don't think it's worth the trouble if you have a choice, and I think writing new software in PHP should be avoided.
I'll admit I'm not familiar with HHVM and Hack. Maybe they alleviate PHP's problems.
P.S. Most of the points under "The Case Against PHP" are also issues with Javascript. But the difference is that if you're developing a web application, you have to use Javascript. You don't have to use PHP.
Zero startup time and a serious JIT aren't actually available in Python or Ruby even after all these years.
I would be hesitant to dismiss the significance of those - although I'm admittedly biased, having worked with Keith previously as well as on an erstwhile "competitor" to HHVM (talariatech.com).
My pretty heavy Django app takes about half a second for Gunicorn to boot 6 workers then it's off to the races. That might as well be zero startup time.
Similarly many of the node apps I've worked with have about a half second or less of startup (unless pre-warming database connections, that takes more time).
I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much.
If you're programming in PHP, you're not running around talking about "convention over configuration" giving talks, or trying to make your code beautiful. It's a garbage language, and you know it. But it allows you to get something up and running, so dang quick. You're failing while the other guy is still updating his gem file. You're advertising while the other guy is trying out some fancy new deploy script. You're incorporating feedback while the other guy is just starting to get to work. When he finally fails, he's used up half his runway, whereas you, the guy who didn't give a fuck about your code has gotten past that first failure, and are finally getting some traction.
Hopefully, the next guy to join the company will clean up your shit. The other guys code may not look like shit, but it doesn't solve any useful problems... so they never got the chance to hire that next guy.