Secret weapons of LISP and Perl
Just saw Gordon Weakliem mention, via Roland Tanglao's Weblog, this article over at New Architect: Orbitz Reaches New Heights. This snags my eye for two reasons: 1) Orbitz is a client of my employer - we do a ton of web promotions for them; and 2) LISP is one of those things I keep meaning to get back into, kinda like I keep meaning to read things from that gigantic Shakespeare collection I asked for and recieved for Christmas from me mum.
The quote that Ronald pulls out from the article is:
The high-level algorithms are almost entirely in Lisp, one of the oldest programming languages. You're excused for chuckling, or saying "Why Lisp?" Although the language can be inefficient if used without extreme caution, it has a reputation for compactness. One line of Lisp can replace 20 lines of C. ITA's programmers, who learned the language inside and out while at MIT, note that LISP is highly effective if you ditch the prefabricated data structures. "We're something of a poster child for LISP these days," says Wertheimer. "Lisp vendors love us."Funny, if you did an s/Lisp/Perl/g and an s/LISP/Perl/g on that text, you'd almost have a quote from me. I've also heard Perl often compared to LISP, amongst the upper ranks of Perl wizards. Oldest language-- hmm, no, but it's been around the block. Inefficient without caution-- check, hand-holding is at a minimum. Compactness-- check, many bash it for obfucation facilitation. Effective after ditching prefab structs-- check, if you enjoy slinging hashes all over, like I have until recently. And so far, we're a poster child for Perl here.
What is it that I have in Perl? Well, I've named it the Toybox. It's a web application platform. We do everything with it. Reusable software components composed into applications with a web-based construction tool. The components contain machine and human readable descriptions on properties and methods, to enable inspection by tool and documentation generation. Also, the components and the framework are designed to provide predefined collaboration patterns so that one component can supplement or modify the behavior of another without that other component needing to be modified or altered. I've also just recently added a persistent object layer for all those pesky little parameterizing trinkets we started needed to throw around. (I really wish I could Open Source this thing. :) )
So there's a continual grumble here to switch to Java, sometimes from me, and sometimes from another developer or two. In some ways, a switch and reimplmentation is a no-brainer, considering tool support and labor pool. But, is this overhyped? Wherever I've gone, I've just picked up whatever was used there. My basic computer science background lets me switch technologies pretty easily. Is this rare?
But as for the languages themselves... From the trenches, doing object-oriented stuff in perl is painful and dirty. In a lot of other ways, it feels nice because you can jump out of the OO mindset and do some naughty things when you think you need to. And if you're careful. But when you do, you don't get any help from the language, which I think is one of the major selling points of Java.
And then occasionally, a client demands to know the specifics of our platform. Such as, what vendor's app server are we using? What database server? And when we say Perl and a platform almost completely developed in-house, noses crinkle and doubts arise. But they rarely have a complaint about the end result and the speed at which we execute it.
I guess what I'm getting at is this: Having a hard time untangling politics, job market, and the right tool choice. LISP seems to have done alright by Orbitz, and Perl's done alright by us. So far, that is. I always vaguely worry about the "non-standard technology" I use here, though. Is that such a valid worry, or am I just swallowing vendors' marketing pills like our clients? Because the "standard" just happens to be the buzzwordy things that a number of companies sunk money into and work hard to justify.
But, hell, someone had to have started creating something alien and new to come up with what's "standard" today. I seem to see stories from time to time about companies whose "secret weapon" is just such a "non-standard technology". They avoid many of the pitfalls that the herd faces by taking their own path, but trade them for new ones. There's risk in that, but then again there's risk in everything with a potential for gain.
Then again, there's the argument against wheel reinvention. I seem to like reinventing wheels sometimes for the hell of it, simply because I want to know how wheels work. Sometimes I even feel arrogant enough to assert that I can make a better wheel. But there is a point where just buying the thing and moving on is the smart option.
Oh well... I've come to no conclusion. But I'm still writing Perl code in my xemacs window today, and about to get back to it when I hit the "Post" button. And things seem pretty good here-- I mean this company managed to claw through the wreckage of the dot-com collapse and still edge toward a profit. We lost more clients due to their bankruptcy than through customer dissatisfaction.
I suppose I can at least say my choice of Perl, if not a secret weapon, didn't break the bank. :)
shortname=oooafc
Archived Comments