Taking PHP Seriously
slack.engineering
slack.engineering
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.
I do care about my code though. I think you can write niceish code, even with a shitty language.
"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."
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 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.
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.
That said, all environments will be one of three:
1 Have warts. 2 Not be used. 3 Be in denial and claim to be perfect.
The GP had a point, perfection is the enemy of good. Something delivered is better than nothing.
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 )
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.
I'm overwhelmed by how rich of a statement that is.
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.
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.
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?
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.
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.
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.
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.
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.
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).
[1]: http://laravel-recipes.com/recipes/60/optimizing-the-framewo...
- 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.
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 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.
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.
If PHP gets you to first base (MVP) in 10% of the time than NiceLangX then you get 10 X more chances to throw shit at the wall and see what sticks.
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.
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.
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)
Not sure whether this is your real opinion or you are just making fun of people who say that.
http://php.net/manual/en/function.usort.php
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.
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..
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.
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:
- Dependency management - Composer and it's centralised library, Packagist (npm/rubygems/maven analogue)
- 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).
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?
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 ;-)
Java: keyboard wear
Scala: not enough programmers
Python: not bad
Ruby: too slow
Haskell: math grad required
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.
Would'nt the good ones logically move to a different language ( JS/Ruby etc ) where they could bill more?
Haskell doesn't support OOP if I remember correctly. And it is complicated too.
That said, it is true that Rust has tricky parts. The domain is inherently complex.
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.
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>
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.
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".
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.
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?
>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.
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.
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.
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.
"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.
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".)
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?
You can go to any Ruby meetup and you will see it's different than PHP meetup which both are quite different from Functional Programming meetups.
Thus I would say that it's not about the technology but about people whom you attract (i.e. culture).
I skip luck & timing, these are mostly random and one has very little power to influence them.
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.
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)
- 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
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.
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.
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.
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.
That was a pretty common truism 10 years ago, but machines haven't gotten faster at the same rate lately.
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.
Again PHP (the language) vs. Rails (the framework).
What framework was that `big php app` using?
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.
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.
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.
i was clarifying the compassion.
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.
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.
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.
This only proves Drupal is slow.
http://php.net/manual/en/intro.opcache.php
https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
You need a lot more than a "Sieve of Eratosthenes" code snippet to back that up :-)
Eh, any PHP developer worth their salt is implementing PHP-FPM. The days of forking expensive Apache processes have long been over.
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?)
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.
https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
"Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!" ;-)
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
But I think, what's important to note is that PHP 7 has improved in speed department by a great deal.
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)
No, the fastest Java program shown does not use java.util.regex
The fastest Java program shown uses com.basistech.tclre
> a C package and performs a lot faster <
You're welcome to contribute a Java program that uses the PCRE library --
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.
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.
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.
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
ArrayList<Integer> s = new ArrayList<Integer>();
ArrayList<Integer> s = new ArrayList<Integer>(8192);
java -Xms1G PrimeNumbersBenchmarkApp
user+sys = 6.9s
http://www.famzah.net/download/langs-performance/java-discus...
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?"
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.
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.
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.
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.)
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.
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.
That's not a reason to use horses instead.
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.
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.
Horses for courses.
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.
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.)
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.
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)
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?
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.
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.
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.
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.
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 :)
I'm not going to make any customers happy working on a product if I hate the codebase and the language I'm working in so much I just DGAF.
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).
Bad code isn't Technical Debt, it's an unhedged Call Option http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...
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.
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.
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.
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.
As of PHP7... it actually is quicker than other languages in it's domain.
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.
See an older counter-point with the much slower PHP 5.5:
https://philsturgeon.uk/php/2013/11/12/benchmarking-codswall...
If you consider Wordpress a success then yes PHP is successful. The thing is, a CMS isn't an interesting project to work on.
Theres a lot of raise ArgumentError.new unless foo.kind_of? Bar
Going on in my code these days.
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.
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.
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.
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();
bill -> charlie (or NewPerson.prototype) -> Person.prototype -> ... -> Object.prototype
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() 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()
Brush up on your Python skills before talking rubbish.
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.
It should be interesting to see if I can actually abuse Python's meta-programming enough to make it work :-)
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();
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).
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;
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.
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).
And I am not only person who needs classes in JS: https://github.com/search?l=JavaScript&q=class&type=Reposito...
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
No, I am ok with mutable values.
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.
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) { .. }
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 });
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
...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.
No. This code causes an error in PHP:
$name = 'John';
echo $nmea; // error
class A { public $name; }
$a = new A;
echo $a->nmea; // error
var a = { name: 'John'; };
doSomething(a.nmea); // no error
$a = notice_there_are_no_quotes;
echo $a; // $a gets assigned the string 'notice_there_are_not_quotes'
$b = MY_CONSTANTT;
echo $b; // $b is now the string 'MY_CONSTANTT' instead of whatever the correct MY_CONSTANT was set to.
let a = new A();
a.setName('John');
doSomething(a.getNmea()); // Error
$a = new A();
$a->setName('John');
doSomething($a->getNmea()); // Also errorThat 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.
PHP4 introduced objects and is the language people shit on when they say PHP doesn't have real OOP
PHP5 introduced Java-like objects PHP5.3 introduced namespaces
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.
You should try "use strict" sometime. If you write sloppy JS, you'll find out in no time.
Javascript will still have most of its warts, mind you. But some of the most obvious errors should at least be catchable.
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
console.log([] * {})
Type casting in PHP gets fixed gradually: https://wiki.php.net/rfc/invalid_strings_in_arithmetic .
[] + {}
{} + []
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.
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.
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
If you think it's not then there's something else going on you're not addressing...
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.
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
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.
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.
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.
Is that a good idea?
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.
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 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.
<%@ WebHandler Language="C#" Class="Handler" %>
using System;
using System.Web;
public class Handler : IHttpHandler {
public void ProcessRequest (HttpContext context) {versus just
<?php
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.
> They just don't care.
> It's a garbage language.
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.
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.)
Painful to read. I've struggled with this my whole career.
Reminds me of Alistair Cockburn's seminal essay about methodologies.
Characterizing people as non-linear, first-order components in software development
Money quote:
"Problem 1. The people on the projects were not interested in learning our system.
Problem 2. They were successfully able to ignore us, and were still delivering software, anyway."
I'm going to frame these words and hang them on my desk.
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.
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.
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.
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.
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.
So what's the catch?
Any recommended places to start with?
Which should be near 0 if you can be bothered to enable OPcache in php.ini. Not only parsing/disk reading but also bytecode generation are bypassed.
In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality
The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"
Not to mention, all the other languages out there memcached just as well.
apc_fetch/apc_store hardly seems painful.
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.
> 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.
Disclosure, I worked at GD in Website Builder when this was being developed, but haven't been there for over 2 years now.
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.
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.
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.
that's not true. especially not in the DaaS space.
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.
A rewrite I worked on, from PHP to C++, had an improvement of 20 times better performance.
That's only one (1) order of magnitude.
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.
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 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.
(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).
import cgi
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).
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.
For the conversion to bytecode, that is what apc is for.
Which isn't what PHP does, fwiw.
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.
It’s really interesting, last time I worked with PHP was a few years ago, then recently I wrote something in PHP 7, and it is a lot safer.
(But still no compile time type checking because there is no compile time).
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.
Define "very". Because for me it's more like "a few hundred microseconds per request".
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.
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.
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.
[1] https://www.infoq.com/presentations/Simple-Made-Easy [2] http://web.archive.org/web/20160709054130/http://c2.com/cgi/...
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).
Not that I feel cgi is the most efficient way to handle requests... but not needing the complexity of GC could be one advantage of that approach...
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.
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.
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.
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).
See: http://reactphp.org http://www.photon-project.com https://gnugat.github.io/2016/04/13/super-speed-sf-react-php...
Even the idea of an alternative runtime for PHP (ala HHVM) is nothing new: http://quercus.caucho.com
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.
Burning cpu and maybe i/o looking for code all over the place is going to make it really hard to make it fast later.
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.
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.
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.
Or that, you know. There is an extremely powerful language feature and the developers are taking advantage of it.
So? If it takes < 1ms, what's the harm? And opcode cache comes out of the box and most PHP DB drivers can use connection pooling.
We serve most of our requests in < 10ms, and we're not even on PHP7 yet.
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.
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.
Here is an example in C: https://www.cs.tut.fi/~jkorpela/forms/cgic.html
Php was born out of trying to reduce a lot of that cruft and blending code and html output easily. And that's what initially made it a winner.
Actually I have never seen that this was a problem in practice with the application server model. I therefore don't think this is a relevant argument.
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).
> 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.
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.
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.
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.
def __call__(self, request):
client_ip = request.META['REMOTE_ADDR']
self.last_visitors.append(client_ip)
...
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.
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.
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.
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.
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, ...).
The catch are couple.
First Concurrency is _hard_ and relying on the OS scheduler would have been really har don ressource until recently, which is why nearly noone did it.
That used ot be a wart of php, only hidden by Moore's Law and recent work on OS schedulers.
But yeah. Erlang do this since the 80s
Isn't there a downside to that? If you want to do multi-threading, you can't just do `ThreadPool.StartNew(() => doSomething())`. You're SOL.
So this process-per-request thing is not exclusively a Php thing.
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.
[1] https://git.zx2c4.com/cgit/about/
P.S. An important thing that contributes to the success of PHP is the amount of hosting services that support it.
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 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.
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.
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.
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.
The Wordpress codebase [plugin api included], though, is utter garbage.
[1] http://www.phpsadness.com/
[2] http://php.net/manual/en/language.expressions.php
[3] https://www.mail-archive.com/internals@lists.php.net/msg7196... (yes, i asked for this in 2014)
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.
Yes, yes it is. That's not the language's fault.
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.
Also it's not a bug, more like a design oversight that doesn't cause any problem if you rtfm
unfortunately, that's PHP's mantra for unexpected/inconsistent behavior (of which there is a plethora)
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.
Do you support that? No one will ever be able to convince me that "<<" and ">>" make sense to be read and write.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
</rant>
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.
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.
> Varnish, memcache, php-fpm, redis, what-have-you are basically mandatory
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.
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 was right it was: https://www.infoq.com/presentations/php-history but the author is the same person.
It is a good speech and I've been developing in php for years, written a blog post (http://sucky.ninja/leaving-php-is-too-expensive/) about it but I do no longer use php for my backends.
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.
I would not go back, even if it is cheaper.
Even if php has it´s nice things it is still not that great of a language.
So if other languages are just as easy to deploy, what does PHP bring to the table?
"PHP is garbage language!", "PHP is a shitty language!"
That is the antiquated view of course. The old days.
Now with Laravel and PHP7 it is a pleasure to use.
I'd go further.
Working in Laravel is BETTER than ROR IMHO.
rails + unicorn/passenger v/s apache + mod_php.
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.
Clean slate, my eye.
They're cattle not pets. (/semi-sarcastic)
Also, most folks serve PHP applications in production under PHP-FPM/FastCGI.
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!
I wish I had learned this few year ago.
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.
Does anyone have a good example of an open-source PHP project that will enlighten me?
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.
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?
[1] https://www.amazon.com/Concepts-Techniques-Models-Computer-P...
You:
<!-- api.php -->
{
<?php
mysql_connect("host", "pass"); mysql_select_db("users");
$uid = $_GET[ "uid" ];
$res = mysql_query( "select * from users where uid = $uid" );
$ar = mysql_fetch_assoc( $res );
echo "name: " . $ar["name"] . ","; echo "location: " . $ar["location"];
?>
}
<!-- end of api.php -->
Just call it http://domain.com/api.php?uid=USER_ID
( 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
If it was an intentional joke in the grandparent post's code, then it's not one that came across well.
- 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?
- Output is not valid JSON
It doesn't contain only PHP. There's the closing JSON } after ?> :D
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.
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.
If you were speaking generally about programming then obviously don't learn PHP.
But that's not the context of this thread.
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
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.
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)!
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.
And the subcycles are literally "Change -> [run test | send test request]".
> 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 3 allows you to do that, too: https://docs.python.org/3/library/typing.html
Javascript has Typescript and Flow, both of which are very popular and allow you to gradually transition.
this is certainly what got me started with PHP and what makes its so easy for beginners
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.
But currently I only care about a fast MVP.
PHP, Ruby and Python here are at a disadvantage. JSON is JavaScript's home turf.
$data['key']['value'][0] is a lot messier than data.key.value[0]. Ruby has ways of mitigating this, but you pay a performance penalty.
but you'll probably spend a few hours stuck with npm the first inevitable time a package doesn't work as expected
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.
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.
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.
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.
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!
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.
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.
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.
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.
Surely, it works.. but that's about it.
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.
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.
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'
https://code.visualstudio.com/Docs/languages/php#customizati...
[0] https://www.infoq.com/presentations/php-history [1] https://news.ycombinator.com/item?id=7054294
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.
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".
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.
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.
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.
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?
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!
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.
- 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.
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.
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.
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 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.
Dealing with the parts that aren't Hackified, though, is horrific. Complex codebases with no types are just ridiculous.
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>;
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.
[0]https://docs.hhvm.com/hack/XHP/introduction
[1]https://coderwall.com/p/3leegq/getting-stuck-in-with-xhp
[2]https://docs.hhvm.com/hack/other-features/autoloading
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].
[3]https://docs.hhvm.com/hack/generics/introduction
[4]https://docs.hhvm.com/hack/types/type-system
[5]https://docs.hhvm.com/hack/type-aliases/introduction
[6]https://docs.hhvm.com/hack/collections/introduction
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.
[7]https://docs.hhvm.com/hack/async/introduction
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.
[8]https://stackoverflow.com/questions/38111369/using-hhvm-and-...
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.
It looks like generics aren't yet in the core language (https://wiki.php.net/rfc/generics), but I believe return type hints work. I think we're also still missing property/field type hints (https://wiki.php.net/rfc/property_type_hints).
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.
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.
Python now has type hints that allow a similar migration for existing code.
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.
when i hear people say stuff like this, I assume they are a rookie dev. Have passed on many interview candidates for it.
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.
That's not mentioned in the blog why they didn't use PHP for this.
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.
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.
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.
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.
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.
What goes around comes around. I'm editing my LinkedIn and dusting off the old O'Reillys...
Never again.
Life's too short to waste on that junk.
Running a 2 year old framework on the Internet because the new versions include a non functional opcode cache kinda sucks.
Back when I was a green web programmer, I loved this feature. After working with Python for a good many years, I now abhor it.
> I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive.
Would you not use file watchers to reload the server? (especially in Node?)
I would bet a donut that Slack is off PHP within 2 years.
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)
> 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:
dotScale 2014 - Fabien Potencier - My Take on PHP https://www.youtube.com/watch?v=gpNbmEnRLBU
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 been almost 5 years. Let it go.
Use this:
www.phpsadness.com
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.
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.