== Quote from Nick Sabalausky ([email protected])'s article
> "retard" <[email protected]> wrote in message
> news:[email protected]...
> > Hi
> >
> > after using D1 and Tango for couple of years we decided to experiment
> > with D2 and Phobos in a small scale project. For some reason the mostly
> > flat package hierarchy seemed rather confusing.
> >
> > For instance, it took two of us 15 minutes to build a program that reads
> > a line from user, converts the string to a natural number, adds one, and
> > finally prints it to the screen. Entities like 'stdin' seem to have no
> > documentation at all. What should I import to get it, what interfaces
> > does it implement etc.
> >
> I actually find that kind of ironic, because that's pretty much how I feel
> about tango's ultra-separation-mania. I use tango all the time and I still
> can't do a single IO operation without spending at least ten minutes hunting
> blindly through the docs and finally finding what I need (including the
> necessary documentation) is spread out across at least three different
> modules.

Yeah, I dislike Tango's (and Java's) I/O design.  I think it's a classic example
of overengineering.  I don't care how efficient, flexible, complete, etc. it is 
if
it doesn't "just work" for the simple stuff.  By far the two most important 
pieces
of I/O functionality I need are:

1.  Read a text file line-by-line.
2.  Read a whole file into an array of bytes.

These are common, simple I/O operations that just about everyone needs fairly
often.  It's ridiculous if I have to use three different modules or whatever it
takes to accomplish something so simple.

I'm convinced that this is one thing that turns a lot of people off to 
programming
if they get past the first hurdle of understanding variable assignment.  File 
I/O
is required for almost any program complicated enough to be worth writing.  
When a
beginner who doesn't necessarily even understand the concept of a class 
hierarchy
well sees a huge overengineered API for basic file I/O, he/she is bound to think
(wrongly) that programming is much harder than it really is and that he/she is
just inept at it.

Reply via email to