Re: another frustrating learner question, CLOS

On Feb 25, 6:08 pm, Ron Garret <rNOSPA...@xxxxxxxxxxx> wrote:
That rumbling sound you hear is Erik Naggum rolling over in his grave.

http://groups.google.com/group/comp.lang.lisp/msg/fc76ebab1cb2f863

rg
<quote>
you can commit any dirty hack in a few minutes in perl,
but you can't write an elegant, maintainabale program that becomes
an
asset to both you and your employer; you can make something work,
but you
can't really figure out its complete set of failure modes and
conditions
of failure.
</quote>

What if committing the dirty hack is the solution to the problem? Like
processing a data file in a one time script? Why spend an hour writing
an elegant, maintainable program when all you need is a one liner that
you will never need again? True, the one liner will be ugly, obtuse,
unreadable, unmaintainable, but if it does the job quickly and easily,
why use something that is hard and slow?

<quote>
I'll concede, however, that it is very important to be able to
understand
what perl programmers do. if you don't understand what they are
talking
about, you won't understand what they are actually trying to
accomplish
with all the incredibly braindamaged uses of hash tables and
syntactic
sadomasochism, and you won't be able to see through their charades
and
"just one more hack, and I'll be there" lies.
</quote>

If you need a puree, you run the food through the food processor, and
the incredibly brain damaged hash tables and syntactic sadomasochism
is simply the form of the processor. I'll agree in a heartbeat that a
block of Perl code can look like line noise, particularly if it
involves regular expressions and hash references (which it usually
does), but Perl's facility of
(1) providing a powerful tool for pattern recognition, matching, and
replacement, and
(2) providing sophisticated and very finely grained data structures
makes life easy WHEN THE USE OF THESE TOOLS IS APPROPRIATE TO THE JOB!

CC.

.

Quantcast