lesscode.org


WASP - Easing the Switch from Java to PHP  

By Brian Fioca under PHP, LAMP on 23. October 2005

Author’s Note: I originally wrote this article on the WASP homepage. Ryan has graciously allowed me to post it here. WASP was partly inspired by lesscode.org, and hopefully it’ll make a good contribution to this community.

The year 2005, so far, has been the year of scripting languages. Across the web-application programming sector there has been a growing movement toward acceptance and general usage of dynamic languages like Ruby, Python, and PHP. Fundamentally, these languages have been present in the industry and in use by developers for a long time, and really aren’t anything new. Lately, however, due to advances in server technology, scripting language maturity, and improved development libraries, it is possible to write scalable, well architected, “enterprise” applications in less time with less code using frameworks like WASP for PHP.

Scripting languages have been used to build millions of applications on the Web, but in general have not been adopted widely by corporate developers. But more and more businesses and IT professionals are looking to these languages as a way to simplify and speed the creation of custom in-house programs, thus avoiding the now all-too-common logjam of late or overbudget applications. — CNET

It has always been faster to write applications for the web using scripting languages. PHP has long been accessible to the fledgling developer. It has been widely used for prototyping of large applications written in languages like Java simply because web designers, most often specialized in design artistry rather than computer science theory, are able to quickly grasp the syntax and embed it in their HTML code.

Interestingly enough, the same reasons why languages like PHP are so easy to learn and use are what often keeps seasoned software engineers from wanting to use them. Deemed “hacker” languages, 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, they have been prone to lax design practices, leading to code that isn’t efficient, stable, or maintainable enough for large solutions. With the correct mindset and help from structured frameworks like WASP, this no longer has to be the case.

Making use of the advancements made to PHP in version 5, web application architects can implement structure to their code in the form of tested design patterns and full-featured frameworks, like WASP. In fact, WASP was written to make the most pedantic software architect feel at home, in an effort to ease the transition for Java developers to coding in PHP.

It’s important to resist the gut reaction most people have to these statements. Most people’s perceptions of PHP are from the PHP 4 days, where “object oriented” frameworks existed, but were crippled by the loose OO implementation of the language. While PHP 5 is mostly backward compatible with PHP 4, it is almost completely different when it comes to things like abstract classes, interfaces, private and protected methods, and exceptions. Sure, you can write spagetti code in PHP 5, but if you have a well designed framework that keeps PHP code outside of your HTML and in tightly structured classes, you’re more likely to end up with code that looks and works and feels like Java.

But will using PHP confine application developers to small customers and fringe, open source communities? Not for long. The big guys are starting to catch on to this shift.

PHP, like open-source projects including Linux and Apache, now has received the blessing of major powers in the computing industry. IBM and Oracle are working on software that let PHP-powered applications pull information from their databases. — CNET

As the user base of PHP and other scripting languages continues to grow, broad support is becoming available on platforms trusted by the Fortune 500 crowd. This exposure will increase the rate of improvement to the efficiency of these languages. Early in its life, Java was highly criticized as not being scalable since it runs on a virtual machine, and therefore could never achieve the speed of C++. As Java matured, advances were made in optimizations to alleviate much of these concerns. The same sorts of advances are being made in the PHP language, and the hardware and software that drives it.

The goal of any good software development department or organization is to efficiently turn out code on-budget, and on-schedule. Until recently, platforms like Java were more likely to provide a stable, proven foundation to design and build well designed code, however by their nature they introduce a level of complexity that takes extra time to overcome. Using scripting languages like PHP tended to produce code in a faster time frame, but it was often impossible to maintain the architectural integrity necessary for building maintainable, extendable applications. With its strong design foundations, the WASP framework makes achieving all of these goals possible, providing the means to creating world class software to anyone with basic skills in PHP.

Further Reading:

WASP How-To
Andreessen: PHP succeeding where Java isn’t
Grassroots computing languages hit the big time
Java devotee BEA eyes scripting languages

28 Responses to “WASP - Easing the Switch from Java to PHP”

  1. David Heinemeier Hansson:

    “Rails also suffers because it is hard to decouple Rails code from page display code.”. WTF?

    Have you actually tried Rails? What part of MVC escaped your observant eye? When you talk about “Rails code”, what would you be referring to? Business logic? Controller logic? Hand-waving logic?

    Not only does Rails go to greater lengths than most to separate concerns, but it also ships with a host of solutions to better organize “page display code” (I assume you’re referring to view logic). From partials to helpers to layouts.

    Hell must certainly have frozen over with pigs flying across the skies. There’s no other day of the week that a PHP framework could be slinging accusations of poorly separated concerns.

    comment at 23. October 2005

  2. Brian Fioca:

    Excuse me, but I’m a little bit taken aback by your harsh comments. In fact, I have used Ruby on Rails, and I decided not to use it for the reasons I described in my article.

    “Hell must certainly have frozen over with pigs flying across the skies. There’s no other day of the week that a PHP framework could be slinging accusations of poorly separated concerns.”

    Have you used WASP? If not, how can you make such accusations.

    It was not my intention to attack Rails, but to suggest that a PHP alternative might be just as good, if not better in some aspects. I personally think Rails partials and helpers can be cumbersome at times. I also think embedded rails tags in HTML can be rather complex, and may lead to less seperation of display logic from business logic. I didn’t mean to turn this into a code-as-religion type discussion, although I suppose that is hard to avoid.

    I realize this stuff is controversial, however I’m not going to defend these ideas against mud-slinging.

    comment at 23. October 2005

  3. David Heinemeier Hansson:

    I didn’t accuse WASP (don’t know anything about it), but gave you a frame of reference for the non-sensical slander. I did PHP for 5 years before switching to Ruby. I used MVC, applicable patterns, and basically tried to live The Good Life. Yet still, I had to defend PHP at every turn because the base assumption was that it could only be used to generate big balls of mud. I think all PHP programmers have been in that position. Thus, I couldn’t fathom how someone still in the hood could deem it appropriate to use the same misinformed labels.

    Although my surprise of the original article is dwarfed by the disbelief that’s now mounting. Are you telling me that you couldn’t forsee the snowball that “Rails also suffers because it is hard to decouple Rails code from page display code” would create?!

    This has nothing to do with alternatives. There are plenty of reasons to pick PHP. Any $2 hosting firm supports it, modphp is easier to install than modfastcgi (if you’re new to Apache/nix), PHP has more boardroom pull (thanks to public support by IBM, Yahoo, etc). You could have picked any of these (and plenty more), but you didn’t.

    comment at 23. October 2005

  4. Tony Wright:

    Good lord– put down yer Rails Bible for a second. He expressed an opinion:

    “Rails also suffers because it is hard to decouple Rails code from page display code.”

    You responded with obscenity (”WTF”), sarcasm (”your observant eye”, “hand-waving logic”) and hyperbole (”Hell must have frozen over…”).

    Good lord, man. If your goal is to counter an idea, PERSUADE. If your goal is look like a histrionic geek who has joined the Cult of RoR and will not allow anyone to to even open the door to a possible downside of the technology… Well, you should do exactly what you did.

    Whoever has the authority to do so should remove these comments (including mine) to make room for real discussion.

    comment at 23. October 2005

  5. Ulysses:

    “You responded with obscenity…, sarcasm … and hyperbole …”
    Congratulations on correctly presenting three facts. Unfortunately you forgot to use these facts to prove a point or make a statement.

    I can only assume that your intent was to claim that these styles of communication are not valid. But I shy away from making that jump, as it requires the assumption that you are a facist.

    And Good Lord, man. If your goal is to counter an argument, COUNTER THE ARGUMENT. Don’t go all meta and explain why the other parties’ style of argument is unacceptable to you.

    Your plea to erase these comments reminds me most of a certain novel by G.O. Perhaps while we’re at it we should remove pages we don’t like from the encyclopedia.

    comment at 23. October 2005

  6. Joe Anonymous:

    In my experience, the main perceived advantages in using PHP are:

    1. it is supported by all the web hosting solutions, even the
      cheaper ones;
    2. it allows to create quick’n'dirty prototypes by inlining code
      and HTML (no Big Design Up Front required, a wonderful
      feature for inexperienced programmers and/or Agile
      Methodology zealots).

    A moderately serious project is not interested at all in the first
    advantage. Even if you’re short on money you can get a Linux virtual
    server for $10/month, and you can install everything you want on it.

    And when you start decoupling the view from the logic, and using
    template engines like Smarty or Flexy…
    well, then you lose the second perceived advantage, too.

    If you’ve come so far, what’s the point in using PHP? What’s the
    point in YAPF (Yet Another PHP Framework)?

    PHP 5 is quite a limited and ugly language IMNSHO (why is the
    standard library so poor and inconsistent? why dosesn’t it support
    Unicode properly, except for the UTF-8 encoding? why does it require
    to put a dollar sign in front of every variable?…)

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

    comment at 23. October 2005

  7. Brian Fioca:

    Wow… so much hostility. I had (mistakenly?) come to the conclusion that this site was primarily the home of programmers and engineers and other professionals unified to advance similar ideas. I didn’t intend to contribute to the jockeying of position of players, or the “whose coding toy is better than whose” argument.

    Listen, WASP is not trying to replace Rails. I wrote it as someone used to programming in Java to try to make me feel more at home in PHP, and I wanted to share it with others who might feel the same way.

    Rails is great! I can’t always use it because of random constraints. If you’re ever in the same position, take a look at WASP.

    comment at 23. October 2005

  8. Brian Fioca:

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

    Simple. Because it’s cheaper to hire programmers that can write code in PHP. And if you have a good technical lead and a well implemented framework, your cheap programmers are going to pick it up and run and write good (and maybe even less) code.

    comment at 23. October 2005

  9. David Heinemeier Hansson:

    Fioca, that’s a noble and amicable reason to share a piece of software. How could I or anyone ever have any beef with that? The hostility is solely a reaction to the slander that “Rails also suffers because it is hard to decouple Rails code from page display code.” constitutes. I’m still baffled that you’re surprised of the turn of events following such a statement. This has nothing to do with replacements, alternatives, or anything else. For all I care, you can think Rails is inappropriate because it has a red logo. Just don’t cop out with lame off-hands like the quote in question.

    comment at 23. October 2005

  10. Joe Anonymous:

    > > Why would you want to stick with PHP even in situations when
    > > you can use Python, Ruby, or anything else?”
    >
    > Simple. Because it’s cheaper to hire programmers that can write
    > code in PHP. And if you have a good technical lead and a well
    > implemented framework, your cheap programmers are going to pick
    > it up and run and write good (and maybe even less) code.
    

    Oh, now it definitely makes sense.

    comment at 23. October 2005

  11. Simon Willison:

    Charges of looking like “a histrionic geek who has joined the Cult of RoR” are probably inappropriate when talking about the guy who created RoR in the first place… ;)

    If you don’t like the Rails template solution (I think it’s very neat, and I designed much of Django’s template language) you can always use a template language more similar to Flexy - but you would be breaking away from the Rails norm which the community tends to advise against (Rails is, after all, opinionated software).

    I’d like to hear more of this discussion, but please, turn down the heat a bit!

    comment at 23. October 2005

  12. Rimantas:

    Ha ha, that’s so funny - DHH joining the Cult of RoR.

    comment at 23. October 2005

  13. Brian Fioca:

    Mr. Hansson,
    I don’t really see how that’s slander. I didn’t intentionally deliver a false statement. In my experience, this was true. Others may agree.

    I have the absolute utmost respect for what you have accomplished with Rails. I appologise if what I said in my article seemed worded as an attack on you, or your contribution.

    comment at 23. October 2005

  14. David Heinemeier Hansson:

    Simon: Actually, we do include another template language right out of the box (Builder). And Action View also includes hooks to get your own template language in there. I know that at least two other integrations have been shown. But yeah, most people use ERb most of the time, so its definitely where you’ll find the most examples and support.

    And sure. With the incineration out of my system, Fioca committing to “no intent”, I think we’re about ready to turn the knob down a notch or two.

    comment at 23. October 2005

  15. George Hotelling:

    Flames aside, “Rails also suffers because it is hard to decouple Rails code from page display code” is factually incorrect for very low values of “hard.” Section 17.11 of Agile Web Development With Ruby on Rails is “Adding New Templating Systems.” It explains how to create a new templating system, which basically requires creating a class with a render method, then calling ActionView::Base.register_template_handler(extension,classname)

    Admittedly it could be done with less code if a base template class used Ruby’s inherited method to automatically register subclasses.

    All that said, it’s sad that this piece includes an unsound argument against RoR because it takes the discussion away from WASP.

    comment at 23. October 2005

  16. Tony Wright:

    Wow. I just got called a fascist and big brother. Awesome.

    I’m going to ignore the comment comparing comment moderation to George Orwell… If you feel that moderation is evil, and that a site owner shouldn’t have the right to remove stuff that is diverging from the topic… Er, I don’t know what to say.

    And in response to the comment that my post was only responding to style and not substance– that’s PRECISELY what I wanted to do. I don’t know enough about RoR to participate intelligently in his points… But, as I read his comments, I said to myself “Wow… What a jerk.” My point was that keeping your style respectful and polite isn’t that difficult– and doesn’t require any more words. Just different ones. And, ultimately, I think that it makes you more persuasive (if that’s the goal of the writing that you do). Unfortunately, I think the goal of most of my fellow-geeks (both online and academic) isn’t to move closer to truth and knowledge, but to beat someone.

    comment at 23. October 2005

  17. Danno:

    You don’t make an uninformed remark about someone’s baby and not expect them to get upset about it.

    Sewiously.

    comment at 23. October 2005

  18. Ryan Tomayko:

    Are we done?

    I’m working on a moderation policy. As it is, I’m considering wrapping this entire article and nearly every comment in a <strike> - only that wouldn’t validate. I’ve also received offers from some of the “editors” to review posts and am considering it.

    I have to apologize for not catching trolling language in the original article. The claim that “Rails also suffers because it is hard to decouple Rails code from page display code” should have either not been there or been accompanied with a full length article describing the position and even then, should have been sent to the Rails mailing list.

    comment at 23. October 2005

  19. Geoffrey L. Wright:

    Well, one man’s dreary is another man’s divine.

    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.

    comment at 23. October 2005

  20. Brian Fioca:

    I’d like to apologise. Mia culpa, my bad. The article was never suppoed to be about Rails. I don’t want to be one of those people that compares my work to someone else’s, for better or for worse. It’d be best if it stood on its own.

    “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? :)

    comment at 23. October 2005

  21. Aristotle Pagaltzis:

    Ryan: use <del> tags—they’re the semantic version of <strike> and can also be used as both inline and block-level elements. :-)

    comment at 24. October 2005

  22. Simon Willison:

    I hadn’t seen ActionView::Base.register_template_handler(extension,classname) - that’s a very neat solution.

    comment at 24. October 2005

  23. Sune Kirkeby:

    [..] , 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.

    comment at 24. October 2005

  24. Harry Fuecks:

    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?

    comment at 24. October 2005

  25. developers.org.ua » Blog Archive » weekly linkdump:

    […] WASP - Easing the Switch from Java to PHP […]

    pingback at 28. October 2005

  26. Aristotle Pagaltzis:

    For the time being, I only want to comment specifically on this puzzling “Rails also suffers because it is hard to decouple Rails code from page display code” sentiment (though it seems to have been edited out of the article).

    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?

    comment at 31. October 2005

  27. Daryll Plant:

    Ed. — Broken link removed

    comment at 09. December 2005

  28. Maintainable Programmers [@lesscode.org]:

    […] I thought it unfortunate that the controversy kicked up by a few (now retracted) passages in Brian Fioca’s article about WASP detracted from a proper discussion of the article’s real flaw. I addressed the controversial, less interesting sentiments in comment over there, but wanted to take a few moments for a longer commentary. It took a while, but here we go. […]

    pingback at 30. December 2005