"Perl Design Patterns"

[tjh]

Recently an article appeared on perl.com titled "Perl Design Patterns".

Not having the CS background many monks have, such discussions help me better understand issues surrounding design, and often, these discussions help me understand that sometimes when I thought I didn't need to worry over design issues - that I was kidding myself.

In the past, I've enjoyed PM threads such as these on the same subject:

• The very recent node, When Is Dividing Code Into Different Subroutines/Packages Important?, which combined with the perl.com article, got me thinking about all this again,

• Perl Design Patterns Book

• Are design patterns worth it?

• Design Patterns Considered Harmful

And those have led me to:

• Wishing I had been on hand to hear this presentation,

• and, wondering (at least a little) what's going on at this site.

These discussions have helped me come to understand Perl better, and in some ways, have helped me come to grips with new Perl 6 design issues or decisions I often don't fully understand.

In the perl.com article, the section titled "If a pattern is really valuable, then it should be part of the core language", contained this phrase, "Perl succeeds largely by excellent use of the principle of promotion. Essential patterns are integrated into the core of the language. Useful things are implemented in modules. Useless things are usually missing."

And frankly, that phrase tweaked me a different way in maybe understanding some differences between Perl, and some other languages, as well as getting a little insight into language design itself.

However, not all that glitters is gold, so what are your thoughts on this? Are the author's thoughts on Perl and design patterns more right than wrong?

Why wouldn't a language move "essential patterns" into the language's core? Why haven't other languages evolved a CPAN equivalent, which, to my naive eyes, has simplified and modularized essential, useful and/or interesting elements, saving me from fatal design pattern decisions?

And, as an aside, I'll bet the decisions and debate around what consitutes an "essential pattern" can get quite heated. Also, one wonders if this "essential pattern in the core" issue is any kind of force in Perl 6 development. If so, for instance, is memoization an essential pattern, per se?

[jepri]

Why wouldn't a language move "essential patterns" into the language's core?

I can suggest two reasons:
One is that many languages do not have 'postmodern' as a goal.

• Scheme was designed to have an exceptionally clear and simple semantics
• (Nicklaus Wirth created pascal).His principle objectives for Pascal were for the language to be efficent to implement and run, allow for the development of well structured and well organized programs, and to serve as a vehicle for the teaching of the important concepts of computer programming.
• Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language.
• Ada was originally designed for the U.S. Department of Defense (DoD) for real-time embedded systems.
• Perl was designed to be postmodern.

The other reason could be related to the way that some people like to boast about features in their favourite language, as if the features are unique to that language. The flip side of that attitude is that the designers won't put a certain features in, because then their language will be like another language that happens to have that particular feature.

Why haven't other languages evolved a CPAN?

There are probably more generous theories, but I would suggest that it is because most programmers are idiots who think they can write better code than anyone else.

Take a look around at other peoples code.

Every idiot C coder (almost all of them) thinks that s/he can write better memory management routines than someone who has been studying the problem for 10 years.

Every idiot PHP programmer thinks that s/he can write a better 'news portal' than the current 50 million news portals already written in PHP.

Every idiot Perl programmer thinks s/he can write a better CGI handling routine than the one that has been developed and field tested for 8 years.

A possibly more generous reason is that not all languages have the example of other coders using the Artistic License to release code. Ya need to have that community sharing feeling going.

But if you consider CPAN to be just a repository of libraries, then I would argue that C has many CPANs. There is the Red Hat CPAN, the Debian CPAN, the BSD cpan, The GNU CPAN...

____________________
Jeremy
I didn't believe in evil until I dated it.

[Aristotle]

Java: A simple, object-oriented, network-savvy, interpreted, robust, secure, architecture neutral, portable, high-performance, multithreaded, dynamic language.

Bingo!!!

;-)

Makeshifts last the longest.

[simon.proctor]

I have always been given to understand that a Pattern boils down to a common solution to a common problem.

Perl is used to solve more *common* problems in double quick time than other languages due to its chainsaw nature and due to the fact that someone (somewhere) has solved this before and usually realeased to CPAN.

This collective *laziness* is yet to hit languages like Java and C++ who (in my opinion only) are still relatively stuck in the classical era of programming. Thus if something makes someone elses life easier, release it commercially and make a buck out of it. But then again those languages don't evolve in the way that Perl does.

I think that is the core strength of Perl. Its language evolution, support and growth is determined on the front lines.

As to centralising this into the language core, I personally feel this would break the flexibility of Perl. Modules already come with the core and installing new ones is (generally) a breeze. Compare this with something like Java where you have to wait for the next release of the language before the core libraries are fixed/updated.

I'll stick with the Perl way thanks.

[Anonymous Monk]

Compare this with something like Java where you have to wait for the next release of the language before the core libraries are fixed/updated.

Or, more usually, *not* fixed/updated but supplanted (without being removed) by a new, incompatable, larger set of, often equally buggy, api's.

[TomDLux]

A design pattern is a way of using components; that's why design patterns are not components of languages.

You might come up with a "language" consisting of mortar and bricks of various sorts. The design patterns would be the various common ways of arranging bricks to achieve various results. For example, when building a freestanding brick wall, you'll see some bricks sideways, to tie two layers together.

Cliches, aka idioms, are standard bits of code, such as open ... or die $! in Perl, or while( (c=getchar()) == 0 ) in C. Design patterns are both more complex and more abstract than these.

One simple design pattern is the use of an object, the iterator to traverse an array or linked list, rather than coding a loop. You could not make an iterator a part of a language in the sense that while loops or exceptions can be. If you have a library of data structures, as Java & C++ do, you can implement iterators as part of that.

--
TTTATCGGTCGTTATATAGATGTTTGCA

[tjh]

And wouldn't the design of the components also fall under the design pattern issue? What type of bricks, for instance?

Possibly the accepted idioms, either included in the language, or as an external library or a CPAN module, directly or indirectly, force the patterns of their usage on the work?

The perl.com article discusses the iterator in Java and Perl, resulting in this statement,

"In Perl any built-in or user defined object which can be walked has a method which returns an ordered list of the items to be walked. To walk the list, simply place it inside the parentheses of a foreach loop. So the Perl version of the above hash key walker is:..."

"The inclusion of iteration as a core concept represents Perl design at its finest. Instead of providing a clumsy mechanism in non-core code, as Java and C++ (through its standard template library) do, Perl incorporates this pattern into the core of the language." (emphasis mine)

The iterator is simply an example. I'm not interested in dissecting iterators specifically.

However, the article led me to think that Perl developers considered the iterator component mentioned important or reasonable enough to more thoroughly integrate it, given their view of the language's mission.

Maybe it's a pattern-within-pattern-within... question for me, a fractal issue. More global design issues (probably moderated by 'accepted usage' or what becomes idiomatic) containing idiomatic usage of core components, external modules, object usage, etc. Something is Perlish, for instance, and becomes an accepted pattern of usage.

[zby]

use of an object, the iterator to traverse an array or linked list, rather than coding a loop - I think you still need a loop to use that iterator, the opposition is artificial.

[kabel]

did somebody notify the map that wants to be a grep? ;-) of course, i think:

# code found under "Decorating Lists" entitled paragraph, line 6.
my @files = reverse sort map { -d $_ ? $_ : () } readdir DIR;

i have not seen this solution before, but i find it all sorts from cool to strange.

strange - i think, anyone with a functional background expects that, after a map, there is exactly the same number of elements in the list as before.

cool - it shows that the grep is essential the sugar coat around the syntactic sugar. but, because the grep is a standard tool in any unix environment, the gain of expressiveness is tremendous.