I come from a C++ background, and early last year tried my hand at web development.
After hearing about all the stuff about how PHP was an "old", kludgey language, I tried to learn python, and go the webpy. It was doable, but I kept running into issues all the time.
I gave up and switched to PHP, and I have to say that it was a much easier experience. For the most part, everything just worked. Regardless of how kludgey its history is, how inconsistent the syntax is, etc, it really does work well. I'm now doing PHP development at my current job and it's been fine.
One thing I learned from a previous job was the saying "Your customers don't care about your technology. They care about you solving their problems." If you are solving their problems, they will pay you, regardless of whether or not your back-end is CGI, perl, PHP, or whatever.
I don't do much PHP anymore but I can see the appeal coming from a c/c++ perspective. When I was doing PHP I felt closer to the metal than I feel with Python now.
A lot of the PHP libraries looked like thin wrapper over well known c libraries. Instead of shoehorning everything to make it PHPonic, the function calls were similar to their c counterpart. You could sometimes even read the man pages for the c libraries if you needed extra details on how the internals worked.
There was a simplicity to this that was appealing to me. The lesser amount of magic and abstraction meant I could more easily visualize what was happening under the hood and find bugs quickly.
"PHP Should Be Implementation Neutral, and Support All Paradigms Equally".
This is what I like about PHP. When you want a 4 page site, you can use procedural and functional programming. When you're working on an enterprise level CMS you can whip out the OO paradigm and you're set. PHP is a messy soup but it does web better than most other languages.
One nice side affect of this is that PHP can suit both novice and experienced programmers. Newbies don't have to learn OO before they write Hello World.
Yeah, and thanks to this, you end up with a "beast" like Magento, written by "experienced" programmers, and then you have novices tasked with writing themes and components for it, but it doesn't work that way because the "beast" is not "black boxed" well enough for the novices to ignore it. (I keep quoting "experienced" here because the example Magento is just "Java written in PHP" and I'd fire anyone turning up this type of code.)
Having had the unfortunate experience to work with Magento recently, I completely agree with your evaluation. My reoccurring thoughts were exactly "this is Java written in PHP!".
Then please spread the word and stop clients/managers from choosing it! Let's stop others from falling into the "look, it even has ebay integration!" trap!
Unless you can offer any real alternatives to Magento I have to call bullshit, yes the framework is far from perfect and PHP is not the prettiest language.
But calling Magento "Java written in PHP" without offering alternatives, specific criticism or any backing of the argument is just childish.
That's also a problem because anyone with a day experience in PHP can claim to be PHP developer, and often companies can't really tell the difference between an experienced and non-experienced programmer. If they can do PHP, they can build our website and we end up with horrible unmaintainable code. I think that's why PHP has such a bad reputation.
...naah, any kid can learn Brainfuck in a weekend ..."real" programmers don't even need a 100% Turing complete language to get the job done: choose Malbolge instead! (http://en.wikipedia.org/wiki/Malbolge)
I get your point, but being easy to pick up AND easy to make dangerous mistakes is a bad combination. The goal isn't necessarily to "weed out the stupids", but rather to prevent bad practices from propagating. "Too easy", in my view, means having a rotary saw with no guard and a hair trigger.
In a way this means nothing: experienced programmer can program in any language.
In another way it is wrong: experienced programmer know how so well that building a solid application on rotten grounds is a pain, and would prefer a more solid ground to build their application upon.
Are the sort of people writing straight PHP the sort of people who would be using rails? Try a PHP framework like Laravel and then compare that to Rails.
I took a look at that, it appears that you unzip the framework and then start modifying it directly. After you "upload it to your webserver". Deployment? Source Control? No, not in PHP, you just modify shit right on the webserver.
I'm sure this process makes upgrading painless, just unzip the framework and... wait... all your changes just got overwritten.
This kind of crap is exactly why everyone with a clue laughs at PHP.
No. Everyone knows that you do not modify the framework files. Hell, everyone knew that you do not touch the framework system files years ago with older frameworks like CodeIgniter, so it makes me doubt that you have any experience with PHP frameworks at all.
You would upgrade your Laravel framework with composer, which runs on Git. And it'll most likely just work without any "Gem hell" that i've come to experience with some other languages.
The docs don't say that you would update the framework via composer (though this may change when Laravel 4 is released) but they do say that you should just replace the "laravel" folder with a new version using whatever method suits you best, which can be even easier. It certainly seems easier than upgrading Rails, since then you can update your whole remote application code and framework in a single push.
The docs clearly explain that your bundles go to the "bundles" directory, controllers go to the "controllers" directory, views belong in "views" and so on. And your whole application resides in a directory called... "application". You'd actually have to be pretty advanced and amazingly stupid at the same time to make a functional app in the framework core folder and than destroy it by overwriting.
Rails docs don't tell me to unzip the framework and start hacking, but they do instruct me to run "gem install rails", wait a couple of hours till it's done, then run "rails new blog", "cd blog" and then start hacking. Neither set of docs tell me how to setup version control before i begin my work, and they shouldn't. That's not the job of the framework docs.
And of course you're gonna hack your application directly on the server, albeit a local one, as PHP applications are typically developed. This in no way prevents you from using version control and proper deployment techniques.
Nothing stops you from using source control with PHP. Nothing stops you from working locally and then pushing changes up to the server. You make no sense.
The problem with php is that is scales terribly with the size of the codebase. Try to move away from the comfort zone of the language and the size of the project and it changes a lot.
The codebase of Wordpress is an utterly terrible, offensive, kludgy, hacked-together mess of spaghetti code. The last time I looked at the internals it still lacked a coherent MVC structure. There are big, good things built with PHP, written the right way with solid software engineering principles, but Wordpress is not one of them.
The number of users is not equivalent to quality. It's an indication of quality.
As for quality...
No, Wal-Mart isn't a purveyor of items with the qualities of being expensive, extremely limited, and old.
Quality is a subjective word, defined by different aspects. Just as I can, with justification, define Apple as a purveyor of low-quality hardware, I can say equally it sells high-quality software.
It's not even an indication of quality, it's an indication that many people use it.
I guess you can quibble about definitions all day if you like, and you can take "family heirlooms" literally instead of metaphorically as it was intended, but that won't make Wal-Mart a seller of quality items nor will it make PHP a well-designed language under any sort of definition that is relevant to reality.
And, honestly, if the only thing we're going to argue about is whether or not quantity equals/implies quality and the definition of "quality", the argument against PHP has already won.
As you say, quality is defined by a number of factors. I'd say that a good, high-level general purpose programming language should be:
- coherent
- non-verbose
- provide solid high-level abstractions
- safe
- have a solid standard library
- optionally, easy to get started with
Of all these qualities, PHP is geared toward "ease of access" with a sprinkling of non-verbosity, and fails mostly or totally in the other categories. Just like the popularity of the Millenium trilogy does not mean Stieg Larsson can write, the popularity of PHP is more an indication of its low barrier to entry (especially combined with widespread hosting support) than anything else.
> Just like the popularity of the Millenium trilogy does not mean Stieg Larsson can write
Technically, it does. =)
I'm surprised you wouldn't consider the license a language is released under as one of the factors. Or maybe you do, and you forgot to list it. And therein lies the issue: the number of people are indicative of certain qualities, qualities you might not consider important, or might not weigh as highly as other people.
I love erlang, but I'd be hard pressed to use erlang for as many projects as I would like. Not because of failings of the language itself, but because certain qualities it does not possess (ubiquity for one, which affects so many other areas).
Yes, it is a "good one." Wordpress' source looks like spaghetti with shit sauce. The fact that it runs is a testament to something, but not the readability, maintainability, or usability of the code base. Those people wouldn't know a well-designed API if, well, fill in the rest here.
Whatever else you are, you're not too stupid to see what's wrong with this argument. So the fact that you're forwarding it anyway means you can't make a real point, or you are trolling.
Facebook _doesn't_ run PHP. A large portion of it is coded in PHP, but it runs C++ through HipHop[1]. Facebook may as well be written in anything that compiles down to C++.
Actually, the difference between compiled C++ code, and the newest version of PHP with APC/Xcache is not that drastic, but facebook needs to squeeze out every bit of performance so they can to cut down on the number of servers.
If you have experience in c++, I have used Wt [0] previously for webdev and found it pretty straightforward (it's like Qt for the web) and extremely performant. Dual license GPL/commerical.
It sounds like you've never properly programmed in php a day in your life. Stop spouting nonsense. If you're going to develop in php, you do so in strict mode with all errors turned on. Doing otherwise makes you part of the problem.
I'll accept this argument when PHP starts shipping with sane defaults. It's only quite recently that register globals got turned off in the default config.
Yes, it is PHP's fault. It's endemic to the general attitude of the PHP team.
"Now just marginally less braindead than every other language" isn't exactly a selling point.
Sure, it used to be worse, but I see zero commitment from PHP to actually make real steps to fixing the situation. A real first step would be to start working on a 6.x release that actually removes the gazillion deprecated-but-still-present-and-thus-used things in the language.
After hearing about all the stuff about how PHP was an "old", kludgey language, I tried to learn python, and go the webpy. It was doable, but I kept running into issues all the time.
I gave up and switched to PHP, and I have to say that it was a much easier experience. For the most part, everything just worked. Regardless of how kludgey its history is, how inconsistent the syntax is, etc, it really does work well. I'm now doing PHP development at my current job and it's been fine.
One thing I learned from a previous job was the saying "Your customers don't care about your technology. They care about you solving their problems." If you are solving their problems, they will pay you, regardless of whether or not your back-end is CGI, perl, PHP, or whatever.