Purportedly, a template written in Ruby is unclean. I’ve seen the same belief in the PHP world; it has led to the creation of such absurdities as the Smarty templating system. Think about it: PHP is itself actually a templating system (arguably an overgrown one), so Smarty is basically a templating system written in a templating system.

And over here in Perl-land, we have the same misconception. All over, people seem firmly convinced that templates must be written in a language different from the one the main code is written in.

But why? After all, most templating mini-languages I’ve seen have accrued features until approximate Turing completeness anyway.

The core question is, what essentially happens when you use a templating system with a mini-language? What is the “main code” and what is the “template?” Ideally, the “main code” is the controller and the model, whereas the “template” is the view. Hence, using a template mini-language theoretically forces you to separate the view logic from the controller and model logic. But do you truly need to change languages to do that? No. You don’t. What matters is only that you have a clear understanding of your design, so you can understand which part belongs to the view and which to the controller (or to the model).

In fact, even the use of a templating system does not save you from concern creep, since the mini-languages of powerful templating systems are relatively complete. I’ve seen cases where this mini-language was used to fudge things into the view which should have been implemented in the controller.

Given, then, that you have the choice to write the view logic in whatever language you deem appropriate, why not use the language you already know best? Isn’t that much more productive than tying yourself up with yet another ad-hoc mini-language in all its glory of undirected design, organic growth and arbitrary limitations?

… does the world really need another PHP?

PHP 5 is quite a limited and ugly language IMNSHO

Fair enough

why is the standard library so poor and inconsistent?

In PHP5? For backwards compatibility given a significant chunk of the world using PHP4 - i.e. nothing’s changed - PHP is just as ugly as it’s always been. If you want clean implementations, head to here - http://www.php.net/spl . The flip side is PHP has always been no much more than a wrapper on C and that can be a good thing as you don’t get someones fresh idea of what a good API design is. Some of Python’s API’s, for example, enter the territory of someone attempting to be too smart e.g. urllib/2 - times I’ve played with it I’m crying “Jesus! Just copy lwp for Christ sake!”. But that’s my MNSHO now.

why dosesn’t it support Unicode properly, except for the UTF-8 encoding?

PHP5, by default, doesn’t support UTF-8. It doesn’t really have any awareness of any character encoding other than ASCII and what your current locale setting is (which I believe is more or less the same position Ruby is in). The iconv extension is bundled by default but character set conversion is not character set support (i.e. what does strlen() tell you). There is the mbstring extension which can magically replace some (but not all) of PHP’s string functions but not all and it’s not part of the default distro. For Unicode you’ll have to wait for PHP6 which may be out sooner rather than later - there’s some info here (PDF) - interestingly looks like it will be using ICU so it may be a shot in the arm.

why does it require to put a dollar sign in front of every variable?…

Probably Perl inspired. Basically makes no difference once you’ve got used to it - similar issue for new users like whitespace in Python.

Why would you want to stick with PHP even in situations when you can
use Python, Ruby, or anything else?

Well first, because once you know it, it basically makes no difference (yes there are many gotchas to learn but once learnt, that’s it). David may disagree and to an extent I’d agree with points I can imagine he’d make. But the only really significant thing about PHP that programmers need to know about is they’ve chosen not to take the road of metaprogramming - instead of mixins / metaclasses PHP5 has interfaces - i.e. PHP isn’t tending towards LISP.

Another reason: PHP is getting mature in it’s own field. Was recently surprised to discover Perl’s DBD::Oracle driver doesn’t support Oracle collection types (resulting an a slow and ugly hack generating PL/SQL on the fly). Was more surprised to find that of the dynamic languages it seems only PHP does does.

Side observation: it’s interesting how much X vs. PHP debates are becoming more and more like Java vs. Visual Basic. Whatever gets you on I guess. And PHP most definately is the VB of the Internet.

Re the orginal post: so why WASP vs. one of X thousand other PHP frameworks or even this?

[..] , scripting languages can be quick to write, but since they do not have
many of the advanced features of compiled languages like C++ and Java, [..]

This was about where I stopped taking the post serious; it’s Java that
lack the advanced features, for example lists and hashes as builtins with
nice syntax.

“And isn’t a good ecology of frameworks in many different languages a good thing? We can all (hopefully) learn from one another and collectively work towards getting better and better at building great software.”

Agreed! Can’t we all just get along? :)

Personally, I find Python to be very pleasant language to work with. From my perspective, white-space-as-syntax is a beautiful thing, and it’s hard for me to understand why others don’t see my point of view. But I know a number of programmers — much better guys than me — that won’t touch it. They hate the syntax, and they don’t think Python is “Enterprise” enough. To each his own, I suppose.

The way I look it, lots of really impressive stuff has been built using Java, Python, Ruby, PHP, Perl, C#, C++ Cold Fusion — and hell, even Visual Basic. All languages are useful tools. There are intelligent people who use all of these languages and enjoy doing so.

Now in the spirit of a lively discussion, here are a couple of real-world reasons to use PHP:

• There is a veritable army of developers out there who already know how to use it. Ugly or not, it’s a very well-known language, and that means it’s easy to find folks to work on it at a reasonable rate.
• There is a staggering amount of free, repurposable PHP code already out there. Flexy is one great example. Rather than start from scratch, WASP was able to make use of a very mature, tested, and well-understood templating system. In PHP-land there is endless opportunity to wrap and extend existing code just because there’s so damned much of it in the public sphere.
• Many business already have deployed PHP applications and have folks on staff who can work with them without additional training.
• PHP — like Java, Ruby, Python, Perl, etc. has been had been used to successfully build large, complex and heavily used applications.

I come from the perspective of owning a small (10 person) custom software company, and we helped fund the development of WASP. I started my career in an in-the-trenches programming position, but these days I tend to think about these issues as much from business perspective as from a technical one.

When working with our clients, my big concern is delivering a highly functional and maintainable solution for the lowest possible cost. I also deal regularly with conservative IT managers who are hesitant to let anything “new” into their shop.

Using PHP for custom solutions helps me in ways both practical and political. Finding experienced PHP developers is easy. Training folks on new technologies — especially with smaller projects, less costly projects — can chew through a lot of a project’s budget. Adding functionality by reusing existing free code is a great way to add value to a project. Also, a surprising number of business already have deployed PHP applications internally, so I don’t face an uphill battle convincing conservative IT managers to let us build in PHP.

And with all that said, I should point out the we’re not a “PHP shop”. We develop in Java, .NET/C#, PHP, Classic ASP, Python, Cold Fusion — really with anything required by the client. In many (if not most) cases the choice of technology is dictated by the client. So I have no religious attachment to PHP. Funding the development of WASP was just a practical business decision. We’re already rolled out one solution build using WASP, and are just about to to complete another. And so far, so good. We’re been able to deliver two high-quality, cost-competitive solutions.

And isn’t a good ecology of frameworks in many different languages a good thing? We can all (hopefully) learn from one another and collectively work towards getting better and better at building great software.