What's better about Ruby than Python?

[Jacek Generowicz]

"Andrew Dalke" <adalke at mindspring.com> writes:

> As a consultant, I don't have the luxury of staying inside a singular
> code base.  By your logic, I would need to learn each different
> high level abstraction done at my clients' sites.

The alternative is to understand (and subsequently recognize) the
chunks of source code implementing a given patten for which no
abstraction was provided (often implemented slightly differently in
different parts of the code, sometimes with bugs), each time that it
occurs.

I'd rather use multimethods that implement the visitor pattern.

I'd rather look at multimethods, than at code infested with
implementations of the visitor pattern.

(The above comments are _not_ about the visitor pattern per se.)

> The inference is that programming language abstractions should not
> be more attractive than sex.

Why ever not?  Don't you want to put the joy back into programming :-)

> Functions and modules and objects, based on experience, promote
> code sharing.  Macros, with their implicit encouragement of domain
> specific dialect creation, do not.

I don't believe you can reasonably draw a rigid and well-defined
boundary between functions, modules and objects on one side, and
macros on the other. They all offer means of abstraction. All are open
to abuse. All can be put to good use.

In all four cases, I'd rather have the opportunity to create
abstractions, rather than not.

I find your suggestion that macros are in some way more "domain
specific" than modules, or objects or functions, bogus.

> A language which allows very smart people the flexibility to
> customize the language, means there will be many different flavors,
> which don't all taste well together.

> A few years ago I tested out a Lisp library.  It didn't work
> on the Lisp system I had handy, because the package system
> was different.  There was a comment in the code which said
> "change this if you are using XYZ Lisp", which I did, but that
> that's a barrier to use if I ever saw one.

You are confusing the issues of

- extensibility,
- standard non conformance,
- not starting from a common base,
- languages defined my their (single) implementation.

A few days ago I tested out a C++ library. It didn't work on the C++
system I had handy because the STL implementation was
different/template support was different. etc. etc.

A few days ago I tested out a Python library. It didn't work on the
implementation I had handy because it was Jython.

> 4) a small change in a language to better fit my needs has
> subtle and far-reaching consequences down the line.  Instead,
> when I do need a language variation, I write a new one
> designed for that domain, and not tweak Python.

So, what you are saying is that faced with the alternatives of

a) Tweaking an existing, feature rich, mature, proven language, to
   move it "closer" to your domain.

b) Implementing a new language from scratch, for use in a single
   domain

you would choose the latter?

If so, you are choosing the path which pretty much guarantees that
your software will take much longer to write, and that it will be a
lot buggier.

It's an extreme form of Greenspunning.

How do you reconcile 

> when I do need a language variation, I write a new one designed for
> that domain, and not tweak Python.

with

> Functions and modules and objects, based on experience, promote
> code sharing.  Macros, with their implicit encouragement of domain
> specific dialect creation, do not.

?

You criticize macros for not encouraging code sharing (they do, by
encouraging you to share the (vast) underlying language while reaching
out towards a specific domain), while your preferred solution seems to
be the ultimate code non-sharing, by throwing away the underlying
language, and re-doing it.