== Quote from Roman Ivanov ([email protected])'s article > retard Wrote: > > 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(); > > } > One of the important factors in API quality is feature discoverability. That > is, the amount of time you need to find a sane way to do something, provided that you know the language. Java has very low discoverability. The code above is extremely unintuitive, because the abstractions you are required to use have nothing to do with the task at hand. FileReader? BufferedReader?
Right, very well said. Bringing this discussion full circle to where it started, IMHO very fine grained modules hurt discoverability. In D, namespace pollution isn't a major problem because hijacking can't happen. If you know everything related to file I/O is in one module (basic functionality common to all forms of I/O can just be publicly imported and the important stuff demonstrated in the example docs), it's a lot easier to browse through the docs for that module and understand the API's concept of file I/O than if the logic is spread across a zillion files w/o any obvious relationship between them. This was my main gripe against Tango. Once you figure out what modules you needs, it's pretty easy. The problem is that there are an overwhelming number of I/O modules, each of which, by itself, does practically nothing. Of course Java is even worse because iterating over the lines of a text file isn't even consistent with Java's standard way of iterating over other stuff (it doesn't use iterators), so it's much more non-discoverable.
