software design (was Re: [geeks] perlish disgruntlement, java considered, sun hardware sought)

[alex j avriette]

On Monday, April 8, 2002, at 06:33 AM, David Cantrell wrote:

> On Sun, Apr 07, 2002 at 08:53:46PM -0400, alex j avriette wrote:
>> We're not talking about short cuts here. We're talking about clear and
>> concise code. If you cant understand map and would prefer foreach, 
>> well,
>> thats fine. But my code is going to gain that 10% efficiency for its
>> 5,000,000 iterations.
>
> Did you bother benchmarking your nested maps against my solution using a
> single foreach?

no, and i dont have to for reasons i'll explain in a moment here.

>> my %hash = map { chomp; /^([^@]+)@([^\s]+)$/ ? ($1 => $2) : () }
>> read_file("filename")
>
> Errm, proper indentation?  You should indent the second line there so 
> that
> it is obvious it is really part of the first and not to be read on its 
> own :-)

you have either my MTA or your own to thank for that.

> And you mean \S, not the harder-to-read [^\s].
>
> If you're going to pontificate on perl style, it's a good idea to learn 
> the
> language first.

yes. but code written on a mailing list to indicate a point (i guess 
with the exception of a patch) is hardly worth judging anyone on.

>> i'm sure you find that very readable. i find it hideous and abhorrent.
>
> It is indeed very readable.  The only bug I can see is that there is no
> error-checking (although that might be done later by looking at the 
> contents
> of the two variables, I can't tell from that snippet).

error checking? whats that? you mean

[Mon Apr  8 07:40:19 2002] [error] [client 10.1.2.1] malformed header 
from script. Bad header=permission denied: 
/Library/WebServer/CGI-Executables/pd.cgi

is not valid error checking? rubbish.

>> your c professor would fail you for making system calls in code.
>
> I don't give a rat's arse what your C professor would do.  This isn't C,
> and I'm not a student.

perhaps i should refrain from figurative speech and sarcasm and other 
forms of humor on-list. that having been said, you missed the point.

>> if youre not writing code that is *fit* to be passed from person to
>> person, you shouldnt be writing code.
>
> so if the shell porogramwhich I use for publishing my website is a dog's
> breakfast, I shouldn't have written it at all?  How, pray, is one meant

no. again, youve missed the point. you should have written it well to 
begin with. i never sit down to write _any_ code without "designing" it 
first. i figure out what the needs of the application are. i start 
working on "compartments" of code based upon those requirements, and i 
further compartmentalize those individual compartments if i can. this 
way i am making sure that in the future i am looking over the code, its 
just code (not an intermingling of code and data), and also should i 
need to rewrite, i can take the good and rewrite the "bad" (which for 
whatever reason needs to be changed -- but isnt necessarily bad, just 
dated).

it makes me *sick*, literally, to write code that is ugly or unportable 
or breaking an API or without an API. every time that i've done this (i 
was forced into such a situation last thanksgiving actually), i could 
not sleep or eat until i had fixed the code, generalized and 
compartmentalized it, and fixed the DB schema it was working with. 
literally sick. im not sure whether to be sorry you dont have the same 
trait or not. i consider it mostly a blessing.

> to learn to program if one isn't allowed to write one's first non-
> trivial program in $language?  That particular shell program is ugly,

my first perl "program" was a wrapper for tcpdump (i had written scripts 
in it before intending to move data around but i wouldnt call them 
programs). i learned from one of the best perl programmers there is -- 
Jeff Pinyan -- as I went along. i went along with the rules i learned in 
college in CS:

compartmentalization
orthogonality
portability
proper indentation
lack of global variables (see orthogonality)
proper comments
dont repeat yourself (write a sub/func/proc/macro)

and my little tcpdump program had several compartments:

managing the tcpdump program
input gleaning
pattern matching
text modification
output patching-together-of

so my first perl program was around 400 lines. i used very rudimentary 
regexps, i didnt use map when i should have, and i overused split and 
join when working with arrays. however, the code didnt suck, and i'd be 
happy to work on it today.

> but I have learnt from it.  My next shell program will be better.  That
> one though - I can't be bothered to fix it, cos it does the job *and* is
> for my use only so no-one else needs to understand it.  Hell, *I* don't
> need to understand the code any more.

you will continue to tell yourself that until the time you need to 
rewrite or replace it. then you'll spend an entire weekend (week?) on it 
instead of an hour or two with a cup of coffee.

i think perhaps this thread has come upon a personality difference in 
the various posters. when something goes wrong with my car (and it 
happens sometimes), my question isnt "what do i need to do to get it 
fixed," but rather "what is the best possible component I can use to 
replace this so that I'm not faced with it again?" my car is over 20 
years old now, and i know every single nut and bolt on it because _i put 
it there_. i have complete trust in all of its components because i know 
that i made _the right decision_ when those components were installed. 
the same is true of the way i cook and even shop (if you have a recipe 
for "tuna," you dont buy the yellow slimy stuff that satisfies the 
requirement, you buy the sashimi grade yellowfin steaks -- bluefin is 
impossible to find -- and cook it with similarly superior ingredients).

so i'll ask again, why is it we own suns and sgi's if its simply okay to 
"get the job done?"

alex

--
alex j avriette, perl hacker
avriettea at speakeasy.net
http://envy.posixnap.net/