Reflections on software

Currently, php is the most popular language on the web, popular here meaning sheer numbers. There are number of reasons for this, some of them obvious in retrospect. But then again, a lot of things are obvious in retrospect.

Php is easy to get started with. I think this one most of all is the biggest reason for php's popularity. In its simplest form, php is just a powerful templating language. We can take some html, sprinkle in a couple of php tags here and there, and presto, we have ourselves a dynamic page.

Php is easy to deploy. This almost goes hand in hand with php being easy to get started with. Most web servers are already php enabled, so chances are good that things will "just work" for us out of the box. If they don't, php's popularity virtually guarantees that the solution will be easily found online.

Updates are easy to see. All we have to do is save a file, and reload our browser. As a programmer, I can really appreciate this one, since I'm used to having to restart a process and waiting for it to come back up before I get feedback.

It's easy to find somebody that understands php. I can say this for anything that's really popular currently, so it's not something that's specific to php. What php has going for it here is that there is a low barrier to entry, making it easier for a programmer to quickly learn php without having any previous experience.

If I were to sum up php's downside then, it would have to be its ability to scale in terms of complexity. Most changes are made in an ad-hoc manner, with little thought for the whole. With respect to systems, this is the wrong approach. We want the overall system to have a strong foundation, and have the individual pieces be the ones that take care of their own messes. Php emphasizes getting the individual pieces working, and they often have to know about each other's internals.

For simple systems though, this doesn't matter. If we're just building a doghouse, we don't need to spend the time thinking about having a strong core, because we won't need one. If we just slab things together, it'll hold. We only run into problems when we use this approach to build a skyscraper.

That being said, I think most sites on the web are simple. There's a way to put new data in, a way to control what gets displayed, which could be through a search or not, and maybe a custom workflow for interacting with the data. It's often the case that building up these small pieces from scratch is faster than trying to fit them into the context of a larger system.

Even for more complex systems, there is a benefit to prototyping a naive solution, and seeing where it breaks down. Sometimes it's not where we expect, and this information becomes tremendously valuable when trying to design a more robust solution.

There are attempts to overcome php's shortcomings too. There are many php based frameworks and content management systems out there. Each one of these makes certain separations for you, like MVC, to help ease the burden of maintenance.

There's no denying that php does some things well. After all, millions of web sites can't be wrong, right?

It's interesting to hear so many different opinions on the command line. Many see it as archaic. Others are scared of it. And then there's a few who prefer it to all other interfaces. But regardless of how you feel about it, there's no denying that it's here to stay, at least for the near future.

I've mentioned earlier that interacting with a computer can be likened to communicating with it. We usually "speak" to it in the physical sense through a keyboard or mouse. On the virtual or software side of things, the most popular interfaces are either through the command line, or a gui (wimp interface).

Command line interfaces allow for more direct communication with the computer. You type words that you want the computer to execute, and it returns the response. Going through a gui is like talking to an interpreter first, and then having the interpreter relay the information. This can be more useful if the interpreter can figure out what you mean and make a more informed request to the computer. But for informed users, interpreters just get in the way.

Where I think the command line really shines is its flexibility. At a moment's notice, you have access to virtually anything, all through a single interface. You have access to a large, powerful set of tools that can be widely used with one another. For example, what if I wanted to count the number of files in a directory that had an odd number of lines in them? That were edited in the last week. And have those sent out in an email. Biweekly. Granted, that's a contrived example off the top of my head, but one that is virtually effortless to accomplish from the command line, yet difficult with a gui that wasn't designed specifically for that.

Another useful feature of the command line is its inherent repeatability. Once a command has been run, it can be recalled, executed as is, or executed with slight variations, all with little effort. This is true for sequences of commands as well. And, if the sequences themselves start repeating in sequence, then they can be moved to a shellscript or function and run with a single command. In this way, the command line allows for the user to create new language that is better suited for the problem, in a bottom up approach.

Guis have their place too though. The knowledge required is usually much lower to start being effective with an application. And guis are a better fit to solve visual problems. It's much easier to work with a wysiwyg type app when you're producing a new design, rather than having to perform transforms with commands and then redisplaying.

But I think the audience is what makes the biggest difference. Programmers, and "expert users" have a tendency to prefer command line tools. Novice users are usually afraid of having something go wrong, and find comfort with gui applications. And for the die hard gui guys, all you have to do is tell them:

Smith and Wesson was the original point and click interface

For any given problem, there are lots of tools out there to help us solve it. The programming world is no different. In fact, programmers usually have very strong opinions on the tools that they use. Some will even outright refuse to work with a particular tool that they don't like. And in some cases, this is for good reason. After all, you wouldn't build a rocket armed only with a hammer would you? (Iron man doesn't count) Well in the software world, chances are that you wouldn't want to build a web app using assembly, or a command line tool with a gui builder.

But in the real world, or at least my world outside of clear cut examples, the answer is not always obvious. There are many tools that would do the job, and they would all do it well. And what's more is that it's difficult to predict the future of a particular project, so how do we know that the tools we pick today are suited for future needs? (Of course with python, the answer is simple: from __future__ import tools)

There are more web frameworks than I can count to, and we still can't agree on which text editor to use. (I myself use nothing but ed, because it's hardcore and it's what picks up chicks in a bar.)

Fitness experts also have these kinds of problems. If I want to build more x muscle, or get better at y, how should I work out? What should I eat? These are not always easy questions to answer, and what's more, is that if you ask 5 experts you'll probably get 5 different answers. But, I ran across one interesting response:

Everything works, but nothing works all the time.

I think this holds true for programmers too. I for one find myself constantly comparing different characteristics of similar tools, trying to come up with which one is "the best". However, when coming up with which is better in my mind, I usually only consider my particular short term needs, so my conclusions tend to be biased. Then when faced with similar problems in the future, I go with what I know. But of course, this time it might not be the right tool for the job. I could try to be hitting everything with my new hammer as if it were a nail.

Which brings us to another quote:

The best workout is the one you're not doing.

New frameworks, new languages, and new concepts are what expand our minds the most. Change the tools you use every now and then. You'll be glad you did.