On Monday 02 December 2002 10:50 pm, Christopher Milton wrote:
If there are any good ways in which non-mathematicians can get to grips
with these terms from category theory, they would be well worth
promoting. For example, despite having a good computer science degree (in
which I was at
Hi, Bill.
I agree 90% with you in your questioning the adequateness of trying to
incorporate design patterns in Haskell, and the actual productive use of
them in other languages as well.
But, I must defend design patterns, and Haskell, a bit...
William Lee Irwin III wrote:
On Mon, Dec 02, 2002
G'day all.
Just to clarify...
On Tue, Dec 03, 2002 at 12:42:21PM -0500, David Bergman wrote:
But, design patterns are clearly overestimated as a tool for (indirect)
code production, you are right in that.
Absolutely agreed. Design patterns are little more than:
- A common language
On Mon, Dec 02, 2002 at 10:37:09AM +1100, Andrew J Bromage wrote:
In the interest of fairness, the declarative programming community
occasionally appears to have an aversion to actual engineering. If
you mention a term like design patterns, people look down their
virtual noses at you like
On Mon, 2 Dec 2002, Andrew J Bromage wrote:
... If you mention a term like design patterns,
well I love design patterns, it's just that in Haskell-land
they are called higher-order functions, or polymorphic functions, etc.
-- Johannes Waldmann
John Hughes wrote (on 02-12-02 10:27 +0100):
On Mon, 2 Dec 2002, Andrew J Bromage wrote:
... If you mention a term like design patterns,
well I love design patterns, it's just that in Haskell-land
they are called higher-order functions, or polymorphic functions, etc.
-- Johannes
John Hughes wrote:
On Mon, 2 Dec 2002, Andrew J Bromage wrote:
... If you mention a term like design patterns,
well I love design patterns, it's just that in Haskell-land
they are
called higher-order functions, or polymorphic functions, etc.
-- Johannes Waldmann
On Mon, 2 Dec 2002 13:05:27 -0500
David Bergman [EMAIL PROTECTED] wrote:
or using highly formal language,
with terms such as catamorphisms.
Ok I can't resist longer. It's ages I have been wondering what's a
catamorphism, and an anamorphism, and what the hell does it mean data
is expressed by
Nick Name writes:
:
| Ok I can't resist longer. It's ages I have been wondering what's a
| catamorphism, and an anamorphism, and what the hell does it mean
| data is expressed by destructors and not by constructors, but I
| have had no time till now. Please some of you all catamorphism
|
--- Tom Pledger [EMAIL PROTECTED] wrote:
Nick Name writes:
:
| Ok I can't resist longer. It's ages I have been wondering what's a
| catamorphism, and an anamorphism, and what the hell does it mean
| data is expressed by destructors and not by constructors, but I
| have had no time till
As a reader but not an expert, I recommend
http://www.cse.ogi.edu/~mpj/pubs/springschool.html
It seems also a good summary of everything haskell-related :) Thanks, it
is useful to me.
Vincenzo
___
Haskell mailing list
[EMAIL PROTECTED]
G'day all.
On Mon, Dec 02, 2002 at 08:26:06AM +0100, Johannes Waldmann wrote:
well I love design patterns, it's just that in Haskell-land
they are called higher-order functions, or polymorphic functions, etc.
Can I safely translate that as We use design patterns but we don't
like the name?
G'day all.
On Mon, Dec 02, 2002 at 10:27:21AM +0100, John Hughes wrote:
There are patterns of that sort in our programs, which we would probably
rather call design techniques, which aren't so easily captured by a
higher-order function definition.
As a matter of interest, _why_ would we
G'day all.
On Mon, Dec 02, 2002 at 01:05:27PM -0500, David Bergman wrote:
It seems like all the patterns, at least the ones in the GoF's
enumeration, can be expressed as higher-order functions and classes if
we only would have a way to traverse a record structure dynamically. If
someone can
On Tue, 3 Dec 2002, Andrew J Bromage wrote:
On Mon, Dec 02, 2002 at 10:27:21AM +0100, John Hughes wrote:
There are patterns of that sort in our programs, which we would probably
rather call design techniques, which aren't so easily captured by a
higher-order function definition.
As a
On Mon, 2 Dec 2002, David Bergman wrote:
(snip)
Till then, we Haskellers will probably continue expressing our
patterns either directly in Haskell or using highly formal language,
with terms such as catamorphisms.
The virtue, and weakness, of traditional design patterns is their
vagueness
G'day all.
On Thu, Nov 28, 2002 at 12:32:19PM -0500, Paul Hudak wrote:
reminds of what I think is one of the biggest problems with conventional
software development: the lack of appreciable mathematics in the
specification, design, coding, or implementation of programs.
In the interest of
On Mon, 2 Dec 2002, Andrew J Bromage wrote:
... If you mention a term like design patterns,
well I love design patterns, it's just that in Haskell-land
they are called higher-order functions, or polymorphic functions, etc.
I think you need `design pattern' as a special concept
only if you
18 matches
Mail list logo
