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

Michael Turner <>
Thu Mar 29 12:15:17 CEST 2012

> It doesn't frighten me that [such programmers] _exist_,
> it frightens me that they are _programming_.


I don't have that much against create-set-call, provided that

(1) What I get from creation is either
(1a) ... something in a consistent and usable state, or
(1b) ... something that will throw a useful exception in informative
ways if it can't (yet) be used
... and ....
(2) Expression of the "set" part is reasonably concise and clear, and
always yields a situation like (1ab) above.

But it does seem to lend itself to small-minded purism. Of which we've
had plenty. And from Microsoft, too. (Remember Hungarian Notation?)

I mean, how about this?

   P = new Point

It's just dumb to *require* doing it that way. The test for me isn't
purity, it's idiomaticity. I'm not saying Point wouldn't have setters
and getters. Just that I shouldn't be limited to those.

On the other side of the debate: I once worked in a C++ shop with an
API that required up to 22 parameters for construction of certain
objects. "It's not so bad," a long-timer tried to assure me, "You just
copy-paste a call from someone else's code then make the changes you
need ...."  I almost hit the ceiling.

-michael turner

On Thu, Mar 29, 2012 at 4:32 PM, 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!
> Their sample was carefully chosen to include three kinds of programmers:
>  *     OPPORTUNISITC programmers are more concerned with productivity
>        than control or understanding.  For these programmers objects
>        that required constructor parameters were unfamiliar and
>        unexpected, and even after repeated exposure these programmers
>        had difficulty with these objects.
>        That is, they just didn't "get" the idea of constructors having
>        parameters.
>  *     PRAGMATIC programmers balance productivity with control and
>        understanding.  These programmers also did not expect objects
>        with required constructors, and while pragmatic programmers
>        were more effective than opportunistic programmers at using
>        these objects, the objects still provided a minor stumbling
>        block and these programmers preferred the flexibility offered
>        by objects that used the create-set-call pattern.
>        Remember, this was all about .NET.  Failing to expect
>        constructors with parameters in C# is like failing to expect
>        assignment statements in C.
>  *     SYSTEMATIC programmers program defensively and these are the
>        programmers for whom low-level APIs are targeted.  These programmers
>        were effective at using all of the objects; however, they preferred
>        create-set-call because of the finer granularity of control it
>        offered by allowing objects to be initialized one piece at a time.
> The purpose of the study was to provide guidelines for API designers at
> Microsoft:  apparently they now recommend create-set-call.  Remember,
> that's the idea where you create an object without saying *anything* about
> what you want it to be and then successively kick it into shape.
> They later say
>        [Systematic programmers] want not just to get their code working,
>        but to understand why it works, what assumptions it makes
>        and when it might fail.  They are rare, and prefer languages that
>        give them the most detailed control such as C++, C and assembly.
> I'd like to think of myself as a systematic programmer.  I certainly like
> to understand all those things.  But if I preferred assembly I would not
> be writing in the Erlang mailing list!  The basic conclusion seems to be
> that you should not design APIs for such rare animals.
> I made what I thought were three obvious points:
> (1) There is a confounding factor in the study:  the create-set-call style
>    lets you *name* the information going into an object, while at that
>    time the full-initialisation style did not.  There are constructors
>    for System.IO.FileStream with six arguments; maybe more.  It seemed at
>    least *possible* that if the subjects had been given a third choice,
>    constructors with *named* parameters, they might have preferred that.
>    Because the study didn't include such a choice, we certainly cannot
>    use it to argue *against* that style.
> (2) C# 4.0 has named (and optional) parameters, so the study is no longer
>    adequate to tell us about good API design in C#.
> (3) If there are programmers out there who *don't* care much about
>    understanding what they are doing, I certainly don't want them writing
>    anything that might in any way affect me or anyone I care about.
>    If they just don't "get" constructors with parameters, that's really
>    scary.
> 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_.
>        they are successfully building applications in many different domains.
>        They may work differently to you and many other programmers but that
>        doesn’t necessarily mean that the code they create is worthless.
>        Within the Visual Studio team at Microsoft we’ve devoted efforts to
>        attempting to make them successful by adapting to their workstyles
>        when appropriate.
> I find myself wondering just how "successful" their applications really are.
> Oh no!  I hope they're not writing climate modelling code!  That would
> explain so much...  (Yes, I've looked at the code in the ClimateGate dump.)
> Frankly, I've turned here for a bit of comfort.  If anyone likes completely
> initialising things rather than smacking one field at a time, surely I will
> find such people here.
> Am I wrong?  Would *you* be happy opening a file in C by doing
>        FILE *f = malloc(sizeof f);
>        set_title(f, "foo/bar.txt");
>        set_access(f, "r");
>        gets(f, buffer);
> _______________________________________________
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list