Dumbing down is dumb

Implicit Interfaces

ImplicitInterfaceImplementation - from Martin Fowler is an interesting piece where Martin suggests that it would be useful to be able to provide alternative implementations of a class’s implicit interface. That is, given a class that does not inherit from an interface, it’s sometimes useful to be able to split the class into an implicit interface, the public operations that it provides, and treat that as if it were explicitly declared as an interface from which the class derives.

If you enjoyed the Petzold thing earlier...

This may also be your kinda thing. Ellen Ullman’s 1998 two part series “The Dumbing-Down of Programming” from Salon archives. Rebelling against Microsoft, “My Computer” and easy-to-use Wizards, an engineer rediscovers the joys of difficult computing. Returning to the Source. Once knowledge disappears into code, how do we retrieve it? Via Joey deVilla over at The Farm. I’d forgotten how readable Ellen Ullman was (especially for techies of “a certain age”).

Sacrificing precision for ease of use?

I’m probably jumping the gun a little here as I can’t find Herb Sutter’s slides that Matt Pietrek is referring to, but… Once again I find myself asking why is it actually useful to repurpose the auto keyword in C++… The idea seems to be that rather than this: foo::iterator<int> i = myList.begin();</int> You can do this: // Type of 'i is inferred from the assignment auto i = myList.begin(); I really don’t get what’s with these “productivity” enhancements that allow people to think less whilst coding.

C# v3 Extension methods, syntactic sugar for the lack of free functions?

There’s a lot of noise coming out of the Microsoft PDC right now. Something that interested me was the future direction of C#; you can grab the spec from here. It seems they’re adding “extension methods” which, to me, appear to be just syntactic sugar to make up for the lack of free functions… In C++ you can have functions that aren’t part of an object. In C no functions are part of an object.

Some thoughts on complexity

I find that these days I prefer my complexity to be obvious. Things with hidden complexity aren’t any less complex, they’re just less obvious. If you make all of your complexity obvious then you know which pieces of code are complex and you can focus your attempts at simplification on the right places… Some of this comes from the testing that I’ve been doing; liberal use of parameterize from above means that an object that uses several services is explicitly given those services when you create it.