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

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

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

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.

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!"

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.

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.

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

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.