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

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

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

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.

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