Automatic transmissions have sheltered people from having to worry about specific gears. Why not shelter computer users from worry about specific files?
The problem with getting rid of the file concept is that people need to preserve snapshots of documents, work on alternative copies, work speculatively forward from a checkpoint, look for documents by name or content, dispose of things that are no longer needed (and are just in the way), etc. Snapshotting named versions of a document is a simple way of accomplishing these things for which no reasonable alternative has been proposed that I know of -- and right there you already have most of the complexity of the file concept.
I don't claim that there is no possible alternative to the file concept, but simply "sheltering" users from its complexity would force them to reinvent most or all of the complexity via onerous workarounds that might not transfer from one application to the next.
This is a particular instance of the general problem that the user's life is already complex without the computer. A supremely simple computer with no features does not reduce the complexity -- it is simply ignored. A slightly more complex computer may be able to simplify the user's life somewhat by providing simple functionality. The problem is to optimize the situation so that the user's life is as simple as possible. Reducing the complexity inside the computer may not reduce the complexity of the user's life.
For example, you can simplify the "stapler system" by doing away with the stapler and letting the user apply the staples manually -- no more jams, no more refilling, no more moving parts -- but the user's life is simpler when using the more complex system.
Anyway, the optimal solution can only be arrived at by experimentation. There are no general principles -- general principles tend to drive designs to unusable extremes like extreme orthogonality or extreme complexity.
So if there are unnecessary complexities in an interface, I say take them out. If people can find 90% of what they want on the internet, for example, with a single Google input box, that is ideal. It would be counterproductive to present each user, by default, with a complex "advanced" search form just because it might make searches slightly more effective.
Very true, but we can only work out by experience what is unnecessary. Google is a great example -- its demonstrated success defied what many people considered common sense and changed the conventional wisdom. It's pointless to argue about such things. The most successful method is the best method until superior success is demonstrated with a better method.
The bottom line is that most people simply don't care about the underlying complexities of computers or automobiles.
Right. They care about the complexity of their lives, in which computer interfaces now play a large part. It should be pointed out that many of the complexities a user deals with -- mouse, keyboard, menus, program interfaces -- are artifacts created expressly for users, not part of the underlying technology. We actually got to the point where the required understanding of the underlying technology -- the hard disk, removable storage, files, the monitor, power on/off, network connectivity -- was simpler than the required understanding of artifacts created for the user. Then the web came along, users caught on too fast, and now they're exposed to artifacts that were designed for programmers. Maybe some kind of usability police should have kept them out until we were ready for them;-)
Java is popular because strong typing prevents bad programmers from being stupid.
Not really. Compile-time type checking catches a certain amount of absent-mindedness and serves as a bit of extra documentation, no more. What Java really does is force people to do things the long, simple, stupid way instead of the clever way. Brian Kernighan wrote, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." The same goes double for your coworkers, who did not write the code in the first place. Many people do not have enough discipline to refrain from cleverness in Perl or Haskell, especially Perl, where one person's everyday tool is another person's obscure little corner of the language.
The relative merits of design paradigms don't matter if the code and application domain are both mature. The design serves to accomodate change; it only has shortcomings if you need to make changes that the original design won't accomodate. If the current design has survived for years without becoming a tangled mess, then it has a proven soundness of design that no first-try redesign could match, no matter what techniques and concepts were applied.
Frankly, throwing away a perfectly sufficient design and implementation because the programming team only knows the newer design concepts they were taught in school is as stupid as an old procedural coot refusing to work on a project with an OO design.
You're right that it's fruitless to try to teach "states" and "modes" to users. People learn these things on their own through fiddling around, and it isn't too hard if you aren't afraid and aren't impatient. People who are too afraid or too impatient go to a class and demand to be taught something that is much harder to grasp through words and concepts than it is through experience.
The problem will go away when every kid grows up around computers, because kids don't know enough to be afraid of computers, and they're innocent enough to think they have all the time in the world.
I don't agree that novices can be considered "normal." The computer illiterate are quickly becoming an oddity, a special niche in usability design. There's really no need to consider them anymore unless you have a special reason to.
The real question is how much sophistication can be reasonably expected from lifelong computer users. The file concept and needing to save one's work is an example of something that we've accepted that everyone can and should learn, in spite of the dire predictions of UI experts. The idea that people would be better off sheltered from the file concept is, in retrospect, pretty silly -- as silly as the idea of equipping an automobiles with reins and a whip so it would feel like a horse-drawn carriage.
I think we should stop projecting limitations onto humanity and see what happens. The typical "poor ignorant user" of 2030 is going to be at least as savvy as today's typical middle-class college student, and maybe more savvy in ways that surprise us.
It's a joke. This is enough to put me off, and I would say I'm more skilled than the average user,
I've been using Linux since 2000, starting with no GUI at all for the first two weeks because I couldn't get X to work. These days problems are rare on desktops, but newer hardware still sometimes requires twiddling. Laptops are the worst -- the odds are bad when trying to install Linux on a laptop. Desktops are much better; a trouble-free install is the norm these days.
It isn't really a difference between the amount of work required to set up Windows or Linux for a particular computer -- the difference is who does the work. With Linux, you just have to cross your fingers and hope that someone else has done the work, and that work has been incorporated into the install disks you're using. If not, you're going to end up doing some manual tweaking. You never have a problem with Windows because every computer seller and hardware manufacturer does the tweaking for you.
Anyway, these days Linux desktop users have it pretty easy. In the last four systems I've set up (two with Red Hat EWS and two with Fedora 5), the only tweak I had to do was downloading the proprietary NVidia driver for a new-to-the-market graphics card. I only had to do that because the open source driver that was automatically installed could not rotate the screen so I could use the monitor in portrait mode. Modulo that, all four installs went perfectly smoothly and resulted in immediately usable systems.
Using Linux in a school or corporate environment would be much easier because you'd be working with common hardware, and any tweaking would only need to be done once for each set of hardware, by an experienced sysadmin, and the tweaks incorporated on an install disk.
I'd install KDE and try that, but I can't figure out how. There may be a point there somewhere.
Well, you probably aren't allowed to. It's called security;-) Just kidding. You're right that the apps need more polishing, but that will come in time and isn't what most users care about anyway. "Ease of use," for most users, means quickly reaching their old level of proficiency on the applications they normally use, and nothing else. That means ease of use is mostly a measure of similarity to Windows. There have been debates about making Linux look and act exactly like Windows, but developers have pretty much decided that the Linux community should make its own determinations about what is best and easiest for users (which is often the Windows way, but not always) rather than blindly copy Windows. Some further improvements in "ease of use" will come from apps acquiring a bit more polish and maturity, but mostly "ease of use" will "improve" through changes in public prejudice. USA Today will announce "Linux finally easy to use" and suddenly everyone will believe it, no matter what their actual experience is.
I just thought of something else: The Linux kernel development team now uses static analysis tools to uncover bugs. AFAIK, this is a recent development for widely-used operating systems, and one that threatens the dominance of C in kernel programming. C is inherently difficult to analyze, yet static analysis uncovers so many bugs that it simply can't be neglected. Anyone planning on writing an operating system from scratch would surely note this trend and choose to write in a language (or dialect) for which excellent static analysis support can be provided.
There's not much point developing an OS in Ada if the standard run-time system already has many of the features you need to implement. The same goes for any language that supports concurrency to a decent degree.
Well, sure there's a point -- you get an operating system! If the basic functions of the operating system overlap with the language runtime, then you can use one implementation for both. For example, C implementations on Unix get to rely on the system linker and loader, but Java and Lisp implemantations have to provide their own linker/loaders. The kernel implementation language will be fast and well-supported on the system and become the systems programming language of choice on the operating system. That has happened with Lisp on Lisp Machines and C on Unix; probably my ignorance prevents my from listing half a dozen more instances.
If a language specifies concurrency support, then the OS can choose between implementing the language's model of concurrency or merely supporting it by providing appropriate primitives. Writing a kernel involves creating virtual dialects of a language because of the various contexts in which code executes, and that would certainly include dialects in which the concurrency features of a language were unavailable.
That jives with my Java experience. Our development machines were mostly Windows boxes with a few Linux guys mixed in, and we deployed to Solaris servers. The only guys who ever ran the code under Solaris were the load testers. Even QA was done on Windows boxes. Think about that for a second: we did release testing on an entirely different architecture than deployment, and it never bit us a single time. Freaking amazing. That was around 2000-2001.
Are there any other languages that could actually replace C?
C is unmatched in its ease of use from other languages and in the consistency of compiler support. That will ensure that it stays at the center of the programming universe. A library written in C can be used from virtually any other language in the world, on almost every system in the world, so a library developed in C will always have twenty times the users that an equivalent library in another language would. This is the real key to C's success, not anything else. Well, that and the fact that C is a simple language that is very easy to learn.
is there anything (practical) you can build an operating system out of, short of machine or assembly?
What do you need to write an operating system? First, access to the hardware. This seems like a deep and mysterious power, but whether a language can do this only depends on whether the language implementer decided it was a good idea -- you can hack a compiler for *any* language to emit the right sequence of instructions to access hardware controllers, handle interrupts, and control the processor. It doesn't take much linguistic support.
Actually, that isn't the way it's normally done anyway. That stuff is handled at the lowest levels by assembly code. The HLL part of the OS just has to interact with the assembly code efficiently. That means two things: the ability to define and manipulate binary data formats in memory, and the ability to call code written in assembly.
You'd also want the language to function without a large run-time system, to minimize the amount of assembly bootstrapping necessary to start up. You probably also want a language in which it is simple to write efficient code, unless you have more system resources than you know what to do with.
So that's all you need to write an OS:
Convenient access to system resources.
Convenient definition and manipulation of binary formats in memory.
The ability to call assembly code.
A small run-time system.
The ability to write efficient code.
Practically speaking, I can't imagine doing it without an imperative language with a clear linguistic separation between stack allocation and heap allocation. That's probably just my mental limitations, but let's allow it anyway. You still have a very large number of languages left, though most of them have been choked off by the success of C. Off the top of my head, Ada and C++ are well-established languages that meet all the requirements I just stated.
An argument is often made that an OS must be implemented in a language that *lacks* certain features, because those features shouldn't be used in kernel code. I really don't understand that. What's even more mystifying is that the argument comes from C programmers. A C programmer will chew your ear off talking about how languages shouldn't protect programmers from their own mistakes, programmers need the full power of the computer, if a guy can't handle pointers then he shouldn't be programming in the first place, blah blah blah, but if you mention C++, his scrotum shrivels up and suddenly he's afraid that this big bad language will force him to write bad code.
The idea that someone might have the intelligence and discipline to design and implement part of an operating system, but will willy-nilly inject terrible features into that operating system merely because the language supports it, seems utterly bizarre to me. Surely everyone who has programmed in C or C++ has had to follow project coding guidelines. Of all the coding mistakes you can make, accidentally using a forbidden language feature seems like a pretty easy one to avoid.
Another frequently cited problem with using languages other than C is compiler support. I don't know if you meant to include such issues in your question or not, and I really don't have the knowledge to comment about compiler sup
I think the clearest way to say it is that Java is pass-by-value, and all Java variables and method parameters hold primitives or object references, never objects. Since a method parameter never contains an object, an object can never be passed. A reference to an object can be passed, and it will be passed by value.
Remember that you're talking about a guy who thinks that if something is designed correctly then it becomes stillborn.
Only if your definition of "correctly" is a very limited one. Stroustrup had an idea of what problems the language should be useful for, he made himself intimately familiar with the burdens and obstactles faced by people solving those problems, and he labored very hard to make sure that his target users would actually be able to use C++. If you think those things have nothing to do with good design, then you probably think sod skyscrapers and fur swimsuits are a good idea.
The bottom line is that C++ was not meant to be a proof of concept or an objet d'art. Wishing away C++, if it were possible, would not make it any easier to apply "better" languages to practical problems.
Historically, object orientation was the raison d'etre for C++. Stroustrup liked Simula's class concept and the way it allowed him to structure programs, but his effort to use Simula in a large project failed because its performance was too poor. He decided that Simula was inherently inefficient and could not be implemented efficiently, so the next time he encountered similar requirements, he started extending C.
The GP was wrong when he said Stroustrup wanted to bring OO "to the unwashed masses" -- Stroustrup wanted to bring OO to himself and other AT&T engineers who needed performance characteristics similar to C. Their only motive in making the language popular was to make the language self-supporting.
The designers clearly meant for the "unsafe"^H^H^H^H^H^Hefficient access to be the norm. If you get the length of the vector first, and loop from 0 up to before that, like everyone is used to doing with arrays and using the square brackets operator, it's unnecessary to pay the price for the overhead of bounds-checking the index on every access.
Don't assume that getting rid of safety buys efficiency. Check out these implementations of the scenario you described (your "efficient" version is method2):
void method4(vector<int>& v) { for(vector<int>::iterator i = v.begin(); i != v.end(); ++i) { twiddle(*i); } }
Using gcc 4.1 and -O3, the fastest version is... are you ready for it? method1. method0, method2, and method4 have essentially identical numbers, and method3 is the slowest. That's right: method1 beats method2, and method0 beats method3. Don't ask me why. On -O2, your implementation (method2) and the iterator implementation tied for first, significantly ahead of the others.
That's why the default should be safe access. Compilers and processors are incredibly weird and complex beasts, much more complicated than programming languages. You can't reliably label code "efficient" or "inefficient" based on inspection, but you can almost always rely on guarantees made by languages and high-quality libraries. You know that v.at(i) does a bounds check, and v[i] may not. You don't know that v[i] will compile to faster code than v.at(i); you can only make a very unreliable guess.
I believe the aim of OLPC project is to provide a laptop to a child.
You are correct. Unfortunately, most people can't see the benefit of that in itself. They think you have to have uniform literacy and mass usage right away to have benefits, which is an unnecessary and probably unreachable goal.
A much more likely outcome is that organized training efforts will achieve very little before the money runs out. The first generation of users will be smart kids with free time. They will be eager but clumsy proselytizers, and their efforts will enable a certain level of usage in local schools and governments. That kind of organic growth is inevitably unpredictable and unequal, and it will leave people out. (There are people who would oppose the program on these grounds, but they are exactly the same people who can't imagine that there will be any benefits not doled out directly through official training programs, so no worries.)
The organizations that do this kind of cost assessment (like the one leading to $970/laptop) are corporations and public schools, which depend on command and control and only value results that are uniform and reproducible. The uniform and reproducible results, in my opinion, will be nada, and the program will be declared a failure. Meanwhile, a talented, free-time-having minority will become hackers and amateur sysadmins, and their existence will provide a foundation for future developments that we can't predict.
(simple, fast hardware driven by complex compilers)
Unfortunately, the only compiler that can produce decent code for the Cell is the most complex, expensive, and undependable compiler on the market today.
I'm talking about brainwashing, and here you come in with truth and rationality;-)
It may be true about Oz (and Common Lisp, for that matter) but the sad fact is that people will believe it about C or Java or Perl or whatever language they're comfortable with, simply because it gives them an excuse not to learn another language. It's much more valuable to teach them something they won't accept without a forced demonstration (that learning new languages is feasible and often worthwhile) than to teach them something that they'll naturally believe anyway, and in fact will be much too eager to believe (that a single language can be extremely versatile.)
I disagree with many of your points, but I love your idea of starting at the extremes: a class in Scheme (a simple, safe, high-level, supportive language) and a class in assembly language (quite the opposite!) That's a brilliant idea, IMO, and easily the most interesting thing I've read this week. Replace Scheme with a purer, less flexible language, such as Haskell, and it's even more interesting, though perhaps less of a good idea.
Here are two Corrections, two Objections, an Addition, and a Cool Idea:
Correction 1: The Lisps (including Scheme) support imperative and OO programming as well as functional programming,.
Correction 2: Scheme is just as often compiled as interpreted, but that doesn't really matter. At some point students should use a compiled language so they can learn to read compiler output and tweak their source to produce better object code. Beyond that, the implementation of a language doesn't matter. (Dynamic runtime features like class loading, function redefinition, and runtime code generation by no means require that a language be interpreted!)
Objection 1: "Overviews" of languages are evil! You can't learn very much about a language without 1) doing a significant project, and 2) learning the language well enough to work around its weaknesses and discover its strengths. Students should be given at least a semester to learn a language that well, especially since they may be learning other languages at the same time in other classes. You don't want to teach xenophobia by setting them up to fail with new languages:-) If they became familiar with an assembly language and attained practical proficiency in C, Prolog, Haskell, and Java, and never saw any other languages at all, that would be a much better linguistic education than current CS majors get.
Objection 2: Too much flexibility. Operating systems, upperclass-level algorithms, and the intro theoretical class ("languages and automata" or some such) should not be optional classes, if only because they're the vehicles for teaching basic literacy in topics that all CS majors have to deal with: models of computation, models of concurrency, fault tolerance, security, and others. Every student needs at least a passing familiarity with these topics, because every developer encounters them over and over again in their careers, even if they don't realize it. Plus, without some structure to the major, students could accidentally or intentionally graduate with a very limited education. For example, a student could decide only to study things that he already understands the value of, or avoid classes that require projects in a purely functional language. A well-designed curriculum should ensure that any path to a degree requires competence at fundamental skills and concepts (e.g., functional programming, concurrency analysis).
Addition: Students should be given canned (preprepared) projects that require them to deal with already-written code. Hand them a 500,000-line poorly-documented monstrosity (maybe a specially prepared version of a dead commercial product) and tell them to make a 20% performance improvement or add a certain feature.
Cool Idea for a first software engineering class: Second half of the semester: Students are given a specification for a piece of software and split into four groups that each complete the entire specification, producing a working, documented system. First half of the semester: Students are given a specification for a piece of software and specifications for a number of changes and extensions. Every change and extension must be added to each of the four implementations produced by last semester's students:-) Since they've just finished cursing the work produced by last semester's students, they'll be well-motivated to do good work themselves.
Every program, every function you write embodies an algorithm. Most of them are special-purpose algorithms that are only useful for the single purpose you're applying them to, but you still need to understand them. Teaching students to understand algorithms, for the purposes of examining correctness and predicting performance scaling, is best done with simple, classic algorithms like sorting and searching.
The purpose of studying and implementing quicksort is not so that you can understand quicksort later, but so you can understand how to compose statements, functions, modules, and programs into correct, efficient wholes, and how to decompose statements, functions, modules, and programs into sensible pieces for analysis. Quicksort just happens to be a simple and enlightening example.
Are you kidding? That's the best-written book on C++ on the market, and one of the best computing books, period. Most of the books on the shelves at Barnes and Noble are written for idiots with years of experience -- all they know how to do is appeal to ill-fitting concepts you've already learned in another domain. The best books, like TC++PL, are the ones that clearly and logically teach concepts, which requires a bit of intelligence on the reader's part but saves him from sloppily carrying over inapplicable concepts from one domain to another.
If you read the high-quality C++ books on the market and read back issues of the C/C++ User's Journal (now defunct), it's clear that the C++ language as promoted by experts and supporters takes years to learn. A C++ application written in good style will be very difficult for a beginner to understand and can only be further developed under the direction of a seasoned C++ programmer.
I don't agree that "the earth would be a better place without this plague," but I'd like to see it replaced by something better, such as a pair or family of languages (with easy, natural, logical interoperation) that cover the same ground covered by C++.
What separates the good from the bad in the real world is context. Some guys are great at setting up wikis, installing automated testing harnesses, and designing test cases. Others are good at talking to customers and managers. Others are good at debugging and profiling. Others are good at cranking out boilerplate implementations of business logic. Others are good at sitting alone in an office writing diagrams and mathematical equations, designing out redundancy. Others are good at understanding other programmers' minds and produce great APIs and documentation.
Almost everyone is hopeless at one or two of the above, and some people are brilliant at one or two but hopeless at the rest. A guy who is brilliant at one thing is going to fail in a three-person startup where the other two people are nontechnical. Likewise, a versatile, Perl-scripting sysadmin may be a crackerjack developer for a small company, but hopelessly outclassed when placed in a specialized role in a big development group.
C++ vectors *can* be used safely, but the library designers used traditional, easy-to-read syntax for unsafe access and verbose, hard-to-read syntax for safe access. They clearly meant for unsafe access to be the norm and safe access to be used in special cases. I'm a C++ fan, but in this case they screwed up badly.
Slashdot Mirror
The problem with getting rid of the file concept is that people need to preserve snapshots of documents, work on alternative copies, work speculatively forward from a checkpoint, look for documents by name or content, dispose of things that are no longer needed (and are just in the way), etc. Snapshotting named versions of a document is a simple way of accomplishing these things for which no reasonable alternative has been proposed that I know of -- and right there you already have most of the complexity of the file concept.
I don't claim that there is no possible alternative to the file concept, but simply "sheltering" users from its complexity would force them to reinvent most or all of the complexity via onerous workarounds that might not transfer from one application to the next.
This is a particular instance of the general problem that the user's life is already complex without the computer. A supremely simple computer with no features does not reduce the complexity -- it is simply ignored. A slightly more complex computer may be able to simplify the user's life somewhat by providing simple functionality. The problem is to optimize the situation so that the user's life is as simple as possible. Reducing the complexity inside the computer may not reduce the complexity of the user's life.
For example, you can simplify the "stapler system" by doing away with the stapler and letting the user apply the staples manually -- no more jams, no more refilling, no more moving parts -- but the user's life is simpler when using the more complex system.
Anyway, the optimal solution can only be arrived at by experimentation. There are no general principles -- general principles tend to drive designs to unusable extremes like extreme orthogonality or extreme complexity.
Very true, but we can only work out by experience what is unnecessary. Google is a great example -- its demonstrated success defied what many people considered common sense and changed the conventional wisdom. It's pointless to argue about such things. The most successful method is the best method until superior success is demonstrated with a better method.
Right. They care about the complexity of their lives, in which computer interfaces now play a large part. It should be pointed out that many of the complexities a user deals with -- mouse, keyboard, menus, program interfaces -- are artifacts created expressly for users, not part of the underlying technology. We actually got to the point where the required understanding of the underlying technology -- the hard disk, removable storage, files, the monitor, power on/off, network connectivity -- was simpler than the required understanding of artifacts created for the user. Then the web came along, users caught on too fast, and now they're exposed to artifacts that were designed for programmers. Maybe some kind of usability police should have kept them out until we were ready for them ;-)
Not really. Compile-time type checking catches a certain amount of absent-mindedness and serves as a bit of extra documentation, no more. What Java really does is force people to do things the long, simple, stupid way instead of the clever way. Brian Kernighan wrote, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." The same goes double for your coworkers, who did not write the code in the first place. Many people do not have enough discipline to refrain from cleverness in Perl or Haskell, especially Perl, where one person's everyday tool is another person's obscure little corner of the language.
I think he means that incompatibility by design is not engineering. I guess he doesn't work for Sony.
The relative merits of design paradigms don't matter if the code and application domain are both mature. The design serves to accomodate change; it only has shortcomings if you need to make changes that the original design won't accomodate. If the current design has survived for years without becoming a tangled mess, then it has a proven soundness of design that no first-try redesign could match, no matter what techniques and concepts were applied.
Frankly, throwing away a perfectly sufficient design and implementation because the programming team only knows the newer design concepts they were taught in school is as stupid as an old procedural coot refusing to work on a project with an OO design.
You're right that it's fruitless to try to teach "states" and "modes" to users. People learn these things on their own through fiddling around, and it isn't too hard if you aren't afraid and aren't impatient. People who are too afraid or too impatient go to a class and demand to be taught something that is much harder to grasp through words and concepts than it is through experience.
The problem will go away when every kid grows up around computers, because kids don't know enough to be afraid of computers, and they're innocent enough to think they have all the time in the world.
I don't agree that novices can be considered "normal." The computer illiterate are quickly becoming an oddity, a special niche in usability design. There's really no need to consider them anymore unless you have a special reason to.
The real question is how much sophistication can be reasonably expected from lifelong computer users. The file concept and needing to save one's work is an example of something that we've accepted that everyone can and should learn, in spite of the dire predictions of UI experts. The idea that people would be better off sheltered from the file concept is, in retrospect, pretty silly -- as silly as the idea of equipping an automobiles with reins and a whip so it would feel like a horse-drawn carriage.
I think we should stop projecting limitations onto humanity and see what happens. The typical "poor ignorant user" of 2030 is going to be at least as savvy as today's typical middle-class college student, and maybe more savvy in ways that surprise us.
I've been using Linux since 2000, starting with no GUI at all for the first two weeks because I couldn't get X to work. These days problems are rare on desktops, but newer hardware still sometimes requires twiddling. Laptops are the worst -- the odds are bad when trying to install Linux on a laptop. Desktops are much better; a trouble-free install is the norm these days.
It isn't really a difference between the amount of work required to set up Windows or Linux for a particular computer -- the difference is who does the work. With Linux, you just have to cross your fingers and hope that someone else has done the work, and that work has been incorporated into the install disks you're using. If not, you're going to end up doing some manual tweaking. You never have a problem with Windows because every computer seller and hardware manufacturer does the tweaking for you.
Anyway, these days Linux desktop users have it pretty easy. In the last four systems I've set up (two with Red Hat EWS and two with Fedora 5), the only tweak I had to do was downloading the proprietary NVidia driver for a new-to-the-market graphics card. I only had to do that because the open source driver that was automatically installed could not rotate the screen so I could use the monitor in portrait mode. Modulo that, all four installs went perfectly smoothly and resulted in immediately usable systems.
Using Linux in a school or corporate environment would be much easier because you'd be working with common hardware, and any tweaking would only need to be done once for each set of hardware, by an experienced sysadmin, and the tweaks incorporated on an install disk.
Well, you probably aren't allowed to. It's called security ;-) Just kidding. You're right that the apps need more polishing, but that will come in time and isn't what most users care about anyway. "Ease of use," for most users, means quickly reaching their old level of proficiency on the applications they normally use, and nothing else. That means ease of use is mostly a measure of similarity to Windows. There have been debates about making Linux look and act exactly like Windows, but developers have pretty much decided that the Linux community should make its own determinations about what is best and easiest for users (which is often the Windows way, but not always) rather than blindly copy Windows. Some further improvements in "ease of use" will come from apps acquiring a bit more polish and maturity, but mostly "ease of use" will "improve" through changes in public prejudice. USA Today will announce "Linux finally easy to use" and suddenly everyone will believe it, no matter what their actual experience is.
I think they're just being honest about their goals. Retirement is probably the best thing about working on Windows.
I just thought of something else: The Linux kernel development team now uses static analysis tools to uncover bugs. AFAIK, this is a recent development for widely-used operating systems, and one that threatens the dominance of C in kernel programming. C is inherently difficult to analyze, yet static analysis uncovers so many bugs that it simply can't be neglected. Anyone planning on writing an operating system from scratch would surely note this trend and choose to write in a language (or dialect) for which excellent static analysis support can be provided.
Well, sure there's a point -- you get an operating system! If the basic functions of the operating system overlap with the language runtime, then you can use one implementation for both. For example, C implementations on Unix get to rely on the system linker and loader, but Java and Lisp implemantations have to provide their own linker/loaders. The kernel implementation language will be fast and well-supported on the system and become the systems programming language of choice on the operating system. That has happened with Lisp on Lisp Machines and C on Unix; probably my ignorance prevents my from listing half a dozen more instances.
If a language specifies concurrency support, then the OS can choose between implementing the language's model of concurrency or merely supporting it by providing appropriate primitives. Writing a kernel involves creating virtual dialects of a language because of the various contexts in which code executes, and that would certainly include dialects in which the concurrency features of a language were unavailable.
That jives with my Java experience. Our development machines were mostly Windows boxes with a few Linux guys mixed in, and we deployed to Solaris servers. The only guys who ever ran the code under Solaris were the load testers. Even QA was done on Windows boxes. Think about that for a second: we did release testing on an entirely different architecture than deployment, and it never bit us a single time. Freaking amazing. That was around 2000-2001.
C is unmatched in its ease of use from other languages and in the consistency of compiler support. That will ensure that it stays at the center of the programming universe. A library written in C can be used from virtually any other language in the world, on almost every system in the world, so a library developed in C will always have twenty times the users that an equivalent library in another language would. This is the real key to C's success, not anything else. Well, that and the fact that C is a simple language that is very easy to learn.
What do you need to write an operating system? First, access to the hardware. This seems like a deep and mysterious power, but whether a language can do this only depends on whether the language implementer decided it was a good idea -- you can hack a compiler for *any* language to emit the right sequence of instructions to access hardware controllers, handle interrupts, and control the processor. It doesn't take much linguistic support.
Actually, that isn't the way it's normally done anyway. That stuff is handled at the lowest levels by assembly code. The HLL part of the OS just has to interact with the assembly code efficiently. That means two things: the ability to define and manipulate binary data formats in memory, and the ability to call code written in assembly.
You'd also want the language to function without a large run-time system, to minimize the amount of assembly bootstrapping necessary to start up. You probably also want a language in which it is simple to write efficient code, unless you have more system resources than you know what to do with.
So that's all you need to write an OS:
Practically speaking, I can't imagine doing it without an imperative language with a clear linguistic separation between stack allocation and heap allocation. That's probably just my mental limitations, but let's allow it anyway. You still have a very large number of languages left, though most of them have been choked off by the success of C. Off the top of my head, Ada and C++ are well-established languages that meet all the requirements I just stated.
An argument is often made that an OS must be implemented in a language that *lacks* certain features, because those features shouldn't be used in kernel code. I really don't understand that. What's even more mystifying is that the argument comes from C programmers. A C programmer will chew your ear off talking about how languages shouldn't protect programmers from their own mistakes, programmers need the full power of the computer, if a guy can't handle pointers then he shouldn't be programming in the first place, blah blah blah, but if you mention C++, his scrotum shrivels up and suddenly he's afraid that this big bad language will force him to write bad code.
The idea that someone might have the intelligence and discipline to design and implement part of an operating system, but will willy-nilly inject terrible features into that operating system merely because the language supports it, seems utterly bizarre to me. Surely everyone who has programmed in C or C++ has had to follow project coding guidelines. Of all the coding mistakes you can make, accidentally using a forbidden language feature seems like a pretty easy one to avoid.
Another frequently cited problem with using languages other than C is compiler support. I don't know if you meant to include such issues in your question or not, and I really don't have the knowledge to comment about compiler sup
I think the clearest way to say it is that Java is pass-by-value, and all Java variables and method parameters hold primitives or object references, never objects. Since a method parameter never contains an object, an object can never be passed. A reference to an object can be passed, and it will be passed by value.
Only if your definition of "correctly" is a very limited one. Stroustrup had an idea of what problems the language should be useful for, he made himself intimately familiar with the burdens and obstactles faced by people solving those problems, and he labored very hard to make sure that his target users would actually be able to use C++. If you think those things have nothing to do with good design, then you probably think sod skyscrapers and fur swimsuits are a good idea.
The bottom line is that C++ was not meant to be a proof of concept or an objet d'art. Wishing away C++, if it were possible, would not make it any easier to apply "better" languages to practical problems.
Historically, object orientation was the raison d'etre for C++. Stroustrup liked Simula's class concept and the way it allowed him to structure programs, but his effort to use Simula in a large project failed because its performance was too poor. He decided that Simula was inherently inefficient and could not be implemented efficiently, so the next time he encountered similar requirements, he started extending C.
The GP was wrong when he said Stroustrup wanted to bring OO "to the unwashed masses" -- Stroustrup wanted to bring OO to himself and other AT&T engineers who needed performance characteristics similar to C. Their only motive in making the language popular was to make the language self-supporting.
Don't assume that getting rid of safety buys efficiency. Check out these implementations of the scenario you described (your "efficient" version is method2):
Using gcc 4.1 and -O3, the fastest version is... are you ready for it? method1. method0, method2, and method4 have essentially identical numbers, and method3 is the slowest. That's right: method1 beats method2, and method0 beats method3. Don't ask me why. On -O2, your implementation (method2) and the iterator implementation tied for first, significantly ahead of the others.
That's why the default should be safe access. Compilers and processors are incredibly weird and complex beasts, much more complicated than programming languages. You can't reliably label code "efficient" or "inefficient" based on inspection, but you can almost always rely on guarantees made by languages and high-quality libraries. You know that v.at(i) does a bounds check, and v[i] may not. You don't know that v[i] will compile to faster code than v.at(i); you can only make a very unreliable guess.
You are correct. Unfortunately, most people can't see the benefit of that in itself. They think you have to have uniform literacy and mass usage right away to have benefits, which is an unnecessary and probably unreachable goal.
A much more likely outcome is that organized training efforts will achieve very little before the money runs out. The first generation of users will be smart kids with free time. They will be eager but clumsy proselytizers, and their efforts will enable a certain level of usage in local schools and governments. That kind of organic growth is inevitably unpredictable and unequal, and it will leave people out. (There are people who would oppose the program on these grounds, but they are exactly the same people who can't imagine that there will be any benefits not doled out directly through official training programs, so no worries.)
The organizations that do this kind of cost assessment (like the one leading to $970/laptop) are corporations and public schools, which depend on command and control and only value results that are uniform and reproducible. The uniform and reproducible results, in my opinion, will be nada, and the program will be declared a failure. Meanwhile, a talented, free-time-having minority will become hackers and amateur sysadmins, and their existence will provide a foundation for future developments that we can't predict.
Unfortunately, the only compiler that can produce decent code for the Cell is the most complex, expensive, and undependable compiler on the market today.
I'm talking about brainwashing, and here you come in with truth and rationality ;-)
It may be true about Oz (and Common Lisp, for that matter) but the sad fact is that people will believe it about C or Java or Perl or whatever language they're comfortable with, simply because it gives them an excuse not to learn another language. It's much more valuable to teach them something they won't accept without a forced demonstration (that learning new languages is feasible and often worthwhile) than to teach them something that they'll naturally believe anyway, and in fact will be much too eager to believe (that a single language can be extremely versatile.)
I disagree with many of your points, but I love your idea of starting at the extremes: a class in Scheme (a simple, safe, high-level, supportive language) and a class in assembly language (quite the opposite!) That's a brilliant idea, IMO, and easily the most interesting thing I've read this week. Replace Scheme with a purer, less flexible language, such as Haskell, and it's even more interesting, though perhaps less of a good idea.
:-) If they became familiar with an assembly language and attained practical proficiency in C, Prolog, Haskell, and Java, and never saw any other languages at all, that would be a much better linguistic education than current CS majors get.
:-) Since they've just finished cursing the work produced by last semester's students, they'll be well-motivated to do good work themselves.
Here are two Corrections, two Objections, an Addition, and a Cool Idea:
Correction 1: The Lisps (including Scheme) support imperative and OO programming as well as functional programming,.
Correction 2: Scheme is just as often compiled as interpreted, but that doesn't really matter. At some point students should use a compiled language so they can learn to read compiler output and tweak their source to produce better object code. Beyond that, the implementation of a language doesn't matter. (Dynamic runtime features like class loading, function redefinition, and runtime code generation by no means require that a language be interpreted!)
Objection 1: "Overviews" of languages are evil! You can't learn very much about a language without 1) doing a significant project, and 2) learning the language well enough to work around its weaknesses and discover its strengths. Students should be given at least a semester to learn a language that well, especially since they may be learning other languages at the same time in other classes. You don't want to teach xenophobia by setting them up to fail with new languages
Objection 2: Too much flexibility. Operating systems, upperclass-level algorithms, and the intro theoretical class ("languages and automata" or some such) should not be optional classes, if only because they're the vehicles for teaching basic literacy in topics that all CS majors have to deal with: models of computation, models of concurrency, fault tolerance, security, and others. Every student needs at least a passing familiarity with these topics, because every developer encounters them over and over again in their careers, even if they don't realize it. Plus, without some structure to the major, students could accidentally or intentionally graduate with a very limited education. For example, a student could decide only to study things that he already understands the value of, or avoid classes that require projects in a purely functional language. A well-designed curriculum should ensure that any path to a degree requires competence at fundamental skills and concepts (e.g., functional programming, concurrency analysis).
Addition: Students should be given canned (preprepared) projects that require them to deal with already-written code. Hand them a 500,000-line poorly-documented monstrosity (maybe a specially prepared version of a dead commercial product) and tell them to make a 20% performance improvement or add a certain feature.
Cool Idea for a first software engineering class: Second half of the semester: Students are given a specification for a piece of software and split into four groups that each complete the entire specification, producing a working, documented system. First half of the semester: Students are given a specification for a piece of software and specifications for a number of changes and extensions. Every change and extension must be added to each of the four implementations produced by last semester's students
Every program, every function you write embodies an algorithm. Most of them are special-purpose algorithms that are only useful for the single purpose you're applying them to, but you still need to understand them. Teaching students to understand algorithms, for the purposes of examining correctness and predicting performance scaling, is best done with simple, classic algorithms like sorting and searching.
The purpose of studying and implementing quicksort is not so that you can understand quicksort later, but so you can understand how to compose statements, functions, modules, and programs into correct, efficient wholes, and how to decompose statements, functions, modules, and programs into sensible pieces for analysis. Quicksort just happens to be a simple and enlightening example.
Are you kidding? That's the best-written book on C++ on the market, and one of the best computing books, period. Most of the books on the shelves at Barnes and Noble are written for idiots with years of experience -- all they know how to do is appeal to ill-fitting concepts you've already learned in another domain. The best books, like TC++PL, are the ones that clearly and logically teach concepts, which requires a bit of intelligence on the reader's part but saves him from sloppily carrying over inapplicable concepts from one domain to another.
I don't agree that "the earth would be a better place without this plague," but I'd like to see it replaced by something better, such as a pair or family of languages (with easy, natural, logical interoperation) that cover the same ground covered by C++.
What separates the good from the bad in the real world is context. Some guys are great at setting up wikis, installing automated testing harnesses, and designing test cases. Others are good at talking to customers and managers. Others are good at debugging and profiling. Others are good at cranking out boilerplate implementations of business logic. Others are good at sitting alone in an office writing diagrams and mathematical equations, designing out redundancy. Others are good at understanding other programmers' minds and produce great APIs and documentation.
Almost everyone is hopeless at one or two of the above, and some people are brilliant at one or two but hopeless at the rest. A guy who is brilliant at one thing is going to fail in a three-person startup where the other two people are nontechnical. Likewise, a versatile, Perl-scripting sysadmin may be a crackerjack developer for a small company, but hopelessly outclassed when placed in a specialized role in a big development group.
C++ vectors *can* be used safely, but the library designers used traditional, easy-to-read syntax for unsafe access and verbose, hard-to-read syntax for safe access. They clearly meant for unsafe access to be the norm and safe access to be used in special cases. I'm a C++ fan, but in this case they screwed up badly.