Tim Bray fixed a performance problem by correcting the IO buffering, which gave him a "Radical New Language Idea:" "How about a radical new language where the runtime system is hyperaggressive about ensuring that all of its I/O primitives are by default buffered unless the programmer specifically requests otherwise?"
- Posted by: Joseph Ottinger
- Posted on: September 14 2005 08:52 EDT
With a certain sense of deja vu, he follows that question with a possible answer: "I've heard that there's something called "COBOL" that has this capability, I'll have to check it out."
Back when I was coding in COBOL on Burroughs Medium Systems computers (1971-1972 or so), there was a declaration of the number of buffers in the FD (file description) of the FILE SECTION of the DATA DIVISION (as I remember). I think that the declaration could be overridden by control instructions at execution time, but I'm not certain of that (definitely true on Burroughs's Large Systems/A-Series computers).
In any case, I do not see this as a language feature, but a runtime environment feature. It is somewhat unfortunate that the Java I/O libary has different objects to support buffering - overkill in my estimation as well as confusing. Buffering as the default in the runtime environment would definitely be a plus.
Java is still a distant player in the field of operating system events. It requires some ground work to come closer to this target.
For example, it would be nice to have a java class - IOEventCollector that would represent a unified mechanism for multiple OS.
Working with "inotify" in Linux and similar things in other systems, such mechanism could detect creation and changes of files as well as other IO events without polling directories.
Certainly not a "language" idea. Hardwiring IO into a computer language has more or less been dumped after COBOL, FORTRAN and PL/I. PHP is a "modern" exception, but I don't consider it exemplary as a language.
As for doing it at the library level: I'm in favor but worried about the impact on existing coding. I hasten to agree that Java's IO library, while well structured and orthogonal in an academic, OO sort of way, is horribly complicated to use (simple things are made hard to do) while being technically incomplete (select(), mapped files, binary data).
The "technically incomplete" deficiency was (mostly) addressed by the java.nio package in a way that did not disturb the "historic" structure, but the way it was tacked on now looks like a horrible kludge. It's hard to explain to students why the Java IO system is spread out over two disjoint packages like this. Adding support for IO that is buffered by default would probably look similar. I couldn't blame the JCP for being reluctant to do this.
I think that two things are more likely to happen: (1) Newer languages/libraries such as the .NET family will learn (or already have) from the Java debacle, and start off with a more useful IO implementation. (2) Java beginners will be taught (or learn on their own) to keep buffering in mind when coding IO in Java.