<p>I hope that is a joke. I inhaled 1200 page manuals like popcorn when I was a student 20 years ago, and still do to this day. I *hope* that being lazy is their only problem. Yeesh...</p>
<div class="gmail_quote">On Jul 10, 2011 7:33 PM, "Richard O'Keefe" <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:<br type="attribution">> <br>> On 9/07/2011, at 2:44 AM, Ulf Wiger wrote:<br>
>> Having said this, I invite anyone who goes through that kind of exercise to share their results. Not only will it help you evaluate the experiment honestly; it will increase the store of experiments that can be copied and tailored to the specific challenges of the next project.<br>
> <br>> I had an unpleasant experimental experience of my own last year.<br>> Let me first give you the lesson I learned, and then the background.<br>> <br>> LESSON: Expect your experiment to surprise you,<br>
> probably by showing the experiment was a waste of time.<br>> <br>> Background: I'm sick of arguments about style. To my mind, it is so<br>> obvious that baStudlyCaps isAVeryStupidWayToWriteIndeed and I<br>
> cannotUnderstandWhyOtherPeopleDoNotSeeThat. But they don't. My zeroth,<br>> the New Zealand Anglican Church has even brought out an electronic<br>> version of the liturgy called WePray, in a desperate attempt to seem<br>
> hip. (Since it is only available for an operating system sold by what<br>> may be the largest software company to have been convicted to software<br>> piracy, I wonder what their ethics committee were doing. But I digress.)<br>
> <br>> So I devised a little language called Chatterton<br>> (<a href="http://www.cs.otago.ac.nz/cosc345/chatterton.pdf">http://www.cs.otago.ac.nz/cosc345/chatterton.pdf</a>),<br>> which allowed me to mechanically produce several style variants of<br>
> some sample programs and ask some 3rd year software engineering students<br>> to find some mistakes in them.<br>> <br>> What I expected was one of three things:<br>> - no measurable effect<br>> - more readable code (i.e., NOT baStudlyCaps) being easier to fix<br>
> - more familiar (i.e., JustLikeXingJava) being easier to fix.<br>> <br>> What I *got* was students telling me they couldn't read code on<br>> paper; they needed syntax-colouring IDEs (the listings all fitted<br>
> on a single sheet of paper and used black-and-white styling) and<br>> ideally a debugger so they could find mistakes by stepping through<br>> the code. I also got students telling me that it was horribly<br>> unreasonable of me to expect them to read a 30-page manual; NOBODY<br>
> could read that much. And finding a definition of an identifier<br>> in a 2-page listing is just beyond human capacity; it's impossible<br>> to do that without the machine assistance of an IDE.<br>> <br>
> So the whole experiment produced no worthwhile data for reasons having<br>> nothing to do with what I thought I was testing.<br>> <br>> As other people have been saying, the "Erlang web servers challenge"<br>
> is at serious risk of producing no worthwhile data.<br>> <br>> <br>> <br>> _______________________________________________<br>> erlang-questions mailing list<br>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div>