== Quote from dsimcha (dsim...@yahoo.com)'s article > == Quote from retard (r...@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.