December 2007 Archives

my $thoughts; rand ( $thoughts );

| | | |

Perl is now 20 years old. If your wondering what Perl is, Perl is a programming language originally developed by Larry Wall. This 20 year old scripting language became widely adopted for its strengths in text processing. In the world of Unix-based systems (Linux, FreeBSD, Mac OS X for 'modern' examples) most everything is a text file or stream of text. This means, given a language like Perl, anything can be manipulated by a simple script containing a few lines of code. Even before the Web made the Internet a must have in every home (and soon in every pocket) Perl was gaining a reputation as "the duct-tape of the Internet" for its ability to connect disparate systems together.

However, to say Perl is just a scripting language for text manipulation misses the point. In the past 20 years Perl has done well in keeping up with trends in the word of computer science. Perl 5 introduced object oriented programming among other things to the world of Perl increasing its flexibility and use. Perl can deal with text manipulation, process management, rapid prototyping of software solutions and - in my world of software development - is the backbone of web applications such as ... Zoomshare.

I was first introduced to Perl back in the early days of the Web in the mid-90s while working part-time at a local computer bookstore. Being a programmer working my way to a CS degree I was charged with putting a copy of our book catalog online such that technically savvy users, are main customers, could search our catalog from the comfort of their own office. Text manipulation and web integration, the two main challenges of the task then at hand, put Perl on my list of languages to learn.

Having already learned Pascal and C I immediately felt at home with the Perl's syntax. But what really made me feel all warm and cozy was Perl's scripting background. As an interpreted language the natural give and take of working on a task; write, execute, debug, modify, execute again and the non-structured, free form methodology reminded me of my first programming language, BASIC.

What I mean is with a language like C or Java its almost a most have to work with an Integrated Development Environment (IDE). An IDE consists of a source code editor, a compiler and/or interpreter, build automation tools, and a debugger. IDEs can also included version control tools access to common libraries and blah, blah, blah. IDEs always seem to get in my way and I just never feel at home in any of the IDEs I've tried. I suspect I was poisoned by my Apple IIe as I learned Applesoft BASIC, sitting for hours just writing code, executing it, debugging and rewriting with nothing more than the command-line provided by DOS 3.3 or ProDOS.

That's not to say Perl can't be written using an IDE or that C must be done using a IDE. But given Perl's background in the world of Unix where everything is text, why does one need a editor, Perl interpreter and everything else wrapped into one huge program when the platform already provides an editor (vi and/or emacs) and anything else, like the Perl interpreter which can be invoked by simple execution at the command-line?

As for the non-structured part, well while its not grand code if one writes in Perl in a non-procedural methodology, it is possible. While it can be a crutch it also means one can choose and pick a methodology as needed from object oriented to 'spaghetti code'.

That's the thing about Perl. Many languages tend to specialized in one area or discipline. For example there are a number of web development languages these days such as PHP, Phyton or Ruby. Classic object oriented languages include Java and C++. There is the trusted procedural standby C. And anyone whose has explored the depths of Microsoft's productivity suite Office has encountered VB. Yet Perl, seems to be able to do it all....

Its Perl's blessing and its curse. But it does explain Perl's underlying philosophy, that there is any number of ways to do the same thing.

Here's to the next 20 years of Perl.

Facebook's Broken Beacon of Light?

| | | |

Yesterday Mark Zuckerberg of Facebook apologized to Facebook users after the uproar that has resulted from Facebook's latest feature Beacon. The idea behind Beacon is to "help people share information with their friends about things they do on the web." That is Beacon allows Facebook members to share information about their online activity, purchasing a book or posting a product review on a Facebook partner site with others in their social network. Zuckerberk relates that this "simple idea" missed the "right balance" between not "get in people's way ... but also clear enough so people would be able to easily control what they shared." As a result his apology to all notes that changes have been made, including the default behavior of Beacon, which was switched from 'opt-out' to 'opt-in'.

While reading his post, in part because of a prompt from Sare, I realized I've heard this discussion before, its a common view of 'security' vs 'ease-of-use' a lot of programmers have. Well the similarity makes sense, after all personal privacy, the what/where/when/how of sharing, is at its root an issue of security. Hence Zuckerberg's framing of the good/bad/ugly of Beacon version 1, that the two are at diametric opposites; adding security complicates the user experience whereas removing security eases the user experience and that one needs to 'balance' the two at any given time in software development.

The thing is, is I don't really buy that. I mean, yes that might always seem to be the case, but I think that has more to do with the fact that we programmers have painted ourselves into that corner by thinking of the two issues as polar opposites for sometime now. Moreover, I think it becomes an issue of lazy programming since we can say, "it an either/or proposition, pick one and that's what we live with since I can't/don't want to develop something different."

(For a more conventional, not to mention cynical, spin on Facebook's Beacon check out Steven Levy's Do Real Friends Share Ads? article for Newsweek in which Levy suggests that in the rush to maximize Microsoft's $240 million investment Facebook didn't have its user's best interest in mind at all.)

An illustration of my point, a few weeks ago Bruce Schneier posted about a video showing how to circumvent a soda machine. The posting got me thinking about how 'back in the day' it was common knowledge in my high school that one could exploit the dollar bill reader by fooling them with one-sided, black and white, photocopies. If I had to guess, based on the observed behavior, the readers simply cared about being given a piece of paper of a specific length and width that at some point matched the pattern for a One Dollar Bill (some pattern that, I assume, was dissimilar enough to say a Five Dollar Bill). No color matching, matching backside, etc. Today those same readers are more sophisticated, that old 'trick' won't work. Yet the reader's 'user interface' is still the same you orient the bill as pictured, slide the bill in and at some point the reader grabs hold of it, either accepting or rejecting your offering. You, the user, don't have to do anything new, different or complicated, yet the 'security' of the system is greatly enhanced. Sure some readers can seem overly fussy and frustrating, but I've also seen readers that care little about the orientation of the bill, easing use, without, I'm sure, exposing the machine to past vulnerabilities.

The soda machine issue also demonstrates another point about computer security since the 'cracking' of the vending machine is an excellent example of that ultimately it is not about having the programming code in front of you so much as the behaviors, expected and unexpected, that code details that can cause a security issue. In the case of the soda machine video someone discovered how to get the machine to 'fail' and then exploited that to their advantage. In the case of my high school reminiscing it was about literally given the machine what it expected. As Schneier notes this is a simple enough exploit, no source code needed, just a little patience by the observer who determines what behaviors the machine expects by how it reacted.

A few months ago I tried to make the same observation about, ironically enough, a 'security breach' at Facebook when some PHP source code got 'leaked' onto the Internet. It would seem the same can be said for Beacon, its not the code itself that can be an issue but the, in this case, expected behavior that actually becomes a possible security/privacy issue for the user.

The point, if there really is any here, is that on the surface computer security and personal privacy can look cut and dry, good or bad, usability or security, black or white. But, as with those old dollar bill readers, if you ignore the other side, read only in black and white and look only for what your expecting, you can get fooled fairly easy. Oh and that teenagers have a logic all their own since the thought of breaking Federal-counterfeiting law is worth the price of a 'free' soda.

~~~ Stumble It! ~~~ Reddit ~~~ Digg This! ~~~

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.


Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Movable Type Pro