On Mon, Apr 26, 2004 at 10:33:03AM -0500, Eric Lease Morgan wrote:
> I suspect the answer deserves many considerations. For example, do you
> have the time to code? Will the time spent actually result in a
> solution? Is the problem big enough to really worry about and therefore
> is the solution worth the time? To what degree is a solution dictated
> by the existing computing environment? If the solution must be written
> in Fortran, then solutions may be far off, but if solutions can be
> written in any language, then there are more options available.
I'll echo David's comments that the third time is the charm. If I find
myself doing a non-trivial task for the third time, then I consider
automating the process. It's a fine line though. If I get on the wrong
side of the line I start trying to anticipate future usage, and this
can often be a trap. As strange as it may seem, I think there is art to
knowing how much *not* to code, which lends simplicity to your programs,
and ironically means you can get more coding done :)
Another time when I consider writing a program is when the problem is
too big for me to do manually. Computers don't mind doing menial tasks,
so I try to be self aware enough to realize when I'm doing a
menial/repetitive task, and to let the computer do it for me.
The key to this is developing good habits, and investing in your
infrastructure. For example I enjoy putting programs in /usr/local/bin
(or the equivalent) to customize my working environment and to make my
command line feel like home.
> At the risk of starting a religious war, we might also ask ourselves,
> how do you decide what programming language(s) to use to solve a
> computing problem. Again, there are many considerations including
> experience, operating systems, degrees of support in your community.
Yeah, there are so many considerations. An old boss of mine told me to try
to use "the right tool for the job". Of course, what is "right" is
often subjective, and the key is to work with people who see things in a
similar way, so that you have time to collaborate and build instead of
wasting valuable energy on endless arguments.
As James points out, it's a nice position to be in to be able to pick
the right tool. The right tool is often already decided: being the
language used in a larger project, or one that must be used for
non-technical reasons.
While googling for "right tool for the job" I ran across some Lisp
hacker's essay entitled (predictable enough) "The Right Tool For The Job" [1].
He opens with a list of 5 things that he considers essential in a language...
and I totally agree about 3 of them:
- memory management (frees you up to solving the problem at hand)
- objects (essential for thinking about your problem space)
- libraries (no need to reinvent wheels)
A good language that provides these key things makes my life a whole lot
easier. Lastly, I totally agree with the pragmatic programmers [2] that it is
essential to:
Invest Regularly in Your Knowledge Portfolio: Make learning a habit.
Lifelong learning is actually fun :)
//Ed
[1] http://www.podval.org/~sds/tool.html
[2] http://www.pragmaticprogrammer.com/
