This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Don't Talk To Me About Life (Hacks)
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Danny O'Brien says that Life Hacks are those little quick hacks you do to solve a problem, that the rest of the world could do with. Invest 53 minutes of your time (plus download) in watching the video of his talk at NOTCON. Not living in London, or the Valley, or working in the sort of job where I can jaunt off to stuff like this at the drop of a hat, I couldn't attend. But hey; this is the twenty-first century, so I can watch at leisure and ponder.
Releasing small hacks is good. BUT; what are they useful for? What's the intended context of use? I'd never expect to take someone else's personalised backup script and drop it into the mess of interrelated machines and VPNs that is my digital environment. I guess it's more for inspiration; the how has someone else done this? thing. Yesterday I spent twenty minutes finding out how Amazon get those little one-pixel blue borders around the edges of their "boxes" (left hand column). It's a bizarre trick - see if you can work it out. Those who do HTML for a living are excused. Anyway, this example-nature, to me, is the true value of a Life Hack.
Releasing Life Hacks has a potential downside. When I was younger (so much younger than today), I released a little package to let Java classes be run under IIS and other ISAPI web servers. It was a good hack to give out, but one thing I learned is that packaging is 80% of software development (that's a deliberately controversial figure). It's not the code that does the job that matters so much; it's the code that installs it, cushions it, protects it, interfaces with stupid (and clever) humans on its behalf. That's the difference between something that you can release and something that should stay in your home directory, hidden from sight like the mad deformed cousin in the attic.
Danny also talks about how scripting isn't more widely used because it's "brittle" . I see this is a symptom of the worldview that inevitably gets wired into an application - no matter how many objects it exposes, the worldview permeates - and the more objects exposed, the more complex the scripting. The worldview is, of course, that of the developer(s); it's the way they've chosen to represent the problem domain in software. The more one tries to use a package for some task that is not quite the one it was written to solve, the more you can feel it creak around you as it's bent to fit the shape of the new problem. But then this is inevitable, because you can never really design for the future; there are always unintended consequences and unexpected uses. What you can do is to expect that your software will be used as a toolbox.
I still prefer, in general, what one might call the Unix approach - a bunch of separate tools that each do one thing well, and expect to be automated, scripted and generally mixed together in a heterogeneous environment[1]. Canonical example: the entire set of grep, sed, bash, uniq, sort, cut (and so on) utilities. This is the opposite of what I tend to end up labelling "monolithic" code; one mucking great system that does everything for you, just as long as you work the way the designers intended. Canonical example: Outlook. There's a future blog entry about how much I dislike Outlook but lack the time required to replace it, but that's something too many bloggers have done. And yes, I've been into the Outlook object model.
For me, the way in which the libraries of scripting languages have evolved represents the Unix approach in a different context (and here I have both Python and Perl in mind). With each comes a vast assembly of modules that do things, like parse strings, invoke http requests or walk directory structures. They're all intended to be scripted; to be mixed together and used to solve general problems. Along with this goes the wrapping of other applications or packages in Perl or Python libraries so they can be jolted around from inside a scripting language. Part of what's required to let this happen is that the wrapped thing has take-it-apart-to-see-how-it-works-ness, that the scriptor can peer into the workings of the thing to be scripted to see what's actually going on. Windows is bad at this - COM discovery sucks[2], even if you have the documentation. Python, in contrast, is very good at it; it's all built into the language - you can dir() stuff, read __doc__ strings, and so forth. The killer is the ability to experiment that a scripting language gives you. Don't know what a module does? Fire up the Python interpreter and instantiate some objects. Play around. Explore. The very antithesis of the monolithic approach. The essence of exploration.
If you can't find out how to actually do it, you won't script it unless you're paid to. And nobody's paid to do Life Hacks.
[1] I know that, to be pedantic, this is the Unix shell approach, but that would make for an uglier sentence. [2] I've never been 100% sure that this Americanism isn't rude, but now it's on children's TV, so it can't be that bad. Or maybe it's like "freak" - people are just being carefully ignorant of what it actually means...
Previous Topic
