lesscode.org


How’s that for less code?  

By Aristotle Pagaltzis under Python, PHP, Java on 07. January 2006

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.

8 Responses to “How’s that for less code?”

  1. Mr Coffee:

    I rewrote the Java version. It is now just a little under 100 lines of code. This was achieved by using Spring, a more modern framework. Does that make Java superior again? Whee.

    Coffeetime.

    comment at 07. January 2006

  2. Bob Ippolito:

    Does that include configuration and database schema? Does it support several different RDBMS? Does it also do the PizzaService example? Does it have all of the same exception handling sludge? Does it wrap at 79 columns? ;)

    The Python version is about 85 lines for all that when using long lines and without all the newlines introduced specifically for readability’s sake.

    comment at 07. January 2006

  3. Scott Yang:

    It is not comparing languages like Python, PHP and Java — it is actually comparing frameworks. It is comparing TurboGears, a Python framework that is especially designed for CRUD-type web applications using MVC and ORM, with a Java app implemented on top of J2EE, which always manage to (1) confuse the programmers (2) flood the managers with buzzwords.

    (Sorry I did use J2EE in my previous job, and understood the complexity also gives it lots of flexibility)

    My point is, your 117 lines of Python code simply won’t work without TurboGears. TG basically takes care all the complexity so that you can write “less code”, but as Mr Coffee has suggested you can also write less code with appropriate framework in Java. It doesn’t include database schema either — it includes an object relation mapping that doesn’t work well if another application written in another language also needs to access the same database.

    And the PHP example? It does everything (DB connectivity, SQL query, etc) WITHOUT a framework to build on.

    So IMHO, the comparison is flawed.

    comment at 08. January 2006

  4. Bob Ippolito:

    It’s not flawed — the PHP example is using AMFPHP, which is a framework for developing flash remoting services. It’s not “Just PHP”, there’s a large body of code behind it.

    Comparing PHP-the-language to any other language is silly anyway, because PHP includes the kitchen sink and the house to go with it as far as built-in functions and extensions go.

    PHP also does a very bad job at choosing how to expose what it offers. It makes it hard, or at least non-obvious, to write correct code. EVERY SINGLE DATABASE QUERY in the cited example is susceptible to SQL injection attack, where people simply don’t write shit code like that in environments that offer a sane means of SQL quoting. Since everything else is already there, it encourages people to just use the raw MySQL API calls rather than bringing in an abstraction. That’s also stupid because it takes 5x more code to do all the quoting by hand. People are too lazy to bother with that, so they develop big festering security holes like this one. Even worse, this is example code that people will cut and paste into their own applications. PHP programming is a disease.

    Anyhow, TG is actually doing very little in this case besides providing a buzzword and easy means of getting up and running. TG is serving as shim for CherryPy to make HTTP requests transactional with the database, and as a script to create the SQL tables. It also ensures that SQLObject and CherryPy are known to be installed.

    It could’ve been written as raw Python with BaseHTTPServer (or CGI) and the minimum DB-API wrapper in the same amount of code, but that’s stupid and it’s not the point of lesscode. Abstractions that work are good.

    comment at 08. January 2006

  5. Patrick Mineault:

    The current version of the pizza service on the amfphp website includes the methodTable as an external file which reduces the code to 113 lines. The methodTable file itself is generated by the service browser so I would hardly count that towards the total. As for the security flaw, it has been fixed by proper escaping. I don’t think Justin and the rest of the gang ever meant for the pizzaService to be a model in implementation. It was originally created as a simple showcase for a conference talk, where the quality of the code didn’t matter all that much.

    Now as for your claim that ‘amfphp is a framework’, I want to stress that this is false. Amfphp is, and will always be, a Remoting gateway, that exposes vanilla php classes to the outside, enforcing security. One of amfphp’s design goals was that you could integrate it with whatever you’re currently using, so you don’t have to learn to code again. Most amfphp examples onlines use plain mysql, because that’s what a lot of people use in PHP, and everyone’s familiar with these functions. Nothing is stopping you from using any of the other databases that amfphp supports which there days includes ADO, FrontBase, Informix, ms-sql, Oracle, generic odbc, PDO, PEAR::DB, Postgres and SQLite. There’s been nice reports on using it with Creole also.

    Again, I want to stress, amfphp is not a framework. The fact that it can be used as a module in Cake (a Rails clone for PHP) proves it. Note that amfphp’s approach is not universal. People who wanted a cleaner API and a more ‘frameworky’ approach created SabreAMF. I talked to the developer to get him to work in amfphp instead and it turned out that our goals were irreconcilable. This will allow amfphp-enabled classes (that is, classes that set a methodTable) to be used as JSON services for JavaScript, or for XML-RPC, or to generate SOAP services, etc.

    comment at 03. March 2006

  6. The Cave » Blog Archive » Less is More:

    […] ‘Java’ (language, libraries, community…) need to fix the mess they’ve created over the past decade: 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. […]

    pingback at 26. March 2006

  7. Cliff Wells:

    It really irks me when PHP programmers explain away crappy code examples by saying “it was just an example” or “I was just testing”. When you consider that manually escaping code (as is so often seen) is incorrect, insecure and TAKES TWICE AS MUCH CODE as doing it right (using prepare/execute) I have to call bullshit. Someone is either lying or ignorant or both.

    There are tons of beautiful PHP apps out there, most of them plagued with serious security holes because most programmers learn from example and most PHP examples to be found on the net are badly flawed.

    I tend to agree that it’s possible to write crappy code in any language, but PHP seems to have more than its fair share. Some people claim this is because it’s so popular and I’m sure that’s part of it, but I’ll assert that it has more security holes per deployment than any other language. Worse, most of them are SQL injection and remote code execution exploits.
    I attribute this partially to poor ideas in PHP’s implementation (certain settings in php.ini were patently bad ideas), but mostly I attribute it to poor examples for others to learn from. If you don’t want to teach well, then don’t teach. If you make a mistake, don’t make excuses, fix it.

    comment at 25. November 2006

  8. Aristotle Pagaltzis:

    Cliff: I think the language itself is to blame.

    comment at 26. November 2006

Leave a Reply

Note: None of this information is required but leaving a Name and URL is much appreciated. You can also register to have this stuff remembered.

Your comment can be previewed here.


Markdown: use the force, Luke.