Personally, I tend to use 'quick and dirty' when I really mean
'only-lightly-tested'. As in: "Here's a solution that seems to work"
rather than just "Here's a solution".
Also, a lot of scripts I write for myself are 'quick and dirty'. Mostly
they work, but I don't actually remember _how_ with all of them 
···
On Sat, 2006-06-10 at 02:54 +0900, James Britt wrote:
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk
Louis J Scoras wrote:
You're making a good point here. But to me it feels like a "if it works
don't fix it" kind of thing. I mean, all in all, wouldn't Ruby prevail?
Feel free to show me some examples though.
# mp32ogg [untested] - quick and dirty conversion:
mpg321 -w - somesong.mp3 | oggenc -o somesong.ogg -
Question (maybe a bit off-topic):
The example may be quick, but in what way is it dirty?
More generally, why do those two words get used as if they were joined at the hip? Is there a bias against being quick, a belief quick only comes at the cost of clean code?
I think it's a linguistic quirk of English more than anything else. Like the canonical example of 'kick the bucket,' it's an expression that doesn't quite parse for native speakers if you substitute otherwise-equivalent words or grammatical constructions. For example "quick and grubby", "speedy and dirty" or "fast and filthy" don't quite have the same meaning (though I do like that last one quite a bit).
In my experience, 'quick and dirty' doesn't necessarily mean *bad* - a quick and dirty meal can be tasty - it's more a description of the process or role of the activity; informal, slightly tangential to your goals, but has to be done anyway. In other words, it's the means to an end rather than an end in and of itself. And Ruby is *really* good at that sort of programming, precisely because it's quick.
My usual response is that I prefer quick and dirty to slow and dirty; Java or C# (the usual suggested alternatives for "real" programming) offer no more assurance of clean code than using Ruby; indeed, the opposite is likely more the case.
Regardless of the speaker's intention, I think that's a great response. Even better if the phrase is just being used as an idiom, since it focuses the speaker's attention on what 'dirty' code would actually mean.
matthew smillie.
···
On Jun 9, 2006, at 18:54, James Britt wrote:
On 6/9/06, Kyrre Nygard <kyrreny@broadpark.no> wrote:
Louis J Scoras wrote:
More generally, why do those two words get used as if they were joined
at the hip? Is there a bias against being quick, a belief quick only
comes at the cost of clean code?
I think I used that phrase because for as much as I hate them, I am
weak and easily fall into the temptation of using cliches *smirks.*
I didn't mean to single you out; I hear it all the time, and use it myself without thinking, and it struck that it may get used (by most people) more from habit and bias than astute observation.
Maybe there is some value in calling people on it when they use it to bring some awareness: quick != dirty, and the choice to omit various behavior (robust error handling, for example) is not always a sign of weakness. The cost of such behavior may be greater than its value.
···
On 6/9/06, James Britt <james_b@neurogami.com> wrote:
--
James Britt
"A principle or axiom is of no value without the rules for applying it."
- Len Bullard
Louis J Scoras wrote:
> I think I used that phrase because for as much as I hate them, I am
> weak and easily fall into the temptation of using cliches *smirks.*
I didn't mean to single you out; I hear it all the time, and use it
myself without thinking, and it struck that it may get used (by most
people) more from habit and bias than astute observation.
Oh I know. I was just trying to poke some light-hearted fun at myself
=). I didn't take it as being singled out. To go totally off-topic
here, I think the worst is "step up to the plate." Seriously, it
makes it very difficult to enjoy watching "The Apprentice".
Maybe there is some value in calling people on it when they use it to
bring some awareness: quick != dirty, and the choice to omit various
behavior (robust error handling, for example) is not always a sign of
weakness. The cost of such behavior may be greater than its value.
Very well said. I would say that "dirty" implies "unpolished", not
"unclean", and I agree with you--in some circumstances robustness is
certainly less important than getting the job done. As Ken Thompson
said: "When in doubt, use brute force."
···
On 6/9/06, James Britt <james_b@neurogami.com> wrote:
--
Lou.