The only point I want to nitpick here is complexity.
A large program becomes complex for one reason. Fredrick
Brooks (of the infamous Mythical Man Month)
termed Natural Complexity and Accidental Complexity.
A friend of mine worked for a month at a place that needed
some new features added to their program. The program is
10,000 lines, all in one file, and completely incomprehensable. This is one kind of complexity that
doesn't need to exist. Further, the code had no apparent
structure. It was peicemeal. No relationships between
parts could be discerned, and in fact, it was hard to
identify anything as being a part, seperate from the
rest. And fittingly, this is the reputation
Perl has.
I don't advocate making programs more complex than they
need to be, which is to say, they shouldn't be more
complex than the problem they are meant to solve warrents. Patterns are
meant to structure large programs - not small ones.
Out of context, they look, well, dumb. This makes it
hard to write examples and even harder to imagine
what the example would look like in its native
habitat. I have a copy of "Lions' Commentary on
UNIX 6th Edition", ISBN 1-57398-013-7. This book
rocks. It is half explanation, half source code
listing (mostly C, very little assembly through in).
The commentary on the code was done by a college
professor for a class, and it points out idea behind
the code, structure, how things were built, how
the parts fit together - picking on things that
students are likely to someday have benefited from
learning. Patterns. Having structure to the code
doesn't make it complex - quite the opposite. It
makes it interesting and valuable and long lasting.
Look - we're still using Unix, even though it had
to fit into 128k on a PDP-11!
My advice to people writing small one-off scripts
and quick hacks is to
ignore the whole
patterns thing just like you ignore objects. The
tool doesn't fit the job. And trying to make it
will just warp the job - as you say, adding complexity.
However, at the first hint that the code is starting
to outgrow what little structure it has, future programmers
doomed to work on the project will thank you if you
start early trying to fit the code to some higher
level idioms. You use low level idioms, why
not higher level ones?
Oh yeah. I forgot. Perl does that for you. Look.
There are two kinds of programming tools in the world.
4GLs and things designed to make you not have to think
about design or logic, and refactoring browsers and
other things designed to augment the abilities of a
human as they design. ASP fits the first category,
along with dozens of failed graphical-builder tools.
lint, yacc, c-tags, that postscript hack that makes
a poster of the Linux kernel sources, Purify, Rational
Rose and other UML or Use-Case modeling tools fit the
second category. Things in the first category tend
not to be any help at all to an expert - in fact,
they are associated with amatures. Things in the
latter category are associated with skilled professionals,
who are highly effective at their job. These tools
have stood the test of time and repeatedly proven
themselves. Rather than trying to do a job for the
programmer or make a job vanish, they augment what
human can do. Think of humans augmented with computers
rather than humans replaced with computers, if you want
a mnenomic.
To say that Perl has high level design
built in so you don't have to think about it is
to cast Perl as a member of the former group. I don't
like that very much. To say that Perl is a language
more than capable of accomodating the technical needs
of design in a large project when skilled professionals
employ the right tools - that I like. Does Perl
do the job of thinking for you, or does it expand
what you're capable of? Do design issues not exist
in Perl like they do in Java, or do they exist more
readily as Perl increases programmer productivity,
allowing them to build more quickly? When you go
to the book store, do you read just the Perl books,
or do you wander over and actually peek into these
computer sciency rags?
Remember, at one time, no one would touch objects,
and they were the fetish of a few colleges, never
seen outside. It wasn't until the 1980's - 20 years
after their invention - did they get foothold in
global conciousness.
Before that, no serious language
would ever consider a lambda closure feature - people
don't need that to do business reports in RPG or COBOL!
Both of these things slowly seeped out. Lack of
closure bit Java on the butt - inner classes are a
horrible kludge, but absolutely needed the way Java
makes you define objects of a certain class to be used
as callbacks. Closures make code shorter, and to
someone wise in their ways, more readable - they do
great things to reduce the scope of variables, breaking
the code down into obviously seperate, cleanly divided
parts. Stupid CS stuff, trying to make our lives more
complex! Tell yourself that patterns really
aren't anything new, just a better way to learn objects -
and I mean really learn objects - C++ shops have
struggled something awful the last 15 years - objects
didn't click into place for their programmers except
for a very special few. None of the prophacies of
objects making code reusable, modular, resistant
to change came true for the ordinary man because they
didn't grasp the single driving concept. They didn't
have that "ahh" moment. Scheme and Lisp programmers
never had any problem - they had "Structure and
Interpretation of Computer Programs" to learn from.
After an entire generation of doing it wrong, we have
a generation of object programmers doing it right. So,
to put it another way, the Perl global mindset is still
stuck in last generations misused, misunderstood, ineffective
object usage. If you need me, I'll be in the Java
section.
Whoops, I got pretty far afield here. I always do that.
I meant to offer perspective on your comment on complexity -
the rest has little or nothing to do with your note.
Otherwise, I agree. I've focued on patterns that apply
to Perl and Perl programmers, not direct Perl translations
of C++ patterns - on perldesignpatterns.com.
Patterns shouldn't be mindless sprinkled about -
normal code should stay normal code, to paraphrase
Larry Wall's "perl should stay perl". In a large
system, you need glue between the normal code or
you have an endless procession of code. Like a patent,
a pattern should be interesting and non-obvious -
otherwise, people won't want to read them. Most
people don't like to be told the obvious. It is
insulting. And so on. There are very good reasons
why an iterator needs to be something more than a
foreach statement - you're exposing the internals
of one object to another object through a
predefined interface. Returning an array is okey
sometimes, but the internal datastructure may not
jive with that. perldesignpatterns.com's example
of an iterator - or one of the examples -
exposes the contents of a network of objects.
Rather than building a massive array, the natural
recurssion is exposed through the interface.
Tieing and overloading are also very powerful -
Perl shouldn't lose its expressiveness because of
other idioms - but sometimes the idiom of using
an interface and objects packs more of a punch
than that of an array. Sometimes. In large programs.
-scott
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.