<div>
You're certainly not alone :) The idea of create-set-call is, imho, madness. It means that you never really know if an object is in a sane state to be used - what properties need to be set to make the object "usable"? What happens if some properties are set more than once? What if I set some properties, start using the object, and then change some properties?
</div><div><br></div><div>I much, much prefer passing arguments to a constructor and knowing that when it returns to me I have an object in a sane state to use. That said, some of the C# objects have way to many overloaded constructors - named parameters no doubt help here, as would better adherence to the SRP.</div><div><br></div><div>The level of some of the programmers out there is scary - if it were the medical or legal profession, they'd be struck off - who'd want an 'opportunistic' doctor, who's measure of success was how quickly he could get through patients, with scant disregard to how many of them later end up at the mortuary...</div>
<div><div><br></div><div>Love the C example :)</div><div><br></div><div>-- </div>Steve. Strong<div>@srstrong</div><div><br>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
<p style="color: #A0A0A8;">On Thursday, 29 March 2012 at 09:32, Richard O'Keefe wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>I'm to the Psychology of Programming Interest Group mailing list.</div><div>In a discussion of naming, reference was made to a body of work</div><div>containing</div><div> Usability Implications of Requiring Parameters</div><div> in Objects' Constructors</div><div> by Jeffrey Stylos of CMU</div><div> and Steven Clarke of Microsoft</div><div>at <a href="http://www.cs.cmu.edu/~NatProg/papers/Stylos2007CreateSetCall.pdf">http://www.cs.cmu.edu/~NatProg/papers/Stylos2007CreateSetCall.pdf</a></div><div><br></div><div>The abstract reads</div><div> The usability of APIs is increasingly important to programmer</div><div> productivity. Based on experience with usability studies of</div><div> specific APIs, techniques were explored for studying the usability</div><div> of design choices common to many APIs. A comparative study was</div><div> performed to assess how professional programmers use APIs with</div><div> required parameters in objects’ constructors as opposed to</div><div> parameterless “default” constructors. It was hypothesized that</div><div> required parameters would create more usable and self-documenting</div><div> APIs by guiding programmers toward the correct use of objects and</div><div> preventing errors. However, in the study, it was found that,</div><div> contrary to expectations, programmers strongly preferred and</div><div> were more effective with APIs that did not require constructor</div><div> parameters. Participants’ behavior was analyzed using the</div><div> cognitive dimensions framework, and revealing that required</div><div> constructor parameters interfere with common learning strategies,</div><div> causing undesirable premature commitment.</div><div><br></div><div>The study was done in 2005.</div><div>We're talking about the difference between</div><div><br></div><div> fs = new FileReader("foo/bar.txt", Sharing.NONE);</div><div> ln = fs.ReadLine();</div><div> ...</div><div><br></div><div>and</div><div><br></div><div> fs = new FileReader();</div><div> fs.SetFileName("foo/bar.txt");</div><div> fs.SetSharing(Sharing.NONE);</div><div> ln = fs.ReadLine();</div><div> ...</div><div><br></div><div>I think this is worth bringing up here because if functional programming</div><div>is about anything at all, it's certainly about NOT setting up a value one</div><div>field at a time!</div><div><br></div><div>Their sample was carefully chosen to include three kinds of programmers:</div><div><br></div><div> * OPPORTUNISITC programmers are more concerned with productivity</div><div> than control or understanding. For these programmers objects</div><div> that required constructor parameters were unfamiliar and</div><div> unexpected, and even after repeated exposure these programmers</div><div> had difficulty with these objects.</div><div><br></div><div> That is, they just didn't "get" the idea of constructors having</div><div> parameters.</div><div><br></div><div> * PRAGMATIC programmers balance productivity with control and</div><div> understanding. These programmers also did not expect objects</div><div> with required constructors, and while pragmatic programmers</div><div> were more effective than opportunistic programmers at using</div><div> these objects, the objects still provided a minor stumbling</div><div> block and these programmers preferred the flexibility offered</div><div> by objects that used the create-set-call pattern.</div><div><br></div><div> Remember, this was all about .NET. Failing to expect</div><div> constructors with parameters in C# is like failing to expect</div><div> assignment statements in C.</div><div><br></div><div> * SYSTEMATIC programmers program defensively and these are the</div><div> programmers for whom low-level APIs are targeted. These programmers</div><div> were effective at using all of the objects; however, they preferred</div><div> create-set-call because of the finer granularity of control it</div><div> offered by allowing objects to be initialized one piece at a time.</div><div><br></div><div>The purpose of the study was to provide guidelines for API designers at</div><div>Microsoft: apparently they now recommend create-set-call. Remember,</div><div>that's the idea where you create an object without saying *anything* about</div><div>what you want it to be and then successively kick it into shape.</div><div><br></div><div>They later say</div><div><br></div><div> [Systematic programmers] want not just to get their code working,</div><div> but to understand why it works, what assumptions it makes</div><div> and when it might fail. They are rare, and prefer languages that</div><div> give them the most detailed control such as C++, C and assembly.</div><div><br></div><div>I'd like to think of myself as a systematic programmer. I certainly like</div><div>to understand all those things. But if I preferred assembly I would not</div><div>be writing in the Erlang mailing list! The basic conclusion seems to be</div><div>that you should not design APIs for such rare animals.</div><div><br></div><div>I made what I thought were three obvious points:</div><div><br></div><div>(1) There is a confounding factor in the study: the create-set-call style</div><div> lets you *name* the information going into an object, while at that</div><div> time the full-initialisation style did not. There are constructors</div><div> for System.IO.FileStream with six arguments; maybe more. It seemed at</div><div> least *possible* that if the subjects had been given a third choice,</div><div> constructors with *named* parameters, they might have preferred that.</div><div> Because the study didn't include such a choice, we certainly cannot</div><div> use it to argue *against* that style.</div><div><br></div><div>(2) C# 4.0 has named (and optional) parameters, so the study is no longer</div><div> adequate to tell us about good API design in C#.</div><div><br></div><div>(3) If there are programmers out there who *don't* care much about</div><div> understanding what they are doing, I certainly don't want them writing</div><div> anything that might in any way affect me or anyone I care about.</div><div> If they just don't "get" constructors with parameters, that's really</div><div> scary.</div><div><br></div><div>A lengthy discussion has followed in which I've felt rather lonely.</div><div>I'm being beaten about the head for not noticing things in the study</div><div>that I did notice, and for being rather elitist. One quote:</div><div><br></div><div> We don’t have the luxury of dismissing these types of programmers.</div><div> While it might strike you with terror that these programmers exist, </div><div><br></div><div>It doesn't frighten me that they _exist_,</div><div>it frightens me that they are _programming_.</div><div><br></div><div> they are successfully building applications in many different domains.</div><div> They may work differently to you and many other programmers but that</div><div> doesn’t necessarily mean that the code they create is worthless.</div><div> Within the Visual Studio team at Microsoft we’ve devoted efforts to</div><div> attempting to make them successful by adapting to their workstyles</div><div> when appropriate.</div><div><br></div><div>I find myself wondering just how "successful" their applications really are.</div><div>Oh no! I hope they're not writing climate modelling code! That would</div><div>explain so much... (Yes, I've looked at the code in the ClimateGate dump.)</div><div><br></div><div>Frankly, I've turned here for a bit of comfort. If anyone likes completely</div><div>initialising things rather than smacking one field at a time, surely I will</div><div>find such people here.</div><div><br></div><div>Am I wrong? Would *you* be happy opening a file in C by doing</div><div><br></div><div> FILE *f = malloc(sizeof f);</div><div> set_title(f, "foo/bar.txt");</div><div> set_access(f, "r");</div><div> gets(f, buffer);</div><div><br></div><div><br></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>