I think the poster's point 1 is really the key here. In addition, I think Intellisense-driven programming has a lot to do with it. I suspect a lot of .NET programming goes like this (I know I've been guilty of this)<p>1) Hmm, let's see what classes are in this namespace... Ah, this one looks like it might do the job so I'll type<p><pre><code> var foo = new ThingWithInterestingName();
</code></pre>
2) Dang, don't want to scroll through tooltips for 23 different constructors with poorly named params, think I'll just use the default constructor, they probably implemented that for casual users like me.<p>3) Now I can type foo. and let IntelliSense give me options. When I call a function I get an error for each call instead of some crazy exception for the whole thing. Maybe I can even test stuff out in the Immediate window in the debugger.<p>So, I think it's not only miseducation or layzness, it's that modern IDEs for static languages encourage discovery based development in favor of reading through API documents.
It's convenient that the poster initialized the relevant flame war this will degenerate into right in his post there. A discussion about the best way to structure APIs is surely not complete without flaming people about being elitist and that opportunistic programmers exist, and more flames about the fact that since they are producing lots of real world programs you should just shut up about them. I appreciate the guidance. I might have accidentally started flaming about event-based programming or the utility of NULL pointers instead, you know, and that would just be <i>gauche</i>.
Richard O'Keefe has deep knowledge of computer science and software engineering, and his posts to erlang-questions, where you'll often encounter Erlang, Prolog, LISP, Java, and C neatly woven into the same message, are almost always enlightening.
Reading this, I though to myself that one of the biggest features I like in python that is missing in java is named and optional parameters.<p>Also, any api/library that lets you create an object that is unusable because specific methods to set up values haven't been called yet is very error prone.
Needlessly condescending and not so bright himself for it.<p>For example he didn't understand what the three categories of programmers were meant to be (tendencies between good programmers working at MS -- hence, even those deemed "opportunistic" are not some clueless idiots worthy for the Daily WTF).<p>Second, there are a few cases to be made for the second style (even over named parameters).<p>One is less clutter at the constructor level.<p>A second is easier reflection/dependency injection.<p>A third is it forces saner defaults.<p>Also, better readability for some (which is not all about cramming as many lines in the same editor screen).<p>It also makes parameters independent of ordering -- which in the compiler they are, but in a constructor they are not (except with named parameters, and even those have to come AFTER non named ones).<p>The only real downsides are: a) the possibility of using a half-baked object. But I don't see how that would be any different than omitting some of the named params. b) third parties mutating the objects. But then you have the same "issue" in most dynamic languages anyway.<p>(The off topic jab against "climate change" at the end was also pathetic -- apparently he's one of the climate change deniers, despite overwhelming acceptance of the notion from the scientific community, putting them on par with Creationists).
I like readable code, he didn't mention readability. The only thing I really care about in code is that it is readable and doesn't stretch all in one line and not broken up. Small chunks are better than a ninja one liner.<p>Constructor arguments/params are fine as long as the code is readable and line breaks to keep it within a decent column size. I also think that constructor arguments can sometimes get into overload messes just as method calls can. A good api breaks up any overly parameterized constructor or methods.<p>I just want code to be readable, fit within a decent column area and make sense. Whether it is in constructor params or method params there shouldn't be too much done in one line for complexity sake.<p>If programmers don't get constructor params then they probably don't get method params either. I think people just want stepped-readable code in most cases. Named and optional params help to clear up long initialization or method calls but in the end it is about balance and readability.<p>Smaller, iterative code bits are easier to put a breakpoint on as well say for instance one param was null and it broke on constructor, it might take some more inspection to find unless it was a specific set.
FYI this was posted in Erlang's mailing list. There was a following discussion about it if anyone is interested.<p><a href="http://erlang.org/pipermail/erlang-questions/2012-March/thread.html#65519" rel="nofollow">http://erlang.org/pipermail/erlang-questions/2012-March/thre...</a>
From a purely technical point of view, doing this is a terrible idea as it adds additional, unnecessary state to objects, and hence makes it possible for them to break in more ways.<p>Using the Builder pattern, or keyword arguments, achieves the intended goal of making API features discoverable without the added complexity.