Subject: Re: Worse is Better (was: torvalds)
From: Simon Cozens <simon@netthink.co.uk>
Date: Mon, 22 Oct 2001 23:12:27 +0100

On Mon, Oct 22, 2001 at 04:59:41PM -0400, Ben_Tilly@trepp.com 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 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.

No, the point of CPAN is reusability, encapsulating common tasks, rather than
attempting to extend the language. (Filter::* and Damian's recent forays into
Latin and Klingon excepted.) No amount of macro processing is going to give
you, say, LWP::Simple, or anything which uses XS.

> 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. When you're starting a project, you think of two things: i) how many
people can we get involved if we choose language X? ii) How many of those
people that we *want* to get involved are likely to use language X?
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.

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.

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

-- 
CLUELESSNESS:
    There are No Stupid Questions,
    But There Are a LOT of Inquisitive Idiots
                                                    http://www.despair.com