Subject: Re: Worse is Better (was: torvalds)
Date: Tue, 23 Oct 2001 10:53:37 -0400

Simon Cozens wrote:
> On Mon, Oct 22, 2001 at 04:59:41PM -0400, wrote:
> > They are interesting.  But I must admit that in reading them I failed
> > to be bemused by the paradox that fascinates Richard Gabriel.  Instead
> > it seemed to me to be an obvious point.  Whether a feature of a
> > language, project, or development environment is good or bad depends
> > on whether you are interested in personal productivity, or creating a
> > good community.
> Counterexample: GNU Hurd.

I didn't mean to imply that those two goals are diametric opposites.
Failing to develop software at all is bad from both points of view.

> > I further submit that Perl would likely not have developed CPAN into
> > what it is today if Perl had a readily available and widely used macro
> > facility.  (Yes, I know about the -P flag.  When was the last time you
> > saw someone *use* it?  Simon, you can put your hand down...)
> I'd never use -P - the idea of bolting a text processor onto the side of Perl
> is pretty laughable. We have macros. Perl calls them subroutines.

But in Lisp it is not laughable since the text processor is Lisp
itself, and the language is designed to be easily parsed.  You could
theoretically play games in Perl using eval, Filter::*, etc.  But to
make it work well you need to parse Perl, and only perl can do that.
(Damian mostly succeeds, but with some definite failure modes.)

This makes Perl less customizable, which in turn makes code reuse
between different sites much easier.

> > So here is the FSB question.  Suppose that you see two projects which are
> > similar but have worse-is-better characteristics at work.  For instance one
> > is written in Haskell and one in C.  How much would you factor
> > worse-is-better characteristics into your decision of which project to get
> > involved in?  Or from the point of view of J. Random Hacker, which language
> > do you use when starting a project?
> Of course, how this is an FSB question really depends on what your
> FSB does. :) From a coder-conslutancy point of view, we only really
> want to get into things our coders know about - that's mainly Perl
> and C. [...]
> For instance, if we're writing a tool aimed at Perl users which we can
> reasonably get away with writing in Perl, we'll write it in Perl - if we write
> it in C or Java, we alienate our own target audience.
> I can't speak for the rest of the Parrot design team, but I know that one of
> the reasons why we wrote Parrot in C was because we knew that the vast
> majority of the people that we *wanted* contributing to Parrot could talk C.

Both of these suggest strongly that the free software world
self-segments by language, and if you want to get community leverage
you have to go where the community is.

I consider the Parrot example particularly spectacular.  You have a
group of people who have all recognized in the languages they wrote
the tremendous value of not doing your own garbage collection, having
the language protect you from buffer overflows, and dynamic typing.
Yet to build a common platform for such language you go with C, which
you know will cause you to spend considerable time and energy on
writing your own garbage collector (again) and spending considerable
development energy tracking down bugs that a better platform would

Now I am not disagreeing with your move.  It is smart based on various
factors ranging from social ones like who you can get involved, to
technical issues like how you link in other projects.  But I still
find it interesting.

> Now, from a standard services-model FSB, things get a little different,
> because you don't want to artificially narrow your own customer base: if
> you've got four Perl-based projects out there, you'll want to toss out a
> couple in Python or whatever.

Again stressing the tendancy for FSBs to segregate by language
platform.  In this case it is an undesired tendancy, and so you have
to devote energy to keeping it from happening to you.  I think that
ActiveState is a good example of a company which has gotten involved
in projects for this reason.

> It's all about maximizing the number of punters, and making sure you get the
> kind of punters you want. :)

In other words it is all about the community.  There would be a lot of
risk if you tried to lead the community.  But I think it is sometimes
a worthwhile risk to take.  Here are two examples.

The first is Dave Thomas and Andrew Hunt.  If you pick up their book,
"The Pragmatic Programmer", among other pieces of advice they suggest
getting in on the ground floor of a promising new language or platform
from time to time.  If you can do so, you will be able to get years of
work from it.  Well the first thing they did after writing that book
was to look at a number of languages, and decide that a little-known
language from Japan showed a lot of promise.  They immediately started
pushing it.  This included making sure good English documentation
existed, doing some sample projects in it, answering questions on the
mailing list, writing a book, etc. And that is one of the biggest
reasons that Ruby started getting some press.  What do people think of
this strategy?

The second is Paul Graham's article, "Beating The Averages", which you
can find online at
After I read this, I began thinking about the question of how you can
value available source-code from the community versus an environment
that makes you more productive.  I don't have the answer.  However it
is not irrelevant.  In virtually any discussion on which language to
use, if Perl is a contender, then CPAN will come up.  How does someone
who prefers Python factor this argument in?

I believe that a good answer to this question goes to the heart of
the open source value proposition.  It is one thing to say, "This is
valuable and worthwhile!"  It is far more telling when you can say,
"This is worth enough to me that I will give up something else of
value for it."