Yesterday, InfoWorld ran a
story on the rise of scripting languages and an
interview with Mozilla JavaScript architect Brendan Eich. Both are very worthwhile reads because they provide a nice mix of the state of the art and the historical context of scripting languages.
Prior to hiring with Compendium about six months ago, I had tinkered with scripting languages largely as side
tasks. The mainstay of my work lie in compiled languages like C,
C++, and occasionally some Java.
As I sought out new job opportunities both locally and nationally last year, I began to realize that openings for compiled languages were on the decline. Indeed, a friend of a friend out in the Bay Area advised me last summer with these words:
In terms of technical skills, C++/Linux is a great foundation, however, there is a caveat. In the SF bay area overall, companies are more likely to use newer technologies for R&D/new development. There is still a lot of support work out there, but I would say the growing trend is to outsource support work, so those jobs are ever decreasing... Also, I would suggest making a larger investment on learning newer technologies, such as Java and other technologies on the LAMP (Linux/Apache/MySQL/PHP, Python, or Perl) stack.
That turned out to be some very solid advice, even though I wound up staying in Indianapolis. Here at Compendium, scripting languages like PHP, JavaScript, and Perl are the bread and butter of our day-to-day efforts to build user-friendly blog software. The transition proved to be pretty smooth because PHP's syntax borrows so heavily from C and C++. I was lucky in the sense that I was learning the language within a disciplined environment that made sure web apps were developed properly.
One of the quotations from the article that jumped out at me was the remark by Andi Gutmans, co-CTO at Zend Technologies.
"It's very easy to pick up and then it will also scale
with your needs," Gutmans explains. "I often call it the Visual Basic of the Web."
The ease with which the language is learned is a double-edge sword. On one hand, it flattens the learning curve, but on the other, it gives mediocre programmers enough dynamite to be dangerous.
Jeff Atwood at
Coding Horror noted as much about a month ago in his bluntly titled blog post
"PHP Sucks, But it Doesn't Matter". Atwood does a pretty good job of surveying the disdain as well as the widespread usage that PHP has managed to garner, but I don't think he quite closes the loop in his analysis.
Syntactically, PHP is a pretty elegant language. It steals enough syntax from C++ to be familiar but escapes the hideousness of template meta-programming because a dynamic language doesn't have to worry about how to deal with generics.
From my own experience the bad reputation of PHP has two origins.
The first lies in its original use as a way to embed server-side executable code within an HTML document. Web programmers latched onto this in droves and abused it, creating websites that did not separate the business, presentation, and application logic cleanly.
The second sore spot is how PHP has managed to assimilate just about every third party library under the sun. If you've ever had to install PHP or build it from scratch, you already have a deep appreciation, or at least a healthy fear, of how many optional elements can be integrated into the system. A lot of times, these APIs are written to parallel the nomenclature of library APIs in C or C++, which makes for inconsistencies.
Ironically enough, both of these things are probably among the factors that helped speed the adoption of the language.
What has helped sustain PHP? Two things come to mind, based on my limited experience.
For one thing, the PHP development community got Model/View/Controller religion. Nowadays, there are tens of PHP frameworks designed to help developers employ the MVC design pattern, which helps separate the logics and avoid the ugly code for which PHP became notorious. Granted, not all of them are of equal quality, and some have already gone dormant. What's important is that enough developers realized that the old way of doing things was neither sustainable nor scalable.
The second thing was the under-the-hood change of basing PHP on the Zend engine, which has helped it to achieve performance levels that you might not expect from a dynamic language.
For all of the speed of development that one achieves with a dynamic language, there is one thing I could live without. The incredible syntax flexibility of a scripting language like PHP can allow you to create code that is syntactically correct but semantically crazy.
For example, I recently wrote some code that was intended to build up a string that you could pass on to a logging facility. It looked something like this:
$logger_string = 'problem with operation foo ' .
$print_r($some_variable, true) . ' some more text';
The bug in this code was that there should have been no dollar sign in front of
print_r. It's a function name, not a variable. PHP sees this as just fine and dandy, converting
$print_r into function name, provided that the variable name evaluates to a string. This kind of thing will pass the PHP syntax checker but will cause a fatal error at runtime. It's similar to the situation where a spell checker won't save you from using mistakenly using a homophone.
In spite of all of that, I'm happy to be coding with PHP. Errors like those above are pretty rare. Moreover, I don't miss having to worry about type declarations and memory management. In spite of numerous sins of programmers past, I firmly believe that PHP is a great language to build a solid blogging platform. We're already doing that!
I've been trying to find a new briefcase for work. My intent was to purchase a really nice one -- like Tumi quality because I keep buying cheapos that look nice and then fall apart in a few months. Except I didn't want a Tumi because...well, I just don't like their styles all that much.
I admit, I have a slight Facebook addiction and through my self justification of this time waster --- I realized a few of the reasons I am so addicted to Facebook:
We tell our clients that best practices for a blog post is anywhere from 2-5 paragraphs. This keeps your readers engaged. They are able to find what they need in a blog post rather than digging through piles of information. If you find yourself writing posts that are 10, 11, and 12 paragraphs then it is time to shorten them up. You can also split them up into several posts or have them as a series of posts. 
Okay, I'm back to my comments about the Forrester report saying that B2B blogging is on the decline. 
To our clients out there - let us Hoosiers here at 
Blogging takes this a step further.
"always be there", presenting relevant solutions when people come searching. Remember how Superman was somehow "always there" when someone was in trouble? Consider business blogs your Superman-like power to be present when a problem arises (only people are typing into Google, not yelling your name for help).
