[prev] [thread] [next] [lurker] [Date index for 2005/04/09]
> There were libraries for I/O long before there was a standard library. Yeh, and if you'd used the v6 libc you'd know why it was a good idea that they didn't rush out and define I/O for C. To do the equivalent of sprintf you opened a pipe, printf-ed to it, and read it into a string. > K&R C had a "standard" I/O library back in 1978 which incorporated most of > the functionality various C compiler vendors had already bolted on. That's "-lS". I used it. Compiler "vendors"? No such thing in 1978. > People > needed I/O and would implement it themselves. Without a standard there > was a menagere of competing, incompatible I/O libraries and it took over a > decade to clean up the mess... Um, no, there wasn't. Unless you count Idris, but they only did it differently because they were trying to avoid stepping on AT&T's copyright on the UNIX progranmmer's manual. Back in the '70s there was only one C compiler, and it was described in the UNIX programmer's manual. The paucity of implementations was such that Ratfor was actually a viable alternative. > > and if C had started out with an I/O library typical of > > the '60s it would never have happened... and we'd all be worse off for it. > ...this is not to say it did not eventually all work out for the best. It worked out quite well all along. There were steady improvements all through the '70s. > However, that was then. I'm talking about languages written NOW where now > == the last ten years or so. And I'm saying that languages written NOW are running into a whole new iteration of the same mess that C was faced with. The mess of I/O standards, now including window systems and toolkits, is exactly the same kind of mess that I/O was in in the '60s. > > > In fact, > > > I've listed "trivializing I/O" as one of the "language design regrets". > > It's not "trivialising I/O", it's "avoiding premature standardization", and > > it's one of C's strengths... not a weakness. > Like I said, C is the exception. Its just one step above the metal. The metal has moved. > Its the sort of language you DO write I/O drivers in. I might throw > something like Forth into that pile. Javascript or Lua do not go in there. Javascript is the Forth of this decade. It operates in environments where there is no C-like I/O Putting C I/O into Javascript is about as important as putting Fortran I/O into C would have been. > They are modern, high level languages designed to be run in environments > where I/O has already been taken care of for them... probably in C. Yeh, and they're run in environments where C I/O is inappropriate. > Additionally, C was written in 1972. Back then they were still figuring the > basics out. Its 2005 now. And we're still figuring the basics out. > We've learned a few things about I/O in the last > THIRTY YEARS. Here in the year 2005 we have a pretty good idea about how > I/O should work (in part because of the pain C went through). And how should I/O in a web browser work? How should I/O in a GUI work? How about sockets? You can't write() to a socket in Windows. > At least > enough to know to ignore it at our peril. Java is going through its own > I/O pain right now as we watch because they abstracted it into oblivion. Java is fucked in so many ways that even if they'd standardised on stdio they'd still be in pain. > C is the exception. Its old. Its very low level. Using it as a guideline > for a modern, high level language will only lead to regret. That's why I'm suggesting that it's a bad idea to try and treat the I/O objects that a GUI, web, or database environment has to operate on using C as a model.There's stuff above here
Generated at 12:00 on 12 Apr 2005 by mariachi 0.52