>>>When given a choice to create that sort of abstraction between having one line of code that doesn't give me options to configure the functionality or 10 lines of code where I can get exactly what I need, which do you think is better?
>
>So why do so many Americans drive Automatic cars? Because they like encapsulation! And sometimes there are better things to worry about than clutching in and out of first gear in a traffic jam, even if you do a great job of it ;-)

That's why I don't drive an Automatic <g>...

Seriously though it's a matter of where the abstraction lies. If you put the abstraction in the product you often loose the ability to finely control how you use the functionality. Sometimes that's Ok, other times it's not. .NET has opted for granularity, that why everything is an object rather than a function call which inevitably is 'less code' than object access...

My point here is that if the abstraction is not high enough for you, you can always add it yourself in your library with a few lines of code. That way youo write it once and re-use it everytime. Again, my example is dataaccess. I can't remember the last time I ran ADO.NET code to run a database query or update operation - my business layer does that. And that code is nearly identical to the Fox code I use in my Fox apps.

The argument of 'more code' is only true if you are coding at the language level for everything which for me at least is not option.