lesscode.org

Bob Ippolito, speaking about the upcoming flashticle, offers proof in the pudding for things I wrote a week ago:

This is a total of a whopping 117 lines of very liberally spaced Python code that defines all three database tables and fully implements every feature of both sample applications.

The PHP version of the pizzaService backend […] is 138 lines of code, is one big security flaw (doesn’t escape SQL properly, big surprise), is MySQL specific, and it doesn’t include the DB schema and can’t create any tables for you (thank you tg-admin sql create).

The Java version of the BirthdayOrganizer backend, which I won’t even bother linking to, is well… ginormous. 246 lines of XML configuration sludge in 5 files, 29 lines of SQL schema in 1 file, and 3004 lines of Java code in 45 files. Holy crap. If you add that all up, the trivial BirthdayOrganizer example is only a hair shorter than all of flashticle! And the BirthdayOrganizer example builds on top of 15 Java dependencies and requires a J2EE server plus ant. Friends don’t let friends code Java. Oh, and it’s also MySQL specific, but you better be damn well sure that there’s a stub implementation you can subclass and an XML file you can mangle in order to support something else if you so choose to write that 200 lines of code to support a single three column table database.

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:

Greetings fellow lesscode advocates. For those of you who don’t know me, I’m an industry analyst with RedMonk, and as a couple of the folks here can probably attest, I take every opportunity to push your message and your values on an unsuspecting population of software vendor customers. Ryan’s been gracious enough to grant me the virtual floor as it were to speak to all of you today to request some assistance.

I’m the process of finalizing my keynote presentation for next week’s Zend/PHP conference entitled, conveniently enough, “PHP: Simplicity and Lesscode.” So here’s where I need some help, if you’re willing. My slides are trying to emphasize the role simplicity/lesscode play in all of our lives: both in technology and not. The deck currently starts from non-technology examples such as simple machines and builds to technology related examples, most of which are PHP centric for reasons that are probably pretty clear.

The question I have for all of you then is this: what examples - real world or technology related - might you use if you were trying to evangelize the twin values of s/l? What would/do you tell people that don’t get what lesscode is all about? As an example of the type of thing I’m looking for, I’m planning on opening with one of my favorite comp-sci stories of all time: Ryan’s Insects and Entropy. Adam Bosworth’s discussion of how Google uses the stupidest query language ever is also in there.

Hopefully those will give you an idea of the kind of things I’m looking for, and suggestions in any form would be appreciated. I can’t promise to use everything, but I’ll incorporate whatever I think I can fit in.

A couple of logistical notes:

1. Slides: will be made available following the conference under Creative Commons terms on my site, and here if the community here so desires. They’ll be offered under the same terms
2. Credit: will be given whenever possible during the presentation, and the closing page of the slides will contain the names of everyone whose contribution was included (so if you leave a comment, be sure that’s the name you’d like to have credited). That slide will also include a link to this entry, so that even suggestions that don’t make the deck may get some airtime.
3. Technology: given that this is a PHP conference, I’m probably not going to go in depth on Python, Ruby as much as I or some of you might like. So language specific examples will likely be genericized, just as an FYI, unless they compare more complex languages to PHP - in which case they’re encouraged.
4. Questions: drop them here, and I’ll do my best to answer them.

Thanks for helping me get the lesscode message out, and I look forward to any conributions you might have.

I’ll take it as a given that if you’re reading this then you agree that, for the sake of sanity and productivity, it’s time coders gave up on roll-your-own, and moved over to modern frameworks where one can concentrate on business logic rather than request parsing (and get all those AJAX goodies for free ;-) ).

I’ve been looking on with interest for the last year and a bit, and as I’ve watched the pioneers blaze their XP, RoR, lesscode trail across the web-firmament, I’ve begun to suspect that I must have missed something. Yes, it’s powerful stuff, and yes it isn’t all smoke and mirrors - there really is “gold in them thar hills…” - but, and for me it’s a big but, we seem to be missing the big picture. Where are the map makers? Where’s the documentation for the second (or third) wave?

Self-documenting code is all very well, and having a common vocabulary of design patterns helps when discussing solutions to individual problems. But what second-wavers really need (and I include myself here - no, actually, put me down as a third-waver) are more pictures. More exposition. Road maps.

Is there a way to add XD (eXtreme Documentation?) back into the XP mix? Writing elegant code is hard, and people who do it earn the admiration they received. But I would argue that writing good documentation is harder, and that it shouldn’t be left for the second-wavers to do.

People who’ve moved to XP have already gone thorugh the pain barrier of

• write the tests
• then write the code
• (then refactor)

and have proved that in the long run, it means better code, less debugging, in less time. But having proved that that works, might there be some benefit in switching to;

• write the spec
• then write the tests
• then write the code
• (then refactor)
• then write an overview!!!

Might this result in (my h-nought) more easily modfied code, quicker adoption by other coders, greater community support?

I’m genuinely interested in other people’s views on moving documentation down(?) the food-chain, so that it’s non-optional, and as integral to writing new code (and frameworks) as writing good tests. Yes, there are good auto-doc tools and methodologies out there, but that right now they still seem to be seen as secondary to the process by Joe Frontiersman, and they only deal with what’s in the file, not what’s in the coder’s/architect’s head. (There’s the nine diagrams of UML, yes, but who on the bleeding-wrist of open-source technology is actively using/sharing designs via UML?)

Let me know if I’ve missed a trick somewhere.

[A few thoughts for the pot: I believe the that the reason the Open Source model works because it’s based on non-coercive collaboration. But Source Forge is littered with unfinished, half-baked projects because someone didn’t think to check that there wasn’t already a project out there that they could use. (How many PHPUnits does the community really need?) Should there be a ‘requirement’ for documentation before a project gets listed? Perhaps it’s time for ‘ideaforge’, or ‘architectureforge”?]

This chart showing the number of requests for different languages on O’Reilly’s Code Zoo is interesting:

Yesterday we added two new languages to CodeZoo: Python and Ruby. You can see from the language requests graph, above, the languages for which we got more than a few requests (I’ve left off Cobol and the others that only were requested a couple of times). From this, the choice of Python is completely obvious — it was the winner in the request race, beating out C++ and many other languages that might be considered “larger” by other metrics. In addition to the clear demand for it, Python is a natural fit for O’Reilly, since we publish a great deal of treeware and online material about Python, and cover Python extensively at our conferences (especially at the Open Source Convention taking place this week).

Ruby, however, is tied for fifth on the list, and in raw component counts on our site, it is the smallest of the languages we support. As we’ve discussed on Radar over the past few months, we see Ruby as an emerging force in the open source world, driven by interest in Ruby on Rails, and by the excellent books on Ruby written by the Pragmatic Programmers…

I was actually really surprised at how strongly dynamic languages showed up on this chart. I’m eye-balling it as there aren’t any numbers but Python, PHP, Ruby, and Perl seem to have taken down almost 50% of the requests with C{,#,++} taking down a large majority of the rest. Is this a fair sampling of the general development population? Developers with a web/UNIXy background seem to be over-represented at O’Reilly so its probably a bit skewed, no? Still, the amount of acceptance dynamic languages are gaining is pretty staggering at this point.