== Quote from retard ([email protected])'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.
