This article includes the same false assumption of just about every other article on PHP:
PHP is Easy
I'm not sure how anyone can claim that a language which only exposes the underlying C API of all the included libraries could be considered easy. Does no one stop to think that the reason 99% of PHP code is bad is because the language is actually hard? It's the C of scripting languages; it doesn't include a lot of fancy constructs or high-level abstractions. And, like C, that's what makes it powerful.
I think confusion exists because PHP is extremely accessible. It's intimately connected with the web environment (more so, and less securely, in the past) making it quick to get started. But that has never made it easy.
> I'm not sure how anyone can claim that ... could be considered easy.
PHP is Easy, and it's easier than Perl, I'd be surprised if you argue with me on that. PHP has very little to trip you up mentally (or at least that was definitely the case when it started winning). No closures, "arrays" are just hashes etc.
PHP is not hard. Actually the hardest thing about PHP could well be its dynamic variable names, like $$foo.
Neither is PHP powerful, it is extremely un-expressive when compared with just about any other modern programming language.
With PHP you _just_ use the clean wrappers on the C API, and that is also easy to do, no knowledge of C required at all. It's so easy you can pretty much write PHP apps without knowing that "4" is any different from 4.
I don't know if I've convinced you, but honestly, I would have a hard time making a language that was any easier.
PHP is a simple language, but that doesn't make it easy. PHP does give you enough rope to hang yourself, and unlike most other languages with a similar property (like C, C++, and Perl) PHP gets too much blame for that.
I think Python is a far easier language. No $'s, much greater consistency, more available abstractions.
You can pretty much handle most of the common complaints of PHP and build very large complex code bases, however, you have to put in the work. Other languages have that work already included.
Ah, well this is where we differ, I'd say PHP is easy, not simple, and that Python is simple not easy.
My reason for feeling that way hinges upon Python having more available abstractions.
Scheme is an exagerated example of this. Continuations are a very simple idea, you can describe call/cc to someone without much hassle. But the implications of call/cc can be very difficult to grasp.
The closure is a lesser example of a simple, pure abstraction which allows complex code through this devious form of simplicity.
So that is (pretty much) why it is very easy to reach expert level in PHP but very very hard in Scheme.
At the end of the day, what's easier to learn:
closures, or
the fact that a callback (in PHP) is supplied by giving its name as a string?
Its easier to not learn something than it is to learn it :)
I think I can explain the problem. I taught PHP for a semester at the college level to Web designers. I had 3 months (1 class a week) to get them from no programming experience at all to having a small web application (a contact list). Mostly they all managed to accomplish the task but obviously there's only time to cover the minimum functionality necessary. In that sense, PHP is easy.
Now, here's the problem, absolutely nothing they learned is useful for building a reasonable-sized long-lasting web application. They didn't use any classes. They didn't use a template engine. They didn't use a database abstraction. They learned PHP but they didn't learn to use PHP to build real applications. So all that easiness of PHP is all wrong. If you want to do it right, it's not easy.
"So all that easiness of PHP is all wrong. If you want to do it right, it's not easy."
However, much of the time getting people to do it at all is harder than getting them to do it right after they're doing something. PHP makes it easy to start doing something and see results, and that immediate reward prompts those who wouldn't otherwise get that far. A coupla weeks ago, tptacek made this point, and I think it applies here:
[Edit: to be clear, tptacek may not have specifically been talking about PHP, but about the fact that writing lots of code is an indicator of total usefulness even if the code is currently bad or inappropriate.]
PHP is a templating engine. Writing a templating language for PHP, like Smarty, is like writing a second templating language running on the first templating language.
PHP is a crappy template engine. Inlining code into an HTML document requires a lot of discipline, a lot of code to write, and is error prone. Why not let software handle that task for you? You want to create more work for yourself?
Don't want to inline code? Well don't inline code. No second templating engine can reduce complexting any more than using PHP directly as a templating language. PHP was built as a templating engine from day 1.
There is a reason why php scripts start with <? --- ?>
Isn't that reduced complexity? And that's not even getting into other constructs. In my template language (based on smarty), a single {loop} tag expands to 10 lines of PHP code.
Would you also claim that no programming language can ever reduce complexity over assembly language? Probably not. This is just the same thing. Compiling a higher level language into a lower level language.
Of course you have to define function h() and loop() somewhere. Just don't do it in your template file and you are fine. Hardly saving you even one line of code. We are down to counting how many charecters each need.
Would you also claim that no programming language can
ever reduce complexity over assembly language? Probably
not. This is just the same thing. Compiling a higher
level language into a lower level language.
Bzzzt wrong. And this is why having a template engine might be a good thing. <?= isn't 'safe' because it can be disabled in the php.ini file (and is disabled by default). If only you had a template language that keeps you having to know that! Also, the default is that your html escapes -- you can't forget to wrap your variable in the h() function. So it's already less error prone. And this is still just a simple example.
"PHP's loop: <?while(loop()){?>"
It's at least <?php while(list($key, $item) = loop($iterator)){?> to be correct and useful. And the template engine can inline the code (rather than call a loop() function) for better performance.
All those correctly expanded PHP tags intermixed in the HTML makes the template harder to follow. You might want to type twice as much identical code for each output variable, but I don't want to do that. It is an advantage that it's cleaner and clearer.
This is a web app for God's sake. You have full control on what your php.ini have. Which one is more complex? Install a templating language? or ensure your short-tags=On (or whatever that is) in your php.ini. And if you are talking about hosted service, short tags are by default kept "On" on most hosted services, if not all.
Imagine typing your full page like this! You need to enclose each of your line inside a quote and also escape all quotation marks inside it. Here code and design are mixed in real sense. These are the languages that really need a templating engine.
And the template engine can inline the code (rather than call a loop() function) for better performance.
Here is an idea, better performace is gained by not loading the templating engine at all. Whatever number of chars typing saved is more complicated by loading and initializing the whole templating engine. Even that is not enough, which is why Smarty has {if}, {else}, {switch} statements. So long for seperating code and design.
You might want to type twice as much identical code for each output variable
I am not typing identical code even once.
If only you had a template language that keeps you having to know that!
We can continue discussion without making attacks? No?
"You have full control on what your php.ini have."
If you're writing, for example, an open source application or an application that is hosted by your customers (I have worked on both) you can't assume you have any control over the php.ini. The recommended php.ini file has short_open_tag disabled and having short_open_tag enabled makes it more difficult to use PHP to template XML files. It's not deprecated yet, but I wouldn't count on it sticking around forever.
All my PHP software works irregardless of the php.ini settings and works across all platforms. If that's not a concern of yours, that's fine. We just have different requirements.
"<?while($r=loop($rs)){?>"
You're making the assumption that my template constructs are just simple 1-to-1 mappings to PHP statements but that's not the case. My {loop} tag gives access the previous entry, whether or not the row is odd or even, whether or not it's the first and last entry, etc. It's a very powerful tag for the kind of common tasks that come up in a web application. But that's just one example, there's also tags for caching template blocks as well as tags for interactive controls. The level of complexity that's hidden behind a few simple tags is enormous -- which is entirely the point. I have lots of code which uses PHP itself for templates so I'm aware of the difference. I didn't start using templates, I started the other way and worked towards using templates because they make the job easier and quicker.
"Here is an idea, better performace is gained by not loading the templating engine at all."
For a compiling template engine, there's the initial cost of compiling the template when it's been changed but then there is very little additional cost. It generates a regular PHP file that's run just any other. Once the app has been running for a few minutes the template engine doesn't need to be loaded at all.
"We can continue discussion without making attacks?"
That wasn't an attack. I was making a point -- the template engine insulates you from all kinds of problems. If you forget to wrap some variable in your h() function, you might never even notice. However you've just opened yourself up to a cross-site scripting attack. And even if you never make mistakes ever, you might not be the only one working on it.
There is no reducing it. There is controlling who deals with it. Hiding gobs of details behind a single {loop} construct was probably a huge hassle. For the designers and non-coders touching the templates though, the complexity is gone. It isn't really, of course. It was only transferred from them to the programmer. But from their point of view, it is.
No. C is a very elegant, if somewhat minimalistic, language. PHP is a kludge made of all sort of functions cluttering the only namespace there is. While K&R clearly understood the value of separating language from library, PHP deliberately ignores this lesson. I heard the most recent version (or the next, maybe) will support namespaces. It started as a quick-and-dirty solution for writing dynamic pages and, sadly, it shows.
I somewhat fail to see the power of a language as something derived from lack of fancy constructs or high-level abstractions. And, BTW, C has a lot of fancy constructs and high-level abstractions: you just have to point the right libraries to the compiler/linker.
I am sorry to tell you, but the main reasons PHP is so popular are the low cost of labor and the lack of interest by a large group of self-appointed programmers in learning anything, as you say, fancy.
"PHP is a kludge made of all sort of functions cluttering the only namespace there is"
Yeah, how many namespaces does C have again? If you were to write a web application in C with all the same open source C libraries as are available for PHP, your only namespace in C would look almost identical.
"While K&R clearly understood the value of separating language from library, PHP deliberately ignores this lesson"
Ironically, this is exactly what made PHP successful. Everything is included in the box. It wouldn't have been half as successful without including every useful library they could find.
"C has a lot of fancy constructs and high-level abstractions: you just have to point the right libraries to the compiler/linker."
You're not going to get closures, classes, meta programming, etc, etc, from libraries in C. And guess what, PHP has libraries too!
"Ironically, this is exactly what made PHP successful. Everything is included in the box. It wouldn't have been half as successful without including every useful library they could find."
I am all in for including interesting stuff, but not at the expense of forcing everything in at once and thus cluttering the only namespace people have to work. While C has only one namespace, you only include the libraries you need.
"You're not going to get closures, classes, meta programming, etc, etc, from libraries in C. And guess what, PHP has libraries too!"
While C has no syntactic support for closures and classes, C programmers learn how to build them from scratch (or use some other person's library to support that - after all, C++ stated as a preprocessor that generated C code). Are you sure you are familiar with C?
Compared to many of the alternatives at the time, php was easy. Until you are trying to make a large application that needs lots of abstraction and careful architecture, it stays easy. It is very easy to get something to work quickly in php, it's just hard to maintain a large project in it.
And it is much more accessible than almost anything else when it comes to web programming. Compared to rails even, php is a snap to set up and use. Rails has the disadvantage of being a framework, which means more learning up front. Php has the disadvantage of being (until v5) almost impossible to organize coherently, and so becomes hard to upgrade later.
Php is easy; until you've gone too far to turn back. :(
You can build projects that large and easy to maintain in PHP, but you won't find many examples of that in the community. You can organize your PHP5 code just like almost any project in Python, Java, or .NET. But you do have to write a lot of code that isn't necessary in those other languages because they already have it included (and it's the standard way to do it).
I find most PHP code in the wild totally appalling. It's easy to blame the tool.
I understand what you are saying but I think most of the articles that say PHP is easy, they mean easy to set up and get started. I guess the right term would be as you said PHP is accessible.
This article says "I think PHP is a great language for anyone to learn how to program with." So he clearly thinks PHP is easy rather than just merely accessible and I couldn't disagree with him more.
You're making the assumption that C is hard. C was the second language I learned (after QBasic), and it was easy enough to make working rinky-dink applications even as an ignorant preteen.
I think confusion exists because PHP is extremely accessible. It's intimately connected with the web environment (more so, and less securely, in the past) making it quick to get started. But that has never made it easy.