In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
>| Super engineers want other people to do "grunt works" so that they can
>| have some good time. Those "grunt works" people do not know Lisp well.
>
>I find that the programmers of the Lisp system I'm using have done a _lot_
>of the "grunt work" for me. far less "grunt work" is necessary in Lisp
>than in C/C++/whatever, where it seems there's very little _beyond_ "grunt
>work". in fact, there's so _little_ "grunt work" in one of my current
>projects that I actually miss it a little -- I found it relaxing to spend
>some time with some moderately unintelligent task like putting Emacs or the
>shell to work on cross-referencing my files or tweaking some implementation
>detail, but these are already taken care of (most of them, anyway). which,
>of course, means that most of the "grunt workers" would be out of work if
>they used a better language. maybe _that's_ why they don't know Lisp...
I agree totally. The existance of "Grunt work" is a by-product of bad
development techniques, i.e. C++. Take what I'm doing now for
example. I'm writing about 300 C++ functions called getFoo(), getBar()
et. el. ad infinitum. And I have to do it in both header and source
files. In lisp this just doesn't come up. You can always elimitate
grunt work by making clever use of macros and procedures.
But if there really is a genuine need for "grunt work", I'd feel safer
having some junior programmer write it in lisp. It's quite a bit more
effort to write awful lisp than to write awful C++.
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.