Design Patterns == weakness in language

[Steve Horne]

On Tue, 19 Sep 2006 19:30:46 -0400, David Medlock <noone at 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.