From: Daniel Brockman <daniel@...>
Date: 2005-07-20T11:42:39+09:00
Subject: Re: [OT] blah

Devin Mullins <twifkak@comcast.net> writes:

Devin> Joel Spolsky has a decent piece on making wrong code
Devin> *look* wrong.

>> I guess I'll have to dig it up.

Devin> http://www.joelonsoftware.com/articles/Wrong.html

Thanks!  That's a great article, and I don't think I did
read it before.  I'm sorry, I just have to quote a few
passages that I found particularly amusing.

   “It’s at this point you typically say, ‘Blistering
   Barnacles, we’ve got to get some consistent coding
   conventions around here!’ and you spend the next day
   writing up coding conventions for your team and the
   next six days arguing about the One True Brace Style
   and the next three weeks rewriting old code to conform
   to the One True Brace Style until a manager catches
   you and screams at you for wasting time on something
   that can never make money, and you decide that it’s
   not really a bad thing to only reformat code when you
   revisit it, so you have about half of a True Brace
   Style and pretty soon you forget all about that and
   then you can start obsessing about something else
   irrelevant to making money like replacing one kind of
   string class with another kind of string class.”

   [...]

   “Now, when I’m writing a dinky script to gather up a
   bunch of data and print it once a day, heck yeah,
   exceptions are great.  I like nothing more than to
   ignore all possible wrong things that can happen and
   just wrap up the whole damn program in a big ol’
   try/catch that emails me if anything ever goes wrong.
   Exceptions are fine for quick-and-dirty code, for
   scripts, and for code that is neither mission critical
   nor life-sustaining.  But if you’re writing an
   operating system, or a nuclear power plant, or the
   software to control a high speed circular saw used in
   open heart surgery, exceptions are extremely
   dangerous.”

Anyway, great as the article may be, I feel morally obliged
to include the following small note of warning.

      WARNING:  There is a VERY REAL RISK that the
      aforementioned article WILL SUCCEED in turning
      you on to Hungarian notation.

>> Aw, come on.  You don't even need the __END__ in any
>> other files apart from the one that contains the main
>> entry point.  Actually, if you write that file in vanilla
>> Ruby, you don't need to put __END__ *anywhere*. :-)

Devin> Sorry! Maybe I'm just broken. Maybe I'll experiment
Devin> with it.

Cool!  If it gives you any trouble, please let me know. :-)

>> Hey, you gotta have a system metaphor.  Mine is a cookie
>> monster that eats text instead of cookies. :-)

Devin> Hrm. Haven't had a system metaphor yet. Now I know
Devin> what I'm missing out on.

Look here for more information:

   <http://c2.com/cgi/wiki?SystemMetaphor>

-- 
Daniel Brockman <daniel@brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this?   --TTN.