I read a great article by Derek Silvers entitled 7 reasons I switched back to PHP after 2 years on Rails. I've heard just too many "silver bullet" schpiels about X language, or Y framework. Granted, I've got the tools I draw like a gun in the heat of the moment, but just because it works for me, doesn't mean it works for everyone.

I stayed away from Ruby, and particularly Rails, mostly because of the sensationalism. Yes, I did work with it, and I never found anything that gave me an advantage of Python, but it was ultimately the amount of community hatred for anything else that kept me from taking Rails seriously. The ignorance I found in the Rails IRC channels and mailing lists was a major turnoff. There are fanboys and sensationalists in every language, but I found a concentration of them in the Ruby on Rails community.

And this post on Slashdot is why I stopped reading Slashdot a long time ago...

And then my feelings were expressed oh so eloquently in this post by Jamie Flourney. One of the points that really stuck out to me is made is that sometimes writing SQL is a better way to go. Using Django, I was exposed to ORMs for the first time, and while I liked it, I will admit it made me uncomfortable, but it was a new approach. The question though is "Does it really solve the problem at hand?" Django solves most of my problems for my personal site, but it won't fit in some of my other web applications, and that should be understandable. If a tool doesn't work in a particular situation, that doesn't mean the situation is broken.

I just read an article entitled Want to Learn Web Programming? Write A Blog Engine. I'll admit that I learned a lot about web development through working on my own blog engine. I never actually released it live, but it was educational for me. However, I think there are some caveats that need to be considered when making a broad statement. Note: I'm not disagreeing with the author (Abhijit Nadgouda) at all, but there's just a bit more to consider.

First, let me tell you how I got into web development. I've always liked writing code, but school was boring me, and so there wasn't a lot of growth. While doing an aggressive job search for a sysadmin job (which I had real world experience with), I sent my resume to a recruiter who forwarded it on to a company seeking a web developer. I didn't think I had a chance in hell, mostly because I hadn't done anything but dabble in PHP. However, after a second interview, the company took a chance and hired me. I'll admit that it was probably rough rolling for them for at least the first six months while I learned to work as a developer (culture as well as routine).

On the other hand, I have a very good friend (we'll call him Mike) who's been dabbling in PHP (much more than my "dabbling") for quite a while. Mike started writing a comment system for his existing Blogger weblog. It was rather robust, and I am still impressed. He didn't want to learn SQL, so he stores everything in flat text. Having worked with PHP, I know that flat text files are pretty gutsy. However, after looking at his code, it's noticeable that he cut his teeth on an incredibly high level language. He "dabbles" in other languages, but he's pretty skilled at bending PHP to his will. He lacks one very important attribute to his code though: structure.

When I started my first development job, there was software rot. The software itself was organic, which fit its description well, as it felt like working with a large shrub that never had a good gardener. I had the opportunity to assist in the re-write of the entire system. There were implementation problems, there were structure changes, and there were TONS of architecture meetings (even if it was only two developers). This was quite some feat, considering PHP doesn't lend itself to great coding styles.

Now we come to the whole "Write a Blog To Learn Web Programming," there's more to consider. When you start off writing your blog, start bookmarking sites that you find helpful, and if it's a blog, add it to the RSS reader of your choice. Read general programming blogs, read up on other languages. If you write a blog engine in PHP, and then think you know what it takes to do anything in PHP, you'd better think again. It's a starting point, but the world of web development is far from CRUD applications. There's XML processing, RSS syndication, screen scraping, and the like. Creating a blog engine in a vacuum leads to steaming piles of Wordpress.

Make your blog, but then make something else, and realize that you learned very little from making your blog.

3 Oct 2007 - Update: I recently did a review of a few PHP web frameworks that we were investigating at work. My kneejerk reaction was to develop with each one, and see which one provided what I would need for the work application. What did I develop? An identical blog application in each one. So I'll reiterate that the concept of writing a blog application will give you a good overview, but I'm certainly no PHP web application framework expert now.

My previous employer had some problems with a client, which led to money getting tight, and eventually a downsizing. Unfortunately, I didn't make it through the downsizing process. On Friday, my employer let me go. Without a pause, I went directly home. polished of (or rather, rewrote) my resume, and started sending it out like mad. Monday morning at 8:30, a recruiter called me, at 11:30 she called again for a face-to-face interview, and I started Wednesday at my new position.

I'm now working as a PHP developer for a company called Mocapay. Mocapay is a small startup in Boulder, CO that allows you to use your cell phone like you would your debit card. When you find yourself at a Mocapay approved vendor (and the number is growing), you can text your pin number to a number, and a server will respond with an authorization code. Give that authorization code to the cashier, and everything else is magic. It's like Paypal from your cellphone. Cool, huh?

I spend 8+ hours a day writing PHP code, debugging PHP code, and refactoring PHP code (is that possible?) Needless to say, sometimes I feel the weight of PHP's utter lack of design bearing down on my like your mom when you don't eat your vegetables. I often feel helpless at the fact that PHP has a significant amount of cruft that sometimes you just can't do anything about. I've been reading as much as I can on the topic, hoping to maybe one day learn to write Beautiful Code but I don't feel that day will be anytime in the next few months.

Recently, a few coworkers and I sat around discussing the possibility of creating a Drupal plugin for Turnplay as a supplement to the Turnplay Facebook app. We all had something to say about Drupal and its benefits and detriments. However, all of us came to one conclusion: There is very little need to use a third party framework in PHP.

Let me take a step back and explain myself. I like to write C code. It's fun. However, there's a lot of menial stuff I don't want to do over and over again. So we introduce libraries, and someone else's code. With open source libraries, if the documentation sucks, who cares? You've got the source to peruse (and maybe fix a bug or two...). Using someone else's library speeds up your development time, because they've already debugged their library API. Other developers have learned everything they need to know to write a library for X-protocol, so you don't have to read the X-protocol docs and then write and debug your own X-protocol generator/parser. The time saved by using someone else's library is orders of magnitude better than building your own.

Now, I use a framework for this very site (Django) and I'm an advocate of making life easier. However, with PHP, the design of the language (or lack thereof) is to make everything easy without needing more tools. I can't think of a single time I've needed to go to a site like PHPClasses to grab a module I couldn't write in the same amount of time. Sometimes, the learning curve of someone else's class or framework can cost you a PS3.

With PHP, most things you could possibly need are built in. Want to write an RSS feedparser? Use simplexml_load_file(). Want to interface with a mysql database? Check out mysql_connect(). Granted, support for Oracle database connections and other enterprise software packages take a little more coercion, but I've honestly never needed to use an outside library. The closest I can claim to doing so is using the PHP-Pear libraries (only Mail and Mail_Mime). So, while some languages spend time pulling in external libraries, linking in .o files, etc. I can write code. And I like writing code.

O'Reilly's OnLAMP blog had an interesting article this morning entitled The Broken Metric of "Intuitive to the Uneducated" Language Syntax which I found very interesting. chromatic is a Perl programmer, and his argument comes from that background. I'll admit that I'm among those developers who say things like "I don’t like to read punctuation" but at the same time, I'll completely agree with him. The basis of a language should not be how easy it is for an unskilled user to pick up and use. And no, this is not about my worries for job security by some "silver bullet" programming language making everyone a programmer

The basic idea of the O'Reilly post is this: In english, I can say "Get out of here!" Depending on my intonations, my facial expression afterwards, and my body language, that phrase could mean many things. It's about the semantic application of the syntax that allows for proper handling by recipients.

Here's a great example: I work everyday in PHP. I work in web applications, and while I write in many other languages in my spare time, I feel most experienced with the standard web application languages (PHP, CSS, XHTML, JavaScript). With minimal training, anyone can learn to develop applications with PHP. It's easy. There's not much linking, compiling, and general headache that most compiled languages require, and there's NO learning curve when it comes to using outside libraries. It's just a simple include('foo.php'). The vast array of builtins also means that whatever you want to do is probably already at your disposal. The problem with PHP is exactly those things that make it so easy to work with as well. All of those modules, builtins, and tools all live in the same namespace. Many functions are merely aliases for other functions. The barrier to entry to PHP development is low, but the amount of expression is also low.

Until I decided to venture out of the php world though, I didn't realize any of this. I had no understanding of character encodings or proper design patterns. Why? Because PHP takes care of it all for you. Put your markup and logic in one file, who cares? Shoot, I care. My brain's context switching between HTML and PHP is taxing. PHP takes care of so much stuff for you that you never really know what you're actually saying.

I've been going through the MIT OpenCourseWare recently, and the first class they teach you in the Computer Science department is all about expressing algorithms in computer code. They start you out with Scheme, which I had heard many zealots talk about, but have never felt to go out and learn it. Now that I am learning it, I see it's power. Scheme allows expression, but the syntax is incredibly simple. You simply cannot become an expert in Scheme by becoming an expert in its syntax. That's not where the power is. Bob Poweruser definitely couldn't just pick up Scheme (or any variant of Lisp) and figure it all out in a few days. The simple lack of a for loop would stop even the most advanced un-programmers.

Learn another spoken language, and this will make even more sense. The ability to express what you're saying is more important than just saying it. Having that flexibility will prove incredibly helpful in the long run.