Subject: Worse is Better (was: torvalds)
From: Ben_Tilly@trepp.com
Date: Mon, 22 Oct 2001 16:59:41 -0400


Jonathan S. Shapiro wrote:
> > - Common Lisp
> > - Eiffel
> > - Emacs Lisp
> > - Haskell
> > - Java
> > - Objective Caml
> > - Perl
> > - Python
> > - Ruby
> > - Scheme
> > - Smalltalk
> > - TCL
> > - Visual Basic
>
> I'm an advocate of safe languages, but it is striking that for every
> language on this list, either (a) there is no static typing, or (b) there
is
> no widely-available implementation. Problem (a) makes the language
unsuited
> for large production systems, while (b) makes it too risky to implement
> large production systems in a given language.

Every?  Haskell is strongly statically typed, and there is a pretty
portable implementation at http://www.haskell.org/hugs/ under an open
source license.  That it is not more widely installed is a chicken and
egg problem.  But if you want speed, compile-time type-safety, and
protection from buffer overflows in one package, Haskell is a pretty
good choice.

As for the need for static typing, color me unconvinced.  I believe
that protection from buffer overflows and dangling pointers is a more
important development feature for large projects than static typing.
Furthermore the most widely used languages with static typing also
allow you to cast around the type-system.  As is pointed out at
http://www.pragmaticprogrammer.com/cgi-local/pragprog?JavaIsUntyped,
that leaves you with the worst of both worlds.  In reality no static
type-check, but with compile-time inconvenience.  (In their example
they would have had more protection from a run-time check than they
got from Java.)

Which raises an interesting FSB question.  I assume that people here
are familiar with Richard Gabriel's paper on Worse is Better.  It was
actually the first of a series of papers back and forth.  You can
read several of them at http://www.dreamsongs.com/WorseIsBetter.html.

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.  What is clearly better in one sense can easily be
worse in another.  Though his specific points are interesting.

Another good example is the customizability of a language.  From the
point of view of productivity, a highly customizable language is good
because good programmers will customize it in ways that speed them up.
From the point of view of creating a community, customizability is bad
because it discourages the creating of shared repositories, it gives
room for passionate arguments about how and why to customize the
language, and it makes it harder for people to offer advice to
someone without knowing how things have been customized.

I offer the Lisp variants as examples of customizable languages, and I
offer Perl as an example of a language which is not very customizable.
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...)

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?

Cheers,
Ben