PHP: the quiet powerhouse
blog.appfog.com
blog.appfog.com
"I think PHP is the perfect language for beginning web development for two reasons: Direct HTML embedding."
Server-side view rendering is on its way out. So this is not a real advantage.
"I find it more than a little strange that PHP is simultaneously (a) out of fashion, and yet (b) absolutely everywhere."
This is simply how technologies rise and fall. By the time a technology is ubiquitous, the original problems it solved have changed and new solutions are being created. Just because you have a bunch of legacy code running lots of web apps doesn't mean it's the future--it means it's the past.
Also, why pick a language that pays poorly? Ruby is by no means inferior to PHP, and you will get paid more per hour to program in Ruby.
No it isn't, client side view rendering is just experiencing a faddish phase; it'll fade. It'll never overtake server side rendering on the web.
The Internet is becoming more ubiquitous. Being "on the Internet" will mean less and less being in front of your computer. The proliferation of devices you can access a web app from is increasing (smartphones, tablets, more coming in the future) so it is becoming more useful for web apps to be like a "smart database in the cloud" and for the view logic and code to be on the client.
Disclaimer: I'm not one of the downvoters.
Yes, that's a valid point, if you mean that smartphones have less resources (memory, CPU) to handle JavaScript execution. But keep in mind that a native smartphone app is a thick client; it has all of the view logic.
Perhaps I need to back up and explain my point better. Maybe people are misunderstanding me because they think I'm talking about what's going to happen in the next few months. Server-side view rendering is not going anywhere anytime soon. But it's on its way out in that it's an anachronistic way of thinking about the web; it's a relic of the past--of the time of web "pages"--and not of the future, of web "apps" and "resources". As long as you are serving content that's primarily to be "read", like articles, books, blogs, etc., server-side rendering has its place.
But look what's happening to the web. Native iPhone apps have to store their data somewhere, so they communicate to the backend via an API. Cars are reading Twitter. Thinking about the past of the web, only browsers consumed web content. Now non-browsers consume web data via APIs, and I see this trend as increasing.
I see a trend where more web apps will be like a "smart database in the cloud", meaning they hold data and business logic and communicate via JSON APIs. There may be a variety of client devices accessing this data in the cloud: native iPhone apps, desktop browsers, other Internet-enabled devices.
The main point is that clients are no longer only browsers. The clients could be a variety of devices running on a variety of operating systems. So it doesn't make sense for the server to render the view and send it down the pipe for the client to display. It makes more sense for the server to send data to the client and the client to decide how to render it.
I'm not claiming that server-side view rendering will go away completely; it has its place with articles and blogs. But with apps, I see a movement toward thick clients and I don't see this trend slowing down. It's hard for me to envision a world in 10 years with less smart phones, less devices hooked to the Internet, and people only accessing web apps and web app data with browsers.
Let me also put this in context of the article's original point, that PHP has a nice feature of being able to be embedded directly in HTML. Yes, this is nice. But my point is that if you are starting your web career and therefore are looking toward the future, the types of web sites that will use inline PHP will be more like content sites and less like web apps. And I expect a bigger demand, higher pay, and arguably more interesting work for web app creators than web content site creators.
It's a vastly simpler approach that makes client side code nothing more than update this or that, and works just as well while allowing the traditional server side templates. It's not a relic of the past and it's not on it's way out, nor is it inferior to client side rendering, in fact I think it's better.
That said, I hope you're right. A world in which front vs. back end didn't matter with respect to time would be one in which developers were free to reveal far less on the client side, and that would be a victory indeed!
My perspective is that of web apps. By using client-side rendering I can prefetch more data than the user needs at almost no extra cost, and render it when they click without hitting the server. Not having to contact the server at all beats any server-side rendering architecture. Even web apps that supposedly do server-side rendering will end up with some prefetching for performance (e.g. tooltips and detail panes are already embedded in the page but hidden).
The reality is that the big bottleneck in any web app is not the fetching of data but the fetching of the front-end. The more front-end code (images, js, css) that you can fetch from browser cache or CDN the faster your app. The "ideal" case is not having to fetch anything except the data from the server. You can do that today with client-side rendering combined with far-future expiration or HTML5 appcache. The caveat here is that the performance benefits only start compounding for client-side rendering if you can prefetch data. Twitter couldn't do that, so there was no benefit.
Like any complex technical issue, there is no right answer in general, only a right answer in context. People should just be careful about what they're measuring. The important benchmark is time to load the page, not time to process the page on the server (a huge difference), and measurements should be globally distributed (you should be measuring transcontinental page visits).
Time will tell.
I say this because I am doing it -- building apps with REST interfaces on the server side. It's not a common pattern yet but I think this is where things will actually go (as opposed to the client), because it's actually easier to use, understand and iterate on.
If you can write Javascript templates that interface with your back-end using REST calls like "GET /accounts", you can do the exact same thing in a server side template with better performance and dramatically simpler security.
My point was not directed so much against JavaScript as against the notion that PHP is simply an anachronism.
There's also nothing stopping you from using lots and lots of front-end JavaScript in a PHP-driven context...
Any decision you make to learn anything based on payback has to factor in what will happen if more people choose to learn something. If more people learn Ruby because it pays better (let's assume that is correct) then supply and demand could equalize and the pay will go down. Right now if pay is high for Ruby it means most likely there is a supply and demand in balance. When that changes so will the pay. The only time I haven't seen this happen is with the rates lawyers charge. And the reason for that has to do more with personal relationships and quality of work.
In any event, the transition should be slow and I fully expect Ruby to be around for a long time, but people may notice a slow decline in demand for Rails programmers in the next few years compared to other hotter technologies. Sinatra (or some other Ruby framework) may replace Rails as a backend.
I'm a Rails programmer and I don't bristle at the suggestion that market demand changes. I welcome the change and adapt. I don't mind learning new languages.
So I say don't give up on Ruby. And if you insist on Rails-style MVC, there's always Padrino for Sinatra, Tower for Node, etc.
So much going on, so little time...
How in the world can you predict what will be in fashion 5 and especially 10 years from now?
"That's because the web is shifting to thick clients, and JavaScript is the only choice in browsers."
How do you know that won't change?
JavaScript has a monopoly as the only language that runs in browsers. If this were to change, it will take years, not months, for browsers to start supporting another language (or go to a bytecode model). Then it will take more time for developers to start using these new languages and then an ecosystem of tools and libraries to form around this. Then it will take even more time for the "old" language JavaScript to seem obsolete.
JavaScript is currently gaining traction and is the lingua franca of the client-side Internet, which is growing. This is why I predict it will still be strong in 5 years, because it's got a lot of momentum and I only see the trends as increasing (mobile devices are increasing, browsers are becoming even more like operating systems with memory management etc., JavaScript as a language is continually being improved).
I honestly don't have a clue. I might guess Python because it's so big at Google and Chrome is already more or less the industry standard.
HTML was meant to describe text, now it describes regions of the screen to be repainted as well as the "content" to be repainted.
CSS was meant to add simple effects like bold, italic and simple newspaper-like positioning (float this image left). It's been repurposed to describe visual rendering and even animations.
JavaScript was meant to add some scriptability to the DOM, and now it's morphed into a full-fledged programming language.
So the state of the web is a depressing mishmash of old, repurposed technologies.
It would be nice if there were a programming language that "knew" about the web. It would realize that the programming effort would be shared between two computers, client and server, and would have appropriate security and other conveniences baked in. For example, you should only have to describe your business logic once (as opposed to once on the server and once on the client). Also, this programming language should no longer be tied to the anachronistic concept of rendering a "document" with "styles".
But alas, it's very hard to simply go into an academic tower and design a language and release it into the wild and expect it to catch on. These things tend to grow organically and incrementally. So whatever next step there is has to embrace where we currently are. This is why you see not merely new client-side languages, but new languages that compile to JavaScript. If they didn't compile to JavaScript, how could they ever be used?
I'm not so sure I would describe the mishmash as unambiguously depressing. It's also pretty inspiring seeing people using the mishmash in a sort of bricolage kind of way. One thinks of libraries like Underscore and Backbone that seek to account for some of the "deficiencies" in JS.
And don't even get me started on CoffeeScript.
But I think we would both agree that it's strange that no one has come along attempting to really REALLY break the mold by designing a new browser from the ground up that wasn't tied to JavaScript and the DOM (and maybe not even HTML!).
You go first :)
server side is "on its way out" the way relational databases were "on their way out" when everyone was hysterical about NoSQL 18 months ago. That is, while client side rendering will become much more prominent, server side will remain quite popular as well. Hybrid approaches will likely become the norm.
We've written an app here with 100% client side templates, and while there are some nice patterns that fall out of it, unless you're writing your whole server in javascript as well, you have to give up a lot of conveniences offered by server side templating.
But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a web page and assume that your client was a browser. Not anymore, and that's my point. And my point is that the trend will continue: I think we will have more variety of non-browser clients in the future, not less. Your car, refrigerator, geranium, etc. will all be hooked up to the web.
Keep in mind that I'm not talking about whether you should create your web app in Backbone.js today, but I'm looking years into the future, anticipating trends.
Besides that, the ability to "template" output on the server is still my ideal way to transform the business API to something the client can read. In the case of a browser, I'm templating for HTML. For a mobile app, we may just pass through in JSON and let the native mobile app handle the views, even output HTML5 for mobile in addition.
In all of these cases, server side templating of output plays a role I think. For browser targeted output, server side templates are still simpler in the implementations I've seen.
The only way anyone gets Wordpress to scale is to put caching in front of it. But now the heavy lifting is being done by memcache or varnish, not by anything engineered into Wordpress or PHP.
It's annoying seeing people waste their breath on arguing why PHP is so bad... Especially when many people/companies have proven PHP is good and can be scaled and used on high trafficked sites, yet 90% of the arguments are how it doesn't scale.
Just because you have used Wordpress or built a quit todo app in PHP that took you 5 minutes and that's the extent of your usage with the language, doesn't make OR break the language.
Quit complaining and let PHP users use PHP, and you continue using whatever the language you use is.
Signed, A Python, PHP, and Node.js developer.
I think part of the reason folks pillory PHP is their annoyance that people are using it as their first language and may never move beyond it to the better alternatives available.
I guess you missed this post that highlights a few of them: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
I agree on using what you enjoy using, but implying PHP isn't riddled with flaws is absurd.
And I've done a wide range of thing in PHP, including scaling websites to millions of pageviews per day.
PHP might have design flaw, but in the end, they don't matter because they actually don't affect the day to day developer.
And I've tried my hands at Ruby, Python (still use it but more for scripting than web dev), C# (was actually my first language for webdev), and weirdly enough I find that they get in the way more that PHP does when it comes to building websites.
The overall problem is not with specific flaws of PHP; the problem is that flaws in a language lead to errors in programs written with that language, and when that languages is used to write some kind of web infrastructure, then use of that language by people less than experts (i.e. almost everyone) is harmful to the whole internet. PHP can be used to write useful, scalable, secure web apps in the hands of someone who knows what they're doing, but in the hands of someone who doesn't quite know what they're doing, or who does but is tired enough to miss individual details of their code, it is much more dangerous than other comparable languages.
That is why I discourage the use of PHP if possible.
[1]: https://bugs.php.net/bug.php?id=54547 (Both strings appear numeric, so they are casted to numbers before the comparison, but because they are larger than maxint, they are rounded down. The solution, if you really must use PHP, is to use === instead. The fact that a solution exists does not mitigate my concern.)
But I should say as an aside (and you wouldn't necessarily disagree, I don't think) that these kinds of problems are not exclusive to PHP. JavaScript gets you exactly the same result. And try doing something as simple as 0.2 + 0.1 in JavaScript. Oy vey...
This made me cry.
There are something PHP does nicely than Ruby does. Visa versa. However in all the PHP apps I have made / used, their structures started out with good intentions and then descended into pure chaos. There isn't a unified package manager for Python and PHP that is widely accepted. Ruby has rubygems and bundler.
Maybe next time when I start building another PHP app with namespacing, I'll behave better and make my designs more decoupled so that components can be removed and added, provided their interfaces match.
9600+ generally concise words on many, but not all, of the issues with PHP. As a summary, PHP isn't "out of fashion" as much as people are tired of continuously being misled and abused by their language of choice.
http://www.flickr.com/photos/raindrift/7095238893/in/set-721...
Which... is even odder because some evangelists like to point out that python and ruby are older than PHP, as if that means much.
While I generally agree with the points, many PHP strengths are also weaknesses. For example - "Direct HTML embedding." It's nice and easy, but because it's so easy, it leads to unescaped output, and xss exploits and such.
PHP does let you as productive as you want to be on the web, either with raw PHP or with one of the myriad frameworks. The author's point that no other language gives you that is, I think, another one of PHP's strengths (but yes, is essentially a weakness in the wrong hands as well).
EDIT - have been using PHP since early 1996 - almost since its inception, and have watched the criticism (and occasional hate) ebb and flow over the years. That seems to be the only constant to PHP. :)
PHP is a Web scripting language (which I consider to be very different from a general-purpose programming language or even a scripting language), designed and developed to generate markup.
I have seen a lot of "templating" libraries (Smarty among them) and all they do is mimic the basic syntax of PHP using something else that is not PHP.
I know the theory ("designers don't know how or want to program"), but learning PHP conditional statements or loops is as difficult or simple as any "templating" library that asks you to learn its exotic syntax.
Now, MVC is good and one should avoid blending presentation code with models and controllers, but most MVC frameworks fail when they require you to instantiate a gazillion extra objects, just to render a Web page.
Most of the arguments I see against it though are really problems with the programmers using it. "Look at this horrible code I have to put up with! The comments are inane and useless, there's no structure at all, and I'm stuck in a chain of nested if statements 10 layers deep and I have no idea what's going on. PHP sucks!"
As Jeff Atwood said, "sufficiently incompetent coders can write FORTRAN in any language."
"But the converse is also true: sufficiently talented coders can write great applications in terrible languages, too."
PHP wasn't exactly designed… it was formed, like a ball of mud picking up various debris as it grew. It shows, too, especially if you've had the pleasure of working with PHP 4. (I can only imagine what earlier versions were like.) I can't for the life of me think of a language with more brain-dead "reference" semantics. It's just bizarre. Their date functions miraculously manage to be worse than their C counterparts. I could go on and on.
But in the end, using PHP doesn't doom your project to failure any more than using the current flavor of the week guarantees your success. Jeff Atwood, again: "The only conclusion I can draw is that building a compelling application is far more important than choice of language."
So why are we still comparing programming languages instead of writing code?
I think the author is spot on in this post. PHP is not without its warts, but as a programming language for web development, it is scalabe, reliable and robust.
Can you perhaps do things faster or more elegantly in other languages? Sure, but writing good clean code is really in the hands of the developer. I can do everything in python because its written in python doesn't mean that that code is going to be designed well or scale well.
PHP is my university, Gazi University. It first established in 1926 as a Teacher Training Institute. Nobody knew that there will be a medical school or faculty of fine arts or even a faculty of dentistry. 1926 was the third of our newly established Republic and we needed teachers. So, Teacher Training Institute was born.
Our main campus is very small. Law School or dentistry school is not in the campus. Because, as i said, nobody knew we need them in 1926.
Ruby, C# and many other languages are METU: Middle East Technical University. METU was designed as a university. So, they got a gigantic land in Ankara (capital city of Turkey). They build all their building in there.
Back to the PHP: PHP was born to solve one problem. Just one problem. When they got another problem, they solved it and added the function or implementation in the language. PHP is not designed at desk, it was not "feature-complete" at version 1.0. It's still getting more mature as version numbers increase. For example we get "traits" in 5.4.
PHP is also Windows too (both Microsoft and PHP in a HN comment :) The most un-loved things in this community). Remember the video which a guy installs Windows 1.0 and successfully upgrade it to every version of windows with all his data and programs up to Windows 7? even doom from 1993 works! (http://www.youtube.com/watch?v=vPnehDhGa14) PHP is like Windows. I know the "parameter order inconsistency" problem too. But you can't solve it after this point of time. You just can't. Like windows, every program should work after the upgrade. There are millions of millions PHP sites. after a "apt-get update;apt-get upgrade" they should work.
By the way, sorry for my bad english.
1) It's really only meant for web development.
2) There are other languages now that are simple to learn, flexible (more than just for web apps), and powerful (Python, Ruby, and now even Javascript)
Unless PHP has another major evolution, like its move to OO; (or unless I just missed something else big) I just don't see the point of using it unless you or your company been using it for years already. This article doesn't have any real compelling arguments.
Maybe all of this will change once Facebook releases Hiphop VM AND people actually start using it. To this day, I'm not sure why no one started using Hiphop enmass and why people love using the inefficient eval method. O yeah there's also an issue with PHP and logic dealing with concurrency, in that there isn't a good way to distribute work within an app. Then again I could be completely wrong.
>> Maybe all of this will change once Facebook releases Hiphop VM AND people actually start using it.
The argument that PHP doesn't scale is a strawman. To scale anything to the likes of Facebook or Google you have to have serious architecture in place regardless of the language you choose.
"it was easy to see why PHP got big"
It's easy to see why it's staying big:
1. cheap shared hosting to get started 2. most hosts offer one-click installation of any sort of application people need on the web (blogs, shopping carts, calendars, social networking, file hosting, etc) 3. 15+ years of knowledge about what works and what doesn't when attempting to scale PHP to large needs. 4. ubiquity which keeps a large pool of reasonably priced talent available, which perpetuates the cycle.
When there's a competitive language that can be placed in a directory as FOO.abc, I can hit it as /FOO.abc and have it execute, with html content type sent by default, it'll have a running jump at dethroning PHP.
The barrier to entry is the lowest out there, but the heights it can scale to are facebook-level and beyond.
For some reason most of the major frameworks use it, hence their incompatibility with hiphop; then again I could be wrong.
> 1. cheap shared hosting to get started
One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area.
> 2. most hosts offer one-click installation of any sort of application people need on the web (blogs, shopping carts, calendars, social networking, file hosting, etc)
With the rise of the cloud hosts and automated config, as well as more automated tools available (e.g. Chef, Puppet), this is a temporary advantage. Deploying on Linode and Heroku and (insert cloud host company) are getting easier and easier.
> 3. 15+ years of knowledge about what works and what doesn't when attempting to scale PHP to large needs.
No argument here. My points only apply for people starting now, and not for PHP vets.
> 4. ubiquity which keeps a large pool of reasonably priced talent available, which perpetuates the cycle.
No argument here either. My points were being made for individual programmers who are just starting out, and not for companies.
Even from the point of a company though, PHP's current lack of flexibility lowers the chance of innovation imo. The other dynamic languages are just as easy to learn and they just offer more than PHP does.
I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that.
>> 1. cheap shared hosting to get started
>One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area.
Really? I think there's far more options for people with 'PHP' in the hosting arena. It's not that you can't use other languages/platforms, but ... competition for hosting basic PHP stuff is massive - not so much for Ruby/Rails, Python, etc. along with all the extra stuff you'd need (community libraries and such) - much more is baked in to PHP hosting than you get with the majority of other platforms. Java in particular is expensive to host anything useful because it's RAM hungry.
re: eval - do you have pointers to examples? I just grepped Zend Framework 1.10, and there was 1 eval, in Serializer/Adapter/PhpCode.php, with a warning that it shouldn't be used.
Ruby and Python aren't very new. There are giants there as well. If you're going to make that argument, then Java has a bigger advantage.
> I think there's far more options for people with 'PHP' in the hosting arena.
As I've already said, I don't disagree. I just said that this advantage is going away. Personally I'd also rather go for host that's mid-ranged as opposed to hosts that are in the race to the bottom. I don't think paying $10 more a month is exorbitant especially if it buys you a lot of language power and it takes over more sysadmin duties from you.
> re: eval - do you have pointers to examples?
Every major PHP framework uses it. How do I know? To my knowledge you can't use any of them with Facebook's hiphop out of the box. I suspect this is one of the main reason's no one uses hiphop even though it gives you a good deal of performance gains for PHP.
Zend Framework 1.10 - a fairly high-profile framework - has 1 instance of eval in a component I've never known anyone to use. I suspect hiphop has a few other issues with it, but... even more to the point, I don't think most people think they need hiphop. It's an unknown - it's a compilation step, and adds a couple extra steps of complexity. People can get a lot of performance gains by using Zend Server caching or APC with far less unknowns vs digging in to hiphop.
Additionally, hiphop has had some issues with postgres/pdo, closures, imap and more PHP stuff over the last year or so. It's a nice thing from facebook, but it was written for their own problems, not as a general use tool for everyone. If it can evolve in that direction, the adoption may go up. Until then there's far more well-tested ways to improve your performance of PHP.
It's why PHP would be the best tool for the job once you have a specific objective in mind.
When you have a specific problem to solve other than 'supported by millions of cheap webhosts' PHP is rarely the best choice.
It's like a swiss army knife, it's highly useful in many situations and a good tool to have in your pocket, but if you know you're going to need to unscrew something you should probably bring a screw driver.
There are hundreds of examples that show how bad PHP really is. Why make the choice of using a broken language when there are so many better alternatives?
I strongly believe that using a complex, non consistent and hard to debug language actually slows down development and is even dangerous.
Being "absolutly everywhere" is not an argument. COBOL, PASCAL and FORTRAN used to be everywhere too.
If Facebook powered its front end using FORTRAN, I would call it a quiet powerhouse, too!
The thing is, why choose a flawded language when there are others less flawed (nothing is perfect) for new code?
Building your application as a series of small applications that work with each other is a solution that has worked for me.
So you're quite right, but I hope you would agree that the Rails/PHP comparison, in spite of its imperfections, is compatible with the point I was trying to make.
Although that is not necessarily a bad thing.
Perl, on the other hand...
After thinking about it a bit, it seems that your reasons for suggesting PHP for beginners are about the same as the reasons people gave three decades ago when suggesting BASIC as a language for beginners, namely the norm of having GOTO and global variables everywhere.
Just as GOTO and global variables make it easy for a beginner to easily pick up programming, embedding raw code in your pages and having only one file organization makes it a lot easier to pick up web programming. And yet at the same time, all four are eventually shown to be "considered harmful" - the only ones who advance are those who are willing to abandon the first things they learn while the rest are doomed to mediocrity.
Now don't get me wrong, I don't think PHP or even BASIC is inherently bad (well, they are, but at least they're not MUMPS or Brainfuck). I just don't think teaching bad practices to newbie developers is a good way to promote a language.
I believe you have overstated your case, perhaps due to inexperience with other languages. In particular, claiming that any modern scripting language is inflexible sounds a bit crazy.
I have attempted explaining how to get a WAMP stack running, with EasyPHP, to an absolutely new-to-web-dev indiviual who was curious about creating a chat room. Let me just say that the situation is ten times better now than when I was the same age and was poring, lost, over Bruce Eckel's Thinking In Java trying to do the same thing, which must have been sometime around 1999/2000.
These efforts to teach a newcomer reminded me that there's a lot I take for granted. There is a step where you are saying "okay, we've got to see where Apache is; what port is it listening on, how can we get you to phpMyAdmin; here's how you set up rows and columns in your tables and think about a database; no the reason it's not working is because you saved as '.html' and not '.php'; I know you've seen URLs that don't end in '.php' but that requires invoking the Rewrite Engine and teaching you about .htaccess files; oh the header modifications can't be the first thing you emit; here's the docs, you basically have to search them because there is no organizing principle and no way to find out what you can do..."
I agree, Python+Django will make you learn a bunch of weird "modeling" stuff first. To me, setting up the data model at the beginning of an app is like inputting a character name at the beginning of an RPG: as some sources testify [1], you can easily waste several hours on purely aesthetic concerns before you even really start to play.
Nonetheless, Python+Django comes with a lightweight dev server and an interactive console and a routing table, as well as a template language. The knowledge of the database is internalized to the language, so that I don't have to teach someone how to use phpMyAdmin but rather when to use a ForeignKey. If we talk purely about learning to develop on the Web then PHP has much, much more useless overhead.
Sure, eventually we will have to get a production-ready web server communicating with the application, but that can be abstracted until later with Django: it occurs as an up-front teaching cost with PHP.
I say this not even as a Python aficionado per se. If anything I like Node, and Node is nowhere near either of them in offering pleasant functionality.
What I meant to say is that you can't use either of them in direct conjunction with HTML the way that you can use PHP. This was what I meant when I said "genuine functionality from scratch." Would I prefer Python+Django/Flask for lots of use cases. Absolutely.
As for the "useless overhead," there are things like the command line (which Python and Ruby web dev absolutely demand) standing in the way of some of the other languages. Personally, I strongly prefer the command line for almost everything, but for beginners this is another barrier.
My argument was not for the superiority of PHP over other languages, but rather against its casual dismissal from consideration.
Also, if command line is a barrier for an aspiring (web) programmer, he/she should start looking for a new career path.
2. Is it unthinkable that a person could start learning web dev and pick up the command line along the way? I started out learning PHP/MySQL on my old Windows machine, terrified of the CLI, and now I do almost everything on it (and have converted my old PC to Linux). If the command line were a barrier at all points in the learning trajectory, then you might have a point. But I also don't think that command line mastery should be held up as a sine qua non of learning web dev.
2. You don't have to be a command line expert to start using it. All the books at http://learncodethehardway.org/ show that command line can be integrated in the language learning process seamlessly. No reason to be terrified of it, on the contrary, new coders should embrace it as soon as possible.
In some ways this is true but I would be hesitant. What you're really advertising is that PHP has an implicit `echo("` statement which looks like `?>` and also implicitly occurs at the beginning of the file. A lot of new folks write really hard-to-follow code. Here is the seed of badness from which such code eventually germinates and blossoms:
<ul><?php
foreach ($users as $user) {
?><li class="user"><a href="/users/<?php
echo $user['id'] . '">' . $user['name']. '</a></li>';
?><?php
}
echo '</ul>';
Python+Flask will force you to either do it in a Jinja template, which avoids the problem because you cannot 'return back to Python' midway through:
<ul>{% for user in users %}
<li><a href="/users/{{ user.id }}">{{ user.name }}</a></li>
{% endfor %}</ul>
output += """
<!-- ... more code ... -->
<ul>""" + "".join(["""
<li><a href="/users/%i">%s</a></li>""" % (u['id'], u['name'])
for u in users]) + """
</ul>
'<li><a href="/users/%i">%s</a></li> % (u['id'], u['name'])
for u in users]) + """
Despite the stigma attached to PHP, it's my go to language for web stuff because it gets shit done very very quickly.
You can't beat drop file, edit, refresh and entire deployments which can be done with cp/scp and no process restarts.
In what way does PHP help to get things up and running faster than other languages?
I prefer to work in python, but I don't much care anymore, each language has it's strengths and weakness' but PHP most definitely is good for getting things done "very very quickly"
And yes I did a lot of PHP but that was 5-6 years ago. I know things have changed a lot since then but the language still has a lot of the same flaws.
The language has as many flaws as it's always had but it still works.
// $var = foo(bar);
$var = baz(bar);
OP admittedly has less than one year of web development experience. Perhaps it would be wise for OP to gain a more thorough understanding of web programming before coming to conclusions like this.
PHP could be a wonderful thing if not for its original sins. It is easy and fast, but it is also bad. It is "good enough", and for many years it prevented just "good" from arising and gaining adoption.
I would pick "good" over "good enough" even if it costs me a bit because I think this is fundamentally right.
Do you?