std.string and std.algorithm: what to do?

[Daniel Keep]

Michiel Helvensteijn wrote:
> Daniel Keep wrote:
> 
>> http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx
> 
> Heh, that's a funny story. I didn't know that one. (I do think the sensible
> developer was a bit of a killjoy, though.)
> 
> But how about coming up with some actual arguments here? What are the
> `gloves' in this situation? Don't say `modules' without explaining how they
> offer the same advantages as tags.

You're proposing taking a simple, easy to understand module system and
replacing it with a poor version of Google.  Your idea requires that all
modules be registered with the compiler somehow since there's now no
correlation between module and file.

Then you go on to suggest that you could use the filesystem, something
which is blatantly not possible: WinXP doesn't support symbolic links.
And this still means you can't simply drop a folder with source files
into a project: you've got to screw around setting up symbolic links.

Even then, what exactly does this get you?  The ability to say:

import std & string;

Now you have absolutely NO idea what you've just imported.  You can't
possibly look it up because anything could silently be included in that.
 And what happens when two libraries define two conflicting symbols?
Now you've got to have some sort of disambiguation system.

The tag system is the complicator's gloves: you're solving a problem
which already has a simple working solution with the most complex system
possible for no discernible benefit.

Tags are great for when you have only a vague idea of what you're
looking for.  This might be pretty useful for searching docs, but it's
completely unsuitable for actual code: you have to know what a function
is called and what its arguments are before you call it.  In order to
find that out, you look up its documentation which ALSO tells you what
module its in.

And once you know what module a function's in, the tag system becomes
completely superfluous and counter-productive.

> I can imagine a similar discussion having taken place when someone
> thought of higher-level control-flow constructs (you know, `if' and
> `while'). I imagine most people were perfectly happy with goto's and
> conditional jumps.

You must be joking.  Unstructured programming was a complete mess.
You're actually proposing taking a structured system and replacing it
with an unstructured one... the complete opposite of the introduction of
flow control structures.

  -- Daniel