[erlang-questions] Fear and Loathing in Programming La La Land
Michael Turner
michael.eugene.turner@REDACTED
Thu Mar 29 12:15:17 CEST 2012
> It doesn't frighten me that [such programmers] _exist_,
> it frightens me that they are _programming_.
LOL.
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
P.set_x(0)
P.set_y(0)
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 <ok@REDACTED> 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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list