When you start a project, one of the early choices you need to make is what technologies to use. You use tools that will support your efforts, not get in your way. For Trovz.com, I went with PHP on the server side. Over time, I added CakePHP, and I adopted jQuery for client-side work. I went with a commercial IDE over open source ones because I had an easier time getting debugging working.
I went with PHP because I wanted a simple language that I could fiddle around with. I didn’t know PHP, but it’s similar enough to other languages I know to be easy to pick up. I had to learn how to structure a web application, as well as learn PHP, JavaScript, and CSS. I became a much better developer over the last couple of years by learning about these.
That stuff is kind of obvious, so I’ll focus instead on a specific technical point: I’m really glad that I went with a scripting language. There are trade-offs, but I think it really supported me working part-time.
Over the last two years at my full-time job, I spent time developing a C#.NET web app, followed by a Java web app. The comparison between using those languages and PHP was interesting to me. One big difference is the change-deploy-test cycle. For C# or Java, making a change, even to a CSS file, meant a new build, deploying the new jar files, then hitting the browser to see the results of the change. For PHP, it meant clicking Save in the editor and refresh in the browser. C# or Java: often minutes. PHP: seconds. That’s a big difference in productivity, without having to dedicate time to optimizing the build process. There are other reasons why some people prefer scripting languages, but that’s my main one (I also love how such languages are just built to Get Stuff Done; compare file I/O in Java and Perl, for instance).
There was a time when I thought that scripting languages were for writing simple, one-off scripts that would be thrown away when you were done. My first scripting language was Perl. It’s a great language, but man, you can write some ugly code with it. It’s the only language I know of where you can write a meaningful line of code without using numbers or letters (/^[^\(\)]$/; ensures that there are no parentheses in the default variable).
But, while Perl and similar languages allow you to write ugly code, that doesn’t mean you have to. It just takes more discipline to write something readable. Once I settled on using CakePHP, my team was building well-structured, readable code. You can segment code into modules to encapsulate related parts and apply style standards to work. I think ultimately the developer matters more than the language, but maybe that’s a different post.
So, what do I give up to get that productivity bonus? The biggest one, to me, is that by not having a full compile stage, there is more risk of errors. That can be anything from a typo to changing a method name and missing a reference to it. Errors like that are really simple to catch in a compiled language, but to catch them in a scripting language, you need to run the script. (I’m not counting things like missing semicolons, which a good editor can catch.) In fact, you need to run the execution path of the script that contains the error, or the error might not get caught. This was a problem for me early on. It became much less of a problem once I went to an MVC approach.
In any case, I mitigated that problem by doing something I like to do anyway: I wrote unit tests. The higher percentage of your code is covered by unit tests, the higher the chances of finding such errors with a simple click of a button. I never got my coverage rate all that high, but it was enough to give me confidence when I made changes.
Lesson learned: you can build substantial applications in a scripting language, if you’re disciplined about it.
September 27th, 2009 at 10:44 am
To play devil’s advocate for strongly typed languages, there are technologies that could give you the instant feedback you get with scripting languages, such as JRebel (http://www.zeroturnaround.com/javarebel) and GWT’s Hosted Mode (if using GWT, http://code.google.com/webtoolkit/overview.html).
Would you make the argument that those tools are indispensable to java developers because of the increase in productivity, or that you shouldn’t have to jump through hoops to get what scripting lanauges give you for free in the first place?
September 27th, 2009 at 5:51 pm
Jay, I wasn’t familiar with JRebel, thanks for the link. My work with GWT to date hasn’t shown me the same level of productivity that I’ve seen working with scripting languages — but maybe that’s an imperfectly set up development environment. With GWT, if you make CSS changes, are they immediately available in hosted mode?
I do like that GWT gives you the cross-browser compatibility; I’ve used jQuery to get the same benefit.
October 12th, 2009 at 12:24 pm
Right–the increased risk from lack of compile-time checks can be roughly mitigated with sound defensive coding practices–including TDD and aggressive asserts.
Google clearly agrees with your thesis. For a while, Python was the only language supported in Google App Engine..
Also, see: http://www.paulgraham.com/gh.html
“When you decide what infrastructure to use for a project, you’re not just making a technical decision. You’re also making a social decision, and this may be the more important of the two. For example, if your company wants to write some software, it might seem a prudent choice to write it in Java. But when you choose a language, you’re also choosing a community. The programmers you’ll be able to hire to work on a Java project won’t be as smart as the ones you could get to work on a project written in Python. And the quality of your hackers probably matters more than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages. … Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. He works for Sun.”