The Old New Thing

WTF? "generating a stream from a URL takes an awful lot of code"??

MkParseDisplayName2, IMoniker::BindToStorage anyone??? WTF??? Does no-one program in C++ anymore?? With smart pointers its 3 lines!!!

WTFBGFHHTIBT is the matter with you people?

Ben,

Yes, it takes a lot of code.  Raymond doesn't use class libraries to keep things relevant for us non-C++ programmers, so smart pointers aren't available.

The Old New Thing: Why don't I use any class libraries in my sample code?

http://blogs.msdn.com/oldnewthing/archive/2007/02/16/1689217.aspx

I agree it is alot of code to create an IStream on a URL. You have to go out and call URLOpenBlockingStream, really you should check the return code (not that any check is made in the example) and you also need to make sure urlmon.lib is linked (well you already needed shlwapi). Maybe approximately _no_ extra code. Just saying is all ;)

Or alternatively Raymond could do something simple and familiar to 99% of developers, with the point being to illustrate drag/drop.

I don't particularly care how much code it might take him to *illustrate* something to everybody - if you're going to implement it, you have the benefit of using libraries and not needing to explain a concept to a wide variety of people with different experience. As such, it won't take *you* any more code.

Apart from the arguments in the linked article.. there are so many programmers out there who just rely on their libraries and have no idea what they're doing.

Imho it's horrifying if you think that there are programmers out there who wouldn't be able to do something as simple as to write a LinkedList class, or implement a quick sort or binary search algorithm.

And that's the easy stuff.. how many people who generate streams from a URL know what their library is doing? (No I'm not saying that you have to implement everything on your own, it's fine to use class libraries, but you should UNDERSTAND what's going on.. at least on a high enough abstraction layer)

Take a load of programmers with limited knowledge, a short time frame, black box class libraries, virtual machines and fast developer machines.

Now wonder why we have bloated code that performs poorly on average machines.

@porter: Yeah, but it gets out of the door fast. And that's what pays the bills. Getting customers to accept that they need to buy beefier hardware is a walk in the park compared to getting them to accept that they have to wait longer because you're making sure it runs well on the average machine. Buying beefier hardware is seen as spending money; waiting for optimization is seen as losing money. The economics make sense, even if the aesthetics don't.

You should be able to tell what a method does by reading it's name. Docs should specify additional details. You should NOT be forced to read the actual code to understand what a method/library does. If a programmer is forced to educate oneself of the inner of libribraries it's lousy coded to begin with and should not be used. Ever.

@640k: A lofty ideal, but for me that would mean I'd have to abandon quite a bit of the .NET base class library, for example, which I'm just not prepared to do. You can file that under "buggy/incomplete documentation", but "should not be used ever" is not a practical attitude. That's tantamount to saying that any library that isn't a perfect abstraction is worthless.

Sometimes you want to use the library in scenarios its authors couldn't completely document for, you get behavior you can't quite explain, and explaining it requires diving into the code. True, this should be the exception and not the rule, but the mere fact that you do it can't be an absolute disqualification.

>> If a programmer is forced to educate oneself of the inner of libribraries it's lousy coded to begin with and should not be used. Ever.

Wow, what an argument for encouraging the dumbing down of an industry.

How about the consequences of using a particular function? Consider a large database, you are basically pleading for moronic queries because programmers shouldn't have to understand the consequences of different query styles. Same applies to OO and procedural programming, there are good ways and bad ways of doing things, stuff you might only find in the documentation. Or perhaps you want an excuse not to have to write any documentation.

Well there's also another point.. if you just know how to call something and never look inside those black boxes you end up with sub par code. Oh and at least for me it's also no fun.

One thing I had to implement some time ago was a matrix multiplication for complex numbers - well I could've used a library for that, but these was written for real numbers and just opening the black box and implementing my own version got me runtime of 3n instead of 4n (not too hard to understand how I got that I assume..) which is a great improvement in a tight inner loop.

Or another thing: People who don't understand how regular expressions work/are implemented in their favorite language usally assume that that stuff is rather efficient, which usually isn't true.

That doesn't mean I never use REs, in fact they're a great tool (at least if you document them.. I'm horrible at decrypting that stuff), but you better know about their disadvantages

And it's not only about speed disadvantages, you can also introduce really bad bugs that way - just think about floating point math.

The reason why a developer shouldn't have to read all the underlying code in all layers down to the hardware is because he/she looses focus. And simply, it COSTS time.

That's why paradigms like RAD and Convention over configuration has become so popular.

A lofty ideal is to think developers have infinite time at their hands. They dont. It doesn't have anything to do with how smart or educated you are. Any new field which you dont have experience of, costs time which could have been spent on solving the actual problem.

Libraries, APIs and components which forces developers to dive in and study them in depth are unproductive, and expensive to use.