Gustavo Rios wrote: > Hey folks, > > sorry, but i found this on the web. May someone tell if it is serious, > i myself could not believe it. > > http://www.informit.com/articles/article.asp?p=424451&seqNum=1
The author is taking themselves seriously. I don't recommend you make the same mistake. 1) Everything Is a File (Unless It Isn't) yeah, so? The better solution would be to make somethings a file and somethings not? Hows' that different? Or maybe the Plan 9 option which is supposedly super-consistent, but lacking applications and usage in real life. 2) Everything Is Text I've worked on systems where some files are fixed records, others are binary, some are text...thank you, I like the Unix approach. 3) No Introspection Har. MacOS as an example of what he wants? Gee, isn't Apple DROPPING that "feature" on OSX? While it is great if you happen to be interested in only talking to other Macs, it's a major irritant if you can't get the ENTIRE REST OF THE WORLD to agree with you on how its done, and that WILL NOT happen. 4) X11: Almost a GUI a very weak, but almost valid point here. I first saw this comment about X almost 20 years ago. X11 is kinda clunky in some regards, but not so clunky that people have decided as a group on a good alternative. Propose an alternative, port it to a lot of platforms, port a lot of software to it, and then we will talk. Until then, enjoy X. 5) Standard Input, Standard Output Without an alternative stated, this is complete bull. Don't like STDIO? Don't use it. Isn't appropriate for your app? Don't use it. Sheesh. 6) Synchronous System Calls *yawn* Hm. If QNX is so much more efficient, why is Unix used on most supercomputers now? Obviously, the "issue" isn't big enough to cause people to jump favorite OSs. 7) One-Way System Calls Yes, this is clearly why there are so few applications written in Unix. *snicker* 8) C: Cross-Platform PDP Assembler ok, this argument kills all credibility for the whiner..er..author in my eyes. C became the language of choice for because it WORKS and works well for its intended purpose. It was developed by people who used it for their own use. It was chosen by others because it worked for them. Yes, it was developed IN a Huge Company, but it was not pushed by them. Contrast that to a popular language right now which is being crammed down the corporate world's throat. I really suspect that ten years after Sun Microsystems vanishes or quits pushing Java, Java will vanish like scores of other proprietary languages, and C will still be actively used. ok, I may be a bit biased here. I love C. I fell in love with it almost from the first article I read about it (Byte Magazine, early 1980s), and loved it when I first started programming in it (Software Toolworks C on CP/M-80, later BDS C, also on CP/M-80. BDS C could produce "hello world" in a COMPLETELY self-contained 2k binary). The "White Book" was the ultimate programming language definition guide -- very complete, and very readable, and very slim. You could feel the bits and bytes flowing by in your programs. Everything was an integer -- pointers were integers, strings were integers, and even floating point was just a bunch of bytes(=integers) you handled carefully. Yeah, obviously, it had some serious problems -- the "portable assembly language" idea just doesn't work out for anything other than the most basic of programs, so layers of abstraction were added in ANSI C. The whole "C doesn't do strings" has always been complete Bull Sh*t in my mind. C does strings like the processor underneath does -- it doesn't make complex operations involving moving thousands of bytes look "simple". While I do use Perl for some apps, the stuff it lets you get away with in one line creeps me out horribly...knowing C and a few (ancient) assembly languages, I know what is going on under the covers, but I have sympathy for the new programmer (or very experienced programmer who lacks certain bits of experience) who writes a ten line program and wonders why it takes twenty minutes to run... C isn't the ultimate language for all activities, but it is darned good, it has been chosen through natural selection, not marketing money and buzzword compliance. Sure, I'd love to see a "better" language, but I haven't seen it yet, and I have seen LOTS of "replacements for C" that clearly will never take over. Funny, many of the alternative languages to C are written in..C. And, they are available and were originally developed on Unix. I'll admit, my love of C kinda faded when it went from being a "PDP assembler" to a "completely portable, abstract, high-level language" that ANSI C is now. Yeah, yeah, I know, all kinds of advantages to portable code. But no ANSI C compiler does a "hello world" in a 2k stand-alone binary...and you can't "feel" the bytes in your fingers anymore (and if you do, you are writing non-portable code, which is bad. See why I stay out of src/ ? :). Some clues to what the alternative to C will look like: * It will NOT be a committee designed language. There will be no "IEEE" or other "working group" standardizing it before it gets popular. * It will NOT be a corporate pushed language. Programmers will adopt it because it is the best tool for the job, not because someone wined and dined their boss. * It will not be developed in the academic world. Sorry guys, but the real development in the computer world has been done in Industry, by people who have to show results to get paid, not papers to get published by people who couldn't get a job in the real world. * It will not be tied up in copyrights and patents. * It will be the work of a very few people who saw a problem, fixed it, and said, "wow, this is cool", and they show it to their friends. * It will be ported to platforms other than Windows and Linux immediately, both because it is possible and because it is desired. * The language definition will be very concise (like the first edition of the "White Book" (_The C Programming Language_). There may be some ambiguities. Deal with it. It won't be a monster, unreadable text like the C++ definition. * It will self-build. It has to. If it is a replacement for the primary OS development language on most mainstream platforms, what other language could it be written in? (well, one possible answer: the local assembly language. Well, that is unlikely to happen, though there could be some benefits...) * The basic language will be very simple, so it can be "completely" debugged. No one wants to chase bugs in the compiler, it's bad enough chasing them in one's own (or someone else's) code. Of course, it would be nice if the libraries could be kept simple enough to be made "perfect", too...don't wait up. Modern C is clearly too complex now for "perfect" (and maybe, not even "good") compilers to be made (much less libraries), and I don't think I've seen anyone propose a simpler language to replace it (this might be the "killer argument" that C will never be replaced). (btw: if anyone agrees with everything I said here, you are probably NUTS :) 9) Small Tools, Not Small Libraries Well, no one does either anymore. Bloat is where it is at on almost all platforms. This point is completely irrelevant in the real world. (we joke about bash being bloated, yet I have a Unix system with less RAM in it than our current sh(1) takes to run. Yes, our sh(1) does a lot more than that machine's shell does....but I don't think *THAT* much more...) 10) In-Band Signaling as Standard *yawn* 11) Time for U(NIX) 2 Retire No. It is time for the "Unix-should-retire" crowd to shut the fsck up and DEVELOP and SHOW AN ALTERNATIVE (yes, "shut up and hack"). It should be so clearly better that people port apps to it and move to it because they just want to. Don't wait up. Hey, Unix has "issues", I'll happily admit it, I could easily name ten things that most of you would probably disagree with. However, don't talk, fix. Improve. Prove. While it would be nice to scrap and rebuild from scratch the Ideal OS, it just won't happen any time soon -- it took Unix over 30 years to get where it is now...that's a lot of inertia to overcome. Most of the people qualified to actually create a new OS's code base are busy doing other things. Most of the people talking about it are clearly NOT qualified to be developing this new code base. Why do OpenBSD developers hack on the BSD code base? Because it is the best available starting point. Don't reinvent wheels. Polish the existing poorly implemented ones, because it is unlikely you will actually build a better one from scratch. Inertia can get in your way, but it is something we usually appreciate in the long run more than we think in the short run... None of the issues with the basic design of Unix are significant compared to the issues within the development process of Unix (a fractured and internally squabbling base like the many Unix variants provide will never compete successfully for market share against a focused competitor like Microsoft...assuming MS wishes to focus at some point). On the other hand...chaotic, competitive worlds are where New Ideas will happen and be developed and progressed. You don't come up with new ideas when you are too focused in one direction. Anyway...yes, this is way off topic. You should see the stuff I deleted before hitting "send". Let's just say that yes, I'm sure most people will disagree with at least something I said, and I'm sure most people will even disagree with some of the "facts" I have stated. Fine, I'm wrong. Draw your own conclusions. And send comments off-list. ;) Nick.