>the first question that comes up is what to use instead, and they’re met with a barrage of difficult choices and wildly different opinions and recommendations.
The real answer is "it doesn't matter". Of course python people will try to convince you to use python, and ruby people will try to convince you to use ruby. But both groups will agree that either language is far better than PHP. And as someone who likes neither of those languages, I would agree with both of them, just pick one. There's no "wrong choice" to worry about.
Very much this. The comparison he tried to draw with Linux distros, same deal. Who cares? Try one. You're a hacker, go grab a language and hack some code. No, you won't be as good with Python when you start as you may currently be with PHP, big deal.
A weekend project is the PERFECT time to learn a new language/framework. Sure the weekend may become 2-6 weekends, who cares?
If I am not mistaken, Twitter and Reddit have both changed very large parts of their codebase from one language to another, so I don't really know if I buy that argument either.
Finally, I think programming languages should work for the guy writing the program. I made a point of learning everything I could (and continue to do so) about every language I come across. So when I need to do something, I have 6-7 toolboxes at my disposal, as opposed to 1 or 2. I write in 5-6 different languages every day at my current job, and have become a very valuable employee because of this.
This is coming from someone who has only the most basic experience with PHP, take it with a grain of salt.
The choice does matter. A lot. When I started with ruby, I had to decide between 1.8, or 1.9, or jruby, or several other choices. Then I had to pick sinatra or rails or merb or whatever. mongrel or passenger or thin or unicorn. It didn't really seem like the choice would matter, but then you run into some tiny annoyance, do a bit of research and find out that some other framework doesn't have that problem. So you switch, only to find a new problem. This goes on for a little while until you realize that you could write the whole damn thing from the ground up in lua.
The time spent just researching whether it's a bug in my code or their code starts to eclipse the total project time if done in another language.
If it's early in the life of a project and you don't have much experience with the framework, tiny annoyances are a warning sign. If the easy things don't work the way I like, what happens when I try to do something hard? The cost of switching is low.
I used merb for all of about 10 minutes before giving up on it. I fooled around, created a couple very basic crud pages, and it worked for a bit, then I got nothing but error pages. root cause: I had created a new class called 'fish'. That opened my eyes to the fact that were was so much automagic fairy dust sprinkled about, if anything serious ever went wrong I would never figure it out.
You have to choose between all the same kind of stuff with PHP too. The position was "I'm using PHP, and I can't switch to another language because I am afraid I'll pick the wrong one". That position is silly, because anything you pick is guaranteed to be better than PHP. There's no "wrong" between python and ruby, they are for all intents and purposes the same.
As for your specific case, writing your own framework in lua doesn't make ruby a wrong choice. You could have written your own framework in ruby too. Or perl, or python, or even one of those dreaded compiled languages.
x3 - it's far simpler to learn due to consistency, more powerful to do both low & high level programming and a pleasure to work with. Just as simple to setup for web as php. Not real reason to be in knee deep php mess.
That's simply not true. I love Python (I'm using Flask for projects at this moment), but saying that setting up a python web service is as easy as php is disingenuous.
As easy as PHP in what sense? That Python is basically part of all OS' now or as easy as putting in <?php echo "Hello World"; ?> in a .php file and uploading it to your server?
I severely doubt it's as easy as the latter. I'd like to see an article that explains in less than 140 chars how to deploy a simple app as Hello World to the web in Python without the use of a framework like Django or Flask.
Edit:
In the amount of chars Twitter accepts, here's how to get Hello World going in PHP.
This just made me laugh. It reminded me of http://projecteuler.net/ where you are feeling proud because your solution works and then you realize it can be done in one line of one line of Haskel/Python/Perl/Ruby =).
Who cares? Honestly? I'm shocked and appalled that the measure of ease of a web development language is the trivialness of a Hello World. This willy-nilly nature of PHP leads to the disaster that it is today. The language and API are, at every turn, willy nilly. The projects that use them are constantly rewriting and refactoring to follow a new or better pattern or organization.
I haven't touched python in too many months to write it here, but it's not much harder than importing an http package, creating a two line handler and listening for connections. Now you have a much more realistic and robust system and your potential for applications is already hugely increased. (Write a websocket server in php, go on).
Here, I can write "Hello World" in an even easier language!
Your example of simplicity is a bit conflated since you don't even need PHP to put hello world on a internet visible web page in the first place:
echo 'hello world' > /var/www/index.html
Set up something a little more useful albeit trite such as a blog and you wouldn't be able to do that in 10 minutes with PHP without using a framework either. PHP is great for "unit testing" of ideas but once it grows out of that it's debateable
I do concur that deploying a Python or Ruby web app is a pain in the ass. Installing git and installing Heroku, you're only 2 lines of code away though.
OK, so here we have someone who knows PHP but not Git. Knowing PHP, probably they're a web developer and have also learned the standard stack there: HTML, CSS, Javascript, MySQL, and Subversion. And with the way the HTML5 family of technologies is exploding nowadays, that's no small feat.
You're saying that learning Git is going to be the barrier to someone switching to Ruby? Naw, don't think so.
We're making different assumptions. You're assuming a well-rounded web developer that just wants to deploy, while I'm thinking more from the beginner developer perspective. We're both right with our assumptions applied.
Wait, that didn't work. I got all kinds of errors and warnings. I must have the wrong version of something. You win, point taken.
There should be an easier way. I should be able to just run "apt-get install rails-easy" and have a system that is completely configured for development.
It's not exactly mind-shattering stuff, but it's nice to have some common terms to describe the properties programming languages have that make them the kinds of products they are.
I'll sound like a broken record, but I'm convinced Flask is the perfect transition.
It's built for smaller web apps, and rapid prototyping. The system of mapping endpoints to functions is incredibly intuitive -- if you've used Python before, learning Flask is incredibly easy.
Bottle is very cool, but Flask has far more plug-ins ("extensions") than Bottle does. Flask has nearly all the features that Django does, only they are in the form of dozens of separate extensions. In my opinion, this is a good thing. It's easier to understand the framework when you start with the basics and learn more as you add on extensions.
I believe that Flask will move to Python 3 eventually, but at the moment I agree with the decision of Flask's creator (Armin Ronacher) to stick with Python 2.7. In the end, Python 2.7 is probably better for someone new to the language. There's more documentation, and it's still the default Python on most systems(although a few are starting to pre-bundle Python 3).
I just did a comparison of bottle and flask for my job. My recommendation: go with flask. Flask has a bigger community, more built-in functionality, some really cool tools (the debugging functionality is far better than bottle), and is essentially the same as bottle in all other respects that matter.
As far as python 3 support is concerned: this is a minor annoyance, but it will probably be rectified by the time python 3 is relevant in production environments.
The problem is, not all PHP apps are small rapid prototypes. If I'm going to migrate away from PHP, might as well go all in. Does that mean something like Django?
Most people recommend Django over Flask for larger projects. Personally, I've used Flask in bigger applications as well, and its a trade off -- Django saves you time with its app system, bundled ORM and MVC architecture, and the omnipotent admin interface, so you spend very little time reinventing the wheel. On the other hand, my raw speed of development is better with Flask (and I prefer Flask's debugging tools as well).
That being said, for a 'big' project I'd recommend Django over Flask, if for no other reason than googleability -- if you run into a particular error or question, Django's community (due to size) is probably going to be more helpful than Flask's.
What I meant was that it lends itself well to small apps because the lack of code/architectural overhead, as opposed to Django, where coding small apps often feels like only furnishing one room in a five-bedroom house.
Django is good for getting small, simple apps up and running quickly. It all gets overly complex very quickly when you need anything more than that. For a big app, it's better to start with something small that can grow to meet your needs rather than starting with something big that you'll have to fight to do what you need to do.
Interesting! I've never thought about it that way -- whenever I work with Django on a smaller scale I feel like I spend more time tweaking the framework itself rather than the actual app.
Yep, I mean, I think Django is generally a better solution for the average website, as there are many site-related problems that the Django team have had many years to solve, as opposed to you re-solving them with Flask in a few months, however, then you have to learn Python and you have to learn Django.
With Flask, you just have to learn Python, as Flask is so mindfuckingly simple.
I've been having a similar problem with the added difficulty* that I don't do development as my full-time job (yet) and have been coding mostly for developer contests and hackathons.
So when I start something that has a deadline in 24 hours or just a few days, I can either fall back to PHP to get something going fast or spend most of my time just learning a new language. So, I have been typically going with PHP…
I've found that the important thing is to take the time to set yourself up with the minimum environment that can get something, anything going in a different language: that means whatever is needed to print something on a page and get some logic working with GET and POST parameters. Because the nice thing with PHP is that it's so easy to write a single file that displays text on a page, or that responds to POST and GET parameters with some logic behind it. If I started with Ruby for example, I wouldn't know how to do this basic thing. (granted, with Rails and Heroku, this is easy)
My plan is to make Python my generalist programming language and I started to look at Flask (http://flask.pocoo.org/) for that reason: it's a mini-framework that doesn't take long to learn how to do these simple things. I can then play with it for simple things.
*though it can make things easier since I can just work on whatever I want in whatever language I want :)
The importance of mod_php, it's robustness, stability and speed is completely underappreciated. It's not just the language with all it's quirks that people should be focusing on. The php stack is easier to use and configure than any of the other language/framework stacks making the time to publish faster.
Passenger (mod_rack/mod_rails) looks like an attempt to imitate that stack to some degree but so far the results are far from perfect.
robustness and stability would both be properties of the language interpreter (mod_php, cgi, fastcgi...)
mod_php is stable enough for what it is... robustness is arguable... mod_php might not scale but it's a key component in php's popularity because it's a zero configuration plugin for apache that works perfectly for the needs of 90% of people writing php or running php applications.
I guess I still am lost as to what frame of reference people are discussing here. What real host [1] doesn't let you run WSGI processes, or arbitrary processes? What happens if you need to make TCP connections, or run a websocket server?
[1] This does not include Dreamhost, Bluehost or any of the other oversold shared hosting (please, feel free to search G+ and see complaint after complaint about them, especially recently).
I guess I don't see any "real" sites being deployed in environments where only PHP is available. A random script that you want to let someone else use for a few minutes, sure, upload that to randomphphost.com, but a real life public webapp??
If you take the time to learn it, deploying C#, python, ruby apps can be insanely easy. And to be my usual self, deploying Golang apps are beyond insanely simple. (I cross compile from my Mac to my Linux 64bit target, upload and run `sudo ./server -host=:80` and I'm deployed).
Well that's the thing... most of the PHP popularity is for the sites that get installed on Dreamhost etc.
I've deployed C# apps; I did .NET exclusively for about 8 years. It's great! But telling Joe's Washer Warehouse that they have to pay for the .NET stack, and that they can't just find a random PHP guy to do any further development is kind of tough pill to swallow.
Yes, PHP sites are usually the lowest common denominator, but on the other hand there are lots of people that are only willing to pay for that. There's a reason the PHP market is as big as it is. Thankfully for those of us in PHP-land there are starting to be lots of quality frameworks like Drupal and Symfony so that it's not such a horrible experience as it used to be.
And the other part is really the market. You want a large CMS-driven website? PHP is where it's at. That's where the code and communities are. There's a reason that lots of very large websites use Drupal. Sure, if I was going to try and make some sort of big-backend web app that did a lot of services and whatever, I'd want to do .NET. But as a freelance web developer, those projects just aren't there. Like it or not, I'm in PHP land.
(And RoR used to be a total nightmare to deploy. That whole community needs to send a collective giant cardboard check to the mod_passenger guy.)
Most people don't start writing Real Sites hosted at a Real Host. They start with a stupid little static home page as a hobby hosted for free by their ISP or a $2-3 a month hosting provider. Then they want to add just one dynamic feature (maybe include a header and footer for each page), and they're obviously not going to learn Python and work out what the hell a WSGI is and get a new, probably more expensive, hosting provider just for that, so they use PHP, because it's trivial and already included. Then they need another slightly larger, feature. Fortunately there exists an Open Source php project providing just that feature, so they drop it in and it kind of just works.
A few more features get added in this way over the next few month and years and all of a sudden the sites popularity explodes. Now they have a whole bunch of stuff to deal with, and rewriting the entire site in some other language they know nothing about is not on the top of their priority list.
I don't disagree that Python/Go/C#/Ruby represents a bigger upfront learning and potentially cost investment. I think it pays off in functionality, development speed and flexibility in the long run is all.
Its benefits are vastly outweighed by its negatives for me. I've made things in PHP before but if I ever do it again, it will be too soon. Sounds like a nasty addiction.
That's one of the problems with the now-famous Fractal blog, I think: It was a joy to read in the sense that being a Python programmer, it only heightened my appreciation of the achievement that languages like Python and Ruby represent. It's what conscious, determined design gets you and what mistakes they managed to avoid.
But it's preaching to the choir. If you've never seen anything other than PHP, you won't understand two thirds of the list or why they're problems. (<- Not looking down on PHP coders there, rather I'm thinking back to when I started out on PHP and am speculating on how I would have received the document.)
How do we communicate effectively what makes other languages better to someone with no reference frame other than PHP itself?
Most PHP developers don't start their first programming project from scratch using PHP to write their first web app. It's far more common to start because you are running a blog on WordPress and you want to make some small change. Then you make another and another, then you're writing plugins and suddenly you're a programmer and PHP is your language.
So to encourage developers to start with something other than PHP you'll need to lower the barrier to entry to modifying existing software, and also make something as popular and widely useful as WordPress and MediaWiki.
I did a lot of PHP over the years, trying to migrate over to a Python web stack.
A big hurdle is ops dev. All hosting services support PHP out of the box.
Now I'm faced with the "distro choice". Which server do I use (lighthttpd / nginx / tornado)? Which framework (django / flask / web2py / cherrypy / pylons / pyramid)?
Like the original author, I've had a VPS sitting unused for 2 months paralyzed by choices. I eventually decided on nginx / flask, but haven't had the time to set it up. Maybe I should have just used Heroku. shrugs
The same choices exist for PHP, although you may not be aware of them. PHP runs on all the servers you mentioned, and there are many, many frameworks in PHP (although admittedly not quite as many as in Python).
Just choose one and learn it. They're all excellent web servers. I'd recommend going with Flask or Django in the beginning, simply because they have the best documentation. web2py also has pretty good documentation. The only problem with Django and web2py is that they are monolithic. If you don't like their ORM, or templating engine, or authentication/authorization, it's generally hard or impossible to switch, and if you do switch you lose all the benefits of the integrated system. With Flask and Bottle, on the other hand, you are free to pick and choose components. I think the same modular design approach is used by Pylons and Pyramid, but I'm not sure since I've never used them. But as you learn more, there's a lot to be said for being able to switch out components of your framework, or even writing your own in a pinch.
> If you've never seen anything other than PHP, you won't understand two thirds of the list or why they're problems.
Two thirds of that list are actually incorrect.
But I programmed in Java, C++, C, VB, and so on before I started coding in PHP many years ago. So many years ago, in fact, that PHP was easily the best choice.
The problem with lists like that is they obscure the truth -- and that is -- that solving a programming problem in modern PHP isn't really that different from solving it in Python and Ruby. It's just not that much of a leap.
That rebuttal is fantastic. I never actually got through the entire "fractal" article - having read your rebuttal just now I can say I'm glad I didn't waste my time, thanks :)
> How do we communicate effectively what makes other languages better to someone with no reference frame other than PHP itself?
You're trying to convince yourself that you made the right choice, the right investment.
That's sad.
Have confidence in yourself. You made the right choice for yourself and let others choose for themselves.
There is no universal proper language or platform to use.
PHP works and it works extremely well for many companies. Its commercial success is not debatable.
Python on the other hand ... aside from Google, who's using it at a massive scale? Even Google has been shifting to Java for a long time.
See how that works?
Let's stick to the old parable. A proper tool for every job. If you're convinced that there is no proper application for PHP, then you're not even trying to be objective ... you're just trying to make yourself feel better about the choices you made.
> You're trying to convince yourself that you made the right choice, the right investment.
> That's sad.
Err, huh? What's with the preachy tone and the presumptuos attitude there? No, I don't need to convince myself, nor am I looking for confirmation - I know that I'm happier coding in Python than I was coding in PHP, that I get more done in less time, that I've vastly increased the average reusability of code that I write, and that it blows up less in production.
> Have confidence in yourself. You made the right choice for yourself and let others choose for themselves.
That's not what this is about. It's about how I didn't make a conscious choice to use PHP back then - nor would I have if I had been in a position to make a choice. I believe the same is true for many others, so how do we get to a point where they have the facts to make a choice?
> Python on the other hand ... aside from Google, who's using it at a massive scale? Even Google has been shifting to Java for a long time.
Shrug. It's you who's playing up the PHP vs. Python angle here, really -- for me there's plenty of stuff out there that's better than PHP, not just Python.
> If you're convinced that there is no proper application for PHP, then you're not even trying to be objective ... you're just trying to make yourself feel better about the choices you made.
Actually I think there are circumstances where PHP is the right choice, though it's mostly a matter of market considerations, certainly not technical strength.
> Actually I think there are circumstances where PHP is the right choice, though it's mostly a matter of market considerations, certainly not technical strength.
I think technical strength is valued differently in this community than in the web development community at large. I've had a lot of commercial success with PHP and never found a serious problem caused by "a lack of technical strength".
Surely certain languages have created a vision of technical strength that is appealing to programmers who think mostly about programming as the challenge in itself, rather than a tool for the market challenge.
However to people that think mostly about solving market problems, such as entrepreneurs, PHP is known for many attributes that are high value and perhaps have little to do with what you might consider technical strength.
I've programmed in C, C++, PHP, Python, Perl, Java, Javascript, Prolog and probably could program in any general purpose language out there given some training and enough motivation. I still "don't understand two thirds of the list or why they're problems". I.e. not that I can't literally understand what the complaint is about - I can't understand why it's anything special to PHP and why it's a PHP problem as opposed to agressive exaggerated "don't make me actually learn anything that contradicts my preconceived notions" stance. PHP has its own quirks, so has any other language out there. I do not see a big deal about it.
The idea that disagreement is because person disagreeing is not educated enough and only if he could learn The Next Best Thing he'd immediately become a fanboy like you are - is deeply fallacious. I've seen your Next Big Thing. It's nice. So are other hundred Big Things. They are all nice, and all have its place. And no, I'm still not a fanboy, sorry. I still think Python is a nice language for its uses, and PHP is a nice language for its uses. Banality, but somehow so many people can't grasp how can it be. Please believe me, it can.
Disclaimer: I'm a Rails programmer for work and hobby.
Interested in learning something that isn't PHP to code your web applications in? Ok. You have a ton of options and this is a very exciting time to be a web developer.
Do you want to lean towards stability and proven concepts and work within a full application structure? Look at Django and Rails.
Do you want to serve up responses from a simple script without a lot of extra pieces? Look at Sinatra and Flask.
Do you want to get in on the cutting edge and don't mind forging some of the path yourself? Look at Node.js and Meteor.
Got a high level decision made? Sweet. Now compare the primary languages between your choices (forget the framework for now). After a few minutes looking at each, which reads better to you? Feel free to go on gut instinct here: there are no wrong choices.
You've now made a choice for your next learning target. Now: don't spend years. Don't worry about knowing everything about the framework and the language. Google for "X tutorial" and follow the first link that looks reasonable and current. Do that tutorial. Now you have some bearings within the framework and have some idea of how it thinks.
Now. Pick something you want to build (a todo list is popular now, it used to be a blog or a wiki). Build it. You will make mistakes. You will be confused. Google for answers (if you're in Node.js or Meteor you will have trouble here) or hack until you get something working.
Throw what you built up on github and ask others to check it out. Build something else. Repeat.
If you are already a decent programmer with a good grasp of the web and how HTTP works: you will pick up any of these frameworks well enough to work in it in a month or so. In six months you'll be well advanced: especially if there are good books available for the framework/language you are working in.
Actually, the GP was talking about running on your own server. Ruby, Python, Java, PHP, they're all close enough in terms of setup time that it need not factor into the decision. Or you can run any of them on dotCloud, EC2, Rackspace, lots of places. Deployability just isn't a differentiator nowadays.
No, it isn't—but if you knew how to deploy any of that, you probably wouldn't consider PHP.
90% of people just run a web site on a hosting server. Granted it's getting less and less common with the advent of the centralized service-based web, but still, that's the source of success.
Is PHP really more memory efficient than the competition? I know it scores better on the computer benchmark game but the non-existent concurrency support and general leakyness of most the extensions (unless they've fixed that these days?) seems like the difference could actually be a lot narrower in practice.
The advantage it has is that you can run a ton of hosted sites on one mod_php apache server. With Rails, for example, you have to run an environment. Same with many Python apps, or Java, etc.
So it has the memory advantage of being able to run multiple sites on one environment.
Not that big a deal if you're doing any serious deployment, but a big deal for its ubiquitous nature.
I wonder if the better course of action would be to lobby the major hosting providers to include Ruby and/or Python with their base plans. Really, isn't that one thing that keeps PHP chugging along? In the consulting work I've done, my clients already have hosting plans for their website, so if I'm adding a sub-app, or even a new app, trying to convince them (and their IT staff) to manage multiple hosts/plans/etc is off the table.
I think the problem is that the virtual hosting model doesn't work well for platforms where every site is a running app instance. Who starts the processes? How do you restart them when the code changes (some platforms don't do this)? Who assigns port numbers? etc etc etc.. With PHP, whose execution model was kind of built with this in mind, this works out of the box very easily.
That's the thing right? With PHP you need a server or you can't do anything. With Django, Sinatra, Rails, Flask, (Node?, Meteor?) you have all that for development as part of the application.
To deploy you just push to a free heroku instance and you are fine until you get big. Much, much easier than setting up your own Apache+PHP. And much, much cheaper than buying hosting.
So many people point to Heroku as the comparator to the wide availability of PHP.
Unfortunately Heroku is down right now. The wide-availability of choice, it's ubiquity, is why many PHP sites are still running right now - they are not reliant on a single point of failure.
There are many thousands of hosts, spread across the world, offering Cpanel accounts so I'm not tied down to the meteorological events in North Virginia.
If an act of God happens in Michigan right now, I can switch my site very quickly from there to a freshly minted Cpanel accout in California (thanks regular Cpanel backups!), or London or Manchester (Possibly not Newcastle right now, though). I'm really spoilt for choice here.
What are the alternatives to Heroku that don't have the same failing that are running right now that are comparable in getting an app up and running equivalent to PHP time?
> Interested in learning something that isn't PHP to code your web applications in?
That's the problem. I'm in the same boat as Marco with pretty much the same reasoning. I'm not interesting in learning something -- I'm interesting in starting and completing my next project as quickly, cheaply, and well designed as possible. I'm willing to accept that, all things being equal, a better design is possible in Python or Ruby. But for that to be true, I need to know Python or Ruby. I need to know the framework I'm working on.
I can certainly put the time into learning, the time into heading down the wrong path in both design and technology for a project (and that will happen), perhaps rewrite a few times. But with only so many hours in the day (less than I really need), it's not much of an option.
I have a lot of sympathy for that. But the end of that road is the 50-year-old programmer looking forward to spending the next 15 years doing mind-numbing maintenance on vital but terrible corporate code while hoping they don't get laid off. That's what happened to a lot of COBOL programmers, for example.
Software development is a Red Queen field [1]. If you don't take the time to keep up, you will eventually get left behind.
+1, this is fantastic advice. I found that when I stopped reading about languages and instead just opened tutorial and _tried_ them my learning rate improved drastically. Pick a tutorial and go.
Ah, but that's the whole joy of it! Although I have a large enterprise-type code base in Visual Basic/Access Basic, I am still trying to nudge my next project into Python because I love learning new things!
Same with my distro - I am currently using Mint, but that may change, when my next boot hard drive fails.
Even with VBA, where I had done much of the work using DAO (started in 2005 with what I already knew) I am now trying to make the next changes using ADODB. The benefit being it will be easier to shift the back end to MySQL (or any other ODBC-compliant flavor) and have more then one language used in different front ends.
Ah, the learning! My joy in life.... And these days, thankfully little tuition required.
I know it's difficult to compare or find an observer who could adequately judge between the two, but I wonder if Ruby made Jekyll easier to write and maintain? Of course, there's not any easy way to make that judgment without knowing how much effort Marco put into Second Crack versus what was put into Jekyll.
Tumblr, Wordpress, Facebook, Instapaper, Wikipedia... PHP has a stronghold, an opensource equivalent implementation for each platform would take forever
Yeah, I wrote Tumblr in PHP, but I'm eager to abandon it. You know, it's just an easy to use, broken language that you can scale a site to 15 billion page views per month with. I'm sure my next project will need a better language, because it's going to scale to 400 billion page views per month, and PHP just isn't going to cut it.
Hilarious suggestions contained throughout his post.
I was actually pleasantly surprised by not reading about the usual "webscale" BS in these two articles. Both authors made it very clear that this is not about being able or unable to build something with a given language, but the quality of how you do it.
Smarty is the default choice, but of course you can simply require("tmpl/$LANG/index.php") - PHP's short tags like <?=$name;?> are almost as simple as Handlebar's.
Since PHP is a template language at heart, they go ahead and use PHP. For PHP folk, I guess the question is: how do people handle templating simply in other languages, since they can't use the host language itself for that?
EDIT: Disclaimer: I'm a PHP guy trying to make a break for it, and the question was both rethorical and tongue-in-cheek.
In Python, I've always used string substitution. I've never understood the need for a special templating system when it's already built into the language:
template = """<boilerplate html>%(greeting)s</boilerplate html>"""
parts = {'greeting': "Hello, World!"}
page = template % parts
I create my site-wide template in a module and never have to look at it again, so my application code is mostly logic. When I have to work on PHP or Coldfusion, I don't understand how people can bear to have the logic hidden in a markup language that's mixed up with another markup language. Many can't, and that's why there are templating engines for what are essentially template-based languages.
Smarty, dwoo, moustache, some frameworks have their own engine (codeigniter for one). It's pretty much the same as other languages unless you're still one of the people who embed piles of php code in the templates.
Hey Marco,
Thank you for writing this . This is exactly the situation I am in right now. I love this post because it does not look down on PHP programmers, it beautifully illustrates the situation we find ourselves in . PHP is quick easy , and convenient . We are so comfortable in our current state that we don't want to adapt to a better alternative .
You have built successful and high profile applications in PHP, thus invalidating the argument that PHP is useless .
There may be better alternatives , but we must step out of our comfort zone to embrace them .
This post helped me understand the situation so much better. It does not insult or degrade PHP programmers for their language choice , but it gently suggests that better alternatives exist ,and it is worth the short term pain to explore them .
Thanks again , Marco. You've given me a lot to think about .
The reason you describe your relationship with PHP as an "addiction" instead of using a word that described a more healthy relationship is probably because there is something about it that doesn't resonate well with your core values. At least that's the problem that I had with it.
If you want a nice introduction into the world of developing web apps with Python, I suggest you read the Flask user manual (see http://flask.pocoo.org/docs/). It not only covers the basics of the framework, but also seems to assume that you're a first-time Python user as well. It covers topics such as using virtualenv and pip to setup your environment which I found very helpful when getting started with the language.
Here is another point that highlights the problem:
If I want to write a hello world application in PHP, it's neither as long as <?php print("hello world");?> nor as short as <?="hello world"?>
Rather it's simply: hello world. Just type in those 11 characters in a text file and save it as hello.php. Now load it on your browser [or run it from command line] and it will print hello world. I don't think it can get any more simpler than that in other languages. PHP was developed from the ground up as a templateting language for serving HTML pages. These other languages are more of a general type.
Therefore the replacement for PHP should come through a new language targeted as a replacement for PHP as Jeff said. Otherwise there always be extra web/template stacks for the developers to take care of. And that will be the first hurdle to learn and overcome for novice developers looking for switching to something easier.
Are you seriously basing a whole argument on what the hello world program looks like? That has nothing to do with actual real world programs. Mixing logic & presentation might make it easier to get something running quickly, but it's one of the downsides of PHP that these things get mixed up when they probably shouldn't for a project of reasonable size. The whole idea that it's an advantage of PHP that you can get something up and running so quickly is wrongheaded. Actually, it's much better if it requires some amount of thought and planning to code something up because that increases the likelihood that you'll do it right the first time and build on a solid foundation.
> Actually, it's much better if it requires some amount of thought and planning to code something up because that increases the likelihood that you'll do it right the first time and build on a solid foundation.
This is solid advice for an engineer. And absolutely moronic for a businessman.
Choosing what platform to use is a business decision.
If you take too long to get it right, you will never get the chance to make a dime off of your work.
We are all working on limited time frames. It is far better to throw something together that works and rewrite later, when you're actually making money.
PHP is amazing at letting you write something fast and rewrite it into something more manageable later.
> PHP is amazing at letting you write something fast and rewrite it into something more manageable later.
From experience, the mountain of technical debt organizations acquire when starting with PHP can make it near impossible to rewrite it into something more manageable later, and it's a false dichotomy to claim PHP lets you write something fast while the alternatives do not.
That's true only if your audience is well-educated engineers with plenty of experience under their belts working on projects with substantial backing.
Unfortunately, nobody starts out well-educated and experienced. And many projects start out small and grow. If you want to make your platform a broad success, you need to have a good experience for noobs and quickies. PHP is an abomination as languages go, but it's massively successful because any idiot can quickly get something basic up.
What people continue to fail to explain is why PHP needs to be replaced.
Why not improve it? After the millions of man hours that have gone into the plethora of open source PHP based frameworks and tools (aka, what powers the internet) - wouldn't we as a community want to improve the foundations rather then scrap them entirely?
All languages (like any system) will have cruft, after a while. Is the solution really to do a periodic break with backwards compatibility for purity reasons, Python 3 style?
There should be a better way?!
What about a low level machine like Java/.Net and just let the next language evolve on top of that -- so old libraries could run? (Maybe there could be Xcompilers for Ruby/Perl 6/xxx to the Perl "bytecode", to take advantage of CPAN?)
Why should I bother following your demands? If you've ignored a million blog posts that clearly explain it, you'll ignore me as well. And if you don't have enough experience of better programming languages that the warts are obvious, then what I could have to say would make no sense to you. To you it would be just the way things are - even though they aren't that way for other developers in other languages.
I'm not convinced this is true. You see, way back in the day in 1997 when I was doing web dev, everything worked the way PHP does. ColdFusion, ASP (not ASP.net, ASP), PHP, and almost everything else that was seriously trying to do web pages worked that way. It took the community collectively a long time to stop seeing URLs as identifying anything but specific files. This is back when having those files be programs was still a bit of an innovation.
After 15 years of one of the biggest bursts of innovation the open source world has ever seen, and with such diversity in frameworks that the mind boggles, nobody has returned to this model successfully. I've got MVC-inspired designs coming out my ears, continuation-based designs, frameworks just beginning to incorporate web sockets deeply (instead of as an afterthought), GWT, ASP.net, and other attempts at building a fundamentally different model and compiling it into another, and everything under the sun... but no return to the page-is-program model.
I don't think it's the key to PHP's success, because even in the competitive-yet-very-fertile soil of the web framework world, nobody else can make it work anymore. I think it's vestigial, and nothing else.
(Personally I think the key is simply that everybody has deployed it, and since there's basically no way to force every web hosting company to support Language X simultaneously, PHP isn't going away until the entire concept of web hosting goes away. Which isn't anytime soon.)
The page-is-program model still works as well as ever. It's just that, if your problem is so simple that the page-is-program pattern is most appropriate -- for example, if you are eight years old and you want to build a page that serves up a different picture of a dinosaur every time it gets reloaded -- you should just use PHP. Why choose anything else?
It's true that other languages have not wasted a lot of time trying to displace PHP as the language of choice for anonymous random dinosaur servers. That's because there's no money in fighting PHP on its home turf. The turf just isn't worth enough.
"Vestigial" is the wrong word. That's like describing a screwdriver as "vestigial" because the impact driver has been invented. Sure, impact drivers can accomplish many things that mere screwdrivers cannot, but that doesn't mean that screwdrivers aren't still useful, and numerous, and popular.
Vestigial is the right word; a characteristic of a surviving species that isn't particularly relevant to the question of why they survive. While debate goes back and forth between the various potentially-vestigial organs we may possess, it seems clear that if the appendix contributes anything to humanity's survival, it isn't very much. Also, vestigial tends to imply it isn't actively harmful, which I don't think it is because PHP certainly works just fine with other models as well. (If it were only page-as-program, I'd have another opinion... but it would probably also not be doing anywhere near as well on very large sites and we probably wouldn't still be talking about it as anything but a historical language.)
You may disagree that my characterization is correct, but it is certainly the characterization I intended to convey. That's why I parenthetically commented that I think the real reason it has carried on is another one, to contrast the relevant characteristics to the irrelevant ones. Creating a new "PHP-killer" and focusing too much on the vestigial features of PHP is a recipe for failure.
Ease of install is part of the same pattern. PHP has always been easy (with connections to a free database), and got easier with good package management systems. What's coldfusion like for ease of install, ease of install with database access?
ASP for Windows was huge. It was even easier to get started on than PHP because you just needed to install IIS from a EXE and you could reference access files. The only reason it's not still massive is that MS moved on.
I think the argument being made here is not that page-is-program model is superior; it's that it's much easier to understand for newbies coming into the field.
It is not that support is completely non-existant. Ruby, for instance, can be executed in a PHP-like fashion using ERB.
$ echo 'hello world' | erb
hello world
$ echo 'hello world' | php
hello world
If a new user could throw index.erb up on a server and have it execute in a Ruby context, would we be any further to supporting better development practices? Will the user take that experience and move into a framework like Rails later? If yes, what has stopped them from using the similar PHP frameworks that will already take them away from the comfort of the single page template?
If you truly only need a single page template without any further abstraction, then why not use PHP? It seems all of the complaints about PHP stem from using it in big projects. It is hard to argue that it does a single page template very well for when that is all you need. Right tool for the job and all that.
I don't understand why someone does not just fork PHP and create something that's syntactically similar but fixes a lot of the problems people complain about.
PHP is an incredibly complex project which is being actively developed [1] and improved. If there were very simple ways to update PHP that were universally agreed upon, they probably would be added (Like short array syntax, built-in HTTP server or many other new features added in PHP 5.4). It just isn't a syntax issue, there are underlying principles about the way features are considered in PHP that are just different from other "similar" scripting languages like Python or Ruby.
If somebody had profound disagreements with the way PHP was being developed, they would be much better off switching or contributing to another language then they would be trying to re-invent PHP.
"...next language choice was clear: Python, which seems to fit my style better than Ruby"
Just out of curiosity, why would someone believe this? The syntax of python and ruby are nearly identical, but ruby has more tools and support for web-based projects. For someone looking to develop for the web, ruby is pretty clearly a better choice. And this is not knocking python at all, I really enjoy them both and there are many other things python has more community support for - don't get me wrong.
To support what I'm saying about the syntax, check out this comparison: http://hyperpolyglot.org/scripting - they are super similar, if anything ruby is a tiiiny bit more elegant.
Having done substantive work in both, the most significant difference that for me favours Python is that every module explicitly imports the names that are accessible within its namespace (barring use of 'from X import *' which is generally discouraged). In comparison I found it a real pain to track down definitions of specific names in a complex chain of 'require'd Ruby code.
For someone looking to develop for the web, ruby is pretty clearly a better choice.
For someone looking to troll while looking smart and insightful, this comment is pretty clearly a better choice. Python has a ton of web tools and lots of companies build web services in Python. Ruby is simply another choice, not a better or worse one.
Ruby and Python are nearly identical in syntax and basic functionality. But I like Python's community and philosophy better.
If you agree there is a difference, then for some set of people, those differences will be the determining factor.
Also, while fairly comparing the amount of "web stuff" that Ruby and Python have would be an effectively impossible task, the simple truth is that both ecosystems are abundantly full of stuff, to the point that which has "more" doesn't matter. You're not going to miss out on anything by going with Python, unless you drill down to a hyper-specific particular package you may need which only exists on one.
Just by looking at a syntax table, the higher-level differences are not going to be enumerated.
Just off the top of my head:
- Ruby was always designed as an OO language, whereas Python OO was bolted on later. Ruby's object system is almost a straight transplant from Smalltalk and is very powerful.
- Python lambdas can only be one liners. Ruby lambdas can be arbitrarily long. Guido doesn't really like FP - there's no tail recursion, either.
- Ruby's metaprogramming capabilities are a bit more powerful (haven't really looked at Python in this regard, so don't quote me).
- In fact, there are some pretty big syntax differences. Python requires brackets even for the print statement now, whereas Ruby lets you miss them out if it's unambiguous. Ruby has blocks. Python doesn't have "end\n end" sprinkled everywhere.
The main philosophical differences are that Ruby is more powerful and implicit, wheras Python is stricter and explicit. When I say "powerful", by the way, I don't necessarily mean "good", just that it exposes more functionality to the user. Although I like Ruby a lot, I accept that on large projects Ruby's power (like that of Lisp or C) can be dangerous. Python has a lot going for it.
You're right, they're still very similar in many ways. Maybe they're like Democrats or Republicans; up close, they're screamingly different, but from a distance they're almost alike.
While I find Ruby to be nice overall, you're wrong on several points:
- Whether or not Python was historically OO or not, everything in Python is now an object. Its love for protocols drives design like `str(foo)` (which calls `foo.__str__()`), not any particular deficiency in its object system
- Python's lambdas are indeed limited, but one can easily use `def` and just name the function. Functions are first class, after all
- Metaprogramming facilities are very similar in power. Neither language has macros.
- Python tends insist on not duplicating things (i.e. both indentation and braces/end) and on not being ambiguous. There is another reason Python can't omit braces for function calls: without braces, they are references to the function. As a consequence, Python doesn't need things like .call()
Overall, I haven't seen one language or the other to be more powerful.
Personally, I find that Python and Ruby are comparable as it relates to utility. I'd think it is fair to say that argument is a wash. It is Ruby's expressiveness that makes it my choice before Python:
Of course, this is one example where PHP (5.4+) at least somewhat resembles Python. I think that is why some of the more experienced PHP developers tend to choose to go with Python as their PHP recovery language.
Personally, I prefer "letters.map" (Ruby) over "map(...)" and "array_map(...)"; however, that is a personal style preference and has nothing to do with technical merit. And I still enjoy writing Python here and there. PHP is also still a necessity much of the time.
That being said, there are a few edge cases that I've witnessed where Python actually reads better than Ruby; though, these cases are few.
"Whichever language I choose to replace PHP will have its own problems that will take me years to master, but by the time I know whether I chose the “right” language, I’ll have invested far too much time in it to practically switch any meaningfully sized project to another language: exactly the situation I’m in now with PHP."
Something that I'm not seeing people take into account generally when they decide to develop in a "new" language or complain about any established language additionally is how far along that new language is and how many people know it well. Choosing the best thing also involves how easy it is to get the help of others. An analogy might be an automobile purchase. If you are located in the middle of nowhere it might be a better idea to buy the Honda where there are multiple local dealers rather than the NewGreatAuto (pick any car with less market share that is better price and feature wise) where you have to travel 50 miles each way for warranty service.
I went through this with hardware back in the 90's choosing SGI servers that were better price and performance wise than Sun, only to find that many open source software ready to run was not available for SGI. And that there were less people that knew IRIX than Solaris.
I've had a similar issue and have even come up with some suggestions myself[1], but really I think there is only one company in the right place to produce a serious PHP competitor. Facebook.
They have the man-power required to displace it, as well as the serious need... although the only potential solution they have come up with HipHop / HPHPi is really lacking in community support. Its open source but rather undocumented, and took an entire day to get set up.
If they could produce a viable alternative to PHP... something that fixes the clear fuckups but doesn't try to fix everything I think it would have a real shot.
The only thing actually wrong with PHP, is that it's popular but not cool. And that's a terrible place to sit for any product.
It runs half the Internet quite well, but if you went by the posting on HN, you'd think it was Windows Vista.
I've probably read every article critical of PHP that has hit the front page of HN in the last few years, and the one thing they all have in common is the vague refrain that PHP is a broken language. And yet the gap between tangible proof of that being the case in real world use and the gossip of it supposedly being true, couldn't be wider.
> The only thing actually wrong with PHP, is that it's popular but not cool.
Hey now, we're all human. Even engineers. As soon as something becomes popular, it is no longer cool. Cool is the next popular. Cool is being different. That's just how things work.
Apache is slooooow (NGINX is cool!). MySQL is retarded (Postgres is cool!). PHP sucks (Python is cool!). Red Hat is lame (Ubuntu is cool!).
See a trend? The tech that sucks is the most popular and well established. The tech that's cool isn't popular. It has nothing to do with any objective qualities of platforms. It's all about being a part of the cool croud!
Remind you of high school much?
Now, if this is just a hobby, who gives a shit? Roll with the cool kids. If you're starting a business, be aware that the future welfare of your family is relying on your decisions. Think real hard about that.
I was a bit doubtful, so I looked it up... turns out you're only somewhat right: CentOS + RHEL are about 40% together (28.7% + 11.6% = 40.3), but Debian + Ubuntu are over 50% at (30.8% + 19.8% = 50.6). Arguably Debian is not Ubuntu (which is why I say you're somewhat right), but it is just what Ubuntu sysadmins grow up to, and has even more of a cool underground factor, despite being the most popular server distro. Of course RHEL and CentOS are the same thing as well.
I have heard that there is a geographical difference where Redhat is more popular in North America while Debian is more popular in Europe. No idea if it is true though.
Just because a technology is "cool" doesn't mean that you're acting like a high schooler for using it. Nor does using non-"cool" technology make you an adult.
I'm assuming you don't have any arguments left because you're needling me on my wikipedia link rather than addressing anything I actually said. If that's the case, you're really not adding anything constructive to this conversation.
> Now, if this is just a hobby, who gives a shit? Roll with the cool kids. If you're starting a business, be aware that the future welfare of your family is relying on your decisions. Think real hard about that.
Truer words have never been spoken. When you think about it that way, these types of arguments about why language X rocks/sucks become trivial and unimportant.
I like to geek out over languages and technologies as much as the next guy, but there needs to come a time when you put your foot down and make a decision based on more important reasons than personal preference/feelings towards a language.
> It has nothing to do with any objective qualities of platforms.
The problem is, it often does take into account objective qualities.
The downsides of popular platforms are often ignored because they carry with them all the advantages of popularity: good support, a well-established community, a wealth of experienced people you can hire or draw upon.
These are not "objective qualities" of the technology, but real side-effects of popularity. In fact, you could say it's a technology's popularity that fools you into ignoring many of the objective qualities of the platform.
I think part of tech hipsterism (which, let's face it, is what you're talking about) is a rejection of this groupthink, and a return to true technological thinking. It's the ability to say "we don't care what's popular, we're just going to look at what works again and see where we end up." I think this very idea is considered 'cool' in the tech world because we tend to like people who think logically about their problems and don't just blindly follow what people have already done. We like people who look at lesser-used technologies (which all of the "cool" tech you listed above actually are) just on their technical merits alone. This is, perhaps, one reason they're considered cool; because it takes actual thought to break away from simply using what everyone else has used for years.
So I think you have noticed a definite trend, but I don't believe it's as purely social as you imply.
That said, "be aware that the future welfare of your family is relying on your decisions" is an argument that's used in so much Enterprise software that it's almost scary. Often the most popular, most entrenched, least risky, biggest company with the largest pockets wins because the CTO can't be blamed for fucking up that decision. It's an incredible driver of technological stagnation in the Enterprise world. It is great to think through your decisions to their far-reaching impact, but be thankful that all of technology is not driven by that kind of strictness, or we'd never use anything new.
There's a delicate balance between healthy skepticism that comes from experience, and enthusiasm for trying new things.
Going with cool new things for everything is very risky. This is terrible for established businesses, it's great for startups with no legacy and no pressure to maintain inertia. There cultural differences are endemic to the realities of both types of businesses and aren't just the product of politics.
I'd like to extend your claim to Redhat as well. I won't make the comparison directly to Ubuntu, but I will compare it to Debian. And in the realm of server-oriented tasks, Debian is hands-down a better option, from the point of view of a sysadmin.
I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.
It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).
For example,
* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...
* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?
* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".
* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...
* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.
* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.
That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.
Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.
Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.
> * How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
For historical accuracy, the HTTP server binary of the Apache project has been called 'httpd', compiles to 'httpd' in the source official distributions and is distributed as 'httpd' in the binary official distributions for ages, if not since day one.
I don't know enough about MySQL vs Postgres or RedHat vs Ubuntu to make a point with them, but sometimes it's not about being cool.
Apache is a webserver from 1995. It uses a process (sometimes a thread) per request, a architectural decision which made it nearly fundamentally incapable of solving the C10K problem. Only back in January was the Event MPM added (and it's still experimental), allowing you to have many Keep-Alive connections open at once without degrading performance. Nginx was started in 2004, and is event-based allowing for much higher concurrency. (Yes, I'm hand waving.)
PHP is among the worst languages most sane programmers have ever used. The referenced article, "A Fractal of Bad Design" is a pretty good starting point if you want more details on why it sucks. PHP stands for letting amateurs code effectively. Python is designed with an emphasis on readability, and manages to have a rational type system and a fairly regular standard library.
Apache vs Nginx is about learning from the mistakes of your ancestors. Apache was designed with the 90s in mind, and our technology has moved on to the point where the decisions made in its architecture simply don't work anymore.
PHP vs Python is about being a rational, non-masochistic, human being.
To say what is cool "has nothing to do with any objective qualities of the [technologies involved]" is to know nothing about programming as a business.
I hear this a lot. I think people assume that because lots of amateurs use PHP, it must be helping them be effective. This is not a safe assumption. A shoe does not help amateurs drive nails effectively, no matter how many amateurs you see using one.
You wrote a well thought out response. I owe you a response in kind.
People have a tendency to overrate their rational capacity to reason out a viable decision. While you listed a few solid critiques, the situation is infinitely more complex.
And by infinitely, I do mean exactly that. As in, beyond your capacity to reason it out.
In the end, the only right decision is a decision which withstands the test of time. Both Apache and PHP have done that and continue to do so.
Apache holds 65.5% of the market [1]. PHP holds 77.9% of the market [2].
Those solutions are working, right now, for all of those people. That's reality, not grand "rational, non-masochistic" theories.
Now that we're finished with that, I'm going to enjoy myself.
> a architectural decision which made it nearly fundamentally incapable of solving the C10K problem.
C10K is not a problem and never was. The limiting factor in the overwhelming majority of deployments is the pipe. Apache can saturate the pipe just as well as NGINX. You will saturate the pipe long before you reach 10K connections. Which is why people continue to use Apache. Being technologically superior is pointless when there are no real-world benefits to that technological superiority.
On top of that, Apache's thread model provides it with greater stability. If a worker thread crashes for whatever reason, another will simply spin up. If your NGINX process dies, you'll need to wait until your monitoring solution brings it back up. Which could be a long time.
> PHP is among the worst languages most sane programmers have ever used.
Worse than COBOL? Yes, yes, a fractal of bad design! Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.
> Python is designed with an emphasis on readability
Was that humor? Python shoves its version of readability down your throat and laughs as you choke on it. Not all of us get off on syntactically significant white-space. In fact, most of us don't. Which explains why Python is so unpopular. But I get, I get it. It's cool.
The first half of your post is basically a long-winded appeal to popularity. Yes, most people on the web use PHP and Apache. Most people on the web also need nothing more than a WordPress installation and their online needs are met. Does that mean WordPress is the best tool out there? You should stop confusing popularity with quality, because the two rarely overlap.
> C10K is not a problem and never was.
Somebody better tell the developers of nginx, Lighttpd, Tornado, node.js, Cherokee, Apache Deft, IIS, and Jetty! All those hours wasted developing solutions to a problem that doesn't exist.
> Which is why people continue to use Apache.
For someone who just decried a situation "infinitely more complex" a few line breaks ago, you sure did generalize the reason millions of servers use a certain piece of software. It couldn't be because Apache has an easier installation on most of the common distros or that cPanel/WHM, the most-used virtual hosting control panel, only supports Apache as its web server. It also couldn't be because of mod_php.
This all stems from your conflation of popularity with quality. PHP did not become popular because it was good. It became popular because it was easy to learn and run.
> Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.
Most of his criticisms were completely valid, so I'm not sure where you're getting the author doesn't have much experience in PHP. Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?
Not even close. The author trolled through a bunch of other misinformed articles, copied some them verbatim mistakes and all. He doesn't know PHP and didn't research anything.
> Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?
In regard to his "objects compare higher..." point, I think he was referring to this:
class MyClass {}
class YourClass {}
$myclass = new MyClass();
$yourclass = new YourClass();
var_dump($myclass > $yourclass); // false
var_dump($myclass < $yourclass); // false?
In regard to his "there's no pass-by-object identity..." point, there's no way to do this:
class MyClass {}
$myclass = MyClass;
$anotherclass = $myclass();
I really don't have the energy to refute the rest, but most of them are relatively subjective. (I say relatively because most of them promote better programming, but their absence doesn't directly harm)
> In regard to his "objects compare higher..." point, I think he was referring to this:
That all comparisons between objects, except equals and strict equals, return false doesn't seem terribly unreasonable.
> In regard to his "there's no pass-by-object identity..." point, there's no way to do this:
class MyClass {}
$myclass = new ReflectionClass('MyClass');
$anotherclass = $myclass;
$instance = $anotherclass->newInstance();
$myclass = 'MyClass';
$instance = new $myclass();
> I really don't have the energy to refute the rest, but most of them are relatively subjective.
I think you'll be hard pressed to find too much fault with my criticisms of that article. The author doesn't even know common language terms like private/public/protected. And clearly he's never even seen C++.
It should throw an error, not return false. This goes back to PHP's "try as hard as possible to run the script" mentality.
The author doesn't need to know C++ to comment on PHP's failings, does he? And he knows private/public/protected— you even quote him using them. You're probably not familiar with Python, but there aren't any private methods (aside from double underscored-prefixed methods, but that's not entirely the same). That's where he was coming from. It's not that he doesn't know those terms; it's that he thinks that's how they should work.
Judging by your other responses, you're quick to toss out whether someone is a "PHP programmer" or not, as if that has any bearing on their argument. I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.
>The first half of your post is basically a long-winded appeal to popularity.
No it's not. We're not talking about music --how popular Bieber is vs Bach, for example. So he didnt just say "tons of people use PHP", he said "tons of people use PHP and it solves their problems giving results".
This is not an "argument by popularity", its an argument by number of empirical verifications. Which is supposedly what engineering and science is all about.
On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results. "That's (eg python) is how a language should be, and not like php" etc. All the while forgetting to take no account practical, verified, php benefits.
>Yes, most people on the web use PHP and Apache. Most people on the web also need nothing more than a WordPress installation and their online needs are met. Does that mean WordPress is the best tool out there?
OIf it meets their needs and has them happy, of course! Anything else would be dellusional to say.
> So he didnt just say "tons of people use PHP", he said "tons of people use PHP and it solves their problems giving results".
The original discussion was about whether PHP was a good language. He came in and said, "It is because look at all the people who use it! Obviously it's fine!" That's an appeal to popularity.
> On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results.
What results? We're not talking about Mom & Pop's Homepage, here. Posting about how most sites run on PHP doesn't help us when we're not talking about most sites. We're talking about building apps.
Reading through your responses, I'm curious about how much experience you actually have in our industry. Most of what you claim is easily falsifiable.
The idea that C10K doesn't matter is definitively untrue. I've worked with numerous large systems (games, content) where Apache was the problem, and swapping it out was the solution to making maximal use of the hardware and the (gigE+) pipes.
Even outside of saturation, there are large-scale systems that benefit from being able to park an open socket and provide asynchronous notifications over that socket (in web terms, think websockets). If you're paying for a thread or process for every socket, this becomes prohibitively expensive very quickly.
It's also not an unusual use case outside of traditional web development, and now with websockets, this kind of architecture is likely to see considerably more use. This approach provides numerous advantages to legacy polling approaches, but does not work on traditional short-lived connection software architectures.
In addition to the above, your discussion of robustness really has no bearing on Apache's architectural suitability in production use-cases.
Auto-restart functionality exists for other architectures, and in addition to that, it's standard practice to deploy multiple servers with automatic failover behind a load balancer -- in addition to the server process itself, the OS can crash, disk drives can fail, power supplies can blow, etc.
Additionally, you shouldn't have production processes crashing regularly, and shouldn't be making significantly performance-impacting architectural choices on the basis of Apache's ability to restart a child process. Software crashes in production are a worst-case failure, akin to a drive failing, and should never be so common as to justify Apache's performance costs/constraints.
All languages are annoying if you go by the griping, the more popular a language is the more amplified the griping. It scales out of actual proportion to the flaws, and instead scales based on the popularity. Then throw in the wide spread use, the trendy nature of people, and you have a recipe for endless bashing. The better PHP serves the bottom 95% of developers, the more the top 5% will hate on it.
Common sense. Calculate how much traffic Wikipedia + Facebook + Wordpress + All The Rest generate. Calculate in the fact that most services talk to other services and more importantly, talk to Facebook.
No matter how you try to hide from it, it's blatantly clear that PHP runs at least half the entire Web.
What else exactly did you think was? Surely you didn't think Python was running half the web. Obviously Ruby isn't. So what does that leave? Coldfusion? C?
You don't agree with the notion that many tech products like web languages (or browsers, operating systems / mobile platforms, or whatever) tend to trend heavily toward a single dominant product (either due to one simply being better, and or a benefit derived from scale of use such as plugins or knowledge availability etc etc)?
>And yet the gap between tangible proof of that being the case in real world use and the gossip of it supposedly being true, couldn't be wider.
Just because something is shitty to use doesn't mean you can't do productive work in it. We're all just poking Turing machines here. Let's not even talk about the enormous weight of sunk cost fallacies.
> The only thing actually wrong with PHP, is that it's popular but not cool.
No, what's "wrong" with PHP is that other things that are better have come along since. That's not a fault of PHP, that's the nature of language evolution.
> It runs half the Internet quite well
COBOL runs tons of mission critical business services quite well. It doesn't mean that nobody's improved on COBOL or that you should use it for a new project today.
> No, what's "wrong" with PHP is that other things that are better have come along since.
The problem is, no, nothing else has. Node.js is awesome and fun, but far harder to set up for basic webpage serving. Python is awesome, but also has a huge learning curve to learn how to serve basic webpages with. And... I can't think of anything else. Perl? ASP? Java is a huge pain to set up and maintain.
What other language out there is better than PHP for getting simple webpages up and running quickly? I wish there were one, but when you consider practical aspects instead of just theoretical ones, there really isn't. Sadly.
Myself and an army of other ex-PHP developers disagree.
> What other language out there is better than PHP for getting simple webpages up and running quickly?
This discussion is not just about "getting simple webpages up and running quickly". In fact, it's pretty clear people are talking about developing web applications, and not slapping together a quick and dirty page or two.
If you want to have a discussion about what language is best for inexperienced people to whip up a simple site without having to bother learning much, that's fine, but that's not this discussion. At the very least, that's certainly not what Marco was talking about, nor Jeff in the blog post Marco was responding to.
> But when I wanted to write Second Crack, I went right back — it was a quick little project that I only wanted to spend a couple of days on, so it didn’t justify the overhead of learning a new language.
Whether it's webpages or web apps, nothing else is better than PHP for getting something small up and running quickly. That's the whole point of why Marco feels "addicted". I really wish there were something better in this context, but there isn't.
(And what do you mean, "ex-PHP developer"?? I've never heard someone call themselves an "ex-C" developer or an "ex-Java" developer. You make PHP sound like a cult or religion, instead of just a popular programming tool.)
Don't take it personally, but I've seen a lot of confirmation bias from ex-PHP developers.
Often from developers who may, thanks to language Y, write more elegant code on the line / function level, but still create the same architectural mess as they did before in PHP. (Rails doesn't save you from creating a mess, neither does the broad separation of concerns of any MVC framework.).
There are thousands of ex-PHP developers out there that think they are now better programmers because they now use Ruby or Python, building thousands projects that proof otherwise.
Five to ten years from now, people will be bitching on HN about legacy RoR software like there's no tomorrow. And they'll probably be blaming the language and/or the framework.
If whats around 5-10 years from now represents the same improvement RoR has made over PHP in the last 5 years, we better be mad when developers working on team projects try to perpetuate RoR's use.
> Don't take it personally, but I've seen a lot of confirmation bias from ex-PHP developers.
> Often from developers who may, thanks to language Y, write more elegant code on the line / function level, but still create the same architectural mess as they did before in PHP.
That's a longer-winded version of "You Can Write FORTRAN in Any Language". Certainly nothing exclusive or even particularly unique to PHP or PHP programmers.
There is no shortage of people complaining about RoR today. [1][2]
Also, does the word "ghetto" ring any bells?
Not that I think Python solves all the problems well either. I'm a fan of Lua, personally, but only because it's a much cleaner language design, and it's faster, and it's easier to set up, and it's easier to write Node.js-style code that's easier to read, and... well, I guess there are a few reasons.
>The problem is, no, nothing else has. Node.js is awesome and fun, but far harder to set up for basic webpage serving. Python is awesome, but also has a huge learning curve to learn how to serve basic webpages with. And... I can't think of anything else. Perl? ASP? Java is a huge pain to set up and maintain.
The crazy thing is that all of that could change with a simple project that does <?coffee > (or whatever) style templating while automatically offering access to CGI data and cookies at a scope reasonably close to the global one. This should take days to implement, and when I have a few of those to spare, I plan to tackle it.
What I'd like to do is make a project specifically for CoffeeScript (and maybe also JavaScript) which would run with minimal configuration under several CommonJS supporting environments like v8cgi and Node. The conversion from <?coffee ?> templating is extremely simple, and beyond that, it's simply a matter of pasting on some boiler plate to set up global variables. I honestly think that the reason it hasn't been done is that it is so easy to implement that people feel it must not be worthwhile.
There is some truth to this. However, if you define a "better language" as one which is more consistent and predictable and less buggy, that implies less time to master.
One thing I love about Ruby is how many methods suggest one another. For example, Enumerable collections, like arrays, have an `any?` method. It takes a test function and returns true if any of the items pass that test.
[1, 2, 3, 4, 5].any? {|i| i > 4 } # true
Ok, you just learned `any?`. Now, you can replace `any?` in the above with
1) `all?` - do all elements pass?
2) `one?` - does exactly one pass?
3) `none?` - do none pass?
If you can remember one of those, chances are you can remember others. And if not, `myarray.methods` will remind you.
That same array has a `max` method and a `min`, a `max_by` and a `min_by`. It has a `select` to get all matching items and a `reject` to get all non-matching items. Knowing one helps you remember another.[1]
The key is consistency. It speeds up the learning process and makes you refer to the documentation less often.
That's the advantage of choosing a good language. It reduces the very pain that the OP is worried about.
==========
[1] (But wait, there's more! Any class you create, if you define `each` and `include Enumerable`, gets all these methods for free!)
If all someone knew was PHP, maybe they would struggle to learn something else, but in my case, if I immerse myself in something and learn it and use it, it's not going to take me years to get productive with it. Especially given the limited things that PHP can do, learning to do those in python/ruby/C#/Go took... trivial amounts of time. With the benefit of more functionality and a sane API. (and in two cases, static typing)
Alternatively, if all I knew was PHP, I would understand why someone would be scared of learning something new. I mean, look up and down this thread. Everyone thinks a one-liner hello world is the pinnacle of the ultimate web dev language. Because real web frameworks require an http handler, they assume it's more work or harder. To me, it seems that many in the "PHP is easier!" crowd are too scared or lazy to take the time to learn something else and realize that better separation of concerns and tooling actually allows for faster and safer development.
319 comments
[ 0.17 ms ] story [ 433 ms ] threadThe real answer is "it doesn't matter". Of course python people will try to convince you to use python, and ruby people will try to convince you to use ruby. But both groups will agree that either language is far better than PHP. And as someone who likes neither of those languages, I would agree with both of them, just pick one. There's no "wrong choice" to worry about.
A weekend project is the PERFECT time to learn a new language/framework. Sure the weekend may become 2-6 weekends, who cares?
If I am not mistaken, Twitter and Reddit have both changed very large parts of their codebase from one language to another, so I don't really know if I buy that argument either.
Finally, I think programming languages should work for the guy writing the program. I made a point of learning everything I could (and continue to do so) about every language I come across. So when I need to do something, I have 6-7 toolboxes at my disposal, as opposed to 1 or 2. I write in 5-6 different languages every day at my current job, and have become a very valuable employee because of this.
This is coming from someone who has only the most basic experience with PHP, take it with a grain of salt.
The time spent just researching whether it's a bug in my code or their code starts to eclipse the total project time if done in another language.
If you pick a solution and run into a tiny annoyance learn to work around it in some way. It is a tiny annoyance.
Best case scenario, learn why it's happening, how you can fix it, and (in a dreamland) submit a patch that fixes this for everyone else in the future.
Worst-case scenario just find a workaround.
I used merb for all of about 10 minutes before giving up on it. I fooled around, created a couple very basic crud pages, and it worked for a bit, then I got nothing but error pages. root cause: I had created a new class called 'fish'. That opened my eyes to the fact that were was so much automagic fairy dust sprinkled about, if anything serious ever went wrong I would never figure it out.
As for your specific case, writing your own framework in lua doesn't make ruby a wrong choice. You could have written your own framework in ruby too. Or perl, or python, or even one of those dreaded compiled languages.
That's simply not true. I love Python (I'm using Flask for projects at this moment), but saying that setting up a python web service is as easy as php is disingenuous.
I severely doubt it's as easy as the latter. I'd like to see an article that explains in less than 140 chars how to deploy a simple app as Hello World to the web in Python without the use of a framework like Django or Flask.
Edit: In the amount of chars Twitter accepts, here's how to get Hello World going in PHP.
sudo apt-get install php5 && echo '<?php echo "hello world"; ?>' > /var/www/index.php
85 characters. I'm done. Now let's see this done in Python... Ruby... Any other popular language this quickly.
I haven't touched python in too many months to write it here, but it's not much harder than importing an http package, creating a two line handler and listening for connections. Now you have a much more realistic and robust system and your potential for applications is already hugely increased. (Write a websocket server in php, go on).
Here, I can write "Hello World" in an even easier language!
`cat "Hello World" > index.html`
Exactly, who cares?
echo 'hello world' > /var/www/index.html
Set up something a little more useful albeit trite such as a blog and you wouldn't be able to do that in 10 minutes with PHP without using a framework either. PHP is great for "unit testing" of ideas but once it grows out of that it's debateable
I do concur that deploying a Python or Ruby web app is a pain in the ass. Installing git and installing Heroku, you're only 2 lines of code away though.
Which requires you to learn git.
You're saying that learning Git is going to be the barrier to someone switching to Ruby? Naw, don't think so.
Wait, that didn't work. I got all kinds of errors and warnings. I must have the wrong version of something. You win, point taken.
There should be an easier way. I should be able to just run "apt-get install rails-easy" and have a system that is completely configured for development.
It's not exactly mind-shattering stuff, but it's nice to have some common terms to describe the properties programming languages have that make them the kinds of products they are.
It's built for smaller web apps, and rapid prototyping. The system of mapping endpoints to functions is incredibly intuitive -- if you've used Python before, learning Flask is incredibly easy.
I believe that Flask will move to Python 3 eventually, but at the moment I agree with the decision of Flask's creator (Armin Ronacher) to stick with Python 2.7. In the end, Python 2.7 is probably better for someone new to the language. There's more documentation, and it's still the default Python on most systems(although a few are starting to pre-bundle Python 3).
As far as python 3 support is concerned: this is a minor annoyance, but it will probably be rectified by the time python 3 is relevant in production environments.
That being said, for a 'big' project I'd recommend Django over Flask, if for no other reason than googleability -- if you run into a particular error or question, Django's community (due to size) is probably going to be more helpful than Flask's.
The idea of Flask is to build a good foundation for all applications. Everything else is up to you or extensions.
http://flask.pocoo.org/docs/design/#what-flask-is-what-flask...
There's even an entire section in the docs about scaling your application up: http://flask.pocoo.org/docs/becomingbig/#becomingbig
What I meant was that it lends itself well to small apps because the lack of code/architectural overhead, as opposed to Django, where coding small apps often feels like only furnishing one room in a five-bedroom house.
Django is good for getting small, simple apps up and running quickly. It all gets overly complex very quickly when you need anything more than that. For a big app, it's better to start with something small that can grow to meet your needs rather than starting with something big that you'll have to fight to do what you need to do.
With Flask, you just have to learn Python, as Flask is so mindfuckingly simple.
So when I start something that has a deadline in 24 hours or just a few days, I can either fall back to PHP to get something going fast or spend most of my time just learning a new language. So, I have been typically going with PHP…
I've found that the important thing is to take the time to set yourself up with the minimum environment that can get something, anything going in a different language: that means whatever is needed to print something on a page and get some logic working with GET and POST parameters. Because the nice thing with PHP is that it's so easy to write a single file that displays text on a page, or that responds to POST and GET parameters with some logic behind it. If I started with Ruby for example, I wouldn't know how to do this basic thing. (granted, with Rails and Heroku, this is easy)
My plan is to make Python my generalist programming language and I started to look at Flask (http://flask.pocoo.org/) for that reason: it's a mini-framework that doesn't take long to learn how to do these simple things. I can then play with it for simple things.
*though it can make things easier since I can just work on whatever I want in whatever language I want :)
I would love to be able to not write PHP. But the language that replaces it has to be that easy to deploy.
Passenger (mod_rack/mod_rails) looks like an attempt to imitate that stack to some degree but so far the results are far from perfect.
mod_php is stable enough for what it is... robustness is arguable... mod_php might not scale but it's a key component in php's popularity because it's a zero configuration plugin for apache that works perfectly for the needs of 90% of people writing php or running php applications.
[1] This does not include Dreamhost, Bluehost or any of the other oversold shared hosting (please, feel free to search G+ and see complaint after complaint about them, especially recently).
I guess I don't see any "real" sites being deployed in environments where only PHP is available. A random script that you want to let someone else use for a few minutes, sure, upload that to randomphphost.com, but a real life public webapp??
If you take the time to learn it, deploying C#, python, ruby apps can be insanely easy. And to be my usual self, deploying Golang apps are beyond insanely simple. (I cross compile from my Mac to my Linux 64bit target, upload and run `sudo ./server -host=:80` and I'm deployed).
I've deployed C# apps; I did .NET exclusively for about 8 years. It's great! But telling Joe's Washer Warehouse that they have to pay for the .NET stack, and that they can't just find a random PHP guy to do any further development is kind of tough pill to swallow.
Yes, PHP sites are usually the lowest common denominator, but on the other hand there are lots of people that are only willing to pay for that. There's a reason the PHP market is as big as it is. Thankfully for those of us in PHP-land there are starting to be lots of quality frameworks like Drupal and Symfony so that it's not such a horrible experience as it used to be.
And the other part is really the market. You want a large CMS-driven website? PHP is where it's at. That's where the code and communities are. There's a reason that lots of very large websites use Drupal. Sure, if I was going to try and make some sort of big-backend web app that did a lot of services and whatever, I'd want to do .NET. But as a freelance web developer, those projects just aren't there. Like it or not, I'm in PHP land.
(And RoR used to be a total nightmare to deploy. That whole community needs to send a collective giant cardboard check to the mod_passenger guy.)
A few more features get added in this way over the next few month and years and all of a sudden the sites popularity explodes. Now they have a whole bunch of stuff to deal with, and rewriting the entire site in some other language they know nothing about is not on the top of their priority list.
But it's preaching to the choir. If you've never seen anything other than PHP, you won't understand two thirds of the list or why they're problems. (<- Not looking down on PHP coders there, rather I'm thinking back to when I started out on PHP and am speculating on how I would have received the document.)
How do we communicate effectively what makes other languages better to someone with no reference frame other than PHP itself?
So to encourage developers to start with something other than PHP you'll need to lower the barrier to entry to modifying existing software, and also make something as popular and widely useful as WordPress and MediaWiki.
This is going to take a while.
A big hurdle is ops dev. All hosting services support PHP out of the box.
Now I'm faced with the "distro choice". Which server do I use (lighthttpd / nginx / tornado)? Which framework (django / flask / web2py / cherrypy / pylons / pyramid)?
Like the original author, I've had a VPS sitting unused for 2 months paralyzed by choices. I eventually decided on nginx / flask, but haven't had the time to set it up. Maybe I should have just used Heroku. shrugs
Just choose one and learn it. They're all excellent web servers. I'd recommend going with Flask or Django in the beginning, simply because they have the best documentation. web2py also has pretty good documentation. The only problem with Django and web2py is that they are monolithic. If you don't like their ORM, or templating engine, or authentication/authorization, it's generally hard or impossible to switch, and if you do switch you lose all the benefits of the integrated system. With Flask and Bottle, on the other hand, you are free to pick and choose components. I think the same modular design approach is used by Pylons and Pyramid, but I'm not sure since I've never used them. But as you learn more, there's a lot to be said for being able to switch out components of your framework, or even writing your own in a pinch.
Two thirds of that list are actually incorrect.
But I programmed in Java, C++, C, VB, and so on before I started coding in PHP many years ago. So many years ago, in fact, that PHP was easily the best choice.
The problem with lists like that is they obscure the truth -- and that is -- that solving a programming problem in modern PHP isn't really that different from solving it in Python and Ruby. It's just not that much of a leap.
Got a link to a good rebuttal?
http://blog.ircmaxell.com/2012/04/php-sucks-but-i-like-it.ht...
Not a good rebuttal but I've done my own here:
http://news.ycombinator.com/item?id=4177516
You're trying to convince yourself that you made the right choice, the right investment.
That's sad.
Have confidence in yourself. You made the right choice for yourself and let others choose for themselves.
There is no universal proper language or platform to use.
PHP works and it works extremely well for many companies. Its commercial success is not debatable.
Python on the other hand ... aside from Google, who's using it at a massive scale? Even Google has been shifting to Java for a long time.
See how that works?
Let's stick to the old parable. A proper tool for every job. If you're convinced that there is no proper application for PHP, then you're not even trying to be objective ... you're just trying to make yourself feel better about the choices you made.
> That's sad.
Err, huh? What's with the preachy tone and the presumptuos attitude there? No, I don't need to convince myself, nor am I looking for confirmation - I know that I'm happier coding in Python than I was coding in PHP, that I get more done in less time, that I've vastly increased the average reusability of code that I write, and that it blows up less in production.
> Have confidence in yourself. You made the right choice for yourself and let others choose for themselves.
That's not what this is about. It's about how I didn't make a conscious choice to use PHP back then - nor would I have if I had been in a position to make a choice. I believe the same is true for many others, so how do we get to a point where they have the facts to make a choice?
> Python on the other hand ... aside from Google, who's using it at a massive scale? Even Google has been shifting to Java for a long time.
Shrug. It's you who's playing up the PHP vs. Python angle here, really -- for me there's plenty of stuff out there that's better than PHP, not just Python.
> If you're convinced that there is no proper application for PHP, then you're not even trying to be objective ... you're just trying to make yourself feel better about the choices you made.
Actually I think there are circumstances where PHP is the right choice, though it's mostly a matter of market considerations, certainly not technical strength.
I think technical strength is valued differently in this community than in the web development community at large. I've had a lot of commercial success with PHP and never found a serious problem caused by "a lack of technical strength".
Surely certain languages have created a vision of technical strength that is appealing to programmers who think mostly about programming as the challenge in itself, rather than a tool for the market challenge.
However to people that think mostly about solving market problems, such as entrepreneurs, PHP is known for many attributes that are high value and perhaps have little to do with what you might consider technical strength.
The idea that disagreement is because person disagreeing is not educated enough and only if he could learn The Next Best Thing he'd immediately become a fanboy like you are - is deeply fallacious. I've seen your Next Big Thing. It's nice. So are other hundred Big Things. They are all nice, and all have its place. And no, I'm still not a fanboy, sorry. I still think Python is a nice language for its uses, and PHP is a nice language for its uses. Banality, but somehow so many people can't grasp how can it be. Please believe me, it can.
Interested in learning something that isn't PHP to code your web applications in? Ok. You have a ton of options and this is a very exciting time to be a web developer.
Do you want to lean towards stability and proven concepts and work within a full application structure? Look at Django and Rails.
Do you want to serve up responses from a simple script without a lot of extra pieces? Look at Sinatra and Flask.
Do you want to get in on the cutting edge and don't mind forging some of the path yourself? Look at Node.js and Meteor.
Got a high level decision made? Sweet. Now compare the primary languages between your choices (forget the framework for now). After a few minutes looking at each, which reads better to you? Feel free to go on gut instinct here: there are no wrong choices.
You've now made a choice for your next learning target. Now: don't spend years. Don't worry about knowing everything about the framework and the language. Google for "X tutorial" and follow the first link that looks reasonable and current. Do that tutorial. Now you have some bearings within the framework and have some idea of how it thinks.
Now. Pick something you want to build (a todo list is popular now, it used to be a blog or a wiki). Build it. You will make mistakes. You will be confused. Google for answers (if you're in Node.js or Meteor you will have trouble here) or hack until you get something working.
Throw what you built up on github and ask others to check it out. Build something else. Repeat.
If you are already a decent programmer with a good grasp of the web and how HTTP works: you will pick up any of these frameworks well enough to work in it in a month or so. In six months you'll be well advanced: especially if there are good books available for the framework/language you are working in.
Have fun!
Oh.
I hate PHP as much as anyone (of course), but that's what it does.
It's a similar problem as Ruby and Python, believe it or not.
90% of people just run a web site on a hosting server. Granted it's getting less and less common with the advent of the centralized service-based web, but still, that's the source of success.
The advantage it has is that you can run a ton of hosted sites on one mod_php apache server. With Rails, for example, you have to run an environment. Same with many Python apps, or Java, etc.
So it has the memory advantage of being able to run multiple sites on one environment.
Not that big a deal if you're doing any serious deployment, but a big deal for its ubiquitous nature.
The only advantage PHP has in terms of deployment is that there are more cheap, crappy shared hosts that support it.
To deploy you just push to a free heroku instance and you are fine until you get big. Much, much easier than setting up your own Apache+PHP. And much, much cheaper than buying hosting.
It costs 3 bucks for host gator, hmm maybe 4, but heroku is very opinionated on how you should structure your project.
Unfortunately Heroku is down right now. The wide-availability of choice, it's ubiquity, is why many PHP sites are still running right now - they are not reliant on a single point of failure.
There are many thousands of hosts, spread across the world, offering Cpanel accounts so I'm not tied down to the meteorological events in North Virginia.
If an act of God happens in Michigan right now, I can switch my site very quickly from there to a freshly minted Cpanel accout in California (thanks regular Cpanel backups!), or London or Manchester (Possibly not Newcastle right now, though). I'm really spoilt for choice here.
What are the alternatives to Heroku that don't have the same failing that are running right now that are comparable in getting an app up and running equivalent to PHP time?
That's the problem. I'm in the same boat as Marco with pretty much the same reasoning. I'm not interesting in learning something -- I'm interesting in starting and completing my next project as quickly, cheaply, and well designed as possible. I'm willing to accept that, all things being equal, a better design is possible in Python or Ruby. But for that to be true, I need to know Python or Ruby. I need to know the framework I'm working on.
I can certainly put the time into learning, the time into heading down the wrong path in both design and technology for a project (and that will happen), perhaps rewrite a few times. But with only so many hours in the day (less than I really need), it's not much of an option.
Software development is a Red Queen field [1]. If you don't take the time to keep up, you will eventually get left behind.
[1] http://en.wikipedia.org/wiki/Red_Queen%27s_Hypothesis
Same with my distro - I am currently using Mint, but that may change, when my next boot hard drive fails.
Even with VBA, where I had done much of the work using DAO (started in 2005 with what I already knew) I am now trying to make the next changes using ADODB. The benefit being it will be easier to shift the back end to MySQL (or any other ODBC-compliant flavor) and have more then one language used in different front ends.
Ah, the learning! My joy in life.... And these days, thankfully little tuition required.
I know it's difficult to compare or find an observer who could adequately judge between the two, but I wonder if Ruby made Jekyll easier to write and maintain? Of course, there's not any easy way to make that judgment without knowing how much effort Marco put into Second Crack versus what was put into Jekyll.
Hilarious suggestions contained throughout his post.
You know what does that even better? C.
Oh, that's too painful? You want tools that make development easier and less error-prone?
Exactly.
Edit: Perhaps I worded my question wrong. How do PHP programmers try and keep to DRY (ala layouts and view templates)?
EDIT: Disclaimer: I'm a PHP guy trying to make a break for it, and the question was both rethorical and tongue-in-cheek.
http://mustache.github.com/
You have built successful and high profile applications in PHP, thus invalidating the argument that PHP is useless . There may be better alternatives , but we must step out of our comfort zone to embrace them .
This post helped me understand the situation so much better. It does not insult or degrade PHP programmers for their language choice , but it gently suggests that better alternatives exist ,and it is worth the short term pain to explore them .
Thanks again , Marco. You've given me a lot to think about .
If you want a nice introduction into the world of developing web apps with Python, I suggest you read the Flask user manual (see http://flask.pocoo.org/docs/). It not only covers the basics of the framework, but also seems to assume that you're a first-time Python user as well. It covers topics such as using virtualenv and pip to setup your environment which I found very helpful when getting started with the language.
If I want to write a hello world application in PHP, it's neither as long as <?php print("hello world");?> nor as short as <?="hello world"?>
Rather it's simply: hello world. Just type in those 11 characters in a text file and save it as hello.php. Now load it on your browser [or run it from command line] and it will print hello world. I don't think it can get any more simpler than that in other languages. PHP was developed from the ground up as a templateting language for serving HTML pages. These other languages are more of a general type.
Therefore the replacement for PHP should come through a new language targeted as a replacement for PHP as Jeff said. Otherwise there always be extra web/template stacks for the developers to take care of. And that will be the first hurdle to learn and overcome for novice developers looking for switching to something easier.
This is solid advice for an engineer. And absolutely moronic for a businessman.
Choosing what platform to use is a business decision.
If you take too long to get it right, you will never get the chance to make a dime off of your work.
We are all working on limited time frames. It is far better to throw something together that works and rewrite later, when you're actually making money.
PHP is amazing at letting you write something fast and rewrite it into something more manageable later.
"Hey kid, first one's free"
From experience, the mountain of technical debt organizations acquire when starting with PHP can make it near impossible to rewrite it into something more manageable later, and it's a false dichotomy to claim PHP lets you write something fast while the alternatives do not.
Unfortunately, nobody starts out well-educated and experienced. And many projects start out small and grow. If you want to make your platform a broad success, you need to have a good experience for noobs and quickies. PHP is an abomination as languages go, but it's massively successful because any idiot can quickly get something basic up.
Why not improve it? After the millions of man hours that have gone into the plethora of open source PHP based frameworks and tools (aka, what powers the internet) - wouldn't we as a community want to improve the foundations rather then scrap them entirely?
You know, like what happened with Javascript...
PHP has a lot of them. And they interact badly.
All languages (like any system) will have cruft, after a while. Is the solution really to do a periodic break with backwards compatibility for purity reasons, Python 3 style?
There should be a better way?!
What about a low level machine like Java/.Net and just let the next language evolve on top of that -- so old libraries could run? (Maybe there could be Xcompilers for Ruby/Perl 6/xxx to the Perl "bytecode", to take advantage of CPAN?)
Figuring out when that happened to you is a judgement call.
If us PHP developers have such bad judgement, show us the error of our ways.
And do not link to some other persons blog post - explain it yourself.
After 15 years of one of the biggest bursts of innovation the open source world has ever seen, and with such diversity in frameworks that the mind boggles, nobody has returned to this model successfully. I've got MVC-inspired designs coming out my ears, continuation-based designs, frameworks just beginning to incorporate web sockets deeply (instead of as an afterthought), GWT, ASP.net, and other attempts at building a fundamentally different model and compiling it into another, and everything under the sun... but no return to the page-is-program model.
I don't think it's the key to PHP's success, because even in the competitive-yet-very-fertile soil of the web framework world, nobody else can make it work anymore. I think it's vestigial, and nothing else.
(Personally I think the key is simply that everybody has deployed it, and since there's basically no way to force every web hosting company to support Language X simultaneously, PHP isn't going away until the entire concept of web hosting goes away. Which isn't anytime soon.)
It's true that other languages have not wasted a lot of time trying to displace PHP as the language of choice for anonymous random dinosaur servers. That's because there's no money in fighting PHP on its home turf. The turf just isn't worth enough.
"Vestigial" is the wrong word. That's like describing a screwdriver as "vestigial" because the impact driver has been invented. Sure, impact drivers can accomplish many things that mere screwdrivers cannot, but that doesn't mean that screwdrivers aren't still useful, and numerous, and popular.
You may disagree that my characterization is correct, but it is certainly the characterization I intended to convey. That's why I parenthetically commented that I think the real reason it has carried on is another one, to contrast the relevant characteristics to the irrelevant ones. Creating a new "PHP-killer" and focusing too much on the vestigial features of PHP is a recipe for failure.
Ease of install is part of the same pattern. PHP has always been easy (with connections to a free database), and got easier with good package management systems. What's coldfusion like for ease of install, ease of install with database access?
ASP for Windows was huge. It was even easier to get started on than PHP because you just needed to install IIS from a EXE and you could reference access files. The only reason it's not still massive is that MS moved on.
There are alternatives, but nothing that simply 'just works' like PHP seems to.
If you truly only need a single page template without any further abstraction, then why not use PHP? It seems all of the complaints about PHP stem from using it in big projects. It is hard to argue that it does a single page template very well for when that is all you need. Right tool for the job and all that.
Wouldn't that also apply to jsp, cfm, gsp, jsf and asp?
If somebody had profound disagreements with the way PHP was being developed, they would be much better off switching or contributing to another language then they would be trying to re-invent PHP.
[1]: https://github.com/php/php-src/graphs/code-frequency
Just out of curiosity, why would someone believe this? The syntax of python and ruby are nearly identical, but ruby has more tools and support for web-based projects. For someone looking to develop for the web, ruby is pretty clearly a better choice. And this is not knocking python at all, I really enjoy them both and there are many other things python has more community support for - don't get me wrong.
To support what I'm saying about the syntax, check out this comparison: http://hyperpolyglot.org/scripting - they are super similar, if anything ruby is a tiiiny bit more elegant.
For someone looking to troll while looking smart and insightful, this comment is pretty clearly a better choice. Python has a ton of web tools and lots of companies build web services in Python. Ruby is simply another choice, not a better or worse one.
If you agree there is a difference, then for some set of people, those differences will be the determining factor.
Also, while fairly comparing the amount of "web stuff" that Ruby and Python have would be an effectively impossible task, the simple truth is that both ecosystems are abundantly full of stuff, to the point that which has "more" doesn't matter. You're not going to miss out on anything by going with Python, unless you drill down to a hyper-specific particular package you may need which only exists on one.
Just off the top of my head:
- Ruby was always designed as an OO language, whereas Python OO was bolted on later. Ruby's object system is almost a straight transplant from Smalltalk and is very powerful.
- Python lambdas can only be one liners. Ruby lambdas can be arbitrarily long. Guido doesn't really like FP - there's no tail recursion, either.
- Ruby's metaprogramming capabilities are a bit more powerful (haven't really looked at Python in this regard, so don't quote me).
- In fact, there are some pretty big syntax differences. Python requires brackets even for the print statement now, whereas Ruby lets you miss them out if it's unambiguous. Ruby has blocks. Python doesn't have "end\n end" sprinkled everywhere.
The main philosophical differences are that Ruby is more powerful and implicit, wheras Python is stricter and explicit. When I say "powerful", by the way, I don't necessarily mean "good", just that it exposes more functionality to the user. Although I like Ruby a lot, I accept that on large projects Ruby's power (like that of Lisp or C) can be dangerous. Python has a lot going for it.
You're right, they're still very similar in many ways. Maybe they're like Democrats or Republicans; up close, they're screamingly different, but from a distance they're almost alike.
- Whether or not Python was historically OO or not, everything in Python is now an object. Its love for protocols drives design like `str(foo)` (which calls `foo.__str__()`), not any particular deficiency in its object system
- Python's lambdas are indeed limited, but one can easily use `def` and just name the function. Functions are first class, after all
- Metaprogramming facilities are very similar in power. Neither language has macros.
- Python tends insist on not duplicating things (i.e. both indentation and braces/end) and on not being ambiguous. There is another reason Python can't omit braces for function calls: without braces, they are references to the function. As a consequence, Python doesn't need things like .call()
Overall, I haven't seen one language or the other to be more powerful.
--- Ruby ---
--- Python --- --- PHP --- Of course, this is one example where PHP (5.4+) at least somewhat resembles Python. I think that is why some of the more experienced PHP developers tend to choose to go with Python as their PHP recovery language.Personally, I prefer "letters.map" (Ruby) over "map(...)" and "array_map(...)"; however, that is a personal style preference and has nothing to do with technical merit. And I still enjoy writing Python here and there. PHP is also still a necessity much of the time.
That being said, there are a few edge cases that I've witnessed where Python actually reads better than Ruby; though, these cases are few.
Something that I'm not seeing people take into account generally when they decide to develop in a "new" language or complain about any established language additionally is how far along that new language is and how many people know it well. Choosing the best thing also involves how easy it is to get the help of others. An analogy might be an automobile purchase. If you are located in the middle of nowhere it might be a better idea to buy the Honda where there are multiple local dealers rather than the NewGreatAuto (pick any car with less market share that is better price and feature wise) where you have to travel 50 miles each way for warranty service.
I went through this with hardware back in the 90's choosing SGI servers that were better price and performance wise than Sun, only to find that many open source software ready to run was not available for SGI. And that there were less people that knew IRIX than Solaris.
They have the man-power required to displace it, as well as the serious need... although the only potential solution they have come up with HipHop / HPHPi is really lacking in community support. Its open source but rather undocumented, and took an entire day to get set up.
If they could produce a viable alternative to PHP... something that fixes the clear fuckups but doesn't try to fix everything I think it would have a real shot.
[1] http://davelang.github.com/
It runs half the Internet quite well, but if you went by the posting on HN, you'd think it was Windows Vista.
I've probably read every article critical of PHP that has hit the front page of HN in the last few years, and the one thing they all have in common is the vague refrain that PHP is a broken language. And yet the gap between tangible proof of that being the case in real world use and the gossip of it supposedly being true, couldn't be wider.
Hey now, we're all human. Even engineers. As soon as something becomes popular, it is no longer cool. Cool is the next popular. Cool is being different. That's just how things work.
Apache is slooooow (NGINX is cool!). MySQL is retarded (Postgres is cool!). PHP sucks (Python is cool!). Red Hat is lame (Ubuntu is cool!).
See a trend? The tech that sucks is the most popular and well established. The tech that's cool isn't popular. It has nothing to do with any objective qualities of platforms. It's all about being a part of the cool croud!
Remind you of high school much?
Now, if this is just a hobby, who gives a shit? Roll with the cool kids. If you're starting a business, be aware that the future welfare of your family is relying on your decisions. Think real hard about that.
Source: http://w3techs.com/technologies/details/os-linux/all/all (accuracy not entirely trusted, but it appears roughly accurate)
Just because a technology is "cool" doesn't mean that you're acting like a high schooler for using it. Nor does using non-"cool" technology make you an adult.
Truer words have never been spoken. When you think about it that way, these types of arguments about why language X rocks/sucks become trivial and unimportant.
I like to geek out over languages and technologies as much as the next guy, but there needs to come a time when you put your foot down and make a decision based on more important reasons than personal preference/feelings towards a language.
The problem is, it often does take into account objective qualities.
The downsides of popular platforms are often ignored because they carry with them all the advantages of popularity: good support, a well-established community, a wealth of experienced people you can hire or draw upon.
These are not "objective qualities" of the technology, but real side-effects of popularity. In fact, you could say it's a technology's popularity that fools you into ignoring many of the objective qualities of the platform.
I think part of tech hipsterism (which, let's face it, is what you're talking about) is a rejection of this groupthink, and a return to true technological thinking. It's the ability to say "we don't care what's popular, we're just going to look at what works again and see where we end up." I think this very idea is considered 'cool' in the tech world because we tend to like people who think logically about their problems and don't just blindly follow what people have already done. We like people who look at lesser-used technologies (which all of the "cool" tech you listed above actually are) just on their technical merits alone. This is, perhaps, one reason they're considered cool; because it takes actual thought to break away from simply using what everyone else has used for years.
So I think you have noticed a definite trend, but I don't believe it's as purely social as you imply.
That said, "be aware that the future welfare of your family is relying on your decisions" is an argument that's used in so much Enterprise software that it's almost scary. Often the most popular, most entrenched, least risky, biggest company with the largest pockets wins because the CTO can't be blamed for fucking up that decision. It's an incredible driver of technological stagnation in the Enterprise world. It is great to think through your decisions to their far-reaching impact, but be thankful that all of technology is not driven by that kind of strictness, or we'd never use anything new.
Going with cool new things for everything is very risky. This is terrible for established businesses, it's great for startups with no legacy and no pressure to maintain inertia. There cultural differences are endemic to the realities of both types of businesses and aren't just the product of politics.
Cool-ness biases are perhaps not so easy to distinguish from justified ones.
I was a linux sysadmin at a university for 6 years, and I used linux personally for a decade (before switching to iOS dev). During that period, I've had brief, frustrating encounters with Redhat.
It's not that it is unusable -- anything which can be done on Debian can be accomplished on a Redhat box. It's death by a thousand little annoyances, which is exactly the argument against PHP, so I think it's an "apt" comparison (pun intended).
For example,
* How do you restart apache on Debian? "/etc/init.d/apache restart". On Redhat? "/etc/init.d/httpd restart". Ah, so Redhat is in the habit of renaming all of their init.d scripts after the protocol of the service? Nope, turns out they only did that to Apache's script. WTF?
* While we are picking on Redhat's Apache, they also chose to pollute /etc with a bunch of crap which doesn't belong there. Symlinks to /var/log/httpd, /usr/lib/httpd/modules, /var/run, etc. So now, when I grep /etc for something config-related, I pause and think "why is this grep taking so long...", and then a bunch of crap from /var/log spews onto the screen. Thanks, guys...
* Still on the Apache kick, they decided to make the default permissions drwx------ for /var/log/httpd, with root as the owner. Really? Root is the only person who will ever need to look at those logs? Perhaps chgrp'ing to adm would be more sensible?
* Which leads to another problem... because they put their WSGI sockets in /var/log/http (WTF?), which is... only accessible by root. Wonderful, so now I have to reconfigure all of my WSGI processes to stick their sockets into some other location, like /var/run. On Debian, this "just works".
* The package maintainer of util-linux arbitrarily decided to remove cfdisk because it was a "pile of junk" (https://partner-bugzilla.redhat.com/show_bug.cgi?id=53061 ). Really? Because every partition I've created on Debian for a decade worked just fine, using cfdisk...
* There is (was?) no "vim" package. On Debian, to install vim, you type "sudo apt-get install vim". On Redhat, you type "sudo yum install vim", then go search google for a few minutes, and then type "yum install vim-enchanced". Thanks, guys.
* Supported packages. At the time, the Debian package repository was something like 12,000 packages, while Redhat's was around 3,000. This meant that for any production system, you inevitably had to either compile and install lots of software by hand, or you had to rely upon the community (e.g. http://dag.wieers.com/rpm/) for pre-compiled packages, but now you've just thrown away the consistency and quality level which comes from e.g. Debian's Policy Manual, and you've introduced a rather gaping security concern into a "production" system. Wonderful.
That's all I can recall off the top of my head, but the gist here is that there are a ton of tiny little bad decisions which make Redhat suck, and there's simply no good reason for it. Its just a pile of annoyance.
Unfortunately, Redhat has somehow positioned themselves as the "enterprise" linux, so PHB's often make the technical decision to go with Redhat, completely ignorant of its technical deficiencies, dooming their employees to suffer the consequences.
Perhaps I'm jaded, but when someone tells me they run Redhat, I immediately assume they made that decision from a position of inexperience, and they simply don't know any better.
For historical accuracy, the HTTP server binary of the Apache project has been called 'httpd', compiles to 'httpd' in the source official distributions and is distributed as 'httpd' in the binary official distributions for ages, if not since day one.
Apache is a webserver from 1995. It uses a process (sometimes a thread) per request, a architectural decision which made it nearly fundamentally incapable of solving the C10K problem. Only back in January was the Event MPM added (and it's still experimental), allowing you to have many Keep-Alive connections open at once without degrading performance. Nginx was started in 2004, and is event-based allowing for much higher concurrency. (Yes, I'm hand waving.)
PHP is among the worst languages most sane programmers have ever used. The referenced article, "A Fractal of Bad Design" is a pretty good starting point if you want more details on why it sucks. PHP stands for letting amateurs code effectively. Python is designed with an emphasis on readability, and manages to have a rational type system and a fairly regular standard library.
Apache vs Nginx is about learning from the mistakes of your ancestors. Apache was designed with the 90s in mind, and our technology has moved on to the point where the decisions made in its architecture simply don't work anymore.
PHP vs Python is about being a rational, non-masochistic, human being.
To say what is cool "has nothing to do with any objective qualities of the [technologies involved]" is to know nothing about programming as a business.
I hear this a lot. I think people assume that because lots of amateurs use PHP, it must be helping them be effective. This is not a safe assumption. A shoe does not help amateurs drive nails effectively, no matter how many amateurs you see using one.
For a better of idea of how amateurs interact with PHP, see http://stackoverflow.com/questions/tagged/php
People have a tendency to overrate their rational capacity to reason out a viable decision. While you listed a few solid critiques, the situation is infinitely more complex.
And by infinitely, I do mean exactly that. As in, beyond your capacity to reason it out.
In the end, the only right decision is a decision which withstands the test of time. Both Apache and PHP have done that and continue to do so.
Apache holds 65.5% of the market [1]. PHP holds 77.9% of the market [2].
Those solutions are working, right now, for all of those people. That's reality, not grand "rational, non-masochistic" theories.
[1] http://w3techs.com/technologies/details/ws-apache/all/all [2] http://w3techs.com/technologies/details/pl-php/all/all
Now that we're finished with that, I'm going to enjoy myself.
> a architectural decision which made it nearly fundamentally incapable of solving the C10K problem.
C10K is not a problem and never was. The limiting factor in the overwhelming majority of deployments is the pipe. Apache can saturate the pipe just as well as NGINX. You will saturate the pipe long before you reach 10K connections. Which is why people continue to use Apache. Being technologically superior is pointless when there are no real-world benefits to that technological superiority.
On top of that, Apache's thread model provides it with greater stability. If a worker thread crashes for whatever reason, another will simply spin up. If your NGINX process dies, you'll need to wait until your monitoring solution brings it back up. Which could be a long time.
> PHP is among the worst languages most sane programmers have ever used.
Worse than COBOL? Yes, yes, a fractal of bad design! Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.
> Python is designed with an emphasis on readability
Was that humor? Python shoves its version of readability down your throat and laughs as you choke on it. Not all of us get off on syntactically significant white-space. In fact, most of us don't. Which explains why Python is so unpopular. But I get, I get it. It's cool.
> C10K is not a problem and never was.
Somebody better tell the developers of nginx, Lighttpd, Tornado, node.js, Cherokee, Apache Deft, IIS, and Jetty! All those hours wasted developing solutions to a problem that doesn't exist.
> Which is why people continue to use Apache.
For someone who just decried a situation "infinitely more complex" a few line breaks ago, you sure did generalize the reason millions of servers use a certain piece of software. It couldn't be because Apache has an easier installation on most of the common distros or that cPanel/WHM, the most-used virtual hosting control panel, only supports Apache as its web server. It also couldn't be because of mod_php.
This all stems from your conflation of popularity with quality. PHP did not become popular because it was good. It became popular because it was easy to learn and run.
> Except that article was written by somebody who doesn't have much experience in PHP and most of those complaints don't apply to the current stable version. The rest are easily avoided with sane design.
Most of his criticisms were completely valid, so I'm not sure where you're getting the author doesn't have much experience in PHP. Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?
> Which explains why Python is so unpopular.
Now I know you're spouting nonsense: https://github.com/languages/
Not even close. The author trolled through a bunch of other misinformed articles, copied some them verbatim mistakes and all. He doesn't know PHP and didn't research anything.
> Which ones have been fixed in the current stable PHP? And which ones can be avoided "with sane design"?
http://news.ycombinator.com/item?id=4177516
That all comparisons between objects, except equals and strict equals, return false doesn't seem terribly unreasonable.
> In regard to his "there's no pass-by-object identity..." point, there's no way to do this:
> I really don't have the energy to refute the rest, but most of them are relatively subjective.I think you'll be hard pressed to find too much fault with my criticisms of that article. The author doesn't even know common language terms like private/public/protected. And clearly he's never even seen C++.
It should throw an error, not return false. This goes back to PHP's "try as hard as possible to run the script" mentality.
The author doesn't need to know C++ to comment on PHP's failings, does he? And he knows private/public/protected— you even quote him using them. You're probably not familiar with Python, but there aren't any private methods (aside from double underscored-prefixed methods, but that's not entirely the same). That's where he was coming from. It's not that he doesn't know those terms; it's that he thinks that's how they should work.
Judging by your other responses, you're quick to toss out whether someone is a "PHP programmer" or not, as if that has any bearing on their argument. I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.
I don't disagree. Although I think this goes towards PHP weak typing not it's try as hard to run the script.
> It's not that he doesn't know those terms; it's that he thinks that's how they should work.
He thinks they shouldn't exist at all. Which is one philosophy but that's not a valid criticism.
> I'll tell you right now, I work in PHP five days a week, and I agree with most all of eevee's points.
Even where he clearly doesn't know what he's talking about and didn't try the code he was supposedly saying doesn't work?
Those who don't know their tools are bound to have more problems or believe things that are just wrong.
No it's not. We're not talking about music --how popular Bieber is vs Bach, for example. So he didnt just say "tons of people use PHP", he said "tons of people use PHP and it solves their problems giving results".
This is not an "argument by popularity", its an argument by number of empirical verifications. Which is supposedly what engineering and science is all about.
On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results. "That's (eg python) is how a language should be, and not like php" etc. All the while forgetting to take no account practical, verified, php benefits.
>Yes, most people on the web use PHP and Apache. Most people on the web also need nothing more than a WordPress installation and their online needs are met. Does that mean WordPress is the best tool out there?
OIf it meets their needs and has them happy, of course! Anything else would be dellusional to say.
The original discussion was about whether PHP was a good language. He came in and said, "It is because look at all the people who use it! Obviously it's fine!" That's an appeal to popularity.
> On the other hand your arguments are appeals to "logic", "theory", etc, eg idealism and elitism in the face of actual results.
What results? We're not talking about Mom & Pop's Homepage, here. Posting about how most sites run on PHP doesn't help us when we're not talking about most sites. We're talking about building apps.
The idea that C10K doesn't matter is definitively untrue. I've worked with numerous large systems (games, content) where Apache was the problem, and swapping it out was the solution to making maximal use of the hardware and the (gigE+) pipes.
Even outside of saturation, there are large-scale systems that benefit from being able to park an open socket and provide asynchronous notifications over that socket (in web terms, think websockets). If you're paying for a thread or process for every socket, this becomes prohibitively expensive very quickly.
It's also not an unusual use case outside of traditional web development, and now with websockets, this kind of architecture is likely to see considerably more use. This approach provides numerous advantages to legacy polling approaches, but does not work on traditional short-lived connection software architectures.
In addition to the above, your discussion of robustness really has no bearing on Apache's architectural suitability in production use-cases.
Auto-restart functionality exists for other architectures, and in addition to that, it's standard practice to deploy multiple servers with automatic failover behind a load balancer -- in addition to the server process itself, the OS can crash, disk drives can fail, power supplies can blow, etc.
Additionally, you shouldn't have production processes crashing regularly, and shouldn't be making significantly performance-impacting architectural choices on the basis of Apache's ability to restart a child process. Software crashes in production are a worst-case failure, akin to a drive failing, and should never be so common as to justify Apache's performance costs/constraints.
Click on a link?
I promise, at some point, PHP is involved.
http://w3techs.com/technologies/details/pl-php/all/all
No matter how you try to hide from it, it's blatantly clear that PHP runs at least half the entire Web.
What else exactly did you think was? Surely you didn't think Python was running half the web. Obviously Ruby isn't. So what does that leave? Coldfusion? C?
Well, in principle, there's no reason any one language has to run half the web by itself. And there are also static pages.
Of course, once actual evidence is involved, this is just an adventure in nitpicking.
Sometimes people speak in broad generalities, or use "Internet" when they mean "Web." It is in fact extraordinarily common.
It's also wrong.
Just because something is shitty to use doesn't mean you can't do productive work in it. We're all just poking Turing machines here. Let's not even talk about the enormous weight of sunk cost fallacies.
Once you have something that grows faster than education grows, you’re always going to get a pop culture
-Alan Kay
[1] http://queue.acm.org/detail.cfm?id=1039523
No, what's "wrong" with PHP is that other things that are better have come along since. That's not a fault of PHP, that's the nature of language evolution.
> It runs half the Internet quite well
COBOL runs tons of mission critical business services quite well. It doesn't mean that nobody's improved on COBOL or that you should use it for a new project today.
The problem is, no, nothing else has. Node.js is awesome and fun, but far harder to set up for basic webpage serving. Python is awesome, but also has a huge learning curve to learn how to serve basic webpages with. And... I can't think of anything else. Perl? ASP? Java is a huge pain to set up and maintain.
What other language out there is better than PHP for getting simple webpages up and running quickly? I wish there were one, but when you consider practical aspects instead of just theoretical ones, there really isn't. Sadly.
Myself and an army of other ex-PHP developers disagree.
> What other language out there is better than PHP for getting simple webpages up and running quickly?
This discussion is not just about "getting simple webpages up and running quickly". In fact, it's pretty clear people are talking about developing web applications, and not slapping together a quick and dirty page or two.
If you want to have a discussion about what language is best for inexperienced people to whip up a simple site without having to bother learning much, that's fine, but that's not this discussion. At the very least, that's certainly not what Marco was talking about, nor Jeff in the blog post Marco was responding to.
> But when I wanted to write Second Crack, I went right back — it was a quick little project that I only wanted to spend a couple of days on, so it didn’t justify the overhead of learning a new language.
Whether it's webpages or web apps, nothing else is better than PHP for getting something small up and running quickly. That's the whole point of why Marco feels "addicted". I really wish there were something better in this context, but there isn't.
(And what do you mean, "ex-PHP developer"?? I've never heard someone call themselves an "ex-C" developer or an "ex-Java" developer. You make PHP sound like a cult or religion, instead of just a popular programming tool.)
Often from developers who may, thanks to language Y, write more elegant code on the line / function level, but still create the same architectural mess as they did before in PHP. (Rails doesn't save you from creating a mess, neither does the broad separation of concerns of any MVC framework.).
There are thousands of ex-PHP developers out there that think they are now better programmers because they now use Ruby or Python, building thousands projects that proof otherwise.
Five to ten years from now, people will be bitching on HN about legacy RoR software like there's no tomorrow. And they'll probably be blaming the language and/or the framework.
> Often from developers who may, thanks to language Y, write more elegant code on the line / function level, but still create the same architectural mess as they did before in PHP.
That's a longer-winded version of "You Can Write FORTRAN in Any Language". Certainly nothing exclusive or even particularly unique to PHP or PHP programmers.
Also, does the word "ghetto" ring any bells?
Not that I think Python solves all the problems well either. I'm a fan of Lua, personally, but only because it's a much cleaner language design, and it's faster, and it's easier to set up, and it's easier to write Node.js-style code that's easier to read, and... well, I guess there are a few reasons.
[1] http://discuss.joelonsoftware.com/default.asp?joel.3.309321....
[2] http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoni...
The crazy thing is that all of that could change with a simple project that does <?coffee > (or whatever) style templating while automatically offering access to CGI data and cookies at a scope reasonably close to the global one. This should take days to implement, and when I have a few of those to spare, I plan to tackle it.
better = in a better "programming language design" sense only
What? Really?
One thing I love about Ruby is how many methods suggest one another. For example, Enumerable collections, like arrays, have an `any?` method. It takes a test function and returns true if any of the items pass that test.
[1, 2, 3, 4, 5].any? {|i| i > 4 } # true
Ok, you just learned `any?`. Now, you can replace `any?` in the above with
1) `all?` - do all elements pass? 2) `one?` - does exactly one pass? 3) `none?` - do none pass?
If you can remember one of those, chances are you can remember others. And if not, `myarray.methods` will remind you.
That same array has a `max` method and a `min`, a `max_by` and a `min_by`. It has a `select` to get all matching items and a `reject` to get all non-matching items. Knowing one helps you remember another.[1]
The key is consistency. It speeds up the learning process and makes you refer to the documentation less often.
That's the advantage of choosing a good language. It reduces the very pain that the OP is worried about.
==========
[1] (But wait, there's more! Any class you create, if you define `each` and `include Enumerable`, gets all these methods for free!)
Alternatively, if all I knew was PHP, I would understand why someone would be scared of learning something new. I mean, look up and down this thread. Everyone thinks a one-liner hello world is the pinnacle of the ultimate web dev language. Because real web frameworks require an http handler, they assume it's more work or harder. To me, it seems that many in the "PHP is easier!" crowd are too scared or lazy to take the time to learn something else and realize that better separation of concerns and tooling actually allows for faster and safer development.