Flutterby™! : Steam Lisp

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Steam Lisp

2011-04-14 18:49:57.382289+00 by Dan Lyke 2 comments

Needs more exposure: Steam Lisp and Where Lisp Fails: at Turning People into Fungible Cogs.

I predict that no tool of any kind which too greatly amplifies the productivity of an individual will ever be permitted to most developers. In this they shall follow in the maximally deskilled assembly-line footsteps of their grandparents. ...

Whence the popularity of Visual Studio. Via BrainLog.

Relatedly, I recently ran into someone in a coffee shop who said "I've got a client who needs to do a sortable searchable HTML table". A few minutes with Perl, Spreadsheet::Read, jQuery and DataTables and I had a solution. Unfortunately, that solution runs under Linux, and I'm not at all sure how I'm going to deploy it in the guy's Windows environment. So a few minute hack (for me) that I'd have been happy to do in exchange for lunch is going to turn into a couple of hour consulting gig (expensive for him, a pain in the ass for me 'cause I like to bill in days or months, not hours) while I try to figure out how to shoehorn automation into his closed commodity environment that's built for holding cogs in their place, not for creative activity.

[ related topics: Free Software Weblogs Microsoft Perl Open Source Nature and environment Work, productivity and environment Furniture hubris ]

comments in descending chronological order (reverse):

#Comment Re: made: 2011-04-15 02:45:40.580608+00 by: Dan Lyke

Yeah, every time I provision a new home computer I realize just how broadly distributed my various personal processes are. Stuff on my every-day laptop, stuff on my house server, stuff on my web server, all talks to each other and gets backed up to each other and needs to be migrated and it's a big deal.

#Comment Re: made: 2011-04-14 21:37:49.751504+00 by: spc476

One issue with automation though, it that when things break, they break!

For instance, I'm responsible for testing the call processing product our office is making. Even before I start running the test program, I have to start 55 processes across four boxes in a particular order. Then, I have to hope that the SS7 stack hasn't puked on itself as I start the regression test program. I could automate that, but it requires running 48 processes as root, 2 processes as nobody and three as "don't care" (i.e. any account can run them).

So assuming I get that all working. Something breaks. If I'm not around to troubleshoot it, what's the point of automating it to begin with? Even now, if the SS7 stack is borked, I can't fix it since I don't know how (and there have been several times when the person I go to when it's broken can't fix it and he has to go to his manager (who is severely overworked) to fix it because he has twenty years of experience with the particular SS7 stack we're using).

Our issues with automation and non-coggery is independent of the tools we use.