November 30, 2009
"retard" <re@tard.com.invalid> wrote in message news:heuh3h$o71$3@digitalmars.com...
> 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.


November 30, 2009
== Quote from Nick Sabalausky (a@a.a)'s article
> "retard" <re@tard.com.invalid> wrote in message news:heuh3h$o71$3@digitalmars.com...
> > 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.
November 30, 2009
== Quote from retard (re@tard.com.invalid)'s article
> 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.

While I agree that the docs for Phobos should be improved after the language stabilizes, I honestly don't think 15 minutes is too bad if you're completely unfamiliar with the API.  Using Java's file I/O API, for example, practically requires a Ph.D. in object-oriented design.  It's just a fact of life that every API has its quirks that take time to learn, and anything that's not what you're used to is going to seem quirky at first.
November 30, 2009
Mon, 30 Nov 2009 04:51:19 +0000, dsimcha wrote:

> == Quote from Nick Sabalausky (a@a.a)'s article
>> "retard" <re@tard.com.invalid> wrote in message news:heuh3h$o71$3@digitalmars.com...
>> > 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.

Are you sure you know what you're talking about?

> 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;
}

> 2.  Read a whole file into an array of bytes.

new File("foobar.bin").read()


Java isn't that bad IMO - you just have to remember the buffer:

BufferedReader input = new BufferedReader(new FileReader("foo"));
try {
  String line = null;

  while (( line = input.readLine()) != null) {
  }
}
finally {
  input.close();
}

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

Well, that's not the only problem a novice meets during the first minutes / hours with a new language. If you write e.g. console apps for win32, you need to teach them what code pages are, why do you need to convert between utf-8 and windows-1252 etc. since the default console i/o routines are not unicode aware under windows.
November 30, 2009
Mon, 30 Nov 2009 04:55:29 +0000, dsimcha wrote:

> == Quote from retard (re@tard.com.invalid)'s article
>> 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.
> 
> While I agree that the docs for Phobos should be improved after the language stabilizes, I honestly don't think 15 minutes is too bad if you're completely unfamiliar with the API.  Using Java's file I/O API, for example, practically requires a Ph.D. in object-oriented design. It's just a fact of life that every API has its quirks that take time to learn, and anything that's not what you're used to is going to seem quirky at first.

Well, they have been teaching the Java i/o stuff to first year students for a while now. I completely agree that it's a bit too complicated for novices, but it's not the only bad thing:

 public static void main(String[] args)
 { System.out.println("Hello world!"); }

Wtf. They used to learn Scheme:

 (print "Hello World")

I guess the PhD requirement is a bit exaggerating. Of course you do need to learn some basic concepts first. OTOH I know a handful of C programmers who just don't get why their (unbuffered) i/o routines always perform badly, and use libraries instead.
November 30, 2009
On Nov 30, 09 14:02, retard wrote:
> Mon, 30 Nov 2009 04:51:19 +0000, dsimcha wrote:
>
>> == Quote from Nick Sabalausky (a@a.a)'s article
>>> "retard"<re@tard.com.invalid>  wrote in message
>>> news:heuh3h$o71$3@digitalmars.com...
>>>> 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.
>
> Are you sure you know what you're talking about?
>
>> 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.

>> 2.  Read a whole file into an array of bytes.
>
> new File("foobar.bin").read()
>
>
> Java isn't that bad IMO - you just have to remember the buffer:
>
> BufferedReader input = new BufferedReader(new FileReader("foo"));
> try {
>    String line = null;
>
>    while (( line = input.readLine()) != null) {
>    }
> }
> finally {
>    input.close();
> }
>

yuck yuck yuck.

>>
>> 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.
>
> Well, that's not the only problem a novice meets during the first
> minutes / hours with a new language. If you write e.g. console apps for
> win32, you need to teach them what code pages are, why do you need to
> convert between utf-8 and windows-1252 etc. since the default console i/o
> routines are not unicode aware under windows.

November 30, 2009
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?
November 30, 2009
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?


I wouldn't go as far as saying "yuck" to the above, but I like the Phobos way better:

  foreach (line; File("foobar.txt").byLine)
  {
     ...
  }

-Lars
November 30, 2009
Mon, 30 Nov 2009 12:01:22 +0100, 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?

I guess something like this:

JustDoItWith("foobar.txt") {
  ...
}
November 30, 2009
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?