Phobos packages a bit confusing

[dsimcha]

== 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.