Re: Programming Mantras
by japhy (Canon) on Jan 21, 2002 at 06:53 UTC
|
I often think "I've come a long way."
I've come a long way from emailing Larry Wall that his language is cool and that I've written a gcd() and lcm() function that I think he should add.
I've come a long way from writing &foo(...) everywhere, and using @array[$x], and calling external programs where Perl was obviously the better choice.
I've come a long way from writing 20 lines of code where 10 would do, and writing 10 lines of code when 5 would do.
I've come a long way from hand-rolling half-assed overly-specific solutions to problems, instead of using well-written, well-documented modules.
I've come a long way from pissing off Tom Christiansen on EFnet #perl. I've come a long way from sitting at my computer in awe of the fact that I was just talking to the author of the Perl book on my desk.
I've come a long way fro-- wow, what a silly way to code that. I can do that much better... (and off he goes to code some more)
_____________________________________________________
Jeff[japhy]Pinyan:
Perl,
regex,
and perl
hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??; | [reply] [d/l] |
|
| [reply] [d/l] |
Re: Programming Mantras
by Albannach (Monsignor) on Jan 21, 2002 at 06:19 UTC
|
I don't know if it's really a mantra but the voice in
my head when I'm debugging often says "don't stop at one".
This comes from my boss/mentor during a work term at a
really cool shop
in 1984. I was coding on a Cray 1S at the time, and as
compiling was a long term process, he explained that just
fixing the one error that the compiler spat out was often
shortsighted, as there could easily be more examples of the same
error in other locations, or that error could have been
caused by an earlier error, or perhaps a more fundamental
logic problem.
These days I usually don't have too long to wait for my Perl projects to run
(either they are pretty short, or I construct tiny sample datasets for testing),
so I take this advice to mean "don't stop at the easy or 'obvious' answer, as it
is often neither".
--
I'd like to be able to assign to an luser | [reply] |
|
(not really a perl thing, but...)
just fixing the one error that the compiler spat out was often shortsighted, as there could easily be
more examples of the same error in other locations, or that error could have been caused by an
earlier error, or perhaps a more fundamental logic problem.
I have to disagree on that one, the first lesson I
learned the hard way in my first CS class was not to
get bogged down by compiler errors. The prof had given us
some C code, and our assignment consisted of two parts:
- fix the code so it compiled and ran
- modifiy it so it did something slightly different.
As provided, the code generated about 42 compiler
errors/warnings ... people (like me) who tried to fix
more then one error at a time, or fix the later errors
first, spent forever on the assignment. Had we started
at the first error, and then recompiled, about 3/4s of
the errors went away. Fixing the next (now first)
errors made the rest go away.
Moral: start at the begining, and proceed in sequence.
At each step make sure that what you've done has fixed
the first bug, and reduced the total number of bugs.
| [reply] |
|
Superficially it seems that you advocate the whirlpool model
instead of the waterfall one. But really you advocate tripping
blindly in the dark. As I will show, there is nothing wrong with
the method of your teacher but you are getting the wrong lessons
out ouf it!
1. fix the code so it compiled and ran
Most compilers run completely out of sync at the first syntactical
error and produce a cascad of errors. So
incremental fixing is a way to get a program to compile.
That was probably the lesson the teacher wanted you to
learn. I don't see any other interesting lessons to get from
that. Getting a program to compile is no big deal!
2. modify it so it did something slightly different.
That's the way we do everything. Proceed from the known to
the new. We never start anything from scratch but learn from
previous experience. The good teacher is the one that impose
in an new exercice a "slightly difference" so that the pupil
can both build his confidence and exercice his own initiative.
But deducing from these exercices that programming is incremental fixing
of bugs is dead wrong.
Incremental improvment of programs, or Larry's whirlpool
(as opposed to the waterfall model)
is way more than that. Testing and fixing is just the inner
loop or the whirlpoool.
But what you propose is not even that,
it is the blind fixing of visible bugs probably creating countless
of bugs elsewhere. In the linux kernel mailing list,there are recurring threads about self-proclaimed
the bastard Linus against getting a debugger in the kernel to fight
this natural but wrong tendency: "just fix the next bug"
and to encourage programmers to always get the larger view
I guess I could derive my mantra from Arthur Koestler notion
of holon.
Every complex system is an holarchy where higher holons
depends on lower ones.
A program is such an holarchy and
the first thing to know is at which stage of the holarchy
you need to work. Fixing blindly bugs after bugs is working
on lower holons and at best building scar tissues.
In more pragmatic term, getting local optima (here fixing given bugs)
are no guaranty of a global optimum.
And we live in a society where every one is a specialist of
some holon and is able and prone to get a local optimal there but is likely create
a disaster at higher level.
Example: "an optimal so-called liberalist american economy
is likely to wreck the global ecosystem because it does not
care about global warming". Pick up your favorite example.
So the mantra is Which holon needs working? or in term of
Larry's whirlpool Which loop of the whirlpool needs work?
Certainly, these mantra, as any mantra, set the mind but, by themselves, do not
define any course of action.
The devil is in the details and we must go define
in a given fields what an holarchy is and from which holon
it is made. Different schools of programming have various
ideas about that.
I like the concept of holon and holarchy but beware
not to get in new-age drug induced illiterrate holistic dreams!!
--
stefp -- check out TeXmacs
wiki
| [reply] |
|
|
The point I was trying to make is that the compiler error usually tells you one vague thing: you did something wrong. Unfortunately it does not tell you to any useful extent what you did wrong. It could be anything from
a simple typo in one line that lead to 42 messages, or you
could have a whole host of fundamental flaws, and there are many options in between.
In fact, I think I'm safe in asserting tha the most serious flaws in programming are too subtle to be reported by any automated means, so when you do get a warning or an error, the wisdom my boss meant me to take was this: view this warning as a moment of reflection to consider all that leads to this point and all that follows, and take a moment before you simply change one character in a knee-jerk reflex and re-compile.
For another example, I am reminded of a silly little activity my geek friends and I enjoyed in high-school, when we had gained access to the the first BASIC interpreter we'd seen. The speed of response was positively intoxicating! When we got some code from elsewhere, and received the "syntax error on line nnnn" message, we'd just delete that line and re-run, repeating this process over and over. We were at least sure to never get that particular error again (now that's "de-bugging" ;-), and while the result was often a program reduced to just a handful of lines that did little or nothing, sometimes we'd get some really interesting behaviour which would amuse our adolescent minds for minutes at a time. I don't believe we ever got a correct program out of this process however ;-)
While I was writing this, I noticed a great line from virtualsue in the CB:
Programming is a craft not a religion. It's not all that different from construction work ;-)
I think this is absolutely true, and following that metaphor, consider whether a contractor should simply patch cracks in a wall, or have a look to see if there is a larger problem elsewhere in the building.
--
I'd like to be able to assign to an luser
| [reply] |
Re: Programming Mantras
by djantzen (Priest) on Jan 21, 2002 at 06:45 UTC
|
"Hmmmm, Mountain Dew.... Hmmmmm,..."
Actually, I find myself reflecting a lot on what future maintainers of my code will think of what I'm writing. Every programmer has inherited code that's a nightmare to look at, and sometimes we get lucky and find an example of forward thinking design, where the author obviously thought hard about making the software flexible and clean in the knowledge that somebody else down the line would most likely have to augment or modify it.
I want to be the guy that future developers see as having made their jobs easier by coding thoughtfully. Conversely I don't want to be the guy that they think about and shake their heads, like the original (and long gone) programmer at my last job whom we roundly mocked for doing things like declaring every single damn member function virtual in some deeply misguided attempt to write flexible code.
I don't know that this translates into mantra per se, but it is a recurring thought that guides much of my work.
| [reply] [d/l] |
|
I relate a lot to fever's recurring thought. I have inherited tons of hacked-up, dangerously insecure, bloated Perl scripts, and I do not ever want to do that to anyone else.
Like fever, I want to make future developers' jobs easier. But I want to make their jobs so much easier, they won't even realize it was easy. By designing systems, programs and scripts that anticipate future changes, future coders will be able to extend and modify without putting too much thought into the existing code and focus solely on what they're trying to do.
Current mantra: What would I think of this code if I needed to make a change and I wasn't a Perl expert?
Once my current mantra is absorbed into my subconscious sufficiently, I'd like my next mantra to be: Can I think abstractly enough about this task that I could write a CPAN-worthy module for it?
--Dave
| [reply] |
|
I find myself thinking in similar patterns. I try to always be aware of the bigger picture the code is fitting into. I can not count the umber of times in twenty years I ran across code that prevented some function from happening in its current incarnation, or how often I found the same logic in multiple places using different code.
I also try to remember who my future audience is by what platform they develop on (primarily). I tend to see things written differently by big iron, *nix developers and M$ developers.</p?
I liken my thinking to: Is this all I am? Is there nothing more?
Of course, this mantra does have a limit before it becomes a project killer. ;-)
Digiryde
| [reply] |
(shockme) Re: Programming Mantras
by shockme (Chaplain) on Jan 21, 2002 at 08:16 UTC
|
"Am I going to remember why I did this?"
Moreoften than not, it's several weeks - if not months - before I revisit my code. A little one line comment goes a long way toward reducing my debug time... Self-documenting code is great, but it doesn't always explain why I used ++$counter rather than $counter++.
If things get any worse, I'll have to ask you to stop helping me. | [reply] |
|
| [reply] |
Re: Programming Mantras
by FoxtrotUniform (Prior) on Jan 21, 2002 at 07:46 UTC
|
"How can I re-use this?" is something that I'm
trying to make a mantra, especially after reading
through The Pragmatic Programmer a couple of times.
Modular, orthogonal code is a Good Thing.
Not really a mantra, but one concept that's stuck with
me pretty much forever is the idea of conservation of
difficulty, which was introduced to me by one of my profs
in an intro programming course. The idea is that every
problem has a set difficulty, and making some part of the
solution easy (writing hacked-up, off-the-cuff code, for
instance) will make another part difficult (debugging).
Sometimes, the tradeoffs between easy and difficult are
political at best (doing the hard bit when nobody's
looking, and saving the easy finishing touches for when
your boss shows up), but (here's the tie-in with reusable,
orthogonal code) often you can do the difficult bits of
many problems once -- by writing a module to
do something clever that relates to a bunch of your
problems, or spending an hour or two putting together a
really elegant interface to a function you'll call a lot,
for instance.
"How am I going to debug this?", and it's friend "How
am I going to test this?", are ones that I should
keep in mind, though.
--
:wq
| [reply] |
Re: Programming Mantras
by Aristotle (Chancellor) on Jan 21, 2002 at 08:33 UTC
|
| [reply] |
Re: Programming Mantras
by Veachian64 (Scribe) on Jan 21, 2002 at 06:32 UTC
|
I usually end up telling myself "Nothing unnecessary, nothing extra". Whenever I find I can cut out an unnecessary variable, function, or whatever, I do it. Of course, my definition of unnecessary doesn't necessarily mean extra code that improves clarity (which is always a Good Thing). | [reply] |
Re: Programming Mantras
by jonjacobmoon (Pilgrim) on Jan 21, 2002 at 07:00 UTC
|
My response has less to do with mantras and more to do with
the idea of wasting space.
I have a perl pet peeve that I know everyone will jump on me
about, but I do it because of the need to save time during
debugging.
I hate the one line conditional. You know the little villian:
$foo = "bar" if (blah eq "blue");
Funny how it takes no longer to compile or run in a multi-line statement,
yet everyone
wants to do it in one line to look cool. Let's say I need to add a second
statement to that conditional or need to put a print statement
in there to debug it. Cut and paste, cut and paste, and then
cut and paste to put it back.
Okay, so maybe that is my mantra: "avoid cut and paste, avoid
cut and paste..." :)
I admit it, I am Paco. | [reply] [d/l] |
|
$foo = "bar", print "DEBUG: $foo\n" if ($blah eq "blue");
-Blake
with tongue, firmly in cheek. ;-P
| [reply] [d/l] |
Re: Programming Mantras
by Dominus (Parson) on Jan 21, 2002 at 22:24 UTC
|
Says dws:
my $html = $template->expand(\%bindings);
return $html;
... he was always on the lookout
for places where he would later need to place breakpoints to examine intermediate
results while debugging...
It seems to me that if you're writing wasteful code
because it affords a better opportunity for debugging, the conclusion shouldn't
be that the wasteful code is better, but that you need to get
a better debugger.
One of my hobby-horses is that the state of the art in debugging
tools is really crappy. If you look at the debugger programs of the
1960's, you'll see that they are not substantially different from what we have today.
Debugging tools have hardly gotten better in thirty-five years.
I think that's really shocking.
I think there's something to be learned from your example, but
it isn't that you should write more verbose code to save
intermediate results into named variables; it's that
the debugger should be improved so that it provides better access
to the intermediate results.
You should be able to write something like this:
return $template->expand(\%bindings);
and then tell the debugger that you want to place a breakpoint
after the call to expand but before the return,
and examine the value that will be returned. It wouldn't
even be hard for the debugger to get at that value; it's
right there on the top of the stack.
Why can't you do this now? It's not a technical barrier; it's a social one.
We've gotten so comfortable with using crappy debuggers
that we don't stop to notice when the debugger is making
our lives difficult, or to think about how it might be improved.
I'd like to see folks do more work on debuggers. Perl makes
it especially easy to do that, because the debugger is written
in pure Perl; you can just make a copy of perl5db.pl
and start hacking on it. perl5db.pl is very simple;
it's just a big loop with a giant if-else tree that looks
to see what command you entered. To add a new command, you add a new
branch to the tree. The information about breakable lines
and breakpoints and soforth is all stored in straightforward
Perl arrays and hashes, and it's all documented in
perldebguts.
The change I suggested above might be a little harder, because at present
there's no support in the internals for stopping anywhere
except at the beginning of a statement. But with a little
XS support, you could still extend the debugger to do it;
it would only require a little extra expertise.
I'd really like to see more people experimenting with the
debugger and finding ways to make it more effective.
The current state of the art in debuggers is an embarrassment
to the programming community.
--
Mark Dominus
Perl Paraphernalia
| [reply] [d/l] [select] |
Re: Programming Mantras
by chromatic (Archbishop) on Jan 21, 2002 at 11:49 UTC
|
| [reply] |
(jptxs)Re: Programming Mantras
by jptxs (Curate) on Jan 21, 2002 at 10:02 UTC
|
| [reply] |
(tye)Re: Programming Mantras
by tye (Sage) on Jan 21, 2002 at 10:56 UTC
|
The only good answers to "how many X does your software support" are "0", "1", or "as many as resources allow".
-
tye
(yep, I'll just leave it at that)
| [reply] |
Re: Programming Mantras
by Biker (Priest) on Jan 21, 2002 at 14:24 UTC
|
-
"This little application will become huge with time... Make sure it will scale. Error check everything!"
-
"That small data file will become huge with time... Don't slurp it into an array!"
"Livet är hårt" sa bonden.
"Grymt" sa grisen...
| [reply] |
Re: Programming Mantras
by simon.proctor (Vicar) on Jan 21, 2002 at 14:08 UTC
|
- Am I going to be able to understand this in 6 months
- Am I going to be able to read this in 6 months
- Can I reuse anything I have just done
Short and sweet.
| [reply] |
|
Surely you are missing the ever important
- Will the poor sod who takes over when I quit be able to understand it?
Or am I stepping on the toes of job security here :-)
---
If it doesn't fit use a bigger hammer
| [reply] |
|
haha, close but how about:
Will I be able to turn this into 1,000,000 lines of undocumented spaghetti code in my notice period?
One for the - you're only a programmer so no pay rise, pay reviews :).
| [reply] |
Re: Programming Mantras
by Juerd (Abbot) on Jan 21, 2002 at 13:03 UTC
|
| [reply] [d/l] |
Re: Programming Mantras
by George_Sherston (Vicar) on Jan 21, 2002 at 17:00 UTC
|
I have a few, on rotation:
"Does this *really* feel right, or am I shirking?" - you know, the rare occasions I write good code it's because I've made my judgements on aesthetic grounds, rather than by thinking it all through. I mean, the ability to think it through underpins the aesthetic; but in the end it's the unswerving adherence to an aesthetic that forces me to do the thinking through. And so often I think "(it's still a bit ugly but) that's good enough" when it really isn't.
I might boil this one down to "would I want CrazyTachTillyn to look at this?"
"What's the data structure?" Maybe it's because of the stuff I'm working on, but I find it cuts my work in half if I work out in advance whether I need to base my set of functions around a hash of arrays or an array of arrays of hashes or whatever.
"The system works" When something goes wrong it's very tempting to attribute this to some grand abstraction to do with Perl, my ISP or whatever. But that's a mistake. The error is always my fault; and believing this is a good thing because it puts the solution within my power. There IS an explanation: so I can find it out.
§ George Sherston | [reply] |
Re: Programming Mantras
by BrentDax (Hermit) on Jan 21, 2002 at 12:08 UTC
|
| [reply] |
Re: Programming Mantras
by Necos (Friar) on Jan 21, 2002 at 14:29 UTC
|
The thoughts that seem to plague me even as I sleep are:
1.) How can I improve my programming skills to make this block/sub/module more flexible?
2.) How can I write more elegant (yet, still understandable) code?
3.) How can I write less code without jeapordizing stability (in other words, killing duplications)?
4.) Am I re-inventing the wheel, or is this code ground breaking?
Whenever I'm writing code (as I am now), these things race through my head in a (at best) random order. Also, these thoughts have come from my interaction with others here at PM. Since most of the people here are experienced Perl hackers, it would be stupid of me not to take any of their advise.
In short, "Make Perl yours, but always carry around a Bag-O'-Tricks(tm). Someone else might need the gift of constructive criticism (or at least, a swift kick in the rear)."
Theodore Charles III
Network Administrator
Los Angeles Senior High
4650 W. Olympic Blvd.
Los Angeles, CA 90019
323-937-3210 ext. 224
email->secon_kun@hotmail.com | [reply] |
Re: Programming Mantras
by ajt (Prior) on Jan 21, 2002 at 18:41 UTC
|
I often think:
- Can I make it smaller/simpler?
- What will the "idiot" user do?
- What will the cracker do?
I like to make my code smaller, more elegant and more modular, I shudder when I look at how bloated and spagetti like my early code is, and even today, I'd hardly call my code compact...
Much of my stuff is small CGI scripts, so I'm very worried about black-hats and people doing stupid things.
I can see a lot of validity in what other people have said here ++ all around, but I suppse I worry about: Reuse; Misuse; and Abuse.
| [reply] |
Re: Programming Mantras
by lachoy (Parson) on Jan 21, 2002 at 18:32 UTC
|
I wind up writing a lot of infrastructure stuff, so over time I've internalized these questions:
- Is this as simple as I can make it?
- What are error conditions that I need to check?
- How can I break this? What happens if it breaks?
- How can I test this? If I can't test it, I need to rewrite it so it can be tested.
- How would another programmer want to use this? Whare are logical parameters and their order? What are logical return values?
- Is this coupled to anything else? If it relies on a constant, however assumable, can I put the constant in a configuration somewhere or make it available for modification?
- If nothign else works: what would clemburg do? (Plug in your own smart peer.)
Chris
M-x auto-bs-mode
| [reply] |
Re: Programming Mantras
by Steve_p (Priest) on Jan 21, 2002 at 19:19 UTC
|
Being a consultant, I've had one mantra rule my decisions when programming:
"Will they understand this when I'm gone"
| [reply] |
Re (tilly) 1: Programming Mantras
by tilly (Archbishop) on Jan 21, 2002 at 23:42 UTC
|
How should this work?
I ask this on many levels. From how should the API I am calling work, to how should the function I am working on work, to what the API I am working on should work, to how the overall product should work.
My reasoning is that I view a program as a textual representation of the mental model of a solution. Therefore the most important thing I do as a programmer is build, specify, and refine my own mental model of what should happen, and then make what is in the code match that model. | [reply] |
Re: Programming Mantras
by dreadpiratepeter (Priest) on Jan 21, 2002 at 21:33 UTC
|
Well it used to be, "how can I generalize this?". But now that I generalize everything automatically it's become "what are the exceptions?".
When won't this method work? What input can break this? What are the assumptions going in to this?
It's a lot cheaper to think of these things when writing than when debugging.
-pete
Entropy is not what is used to be.
perl -e "$XxKe=$XxTa=$XxE_=$XxUc=$XxBu=$XxAj=$XxCs=$XxFa=$XxGn=$XxVk=$XxJh=$XxLr=$XxM_=$XxNp=$XxOe=$XxPr=$XxR_=$XxSh=$XxQl=$XxWe=$XxDt=$XxXr=$XxHo=$XxIt=$#=qq-X-;$$=qqXxX;print((map{(m/.{3}(.)/)[0]}map{s,_, ,,$_}sort grep{m`[$#-$#][$$-$$]`}keys%::),qq,\n,)" | [reply] [d/l] |
Re: Programming Mantras
by metadoktor (Hermit) on Jan 21, 2002 at 12:13 UTC
|
It's "I Can Do It."
metadoktor
"The doktor is in." | [reply] |
Re: Programming Mantras
by Steve_p (Priest) on Jan 22, 2002 at 07:43 UTC
|
I hate posting twice to the same subject, but I ran across this quote that could easily become my new mantra.
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Found here | [reply] |
|
In other words, Always code as if I will end up maintaining your code ;)
/me shows teeth *arrr*
| [reply] |
Re: Programming Mantras
by clemburg (Curate) on Jan 22, 2002 at 00:07 UTC
|
Do I *really* have to solve this problem?
Who has already solved it for me?
What is the problem that I *need* to solve?
What do I *really* want to do *here*?
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com
| [reply] |
Re: Programming Mantras
by dthacker (Deacon) on Jan 22, 2002 at 06:43 UTC
|
When I used to work for an outbound telemarketer our SysAdmin would end our pre-campaign meetings with "Let's make it a beautiful thing!" I've taken it for my own and added my own meaning.
I want the next person to view my code to see it as a thing of beauty. Not always achievable, but always a goal.
Dave | [reply] |
Re: Programming Mantras
by perlmoth (Hermit) on Jan 22, 2002 at 02:47 UTC
|
When I am coding, I find myself repeating over and over:
"Aw, What gives!?"
Although I don't think that strictly counts as a mantra. | [reply] |
Re: Programming Mantras
by Anonymous Monk on Jan 22, 2002 at 04:33 UTC
|
Write everything as if the person who will be maintaining it is a short-tempered gun nut who knows where you live. | [reply] |