digitalmars.D - Re: Phobos packages a bit confusing
- Roman Ivanov <isroman km.ru> Nov 30 2009
- dsimcha <dsimcha yahoo.com> Nov 30 2009
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? Compare that with C#: string[] readText = File.ReadAllLines(path, Encoding.UTF8); Or PHP: $file = file_get_contents($path); Yes, the alternatives store the entire file in memory. That's perfectly fine for 95% of use cases. Good APIs provide several levels of abstraction. If 95% of the people don't care about the way a file is read, then a good API would provide a simple function that just works for those people. Nobody stops it from providing a low-level API with finer control as well.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.
I'd say most of the programmers learn new APIs all the time. If every one requires you to jump though hoops, you will end up with a significant and constant overhead.
Nov 30 2009
== Quote from Roman Ivanov (isroman km.ru)'s articleretard 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(); }
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.
Nov 30 2009