|Problems? Is your data what you think it is?|
(MeowChow - Rant ON) Re: Productivity and Perlby MeowChow (Vicar)
|on Jun 02, 2002 at 03:02 UTC||Need Help??|
Now, I don't want to get off on a rant here, but if you intend to prove that your pet language is superior to mine for real-world work, at least back it up with a real-world example of a problem that your language solves more naturally and elegantly. And that doesn't mean you should spin some apocryphal anecdote about how Widgets Incorporated turned to your pet language to turn their business around and turned a quick buck while their competition are now taking turns at the unemployment counter turnstyle. Sure, this sort of anti-FUD may collide with the particles of real FUD bouncing around a PHB's hollow cranium and help to illuminate that otherwise dark and vacuous cavity, but I'm a programmer -- I want to see code.
That said, the code example Graham offered was about as useful as the buggy four-page "hello world" program from Que's latest installment of Mastering Java Unleashed in 21 minutes for the Mentally Challenged. Demonstrating how difficult it is to create accumulators in various languages that donít naturally support closures tells me more about the deficiencies of the author than the deficiencies of the languages in question. An accumulator is just a fancy, functional way of performing a simple imperative task, namely x+=y. Graham's argument is as convincing as the collective ramblings of the OOP zealot who insists that because your language doesnít support introspective-metaobject-operator-inheritence, itís not a "true object-oriented language", but at least the zealot is fun to punch in the face... again, and again, and again. And by the way, my language does support introspective-metaobject-operator-inheritence, you just have to go out and buy TheDamian's book, it's all in there, really, it is.
Others have already taken issue with Graham's assertion that there is a linear relationship between code size and development time. Even if this claim were correct, Lisp is stunningly mediocre when measured against this metric, especially for such a supposedly high-level language. Lisp is hardly renowned for its terse and succinct code; a golf contest in Lisp would be about as much fun as an eat-the-biscuit circle jerk, minus the biscuit.
Donít get me wrong, I have nothing against Lisp, except for its verbose, parenthesis-laden, unidiomatic, overly literal, hyper-indented code that makes my eyes burn and my nose bleed. Macros are cool, and sure, itís nice to be able to shoehorn, er... embed Lisp into your already bloated realtime pacemaker application, you know, for end-user programmability. Just donít tell me that your language is so much more powerful than mine, while Iím getting actual tasks done and youíre busy macro-morphing Lisp into a language that still sucks but is just perfect for your problem domain, because you know what? We have a word for that around here. It's called Perl.
Of course, that's just my opinion, I could be wrong.
MeowChow s aamecha.s a..a\u$&owag.print