www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Design Patterns == weakness in language

reply Brad Anderson <brad dsource.org> writes:
This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
long-term given that it's not abstracting away a majority of known design
patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>

http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

BA
Sep 13 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
 
 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns


I've found that when I translate straightforward C++ code into 
straightforward D code, the size of the (source) code drops 30%. That 
means that D *is* abstracting away commonly used C++ patterns.
Sep 13 2006
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 13 Sep 2006 16:15:03 -0700, Walter Bright wrote:


 Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
 
 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns


 
 I've found that when I translate straightforward C++ code into 
 straightforward D code, the size of the (source) code drops 30%. That 
 means that D *is* abstracting away commonly used C++ patterns.


(Design Patterns) != (C++ patterns)

Yes, we all agree that D is a lot more efficient than C++ when it comes to
source code density. However, that has very little, if anything, to do with
"design patterns" as a programming paradigm.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
14/09/2006 9:45:13 AM
Sep 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Wed, 13 Sep 2006 16:15:03 -0700, Walter Bright wrote:
 

 Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>

 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns


 I've found that when I translate straightforward C++ code into 
 straightforward D code, the size of the (source) code drops 30%. That 
 means that D *is* abstracting away commonly used C++ patterns.


 
 (Design Patterns) != (C++ patterns)
 
 Yes, we all agree that D is a lot more efficient than C++ when it comes to
 source code density. However, that has very little, if anything, to do with
 "design patterns" as a programming paradigm.


I think it has a lot to do with it, but I think it's pointless to argue 
the issue. The issue to me (and hopefully to most programmers) is one of 
productivity. Are you getting your programs developed faster with D or not?

I know I'm getting a personal big productivity boost from D - and time 
is money.
Sep 13 2006
parent Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 13 Sep 2006 17:14:46 -0700, Walter Bright wrote:


 Derek Parnell wrote:

 On Wed, 13 Sep 2006 16:15:03 -0700, Walter Bright wrote:
 

 Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>

 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns


 I've found that when I translate straightforward C++ code into 
 straightforward D code, the size of the (source) code drops 30%. That 
 means that D *is* abstracting away commonly used C++ patterns.


 
 (Design Patterns) != (C++ patterns)
 
 Yes, we all agree that D is a lot more efficient than C++ when it comes to
 source code density. However, that has very little, if anything, to do with
 "design patterns" as a programming paradigm.


 
 I think it has a lot to do with it, but I think it's pointless to argue 
 the issue. The issue to me (and hopefully to most programmers) is one of 
 productivity. Are you getting your programs developed faster with D or not?
 
 I know I'm getting a personal big productivity boost from D - and time 
 is money.


Sorry Walter, I did it again ;-)

I wasn't arguing with you, just being a little pedantic. The concepts of
'design patterns' and 'programming language (syntax) patterns' are not the
same thing, that's all. 

And yes, D is definite productivity booster when compared to C++, as far as
I can see.

I don't think there's much purpose in having direct language support for
'design patterns' as those are very high-level abstractions, however it
would be easier to implement such patterns in D if its syntax patterns were
improved. Such as improving templates and mixins, both in functionality and
usability. Adding language support for full closures and co-routines would
also help. But of course, these should not delay v1.0 ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
14/09/2006 10:49:03 AM
Sep 13 2006
prev sibling next sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 13 Sep 2006 17:25:37 -0400, Brad Anderson <brad dsource.org>
wrote:


This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
long-term given that it's not abstracting away a majority of known design
patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>

http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns


Eh!

I'm sure that languages will naturally get higher level over time, and
that as a result the number and complexity of patterns needed to
achieve any given result will get smaller. But you're missing three
crucial points...

1.  As languages get higher level, software generally gets more
    complex. New, higher level patterns arise to cope with that
    complexity. So you need at least as many patterns, just different
    ones.

2.  There's not much to gain by adding compiler support for
    pre-existing patterns. Patterns exist because they are easy. If
    they were hard, people would find other patterns.

    The real complexity is in how patterns are combined to form an
    overall design.

3.  The most useful new language features are never based on
    pre-existing patterns anyway.

The final point is the most interesting. What were the most obvious
big advances in programming languages? - well, just off the top of my
head...

- Structured programming.
- Functional programming.
- Object oriented programming.
- Exceptions

NONE of these was a pattern prior to becoming a language feature.

Structured programming resulted from the observation that some
programmers had a 'cleaner' style than others, and their code tended
to be more reliable. But there were no hard 'if' or 'while' or similar
patterns before then. People with a more structured style still
invented whatever 'structure' suited each problem individually. The
idea of having a predefined set of block structures was a language
feature first. It only became popular to imitate those specific block
structures in assembler when they were already popular in high level
structured languages.

Functional programming can be considered a similar thing, also heavily
influenced by math and computer science theory. A functional 'style'
of programming has become more popular as a result of people using
actual functional languages. To the extent that there was a choice in
Lisp (which is strictly speaking an imperitive language) this was a
general style thing, not a pattern to solve any specific problem.

As for object oriented programming, prior to Smalltalk (the first
object oriented language) there was no such thing. The patterns for
writing object oriented code in non-object languages came later - as
hacks for getting C to work with object systems like COM, for
instance.

Object oriented programming was originally a set of ideas and
metaphors which were aimed at making a whole bunch of programming
tasks easier. The nearest anyone had got to C++-style object
orientation, for instance, was bunging a few related values into a
parameter block with maybe a few function pointers for company.
Virtual tables - no. Inheritance - no.

And there is a good solid reason why this is the case. Treating
'object oriented programming' as a pattern in a non-object language is
an absurdity. It doesn't make life easier - it makes all kinds of
things more complex and awkward, and far more error prone. Sure, it is
a flexible and powerful technique - but that flexibility and power
costs in terms of fiddly error-prone code overheads. The only serious
reason to do it is because you have no choice, e.g. if you need to
interface code in a non-object language with existing object-based
code.

Exceptions were never a pattern before they were added to a language
either. Dealing with stack unwinding manually would be a absurd - OK,
there's the old C longjmp, but that was never used in a pattern that
could be honestly compared with modern exception use. Exceptions were
invented as a new and original idea, and added to a language as an
experimental feature, and they worked.

So, creating genuinely useful new language features has never been a
matter of just adding support for pre-existing patterns. And no
surprise, really. As I said, the whole point of everyday patterns is
that they are easy. If they were hard, people would find different
patterns instead.

Add language support for pre-existing patterns one at a time, and you
get a bloated dinosaur of a language with very few benefits to justify
that bloat. And your style stagnates because of that huge commitment
to always using those same patterns, which don't mix well with new
ideas. And let's face it, use a compiler-supported pattern and you
need to look up the right syntax and keywords out of the thousands in
your every-single-pattern-gets-special-syntax language, instead of
simply expressing the pattern using general purpose language features.

All you prove is that you have no creativity or problem-solving
skills. That you can't spot the general themes in the problems that
happen most often, or that you are unable to create new general
purpose ideas that could simplify a wide range of problems.

A key goal of language design should always be to get the most bang
for you buck. Having a full toolkit is a good thing, but each tool
should give real value.


Actually, I don't see any reason to worry about this. Looking at
what's happening now, I don't see any sign of a catastrophic change
for the worse. After all...


The D 'scope' statement makes a whole bunch of cleanup tasks easier.
It isn't the RAII pattern, but it can replace the RAII pattern in many
cases and in others it can complement RAII, making it simpler and more
reliable.

Aspect oriented languages (Aspect Java, Aspect C++) were created to
solve problems with cross-cutting requirements. There's a lot of
'include this code at this point in every method matching this regular
expression' kind of stuff. If Aspect oriented programming was ever
done as a pattern, it was 'scattering similar fragments of code all
over the place'. Aspect orientation as a pattern would be absurd, but
aspect orientation as a language feature makes a lot of sense.

I could go on, but everyones bored. So I'll just say that if you
really want better support for existing patterns, the obvious thing
you should ask for is better template support. That can help automate
many patterns, not just one or two.

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 13 2006
prev sibling next sibling parent David Medlock <noone nowhere.com> writes:
Brad Anderson wrote:


 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
 
 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
 
 BA


Adding to Steve's lengthy post, I will say the anonymous delegates and 
the lazy eval stuff is way cool and will take some time to flesh out 
common idioms. (Not to mention the template magic tossed about around here).

So far I haven't missed C++ at all.

-DavidM
Sep 13 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
 
 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
 
 BA


Adding to Steve and David, I think the fundemental problem in the 
article's arguments is that "design patterns" are not complicated tasks 
that everone has to implement all the time.
Even if they were, it's still not neccessary to integrate them with the 
language itself if it's possible to implement them in the standard library.
For example, everyone needs to output text to the screen, but why should 
it be a part of the language itself when it could be implemented as a 
library function?
Do most people write containors and iterators by themselves all the 
time? Do they ever have to?

Comparing that with manually implementing subroutines in assembly is 
redeclious.
Sep 13 2006
prev sibling next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
 
 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns


Excellent article, thanks, Brad!

I totally agree with the article.

In a larger context, that's exactly what Man has been doing all our 
history. Anytime there's an often enough recurring pattern, it is "made 
to go away", or at least made easier to accomplish. (Dragging major 
objects: invent the wheel, food too tough to chew or digest: invent 
cooking, too long to swim over: invent boat, too hard to figure out the 
needed field area for crop to feed the village: invent arithmetic, too 
much arithmetic to do: invent calculator, find yourself typing the same 
things: write a macro, etc.)

If we'd have been content with just executing the discovered patterns, 
we'd still hunt by running, kill with our bare hands, and flog with our 
own teeth.

Also, this is exactly how the brain works. Tasks composed of a number of 
discrete subtasks are glued together and automated so that they become a 
single task. Happens all the time. A child has a heck of a job producing 
a single phoneme ("a", "k", etc.) because they require the orchestrated 
cooperation of an incredible number of small muscles -- which he has to 
individually and simultaneously control. Later it becomes just automatic 
to say any single phoneme. Then he has to learn to say words, which he 
initially does by choosing and putting these into a sequence. Later the 
same happens with words to construct sentences.

A beginning programmer tediously chooses which iterating construct to 
use, carefully figures out the starting values and ending values, the 
choice of loop variable names, and whether the check is at the beginning 
or the end. And with the seasoned programmer, this entire task is both 
thought out and even typed into the source code "without a thought". 
It's become invisible.

And in one sense, programming itself is just doing this! The programmer 
creates custom routines so he avoids writing repeated code. And a very 
good programmer creates subroutines even for things he only uses once, 
so that he can manipulate that part of code as a single named entity in 
his head. Clarity of thinking gives clarity of code.

---

D has indeed come a long way further than C++ or C, and I believe it is 
exactly because it has followed the idea in that article.

I think there are two separate things a "better" language can do:

  - make those "patterns" go away
  - give the programmer tools so he can make his own patterns go away

The latter is needed because every programmer has to live in his own 
unique domain, with its unique possibilities and obstacles. No 
programming language can be expected to be perfect for every task, but 
the easier it is to make the patterns "go away", the more time the 
programmer has for the real issues at hand.

The expression power of the language is key in this. And a large part of 
it is the template system, which (congratulations, Walter, and thanks) 
actually has turned out just incredible.

Back to the former, that is achieved of course by syntax and semantics 
that obviate as much as possible the need to do "the mundane stuff". 
Another important part is well written, coherent and orthogonal 
libraries that are easy and efficient to use.

---

Reducing the number of design patterns one uses can not, and should not 
  be the goal. As we make existing patterns "go away", we find that we 
use the time won to do other things, and they invariably do contain 
patterns themselves, which we will in time discover. But if we keep on 
working like this, in the end we are able to produce both in quantity 
and in quality a lot more. And that should be the goal.
Sep 14 2006
prev sibling parent reply renox <renosky free.fr> writes:
Brad Anderson wrote:

 This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
 
 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
 
 BA


Bah, an over-simplistic article with great claims and little substance.

Some design pattern are caused by flaw in the original language, in 
other language they will be invisible, that's quite obvious..

But claiming that *all* design pattern comes from language flaws as the 
author imply??

Uh? Show me the proof: big claims need strong proofs!

And in the article, there is no such proof, not even a beginning:
a waste of electrons.

Regards,
RenoX
Sep 15 2006
next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
renox wrote:

 Brad Anderson wrote:
 

 This might be a bit OT, but I often wonder if D is going to succeed 
 C/C++/Java
 long-term given that it's not abstracting away a majority of known design
 patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>

 http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

 BA


 
 
 Bah, an over-simplistic article with great claims and little substance.
 
 Some design pattern are caused by flaw in the original language, in 
 other language they will be invisible, that's quite obvious..
 
 But claiming that *all* design pattern comes from language flaws as the 
 author imply??
 
 Uh? Show me the proof: big claims need strong proofs!
 
 And in the article, there is no such proof, not even a beginning:
 a waste of electrons.
 
 Regards,
 RenoX


Agreed.  For a simple example, even the classic and uber-common Singleton
pattern should 
not, IMHO, be part of the language itself.  Why?  Because I'd rather implement
it myself, 
so I can choose which Singleton style suits my particular purpose.  Do I want a
true 
singleton, or a namespace, or a deferred/managed singleton, or selective
singletons, etc.

Pointer magic patterns, also, are something I'd rather get my hands dirty with.
 That way 
I can tailor the magic to my specific goal.  Chances are that, if I'm using
magic to begin 
with, I'm shooting for levels of optimization I can't get without hand tooling.

And so forth.

-- Chris Nicholson-Sauls
Sep 15 2006
prev sibling parent reply David Medlock <noone nowhere.com> writes:
renox wrote:

 
 Bah, an over-simplistic article with great claims and little substance.
 
 Some design pattern are caused by flaw in the original language, in 
 other language they will be invisible, that's quite obvious..
 
 But claiming that *all* design pattern comes from language flaws as the 
 author imply??
 
 Uh? Show me the proof: big claims need strong proofs!
 
 And in the article, there is no such proof, not even a beginning:
 a waste of electrons.
 
 Regards,
 RenoX


In sufficiently powerful language design patterns seem to become 
unnecessary:

http://www.norvig.com/design-patterns/

-DavidM
Sep 15 2006
parent reply renox <renosky free.fr> writes:
David Medlock wrote:

 renox wrote:
 

 Bah, an over-simplistic article with great claims and little substance.

 Some design pattern are caused by flaw in the original language, in 
 other language they will be invisible, that's quite obvious..

 But claiming that *all* design pattern comes from language flaws as 
 the author imply??

 Uh? Show me the proof: big claims need strong proofs!

 And in the article, there is no such proof, not even a beginning:
 a waste of electrons.

 Regards,
 RenoX


 
 
 In sufficiently powerful language design patterns seem to become 
 unnecessary:
 
 http://www.norvig.com/design-patterns/



Unnecessary?
The claim is that "16 of 23 patterns have qualitatively simpler 
implementation in Lisp or Dylan than in C++ for at least some uses of 
each pattern" which is a very different that claiming that design 
patterns are unnecessary.

And in fact I think that a book about the design patterns in LISP to 
study the patterns present in LISP would be interesting (because many 
C++ design pattern are invisible in LISP doesn't mean that LISP has not 
some design pattern of its own).

Of course, the more design pattern are invisible due to language 
features, the better.
But that's not the only way to rate a language, it must be also 
readable, maintenable and its implementation efficient.

RenoX


 
 -DavidM
Sep 16 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sat, 16 Sep 2006 09:29:38 +0200, renox <renosky free.fr> wrote:


The claim is that "16 of 23 patterns have qualitatively simpler 
implementation in Lisp or Dylan than in C++ for at least some uses of 
each pattern" which is a very different that claiming that design 
patterns are unnecessary.


23 patterns?

The GOF book has precisely 23 patterns. So presumably, the logic is
that this set of patterns is definitive and they are the only patterns
that exist...

We must bow down to the most holy gods of GOF!

We are not worthy!
We are not worthy!

I haven't laughed so much in ages!


Just to add to your criticism...

There are thousands of widely recognised published design patterns,
encoding experience from a variety of fields - not just OOP. There are
database design patterns for instance. There is this thing called the
Portland Pattern Repository. There are 'pattern languages' for people
who need a standard way to express patterns. There are even
antipatterns - spelling out bad experience so that it can be avoided.

Personally, I've found Martin Fowlers website to be a useful source of
design patterns (and some very interesting papers besides).

http://www.martinfowler.com/

The GOF patterns are meant to be widely applicable, of course, and
they are in so far as a whole bunch of imperitive object-oriented
languages provide similar kinds of semantics. But that's exactly it.
They specifically say that they are for "standard object-oriented
languages" right there on xi of the preface. And Smalltalk, Java and
UML were particularly in mind throughout.

The GOF patterns were mainly intended as an introductory set to
illustrate the principle and get the ball rolling. The 23 GOF patterns
cannot be treated like the 10 commandments.

So Lisp makes some Java patterns look a bit daft. So what? Lisp and
scheme and such have their own patterns and, shock horror, many of
them make no sense in Java or C++.

Learning to use any language goes through a number of stages. The easy
bit it getting used to the syntax and semantics. The hard bit is
adapting your style - finding the patterns that work. I've done the
easy bit maybe a hundred times. The hard bit, maybe ten. I couldn't
get on with Scheme last time I tried - no problem with the syntax or
the semantics, its all a matter of having the patience to figure out
the patterns that work.

One of the explicit goals of design patterns is to standardise common
ideas that have arisen out of experience, and to provide names for
them, so that it is easier for experts to answer "how do I" style
questions.

Novice lisp programmers have been saying "How do I" for a long time.
There's lots of standard answers to common questions of that form,
answers that go well beyond the realm of syntax and semantics and into
the realm of design patterns. There are more design patterns in Lisp
than any reasonable person could attempt to count.

If a design pattern is a language deficiency, then Lisp is a seriously
deficient language.

Personally, though, I think David and his references just don't know
what a design pattern is. They are taking the idea of the GOF book
being a bible too literally. It's not about the word of the four
design pattern gods. It's about collecting design experience and
making it accessible.

There may be some resistance to collecting the design patterns for
Lisp, or at least using the name 'design patterns' for them. That term
is, after all, very young compared with Lisp - the Lisp 'culture'
should be expected to be a bit set in its linguistic ways, and if
terms like 'FAQ' and 'how to' have served well for so long, why
change? OTOH, It may be that I just haven't found such lists.

The design patterns are out there, though, and if someone would
actually collect that knowledge and make it accessible it would be a
good thing. It would make it a lot easier to learn to do real work in
Lisp/Scheme/whatever for a start. Then maybe I wouldn't just forget it
again after the first month or so, turning back to the more familiar
imperitive/OOP patterns that I've used so much for the last 20+ years.

Plenty of languages have influence how I think and inspired new
patterns and approaches, but for me, Lisp isn't one of them. Syntax
and semantics, sure, but no paradigm shift. And the holier-than-though
attitude that happens a lot tends to bug me. I mean, why start a
thread like this in the first place? If your so into Lisp, fine, use
Lisp. I'm all for advocacy, but... Well, there's good advocacy and
theres bad advocacy...

http://www.perl.com/pub/a/2000/12/advocacy.html

There's tongue-in-cheak advocacy...

http://dave.org.uk/talks/advocacy.html

And, well, there's being a prat.


Now - if I went over to a Lisp newsgroup and said "so, this Lotsof
Infuriatingly Stupid Parentheses language of yours, I reckon its a
load of crap. Here are my badly thought out reasons." then that would
be me being a prat.

But I'm busy ordering pizza right now - maybe tomorrow.

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 17 2006
next sibling parent Derek Parnell <derek psyc.ward> writes:
On Sun, 17 Sep 2006 22:39:42 +0100, Steve Horne wrote:


 On Sat, 16 Sep 2006 09:29:38 +0200, renox <renosky free.fr> wrote:
 

The claim is that "16 of 23 patterns have qualitatively simpler 
implementation in Lisp or Dylan than in C++ for at least some uses of 
each pattern" which is a very different that claiming that design 
patterns are unnecessary.


 
 23 patterns?
 
 The GOF book has precisely 23 patterns. So presumably, the logic is
 that this set of patterns is definitive and they are the only patterns
 that exist...


I do not believe that it necessarily follows that ..

  "The claim is that '16 of 23 patterns have qualitatively simpler 
   implementation in Lisp or Dylan than in C++ for at least some 
   uses of each pattern' which is a very different that claiming
   that design patterns are unnecessary."

implies ...

  "The GOF book has precisely 23 patterns. So presumably, the logic
   is that this set of patterns is definitive and they are the only
   patterns that exist..."

The required logic links are not present, IMHO. I think your presumption is
just that; a presumption. It is not really based on logic at all.

Firstly renox quoted someone else and that quote mentioned the number 23.
And while it is a safe assumtion that 23 refers to the GOF patterns, there
is not link that then imples that either renox or the person he quotes is
saying that the GOF patterns represent the entire set of patterns in
existence. In fact, the person quoted could have said '70% of the patterns
found in the GOF book' and still made his point.

Finally, the point that renox was making, namely that even though someone
believes that most of the GOF patterns could be implemented simpler in
non-C++ languages, it doesn't follow then that therefore design patterns
are unnecessary - is still a good point.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Sep 17 2006
prev sibling parent reply David Medlock <noone nowhere.com> writes:
Steve Horne wrote:

 On Sat, 16 Sep 2006 09:29:38 +0200, renox <renosky free.fr> wrote:
 
 

The claim is that "16 of 23 patterns have qualitatively simpler 
implementation in Lisp or Dylan than in C++ for at least some uses of 
each pattern" which is a very different that claiming that design 
patterns are unnecessary.


 
 
 23 patterns?
 
 The GOF book has precisely 23 patterns. So presumably, the logic is
 that this set of patterns is definitive and they are the only patterns
 that exist...
 
 We must bow down to the most holy gods of GOF!
 
 We are not worthy!
 We are not worthy!
 
 I haven't laughed so much in ages!
 


Well since the GOF book is the most popular book on patterns, Norvig 
attempted to emulate functionality in THOSE patterns.  You are laughing 
at your own inferences.


 So Lisp makes some Java patterns look a bit daft. So what? Lisp and
 scheme and such have their own patterns and, shock horror, many of
 them make no sense in Java or C++.


Where did anyone post that they didn't?  The point (since you missed it) 
is that D is a successor to C++ and the OP was lamenting missing some of 
those patterns in D.


 Personally, though, I think David and his references just don't know
 what a design pattern is.


Spoken like a true priest of the OOP church.  I have been programming 
long enough and in enough paradigms to say I don't need your stamp of 
approval, especially for posting what I thought was an interesting link 
to the discussion at hand.

Its amazing how I post a simple link to some slides on Norvig's site and 
the OOP zealots come out of the woodwork.


 Now - if I went over to a Lisp newsgroup and said "so, this Lotsof
 Infuriatingly Stupid Parentheses language of yours, I reckon its a
 load of crap. Here are my badly thought out reasons." then that would
 be me being a prat.


I doubt you even know why the parentheses even exist in Scheme or Lisp.

I don't know what a 'prat' is but what you have posted is definitely 
prattle.  I think jumping all over me over a simple weblink is juvenile 
at best.

I'm done.
Sep 17 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
As an out-of-order starting point...


I don't know what a 'prat' is but what you have posted is definitely 
prattle.  I think jumping all over me over a simple weblink is juvenile 
at best.


For reference - a 'prat' is what I was being when I posted. It is a
common Brit insult, and often refers to someone who irritates people
either deliberately or by being inconsiderate.

It's mostly a mild, inoffensive thing. Something you might call a
friend. Like the terms 'tart' and 'whore' mean similar things, but
'tart' is rarely offensive. People call themselves tarts in a jokey
way, and they call themselves prats just the same.

BUT it is also used in spite, which is what I did, so I appologise for
that.

I'm clearly in a mood where I can't post responsibly. So I think it's
best if I go to 'lurk only' mode until I'm in a mood where I can play
nice.

Sorry.


That said, I still feel the need to make a few points - sorry if that
gives the impression of a 'false' appology, but I've always felt that
I should be able to appologise meaningfully for what I did wrong
without that meaning I'm wrong about everything.

Your bad feeling was justified, but I can't leave what I see as a
factually incorrect claim uncountered.


On Sun, 17 Sep 2006 23:33:37 -0400, David Medlock <noone nowhere.com>
wrote:


Well since the GOF book is the most popular book on patterns, Norvig 
attempted to emulate functionality in THOSE patterns.  You are laughing 
at your own inferences.


I was responding to...

: In sufficiently powerful language design patterns seem to become 
: unnecessary:
: 
: http://www.norvig.com/design-patterns/
: 
: -DavidM

Which was itself in response to..

: > But claiming that *all* design pattern comes from language flaws as the 
: > author imply??
: > 
: > Uh? Show me the proof: big claims need strong proofs!

Basically, I still feel that it is reasonable to take your post as a
quote and link given as proof of an opinion that you agree with.

Now, I'm on slightly weak ground in some respects because I haven't
read much of the link, and made my inferences mostly from renox's
quote. However, renox posted the quote that...

: The claim is that "16 of 23 patterns have qualitatively simpler 
: implementation in Lisp or Dylan than in C++ for at least some uses of 
: each pattern"

And that claim can only support the conclusion that...

: In sufficiently powerful language design patterns seem to become 
: unnecessary:

...if you believe that the GOF patterns are either all patterns, or at
least a reasonable sample of relevant ones, as opposed to the biased
sample that they clearly are since they are explicitly aimed at
"standard OOP languages" and there are many many more patterns, both
published and not, that are aimed at other things.

So when I posted...


 So Lisp makes some Java patterns look a bit daft. So what? Lisp and
 scheme and such have their own patterns and, shock horror, many of
 them make no sense in Java or C++.




I was overdoing the sarcasm, but I still think the underlying point
was a reasonable reaction to what you posted.



  The point (since you missed it) 
is that D is a successor to C++ and the OP was lamenting missing some of 
those patterns in D.


I still don't see any example of anyone lamenting anything being
missing in D in the chain leading back to Brads original post. I saw
only the false suggestion that the existence of patterns indicates
weaknesses in the language.



 Personally, though, I think David and his references just don't know
 what a design pattern is.


Spoken like a true priest of the OOP church.  I have been programming 
long enough and in enough paradigms to say I don't need your stamp of 
approval, especially for posting what I thought was an interesting link 
to the discussion at hand.


I never criticised non-OOP languages. What I said was in support of
patterns, and their being more widely applicable than just standard
OOP languages.

The worst I did was (1) state that I haven't personally been able to
get along with Lisp-alikes, and hadn't got a 'paradigm-shift' from
them, and (2) recycle an ancient Lisp joke in a deliberately sarcastic
point about bad advocacy.

As I said, your post appeared to be supplying the proof that renox had
previously demanded. No matter how many times I go back and re-examine
it, your claim of neutrality on the issue still seems odd.

Oh, and I've been programming a long time (and in multiple paradigms)
too. I do tend to turn back to more conventional OOP/imperitive for
real work, but I've got my paradigm shifts from languages like Haskell
(and Miranda, many years ago), Prolog and Icon (imperitive, but
differently imperitive) as well - all have influenced my style, and
all have influenced what I expect from a good programming language.

So much for that "true priest of the OOP church" claim.


I doubt you even know why the parentheses even exist in Scheme or Lisp.


My knowledge of scheme and lisp is, I admit, superficial. But this was
meant to be a sarcastic point anyway, referring to a common
misrepresentation of Lisp-style languages. Repeating an ancient bad
joke to make a point about bad advocacy (and being a prat as I did
it).

As I already said, I tend to give up on Lisp-alikes soon after the
syntax-and-semantics stage when the real language learning starts. I
never seem to get to the able-to-create-real-software stage.

But that doesn't justify your implying that I'm ignorant. In fact, my
experience with Lisp reinforces my point about patterns.

To expand on the point, I know full well that you can basically define
your own syntax using a library in Lisp-alikes, and that if you do so
you can get rid of the 'infuriatingly stupid' parentheses - if you
interpret them as such. And I know also that most Lisp users choose
not to do that for the most part, since the parentheses do their job
very well - its a style like any style, with its own particular
strengths.

Fancy a parser generator? I don't think Scheme developers understand
the point of lex or yacc. "Why use a noddy little external tool?" they
ask. "Why not just use the language you're already using, and have the
full power of that language available as a bonus?"

I'm fully aware of all that. But really, the problem I have with
Lisp-alikes (or at least the main problem I had last time around the
loop, a few years back) is that there is too much freedom and too much
power.

With infinite flexibility comes infinite options. There are no
boundaries. It is hard to know where there's solid ground to build on.
It is hard to know what structure to apply. The Perl people are fond
of saying that there's more than one way to do it, but when there's no
apparent bounds to the number of ways to do it...

Well, this particular newbie gets overwhelmed, and gives up.

I had similar issues in Haskell, as it happens, but only after some
paradigms had already shifted a bit. Functional programming wasn't
entirely new to me then. I've used Miranda, but not very much and it
was a very long time ago, and let's face it - I didn't like the all
prefix notation, which just seemed like backwards Forth. Hard to get
to paradigms when the syntax is driving you nuts.

Haskells syntax, in contrast, is maybe the exemplar for
indentation-based structuring - almost a paradigm in itself. Python is
cool, but compared with the offside rule, it's just not quite there.

Anyway, a good collection of patterns for Lisp-alikes would be a great
thing, IMO. It would help newbies to get past the syntax-and-semantics
stage to the able-to-build-real-software stage. Provide a mental
vocabulary to use as a start point for creating real world designs, as
opposed to noddy textbook examples of language features.

OTOH, maybe I need to approach Lisp asking "how do I solve this
problem?" rather than "where are Lisps limits?".

Hmmmm...


Anyway, getting back to the point, there was nothing in what I posted
to prove that I'm ignorant about Lisp. To do that, you'd have to look
elsewhere...

Go to Google Groups, and seach for "steve horne lisp interpreted".

"""
It wouldn't surprise me. LISP is normally interpreted - maybe always, 
though I'm not certain of that.
"""

Lisp? Interpreted?

Well, the crucifiction was put on hold, pending any future ignorant
comments I might make. So I do try very hard not to make any. But I
have checked back, and the terms allow that I don't have to get on
with Lisp. Just the 'no more ignorant garbage about Lisp' clause.

So I *should* be OK ;-)

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 19 2006
parent reply David Medlock <noone nowhere.com> writes:
Steve Horne wrote:

 As an out-of-order starting point...
 
 

I don't know what a 'prat' is but what you have posted is definitely 
prattle.  I think jumping all over me over a simple weblink is juvenile 
at best.


 
 
 For reference - a 'prat' is what I was being when I posted. It is a
 common Brit insult, and often refers to someone who irritates people
 either deliberately or by being inconsiderate.
 
 It's mostly a mild, inoffensive thing. Something you might call a
 friend. Like the terms 'tart' and 'whore' mean similar things, but
 'tart' is rarely offensive. People call themselves tarts in a jokey
 way, and they call themselves prats just the same.
 
 BUT it is also used in spite, which is what I did, so I appologise for
 that.
 
 I'm clearly in a mood where I can't post responsibly. So I think it's
 best if I go to 'lurk only' mode until I'm in a mood where I can play
 nice.
 
 Sorry.
 


No problem.


 That said, I still feel the need to make a few points - sorry if that
 gives the impression of a 'false' appology, but I've always felt that
 I should be able to appologise meaningfully for what I did wrong
 without that meaning I'm wrong about everything.
 
 Your bad feeling was justified, but I can't leave what I see as a
 factually incorrect claim uncountered.
 


I was a little miffed, mostly because I haven't seen your posts and you 
implied I was either:ignorant of patterns and/or a Lispnik.


 On Sun, 17 Sep 2006 23:33:37 -0400, David Medlock <noone nowhere.com>
 wrote:
 
 

Well since the GOF book is the most popular book on patterns, Norvig 
attempted to emulate functionality in THOSE patterns.  You are laughing 
at your own inferences.


 
 
 I was responding to...
 
 : In sufficiently powerful language design patterns seem to become 
 : unnecessary:
 : 
 : http://www.norvig.com/design-patterns/
 : 
 : -DavidM
 
 Which was itself in response to..
 
 : > But claiming that *all* design pattern comes from language flaws as the 
 : > author imply??
 : > 
 : > Uh? Show me the proof: big claims need strong proofs!
 
 Basically, I still feel that it is reasonable to take your post as a
 quote and link given as proof of an opinion that you agree with.
 


A fair assumption.  I think you inferred a bit more than that though..
Norvigs presentation shows exactly how to achieve the semantic 
functionality in dylan and Lisp.

Not only that, later in it he shows a bunch of things which are very 
difficult in C++: coroutines, multimethods and partial evaluation.

Advancing programming is all about moving to higher level in the aspects 
we can, I believe he shows some examples of this.


 Now, I'm on slightly weak ground in some respects because I haven't
 read much of the link, and made my inferences mostly from renox's
 quote. However, renox posted the quote that...
 
 : The claim is that "16 of 23 patterns have qualitatively simpler 
 : implementation in Lisp or Dylan than in C++ for at least some uses of 
 : each pattern"
 
 And that claim can only support the conclusion that...
 
 : In sufficiently powerful language design patterns seem to become 
 : unnecessary:
 



 ...if you believe that the GOF patterns are either all patterns, or at
 least a reasonable sample of relevant ones, as opposed to the biased
 sample that they clearly are since they are explicitly aimed at
 "standard OOP languages" and there are many many more patterns, both
 published and not, that are aimed at other things.
 
 So when I posted...
 


Well as you stated there are plenty of patterns(on C2 alone), but we 
cannot dissect them all.  As Mark Twain stated: its hard to argue with a 
good example.


 

So Lisp makes some Java patterns look a bit daft. So what? Lisp and
scheme and such have their own patterns and, shock horror, many of
them make no sense in Java or C++.




 
 
 I was overdoing the sarcasm, but I still think the underlying point
 was a reasonable reaction to what you posted.
 


True, but the point I was making is that the problems are usually at a 
higher level in more powerful languages.


 

 The point (since you missed it) 
is that D is a successor to C++ and the OP was lamenting missing some of 
those patterns in D.


 
 
 I still don't see any example of anyone lamenting anything being
 missing in D in the chain leading back to Brads original post. I saw
 only the false suggestion that the existence of patterns indicates
 weaknesses in the language.
 


The discussion seemed to be Design patterns applied to languages.  I 
would argue not a ton would change with D applied to those patterns. 
That is also my point though...just incurring discussion not arguments.


 

Personally, though, I think David and his references just don't know
what a design pattern is.


Spoken like a true priest of the OOP church.  I have been programming 
long enough and in enough paradigms to say I don't need your stamp of 
approval, especially for posting what I thought was an interesting link 
to the discussion at hand.


 
 
 I never criticised non-OOP languages. What I said was in support of
 patterns, and their being more widely applicable than just standard
 OOP languages.
 
 The worst I did was (1) state that I haven't personally been able to
 get along with Lisp-alikes, and hadn't got a 'paradigm-shift' from
 them, and (2) recycle an ancient Lisp joke in a deliberately sarcastic
 point about bad advocacy.
 


I am not a Lisp-junkie.  I see its inherent power and its weaknesses. 
Unfortunately I also see a million distributions all with quirks and the 
read-it-back issue isn't too good either.


 As I said, your post appeared to be supplying the proof that renox had
 previously demanded. No matter how many times I go back and re-examine
 it, your claim of neutrality on the issue still seems odd.
 


I was attempting to add to the discussion, if I am not adding anything 
tell me why?  Without opposing viewpoints its basically just a pep-rally.

I am actually quite neutral.  If I had to classify my programming style 
it would be data-driven.  Just about every reusable program I have ever 
used concentrated on the data(web browser,compiler,Spreadsheet,etc). 
Lisp is good for a good number of these, python for others, D for others.

My big criticism of OOP has always been inheritance.  I have yet to see 
it applied in a large way(horizonally not vertically) and not had a huge 
mess. I prefer prototypes and delegation to inheritance.


 
 Well, the crucifiction was put on hold, pending any future ignorant
 comments I might make. So I do try very hard not to make any. But I
 have checked back, and the terms allow that I don't have to get on
 with Lisp. Just the 'no more ignorant garbage about Lisp' clause.
 
 So I *should* be OK ;-)
 


Lisp is simply syntax trees, Closures,RTTI and a compile time lexical 
analyzer(aka pattern matching).  The syntax trees make it what it is, so 
you can't remove the parentheses.  The tools it provides to make data 
turn into code are fairly flexible.

In closing, sorry if my post sounded harsh, but your post sounded 
exactly like the OOP-is-the-world responses I have fielded in the past.

I am pretty even tempered usually but I program in Perl all day you see 
so I have a pretty good excuse to lose it once in a while!

Cheers,
-DavidM
Sep 19 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 19 Sep 2006 19:30:46 -0400, David Medlock <noone nowhere.com>
wrote:


Advancing programming is all about moving to higher level in the aspects 
we can, I believe he shows some examples of this.


Yes. I seem to remember the Scheme philosophy going on about simple
but powerful syntax. There's trade-offs, though.

A common claim is that Perl is better for small programs, but Python
better than larger ones. You may need to do a few extra things in
Python, which are a pain in a small program, but as the code gets
bigger those little annoyances pay for themselves in cleaner, more
readable and maintainable code - or so the theory goes. I don't know
if the Perl/Python comparison is fair though. My biggest problem with
Perl has always been the number of unfamiliar details at the start,
which seems kind of backwards from that rule.

I can believe that something like that might apply in Lisp, though,
only much more so. Get past the fiddling-little-details stage and
things maybe work out much easier. But first, you need to decide what
kind of structure to impose on those fiddling details.


Not only that, later in it he shows a bunch of things which are very 
difficult in C++: coroutines, multimethods and partial evaluation.


Cool. I lost count of the number of times I've wanted multimethods.
There are patterns, but they're mostly aweful. Even the
simple-in-principle std::map method has member pointer issues.


Lisp is simply syntax trees, Closures,RTTI and a compile time lexical 
analyzer(aka pattern matching).  The syntax trees make it what it is, so 
you can't remove the parentheses.


Sure you can...


  The tools it provides to make data 
turn into code are fairly flexible.


Exacly. I wasn't that impressed with Scheme macros. Being familiar
with parsing techniques made them easy enough to understand, but I
could also see their limitations. But you can always just quote the
expression and write the functions to translate it. Unless I'm badly
mistaken, a good compiler should spot that the translation function
can be evaluated at compile time, so the binary should hold the
translated version.

Realise that, and that's exactly the point where the boundaries
disappear into the distance and you get lost in all the possibilities
and the details you need to overcome to make them workable. And you
think to yourself "do I really want to effectively design my own high
level language just to write my app", because when you're deciding on
structures from that low level, that's pretty much what you end up
doing.

You can't sensibly remove all parens any more than you can in C++ or D
or whatever, but you can reduce the need a lot. Just write a parsing
function that translates whatever syntax you want to standard Lisp
expressions. And then, maybe you can write a translator that
translates a readable class specification into an object instantiation
function, and...


In closing, sorry if my post sounded harsh, but your post sounded 
exactly like the OOP-is-the-world responses I have fielded in the past.


My fault.


I am pretty even tempered usually but I program in Perl all day you see 
so I have a pretty good excuse to lose it once in a while!


Oh dear! Poor you! :-)

-- 
Remove 'wants' and 'nospam' from e-mail.
Sep 20 2006