On 4/19/06, Brian Chrisman <[EMAIL PROTECTED]> wrote:
I'm putting that in the 'unlearned criticism file':
Based upon that statement alone, I would have to relegate the remainder to
same.
If yer handed a data dump from a 70's era mainframe, or a flat text file
from another old database (dbase, pick, whatever), you are going to want
perl.
In 1996, I would have said I wanted awk or lisp (assuming you are
referring to perl's text-parsing abilities). Now, I would say I wanted
ruby or python or awk or lisp. Perhaps *you* would want perl, to the
disdain of the poor souls tasked with polishing that turd long after
you have come and gone.
I think part of the misunderstanding here is that perl is not designed
to be the best language out there for any apparent task, but rather the
language that is most familiar and easy to adopt by most people in
industry.
That syntactical flexibility leads to the trash that perl is known for
encouraging. Take, for example, a language that also follows the
"TMTOWTDI" motto: ruby. Ruby has a wonderful way of constraining the
programmer to syntactic sanity whilst still allowing flexibility and
creativity in implementation for any given problem set, and not
leaving a bunch of old glue code future programmers will have to
scrape off their shoes before tackling the "real" problems at hand.
Being programmers, whether by trade, by hobby or otherwise, we are
constantly learning and reshaping the way we view any given problem
domain. Need or interest will pull us from language to language over
time and we will fight the comfortable inertia that holds us to a
particular set of paradigms by attempting to form-fit each successive
language to one with which we are comfortable. The issue at hand is
whether a language should encourage this behavior, especially when we
are forced to stick the forms we are familiar with onto the new
language with chewing gum.
It is common for programmer's learning about a new algorithm or an
interesting form in another language (lambda expressions in python
anyone) to start forcing the rest of their world through that prism.
Perl, and to some extent ruby, encourages that behavior, despite the
inelegance of the result. This leads to code that will, for the most
part, be a snapshot of any given programmer's experiences at that
point in time, which becomes the 'anathema' of future maintainers,
documenters and students of that code.
Erik is referring to perl's inherent promotion of the 'easy' or
'hackish' way out of a given problem domain, without consideration for
the existence of a correct, canonical solution that would (as Erik
asserts) be easier to implement and maintain.
--
If UNIX doesn't have the solution you have the wrong problem.
UNIX is simple, but it takes a genius to understand it's simplicity.
_______________________________________________
RLUG mailing list
[email protected]
http://lists.rlug.org/mailman/listinfo/rlug
