Phobos packages a bit confusing

[dsimcha]

== Quote from dsimcha (dsimcha at yahoo.com)'s article
> == Quote from retard (re at tard.com.invalid)'s article
> > Mon, 30 Nov 2009 21:06:21 +0800, KennyTM~ wrote:
> > > On Nov 30, 09 19:01, Ary Borenszweig wrote:
> > >> KennyTM~ wrote:
> > >>>>> By
> > >>>>> far the two most important pieces of I/O functionality I need are:
> > >>>>>
> > >>>>> 1. Read a text file line-by-line.
> > >>>>
> > >>>> foreach (line; new Lines!(char) (new File ("foobar.txt"))) Cout
> > >>>> (line).newline;
> > >>>> }
> > >>>>
> > >>>>
> > >>> yuck.
> > >>
> > >> Yuck?? I find that code very elegant. How would you like it to be?
> > >
> > > Python do it like this:
> > >
> > > for line in open("foobar.txt"):
> > >    print(line)
> > >
> > > How many things you need to explain for that elegant code? Line? File?
> > > Cout? .newline?
> > Your argumentation is getting ridiculous. Reading and printing lines of a
> > text file isn't by any means a good measure of standard library quality.
> > I could define something like
> >   void printFileLines(string fn) { ... }
> > in my code and use it like this:
> >   printFileLines("foobar.txt");
> > When I'm programming with a systems programming language, I really do
> > want to know if it reads the whole 100 GB file into memory before
> > iterating or if not, what kind of buffer it is using. I often also need
> > to work with endianess issues, codepage conversions, file system
> > exceptions etc. If I only need to write simple code (== programming in
> > the small) I might want to use some scripting language instead.
> > It's really hard to please both audiences without cluttering the stdlib
> > api.
> Right, but I do scientific work.  I've never written a polished app that's
> designed to be used by non-programmers or to be internationalized, where caring
> about things like unicode is important.  Most of my programming is very
> algorithm-centric and CPU-bound.  Anything I/O is generally regarded as just a
> means of getting data in to process it with your algorithms.  The algorithms are
> where I want to spend about 99% of my coding efforts, but I need a systems
> language here for performance reasons.  For I/O I just want the quickest, simplest
> thing available.  If the character set supports A, C, T, G, and U (the five
> characters of DNA and RNA), it's good enough for me.
> I'm sure other niches have similar things:  Dead simple requirements in one
> dimension, but need for a full-fledged systems language to fulfill requirements in
> another dimension.  For example, I work with huge datasets and need to tune memory
> management pretty frequently.  Someone writing business software might care more
> about unicode and "proper" I/O than I do, but probably wouldn't care at all about
> the ability to tune memory management.  Maybe their need for a systems language is
> because they want native binaries or an easy way to interface with C code.

I guess the idea here is that the beauty of D2/Phobos is that it's a systems
programming language/lib, but one that only makes you care that it's a systems
programming language for the parts of your code where you really need the power of
a systems language.  For the parts of your code where that power is overkill, you
can seamlessly shift into a more scripting language style of programming, without
any messy glue layers, inter-language interfaces, etc. getting in the way.