Phobos packages a bit confusing

[dsimcha]

== Quote from retard (re at tard.com.invalid)'s article
> Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
> > article
> >> Walter and I discussed quite a few times the possibility of defining
> >> std.all that publically imports all of std. My experiments show that a
> >> short script importing std.all will compile slower, but not too slow,
> >> compared to a script that only import a few modules.
> >
> > Vote++.  This would be a nice little convenience when writing small
> > scripts in D, which I actually do quite often because I already know
> > where basic APIs like file I/O are in Phobos and I don't want to learn
> > another API just for small scripts. This goes along with the scaling
> > down thing I was talking about a few days ago.  A well-designed language
> > and library should be good for both big projects (making complicated
> > things possible) and small projects (making things simple).  std.all
> > would be a trivial addition that wouldn't clash with anything else and
> > would really help Phobos scale down better.
> When writing small scripts, I use bpython:
> http://www.bpython-interpreter.org/screenshots/
> Nicely integrated apidocs.

Yeah, I like Python, especially for things where I need tons of libraries that
have simple APIs and are just there, or where I really need a dynamic language and
even D templates aren't a good substitute.  I do most of my coding in D, with
Python as my second language for when D is just the wrong tool for the job.  However,

1.  I'm more used to D and it's almost as easy to use as Python.  Therefore I tend
to use D more for the "grab the quickest thing available and get it working" kind
of programming.

2.  I sometimes need to write tiny but fast programs, such as simple monte carlo
simulations that I want to be able to tweak and run with as little thumb twiddling
in between as possible, or utility programs that do some specific operation to a
large amount of data.  Since D's build times are negligible for these programs and
D code runs much faster than Python, D is the better tool here.

3.  I've built up a whole bunch of custom libraries in D that I like (the
better/more universally useful ones I've released under various projects, the more
quick and dirty or niche ones I haven't) and I want access to them even in very
small scripts.