[erlang-questions] Fear and Loathing in Programming La La Land

Garrett Smith <>
Wed Apr 4 19:49:55 CEST 2012


Hi Richard,

On Thu, Mar 29, 2012 at 2:32 AM, Richard O'Keefe <> wrote:
> I'm to the Psychology of Programming Interest Group mailing list.
> In a discussion of naming, reference was made to a body of work
> containing
>        Usability Implications of Requiring Parameters
>        in Objects' Constructors
>        by Jeffrey Stylos of CMU
>        and Steven Clarke of Microsoft
> at      http://www.cs.cmu.edu/~NatProg/papers/Stylos2007CreateSetCall.pdf
>
> The abstract reads
>        The usability of APIs is increasingly important to programmer
>        productivity.  Based on experience with usability studies of
>        specific APIs, techniques were explored for studying the usability
>        of design choices common to many APIs.  A comparative study was
>        performed to assess how professional programmers use APIs with
>        required parameters in objects’ constructors as opposed to
>        parameterless “default” constructors.  It was hypothesized that
>        required parameters would create more usable and self-documenting
>        APIs by guiding programmers toward the correct use of objects and
>        preventing errors.  However, in the study, it was found that,
>        contrary to expectations, programmers strongly preferred and
>        were more effective with APIs that did not require constructor
>        parameters.  Participants’ behavior was analyzed using the
>        cognitive dimensions framework, and revealing that required
>        constructor parameters interfere with common learning strategies,
>        causing undesirable premature commitment.
>
> The study was done in 2005.
> We're talking about the difference between
>
>        fs = new FileReader("foo/bar.txt", Sharing.NONE);
>        ln = fs.ReadLine();
>        ...
>
> and
>
>        fs = new FileReader();
>        fs.SetFileName("foo/bar.txt");
>        fs.SetSharing(Sharing.NONE);
>        ln = fs.ReadLine();
>        ...
>
> I think this is worth bringing up here because if functional programming
> is about anything at all, it's certainly about NOT setting up a value one
> field at a time!

<snip>

> A lengthy discussion has followed in which I've felt rather lonely.
> I'm being beaten about the head for not noticing things in the study
> that I did notice, and for being rather elitist.  One quote:
>
>        We don’t have the luxury of dismissing these types of programmers.
>        While it might strike you with terror that these programmers exist,
>
> It doesn't frighten me that they _exist_,
> it frightens me that they are _programming_.

This is study is understandable in light of this:

    To increase the
    usability of these and future APIs, and to improve the
    productivity of the programmers who use them, the
    *Visual Studio* User Experience group conducts user
    studies of APIs before they are finalized.

My emphasis.

Visual Studio has always been built on GUI features -- in particular
object based "property sheets" [1]. I think this is one of drivers
historically for "object oriented" development models -- they're
pretty easy to build graphical tools around.

Functional memes just require a text editor. It's hard to charge >
$200 for a text editor.

Java "beans" also work this way -- they are designed to fit neatly
into graphical IDEs.

You get this set of requirements based on the tooling:

- Objects must be instantiated with a zero argument constructor --
that way IDEs can set them up easily in the UI
- Modifications to the objects are made through property accessors --
also something easy to support in UI
- Once configured by setting properties, objects can be used for
whatever purpose they're designed

It's no surprise at all to me that developers in these communities
prefer zero arg constructors and property configuration.

These are just two totally, totally different world views. Almost
certainly dangerous to cross the streams [2].

Garrett

[1] http://bit.ly/HhQ3Em

[2] http://bit.ly/Hgr97q



More information about the erlang-questions mailing list