[Prev][Next][Index][Thread]

Re: failures



Has anyone here read the book "GUI Bloopers"?  The author attempts to show
people how to do GUI design right, by giving examples of bad design and how
to correct them.  This is combined with an underlying message that good
design requires UI experts to be involved at an early stage, and that
management has a responsibility to make that happen.

I've been thinking that we need a similar book for programming languages,
and typed languages in particular.  We could show examples of where
mistakes were made, and how expert involvement can reduce the chance of
such mistakes.  The book wouldn't explain the theory in any detail; it
would use example code to illustrate the problems, and brief descriptions
of solutions, so that the average programmer would be able to understand it
(and hopefully enjoy it).

There is a large gulf between the people who design languages that everyone
uses, and the people who know the theory.  This gulf is shrinking, thanks
to some people who have worked hard to bridge it, but there's still a long
way to go before the language community's skills are properly recognised.
A popular book like this might help.

Dave.

See
http://www.amazon.co.uk/exec/obidos/ASIN/1558605827/ref=sr_aps_books_1_1/202
-9615352-4335827 for more info on "GUI Bloopers".



At 19:53 02/12/2002, Matthias Felleisen wrote:
>[----- The Types Forum, http://www.cis.upenn.edu/~bcpierce/types -----]
>
>Okay, this didn't work out. Let's try again. 
>
>Are examples out there that show how naive reasoning about languages
>(not individual programs) is a major problem? 
>
>  The canonical example is to combine polymorphic let without
>  restrictions with naive generalizations for references, exceptions,
>  continuations, and channels.
>
>For what else have we needed *any* form of semantics to dispute naive
>generalizations? 
>
>I for one would find it really neat if we had such a list of examples
>on-line for use in courses at all levels and program officers at
>funding agencies, too.
>
>Any other examples than the one above? One is a random hit, two is 
>a coincidence, three makes a pattern. -- Matthias
>
>