What's a pattern?

[Bill McCleary]

Jan Paulsen wrote :

Well, it is cross-language also. The whole thing together uses:
Java
SQL
XML
JavaScript
AJAX
JSP
DHTML
CSS

What's missing from this list, that would help a lot with this kind of
code repetition?

Ah, yes, Lisp, or at least some language with first-class functions...

 

[Bill McCleary]

It is part of academic procedure to trace it back to original inventor
and give proper credit while a project does not care if it works.

Ambiguous sentence construction.

I assume that last was meant to mean "If it works, a project does not
care about much else", rather than that they don't care whether it works.

 

[Tom Anderson]

Good point! I especially like the focus towards smaller domains. I guess
that the "pattern" terminology has become useful even for what I
would've called "techniques". Perhaps we're in the midst of some
important paradigm change in which techniques discovered in different
programming languages are becoming so important that we called them
"patterns"?

It's true that the traditional design patterns are larger-scale than
things like the select technique. Does this mean that small things can't
be design patterns? Or do we have a different name for smaller things?
Would you consider something like "have a single exit point for each
method" and "make all parameters final" patterns (whatever you might think
of their merits)?

When it comes to things which are language-specific, as i think the select
technique is, i've heard the term "idiom", and i rather like that. Our
recent discussions about exception handling techniques fall into that
category too.

tom

 

[Jan Paulsen]

What's missing from this list, that would help a lot with this kind of
code repetition?

Ah, yes, Lisp, or at least some language with first-class functions...

You're talking straight to the heart of someone from functional
programming... Anyway, when are we going to see those things in Java?
Wrapping the stuff in a class and sending an instance as argument is
considered cheating to me. Of course, we'll need type inference for
those things as well. Guess it's never going to happen.

regards,
Jan Paulsen

 

[Jan Paulsen]

It's true that the traditional design patterns are larger-scale than
things like the select technique. Does this mean that small things can't
be design patterns? Or do we have a different name for smaller things?
Would you consider something like "have a single exit point for each
method" and "make all parameters final" patterns (whatever you might
think of their merits)?

When it comes to things which are language-specific, as i think the
select technique is, i've heard the term "idiom", and i rather like
that. Our recent discussions about exception handling techniques fall
into that category too.

tom

I guess to me it's the level of abstraction which does the trick. That
is, when we use some technique over and over again, we start to think
"hey, there's some common use going on here" and then we see an emerging
pattern. The GoF book focused on what in a very loose sense may be
called "collaborating" classes precisely because the level of
abstraction required meant that several classes were needed.

I would probably consider good practice such as "have a single exit
point for each method" a pattern, but in some other sense. I'm afraid
words faild me, but it's been considered good practice since the
beginning of structured programming, I guess (isn't that late sixties or
something, as I recall?). I wouldn't consider these practices patterns
in the sense of the word being exploited by "recent" books, because
these tend to focus on, well, the bigger picture. So, words fail me...

I don't know if the select technique is language-specific. I think the
original article was "Communicating Processes" with a language which I
honestly think was created solely to exploit the idea. I'm unsure, but
just off the top of my head, I believe this technique is found in a
number of languages, since it's so useful.

I think the term "idiom" is a good one, too, but there's some difference
here. I don't know what, but I think "idiom" is a broader sense to me -
and something which needs to be in widespread use. Just putting in two
cents.

Regards,
Jan Paulsen

 

[Tom Anderson]

True, but I do believe that current (as was the case in 18th century) use of
"patterns" in software is especially "design patterns", and I doubt anyone
would disagree that these come from the GoF book. Or am I wrong?

The Fab Four got them from Alexander. Where did Alexander get it from? He
doesn't say in A Pattern Language; he might say in The Timeless Way of
Building, but i don't have that.

The pattern in a pattern book is the same as the one in the 'pattern room'
of foundries, and it means something more specific: an exact plan for
building something. In the case of foundries, it's the master used to make
the mould used in investment casting. Pattern books are also designs to be
copied exactly. To an extent, this is similar to the Alexander/GoF
pattern, but that has the crucial aspect of being a generic shape of a
design, rather than a concrete instance of one.

tom

--
Wikipedia topics: lists of trains, Mortal Kombat characters, one-time
villains from Mario games, road intersections, boring suburban schools,
garage bands, cats, webcomics, Digimon, Bionicle characters, webforums,
characters from English soap operas, and Mortal Kombat characters that
don't exist -- Uncyclopedia

 

[Tom Anderson]

What's missing from this list, that would help a lot with this kind of code
repetition?

Ah, yes, Lisp, or at least some language with first-class functions...

Rubbish - you could do this all in shell script. It's probably a
one-liner!

tom

--
Wikipedia topics: lists of trains, Mortal Kombat characters, one-time
villains from Mario games, road intersections, boring suburban schools,
garage bands, cats, webcomics, Digimon, Bionicle characters, webforums,
characters from English soap operas, and Mortal Kombat characters that
don't exist -- Uncyclopedia

 

[Arne Vajhøj]

Ambiguous sentence construction.

I assume that last was meant to mean "If it works, a project does not
care about much else", rather than that they don't care whether it works.

He he.

The intention was to say the first.

Arne

 

[Arne Vajhøj]

You're talking straight to the heart of someone from functional
programming... Anyway, when are we going to see those things in Java?
Wrapping the stuff in a class and sending an instance as argument is
considered cheating to me. Of course, we'll need type inference for
those things as well. Guess it's never going to happen.

Most likely never. And why should it?

There are already several functional languages for the Java platform.

If you want functional programming then pick one of them.

The "super language that has everything" idea is hopefully dead.

Arne

 

[Robert Klemme]

Well said. I think I'm slowly taking a contradictory point of stand,
which is not what I wanted. I just wanted to say that when I use a
"pattern", it's something I read in those books, when I use my native
tongue for the same word, it's something much looser. Whether those
books are scientific or not is another discussion, I think.

Thank you for the clarification! Now I think I see your point more clearly.

Kind regards

robert

 

[Arne Vajhøj]

It's true that the traditional design patterns are larger-scale than
things like the select technique. Does this mean that small things can't
be design patterns? Or do we have a different name for smaller things?
Would you consider something like "have a single exit point for each
method" and "make all parameters final" patterns (whatever you might
think of their merits)?

When it comes to things which are language-specific, as i think the
select technique is, i've heard the term "idiom", and i rather like
that. Our recent discussions about exception handling techniques fall
into that category too.

Makes sense.

patterns = solutions for specific problems

idioms = solutions for generic problems (like making the code readable)

Arne