Apparently there was some kind of PHP vs. Javascript fight, to see which language sucked the most. The results? Amazingly Banal, if not downright wrong. There is the list of topics, and their scores:

• Syntax: PHP - Sucks, JS - Sucks Hard
• Data Types: PHP - Sucks, JS - Sucks
• Scope / Namespaces / Packaging: PHP - Annoys, JS - Sucks Hard
• Standard Library: PHP - Sucks, JS - Sucks Hard
• Extension Libraries: PHP - Sucks, JS - Annoys
• Procedural Programming: PHP - Annoys, JS - Annoys
• Object Oriented Programming: PHP - Sucks, JS - Sucks
• Functional Programming: PHP - Blows, JS - OK
• Meta Programming: PHP - OK, JS - OK
• AOP: PHP - OK, JS - OK
• Networking: PHP - OK, JS - Sucks
• Error Handling: PHP - Sucks Hard, JS - Sucks
• Multi Tasking: PHP - OK, JS - Sucks
• Reflection: PHP - OK, JS - Sucks
• Garbage Collection: PHP - Blows, JS - Blows
• Security: PHP - Blows, JS - Sucks
• Garbage Collection: PHP - Blows, JS - Blows
• Security: PHP - Sucks, JS - Sucks
• Tools: PHP - Sucks, JS - Sucks Hard
• Server Side: PHP - OK, JS - Sucks
• Client Side: PHP - Sucks Hard, JS - OK
• Final Rave: PHP - Sucks, JS - Sucks

There are some real problems here...

Syntax: Sucks vs. Sucks Hard

I fail to see how Javascripts Syntax sucks harder then PHP. In fact, in a comparison against syntax, it is a lot like comparing whether dirt from your front garden or your back garden tastes worse. It doesn't matter, it is all dirt. For syntax to be not suck, I think it would have to be more like Scheme, where the syntax is very simple and gets the hell out of your way.

Scope / Namespaces / Packaging

The very idea that PHPs Scope just "Annoys" versus Javascript is laughable. Javascripts scoping is by far superior. Show me a closure in PHP, and then show me one in Javascript, and we will see which one sucks and which one doesn't.

The thing about Lexical Scoping and Closures, is that once you have them, then building packaging and namespaces is not too difficult. In PHP, scope is so horribly broken, that people are yelling about needing namespaces and packages, when if they fixed the scope problem, then these other problems are solved. For free.

Meta Programming: OK vs. OK

Now this I don't get, at all. Meta programming in either language involves using eval, along with string manipulation. This is not 'OK', this is definately on the 'sucks' end of the spectrum. To get an 'OK' in this area, you would at the very least, have low-level scheme-like macros, and be able to work with a data structure related to the parse tree. See Lisp and Scheme macros for a better idea of what OK actually means here.

I (sarcastically) love the idea of using Code Generation as Meta Programming (one of the 'perks' of PHP). Code generation should be your final line of retreat. If you are generating code, you may have lost the battle. It is a good tool to have in the toolbox, but it is not one I like to pull out that often.

AOP: OK vs. OK

Dead. Wrong.

Why? Because to get any reasonable AOP in PHP, you need to install an extension into the language. A fully functional AOP system in Javascript however, is painless and easy to write, what with first class functions and all.

Overall

The PHP slides are a bit of a larf. A language with 3080 built in functions is also easy? A language like PHP has a simple syntax? Umm.... No.

To be fair, Harry Fuecks probably had his work cut out for him. How do you explain the basics of a Closure to an audience who might not know what they are, let alone what you can do with them; all in the span of 60 seconds? (psst, objects are closures with syntatic sugar, but you can't "de-sugar" and object to get a closure). If an audience doesn't understand the idea of a first-class function, how can they understand how easy AOP is in Javascript?

I am trying to find the perfect editor for OSX. Actually, I have been trying to find the perfect scheme editor for OSX.

On my windows machine at home i use UltraEdit, which at one point was the ultimate in text editors. At work, I use jEdit, which is excellent , and has a lot of potential. Both of these programs are good at editing source code for PHP, JSP, HTML and PL/B. But in my heart, I knew that when it came to programming Scheme, both of these solutions fell short.

So when I was faced with trying to find an editor I liked for OSX, I immediately jumped to jEdit (being cross platform and all) and I rapidly jumped back. jEdit, while good, just isn't great at editing scheme. Sure there is an R4RS implementation of scheme that hooks into its console, but lets face it, it isn't really that useful. On top of it, its console plugin does NOT like to play nice with the Gambit scheme interpreter. To make matters worse, working with jEdit on OS X didn't feel like working with it on WinXP.

Now let me take a little diversion here. Ever since I have gotten my new PowerBook, I have been sitting in this weird little zone. It is equal parts "Oh Ess Ex? More like Oh! Eh! Sex!" and sitting, quite firmly in the suck threshold. On one hand I am opening terminal windows and hacking like a power user, but on the other, I am running to my more seasoned mac friends to ask how I can use the tab key to switch focus to a button. The overall effect here is that for me to get the simplest jobs done (sometimes) involves a lot of pain and work; this being said, I can imagine switching from OS X to WinXP would be an even worse experience.

So I narrowed my choice down to either TextMate, or Emacs. Now TextMate is the ultimate in slick editors for OS X. It is slick, very OS X in its interface, easy to use... and an absolute pain to work with if you are editing Scheme. Basicly, TextMate has an active community of Ruby, Python and PHP developers doing Ruby, Python and PHP things for TextMate, not Scheme things.

With Emacs, it is quite the opposite. Emacs is de rigeur amongst Scheme developers, so obviously more effort has been made to make it scheme friendly (even allowing for the fact that there are many different implementaitons). The differences don't stop there. While TextMate is flashy, user friendly and OS X like, Emacs, even the latest build for OSX, is not.

So I was faced with inferior editing, in a comfortable (but yet new) OS X style with TextMate; or far superior editing with emacs, but faced with the prospect of not only sucking in OSX, but sucking in a completely different method of editing source code.

Now you might be asking yourself "How different can editing source-code be? Even across WinXP and OS X, its Control (or Command) U for undo, C for copy, X for cut, and V for paste. Right? Right?" Well. No. In Emacs, Undo is done with a Control-/. There is no redo. Instead, undo's are un-done by performing an action (like hitting space-bar), and undoing that, which forces the undo of the undo actions. Essentially every action (hitting a character, deleting a line, or even undoing) puts that action upon a stack, so every action is saved, even actions that were undone. This is a very powerful and slightly confusing concept, but it exactly illustrates emacs. Powerful and Confusing.

Overall my experience thus-far has been good. It is hard work, I still suck at editing Scheme in emacs, but the biggest thing here is that I am the one that is sucking, not my editor. Surely emacs could be built better, perhaps the Headrush folk could build an equally powerful but yet friendlier emacs. But emacs has already given me enough bones to keep slogging away at it. Knowing that I will stop sucking soon also helps.

Google's "Summer of Code" has started and they have announced a few PHP projects. Some of them look interesting and useful. However, I am going to pick apart one in particular, that to be honest, looks neither interesting or useful: The PHP Macro Preprocessor. This (as described) sounds exactly like a rewrite of the C preprocessor, which one can work with fairly easily in a PHP environment. To see this duplication of effort on something so boring and useless makes me question just how much PHP is its own language, versus a Frankensteins monster of language clones; see PHP 5's object system for a perfect example.

Now it is one thing to just simply trash the hard work of others and say "you're doing it all wrong!". It is another thing entirely to come up with a different idea. One of the first ideas that I had was to use PHP to preprocess PHP. Lisp and some Scheme implementations already use this process of taking the host language to process the macros in said language. They operate on the code as data first, and then that data becomes the code that is operated on. For Lisp and Scheme it works really well because the code is formatted like one of their key data-types: s-expressions (for an example of sex-pressions, see the sidebar).

Why does the PHP Preprocessor need to be stuck in a world of #ifdefs and #includes? Instead of blindly copying what the C preprocessor does, why not focus on the languages strengths and deficiencies? The object system of PHP needs to be looked at, and see if it can be improved upon through a method of code transformation. Imagine being able to tell your preprocessor that you were writing a facade pattern, and having it fill in 90% of the details, leaving you with the last 10% of implementation. The reason that the PHP community (and similarly the Java community) are so all upon the pattern bandwagon is that both languages lack the facility to gracefully express the patterns in abstracted code; if there was a way for a preprocessor to deal with this deficiency, then a fundamental flaw of the language is fixed. So why not use a subset of PHP to transform PHP? Just as you use PHP to transform an X(HT)ML document, you could use a speedy subset of PHP to transform a PHP document.

The focus on an inline preprocessor is quite limiting as well. All of the processing capabilities are simply skipping over and replacing small sections of code. Why not take a page from the very powerful syntax-rules processor of R5RS Scheme? In fact, its template matching rules would probably make a lot of sense to PHP developers, it is like using a website template in reverse!

Like I said before, my problem with the macro system as described is that it just copies existing functionality from somewhere else without looking at the problem of creating dynamic, maintainable websites quickly; or looking at the issues surrounding macros and meta programming.

Now a Language on top of Scheme that builds PHP applications would be cool.

I recently got a shock the other day. Calgary Transit has decided to update their website, and giv eit something of a face lift. Specifically, the "Schedules" section is being completely changed.

This. Sucks.

Currently, if you want to find out when your next bus comes, you enter in your stop number, route number, and click submit, and you're taken to a page with a list of the next 5 stop times. The stop times are easy to read, and the font size is just the perfect size. It also displays an arrow with how long before the next bus comes. Furthermore, if your next bus comes within 20 minutes there is an icon of a guy walking to the bus. If it comes in 10 minutes, then the iconthere is a running guy. With one quick glance, you can see when your next bus comes. The interface is easy to see, easy to use and easy to consume—especially if you are in a hurry.

Come July 3rd, this will be replaced with an "improved" interface. This interface is so bad that I will be finding out my next bus via telephone from that point forward. What makes it so bad? First of all, the typeface is too hard to read. The type-size is too small, and the color is a tad obnoxious. Second of all, there is no friendly icons to show you, at a glance, where you are in time, in relation to missing your bus. And the final thing, and quite possibly the worst, it tells you what time the bus comes, but according to who? The bus comes at 8:35AM. Is that 8:35 on the CT server? The time set on CT's CEO's watch? An atomic clock? My computers time? Very annoying.

This is a good example of what to do, and what not to do. Sadly, it seems CT is moving backwards.

Update: I could hardly trash-talk the CT website and not actually send them an email stating how I felt (Thanks to my baby who also made a suggestion). If I want the new CT website to be usable, I needed to take responsibility for it, so I did in fact send them an email right after posting this entry. They sent back an email saying that they forwarded my email to the supervisor. With any luck, this story will have a happy ending—I'll keep ya posted.

The Firebug extension for Firefox by Joe Hewitt just rocks. It is the culmination of a few different Firefox extensions: the Web Developer Tool Bar, the Dom Inspector, Viewed Rendered Source, and Venkmen (the Javascript debugger). Firebug borrows from these extensions and more, packages them up in a nice, tasty usable extension.

It has a Javascript debugger that lets you set arbitrary breakpoints; DOM inspector that not only lets you see the structure of your page, but also any styles and events on each node in the DOM tree; an AJAX console viewer so you can see the raw HTTP requests and responses; and a console, where you can see Javascript and CSS errors and type in arbitrary Javascript.

The inspector alone is worth the price of admission, it allows you to hover over elements on a page, and it will not only highlight the element on page, but also highlight the corresponding element in the rendered source, and show you not only the styles applied to it, but where it got those style rules from. This is probably the feature of firebug that I use the most, and it has made my job as a web developer infinitely easier.

It provides a host of great Javascript functions as well through a console object. Not only can you send it debug, info, warning, and error log messages (no more alert debugging, horray!) but you can send it assertions—great for design by contract.

I have noticed a few problems with it. Every once in a blue moon my browser seems to crash, which might be a fault of firebug. It really is a once-in-awhile issue, like 2-3 times a week after a period of heavy usage. Firebug also has some known issues with regards to viewing HTTP Requests and Responses. Synchronous requests cause it to fail, as well as documents that are XML (like XHTML, for instance). In actual fact, these are Firefox issues, and not Firebug issues, but there is a good chance these issues are being worked on.

Despite these problems, Firebug is a very usable, very cool extension. If you do any kind of web development, as a job, or as a hobby, it is well worth installing.

Techno Chocolate! (oon tsch oon tsch oon tsch... dooo do do do do do!)

I found a neat little surprise the other day. It appears that the Mozilla extension auto update feature is RESTful; I found this out through the use of LiveHTTPHeaders. Whenever you have an extension like Spellbound or Firebug, Firefox will call home to a server, and perform a version check, comparing your version with the latest version it has. It is not 100% RESTful, the biggest problem being that there is an end-point style URI (https://addons.mozilla.org/update/VersionCheck.php) with a query string (reqVersion=1&id=firebug@software.joehewitt.com...) ideally, the uri would be something like /update/VersionCheck.php/1/firebug.software.joehewitt.com/... giving each unique identifier its own space on the URI.

Beyond that however, it is very good use of HTTP, all the information needed is encapsulated in the request and is stateless. Really this shows that a lot of simple web services are either inherently RESTful, or are just a hop skip and jump away from being a true rest webservice.

This is the important thing about REST webservices. It is not that you need to conform to a "REST Standard", but instead you conform to the HTTP spec and end up, by design, following at least some of the REST constraints.

For reference (and the truly geeky) , here is the request and response:

Request

https://addons.mozilla.org/update/VersionCheck.php?reqVersion=1&id=firebug@software.joehewitt.com&version=0.4&maxAppVersion=3.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.5.0.3&appOS=WINNT&appABI=x86-msvc

GET /update/VersionCheck.php?reqVersion=1&id=firebug@software.joehewitt.com&version=0.4&maxAppVersion=3.0&appID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&appVersion=1.5.0.3&appOS=WINNT&appABI=x86-msvc HTTP/1.1
Host: addons.mozilla.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en,en-us;q=0.7,ja;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: no-cache

Response

HTTP/1.x 200 OK
Content-Length: 939
Connection: close
Content-Type: text/xml; charset=utf-8

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:em="http://www.mozilla.org/2004/em-rdf#">

<RDF:Description about="urn:mozilla:extension:firebug@software.joehewitt.com">
    <em:updates>
        <RDF:Seq>
            <RDF:li resource="urn:mozilla:extension:firebug@software.joehewitt.com:0.4"/>
        </RDF:Seq>
    </em:updates>
</RDF:Description>

<RDF:Description about="urn:mozilla:extension:firebug@software.joehewitt.com:0.4">

    <em:version>0.4</em:version>
    <em:targetApplication>
        <RDF:Description>
            <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
            <em:minVersion>1.5</em:minVersion>
            <em:maxVersion>3.0</em:maxVersion>
            <em:updateLink>http://releases.mozilla.org/pub/mozilla.org/extensions/firebug/firebug-0.4-fx+fl.xpi</em:updateLink>

        </RDF:Description>
    </em:targetApplication>
</RDF:Description>

</RDF:RDF>

Getting Things Done, or GTD, is a small book written by David Allen. It is, as the title suggests, a book explaining a method that you can use to get shit done. When I first heard about it, I had relegated it to a Tony Robbins style "increase your personal productivity" affair. But it make large in-roads with the geek crowd. It seems all kinds of uber-alpha-geeks have drank the GTD kool-ade, and are evangelizing it like David Allen is the son of a carpenter.

Why? At the risk of sounding like a bad televangelist (blogavangelist?), I'll give you the answer: It works. It's that simple. Most people have problems where the day-to-day interruptions and madness interferes with the stuff they need to get done. Some of us have all that going on and a hard time organizing their tasks on top of it. With all of this happening, stuff—sometimes important—slips through the cracks. usually this happens because there is a list of things in all of our heads of things that we need to do, but keep not getting done. These things David Allan says, consume a large chunk of our mental processing and energy because they are not getting done, but they are also not stored somewhere in a trusted system so we can let our minds forget about it.

The system that David Allen presents is a relatively simple one that can easily be applied, whether you are a stay-at-home mother, or a high powered executive, it is all the same. You can implement the GTD (Getting Things Done) system with a set of folders and a pad of note-paper, you can go high-tech and use a PDA along with the PIM software of your choice, or anything in between. The key is to gather all the "stuff" in one big pile, and start to process it all. "Stuff" is all the stuff sitting at your desk, in your drawers, filing cabinets, inbox, voice mail, window/mac desktop and even the stuff floating in your head. Once you have gathered all this stuff (and made it tangible) then you go through each item, one by one, and put it in your system.

The system is very simple, given piece of "stuff" you decide whether or not that item is actionable, and if it is, determine what that next action is, and either do it (if it takes less then 2 mins), delegate it, or defer it to a later date. If it isn't actionable, then either it goes in the trash, goes in a reference system, or gets put in a "someday/maybe" folder. the key to the whole system is "What is the next action?" which is to say, what is the very next thing you can do to bring this item to completion. "Pay the taxes" is not a next action, but "go to the accountants and pick up completed taxes" is. This has the effect of turning a lot of "small" projects into what seems like larger ones, but in fact, puts your mind into a sharper focus, because when you are in the middle of your day, you don't have to spend time deciding what you need to do, but instead go through your next action list, and chug through it, depending on time and energy available, priority, and context.

The hardest part of the GTD system is the initial collection procedure. David Allen says that it can take up-wards of 2 days to go through the initial collection and processing stage, depending on how organized you were before and how much stuff you have. Now I had it easy, I grabbed and started reading the book a few days after I started work at Critical Mass, so the initial stuff collection at work was painless, and it's kept me organized ever since. However, at home, it is a whole different ball of wax. I have since re-read the book, and have only just started to put it in practise for my personal life. Don't do this. You should really go the whole hog and organize your whole life, instead of just your job. If you do it half-assed, you will end up highly productive at work, but your productivity elsewhere will suffer, because it will be so much harder (by virtue of not having a working system in place). Yes, the initial outlay of time is hard, and the collection process is hard, but it is worth it.

All in all, I would say this book is monumentally helpful, whether you stay at home, work at home or work in an office. The initial investment in time is very high, but the return is even higher still. David Allen's style is light, friendly, and not too preachy. It can get a little new-agey-power-of-positive-thinking at times, but this seems to be more of an explanation of the result of the process, rather then part of the process itself.

If you have any problems staying organized and on top of stuff: Go. Buy. This. Book.