<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 6, 2016 at 11:32 AM, Garrett Smith <span dir="ltr"><<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div dir="ltr">On Sat, Mar 5, 2016 at 10:04 PM Robert Virding <<a href="mailto:rvirding@gmail.com" target="_blank">rvirding@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>One definite benefit in having to explicitly write every callback even if it is doing "default" stuff is that everything *IS* then explicit and you can directly SEE what happens. And come on, writing a 2 line default case for a few callbacks is really not that much to extra code.<br><br></div>A major problem with having implicit "default" cases is that what people consider to be a reasonable default handling varies depending on what just that server is doing. There is no default that suits every server so I will probably have to write it out and anyway.<br><br></div>Hiding callbacks behind defaults also means that you don't SEE everything that is there. This can be a major problem for newcomers.</div></div></blockquote><div><br></div></span><div>A counter point to this is that by deferring increasingly complex cases by providing sensible defaults, a user can more quickly and correctly understand an API. A useful abstraction has a story line - and I think the simpler the better. Requiring the user to accommodate increasingly edge cases undermines the main story line.</div><div><br></div><div>E.g. I like the pattern in Erlang functions that follows the getopt Tao of required params + options. Let me get to the gist of an operation with the fewest possible inputs and I can incrementally grow into the more complex cases.</div><div><br></div><div>I think this is less about typing and more about clarity of intent. <br></div><div><br></div><div>The challenge to getting this right is drawing that line between the essential interface and the incremental enhancements. Libraries fail when they outright hide important details and leave the user mystified with seemingly magical behavior.</div><div><br></div></div></div>
</blockquote></div><br>Again, apologies--couldn't get away to respond till now:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1.) There's no question that explicit is better than implicit Robert. But on the other hand, if most of the explicit is going to be boilerplate code then it should be hidden by default. I don't know your experience but in mine I've met very few developers who bother to investigate compiler warnings. And I mean _default_ compiler warnings. This is because most of them say "Well it compiles so it's ok right?" Boilerplate code can encourage that tendency too--I simply copy/paste the boilerplate from another codebase and I don't worry about what it does. So, in that case I think it's ok to make an exception to the general rule that explicit is better than implicit. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Explicit is better than implicit because it forces someone to actually _think_. Lots of boilerplate has the opposite effect wouldn't you agree?</div><div class="gmail_extra"><br></div><div class="gmail_extra">2.) As I said in my original response, macros strike me as a very powerful tool but quite dangerous in the hands of a noob developer. I almost wish there were a way to disable macros from the compiler level on a setting that could be hidden from new developers. Yes they're extremely powerful (and yes I agree that LFE is even more powerful) but like so many other powerful mechanisms they're also really dangerous in the hands of the inexperienced. Or even those that learn only part of the story but don't get all of it. As Pope said "a little knowledge is a dangerous thing." </div><div class="gmail_extra"><br></div><div class="gmail_extra">3.) I agree with Garrett. Language defaults are a lot more important than many developers seem to realize. Every since I started developing code I was always told to slap a const on immutable data and to pass arguments by value as much as it could be managed. This prevented accidental changes. Yet in all my experience of writing C and C++ I almost never saw people using #defaines for constants--let alone putting const modifiers on things or trying to figure out how to pass by value rather than pass by reference. </div><div class="gmail_extra"><br></div><div class="gmail_extra">This is part of the reason I think that FP is the future. The default in FP is immutable. The default is the good choice not the bad one. And that's also part of my point about boilerplate code versus macros. If the default on the code that needs to be supplied is relatively intelligent macros then it's one less thing for the developer to worry with--and most developers won't spend time fighting language defaults. </div><div class="gmail_extra"><br></div><div class="gmail_extra">This is part of what has always impressed me about Erlang too. The default is no shared memory. We all know that's a heck of a lot more scalable than what a lot of developers do with shared memory. An intelligent default is a great aid to productivity. </div><div class="gmail_extra"><br></div><div class="gmail_extra">--</div><div class="gmail_extra">Onorio</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Onorio Catenacci<br> <br><a href="http://onor.io" target="_blank">http://onor.io</a><div><a href="http://www.google.com/+OnorioCatenacci" target="_blank">http://www.google.com/+OnorioCatenacci</a><br><div><br></div></div></div></div>
</div></div>