You're right, of course. Except that the topic here isn't about the general population of computer users; it's about teaching maybe 1% of people to develop the software for those computers.

With autos, it's true that 99% of us will never need to understand how a transmission or other internal subsystems work. But if you're considering a career either designing or maintaining vehicles, you'd damned well better be learning about the mechanics (and chemistry and electronics) of their internal mechanisms, or you'll never get a job in the field.

Similarly, drivers might not need to understand routing, but the people who manage the routing system (or the computers that run the routing software) need to understand the topic, or they'll just screw it up. If you want a job developing their routing software, you'd better understand routing algorithms, or the people hiring developers will just laugh at you and toss your resume in the trash.

Most users of computers can do what they want using just a GUI. But we're talking about the future programmers, and if they don't understand the CLI approach as well as the GUI, they'll be crippled as developers. Without understanding both levels of your gadgets' command system, any time it gets flakey, you'll be dependent on the people who do understand the internals to get it working. Either that, or you'll be sold a new gadget because your old one is "broken", although it might have been fixed in a few minutes by someone with full knowledge of how to query its internals.

(This latter point has been important to the spread of unix/linux behind the scenes. You might be impressed to find out how many of the machines behind the Internet started life as DOS/Windows systems, and were discarded by their owners because they no longer "worked". I have two such servers myself. Free cast-off windows boxes are often quite serviceable as gateways/routers/servers when their disk is reformatted with a unix system. I run several web sites on "small, slow" machines no longer usable with Windows, but quite able to handle a million or so web requests per day and still be 90% idle. Most of these don't have a windowing system installed. Right now I have 5 Terminal windows open on this Macbook Pro that are ssh'd into 3 such servers, running OpenBSD, FreeBSD and linux on 10-year-old previously-Windows boxes. Plus one ssh'd into a server machine that was born running Ubuntu. The Macbook has a faster cpu and more memory than any of them, but at 4 years, it's nearing the end of its useful life running OS X and Darwin, and I'll have to replace it soon. Maybe I'll reincarnate it as a linux server. It's overpowered for that job. ;-)

Duh; one of its important jobs is sending that data back to its mother ship (or to the NSA. ;-)

Doesn't everyone understand that? Are there "smartphone" users dumb enough to think that the app isn't doing such things?

Heh. That doesn't always help. A lot of the Internet is painful by design. They make it that way with malice aforethought.

A trivial example in the window I'm typing in right now: There's a horizontal scroll bar at the bottom of this /. window. OK, it has a width= attribute that shouldn't be there that's forcing it to a fixed width, right? Nope. I grabbed one of the resize handles on the window's border, and resized it a few times. No matter what size I made it on my (rather large) screen, the /. window is sized to be slightly wider than that. It dynamically detects the size, and forces the content to be wider.

This is fairly common, and the solution is trivial: Remove all the width= and other size attributes. There's nothing in this /. page that requires such things, and without them, the browser will "flow" the text so that everything fits. But /., like so many sites, tries doing something "clever" (i.e., dumb) with the sizes, and as a result, there's nothing I can do to make it fit.

This is known in legal circles as "with malice aforethought". The developers understand the problem quite well. If they didn't, they wouldn't be smart enough to use HTML in the first place. So they must be doing it intentionally.

And I've seen why this can happen. I've worked on a number of projects that needed a web interface. On many of them, I've gotten explicit orders that the pages must be sized to specific width, so they'll fit in the window the boss wants to use on his desktop. If the boss's desired size isn't the default, it won't be accepted. This sort of idiocy is quite common, and it's not easy to fight.

Actually, I have "fixed" it on a number of projects. These were cases where we had a good reason to have all pages delivered by a CGI program that parses the client's request, runs appropriate data-fetching and -munging subprocesses, and formats the results in HTML. I sneak in a little check of the HTTP_USER_AGENT, and if it's IE (which is the only browser that such bosses know exists), my code generates the required width= attributes; else it produces no sizing instructions at all. The results usually work fine on anything from a dumb "smartphone" to a humongous window on a humongous display. Or a small browser window on your screen, whatever it is. And it meets the boss's requirement for a fixed width on his screen.

So far, I haven't been caught performing such treachery by any of my bosses, but it's probably only a matter of time. They often believe that their web sites need only work on screens exactly like the one on their desk, and they explicitly order their developers to do it that way, or else.

This is just one of the many reasons for the problem we're discussing. It's yet another example of the old one about not attributing something to malice which may be explained by stupidity. (Quick, without googling it, which famous writer is that usually attributed to? ;-)

Reminds me of that old poem about computers, which ends with the punch line "It never does what I want, only what I tell it".

This was a cliche back in the 1970s at least, perhaps earlier. Ranting about it won't have much effect, because those who understand you will have understood the above all along. The rest simply don't understand what computers are at all.

Unfortunately, a lot of those people are in positions of authority in our governments.

Well, if you're talking about the conventional usage of "human" in scientific circles, the answer is: Yes, they were; they just weren't modern humans.

But "human" really isn't a technical term; For that you want something like "Homo" or "hominin", depending on how far back in the tree you want to describe. The term "human" is used informally to mean just about any critters later than the split from the Pan (chimpanzee) branch. It's used when you don't want to be too precise about such things.

OTOH, "human" is widely used in common speech to refer to anyone "not like us". Sometimes it means "white people", especially in writings from before the 20th century. But you don't much hear such usages in scientific settings. You do see it a lot in media coverage of science, but then it means whatever the journalist thinks it means.

It's probably because most "US institutions" are organizations that want members who support their goals, and very few such organizations ever do any investigation at all of new members' backgrounds. If you ask a member of most organizations about their investigations, they'll just look at you like you're some sort of weirdo, and perhaps show a bit of nervousness about someone like you who would even mention such things. If you show an interest in the organization's goals, cooperate in their activities, and pay the membership fee, you're accepted as one of them. That's the way normal human organizations work, after all. Only a few extreme political and religious organizations would ever do such investigations. There's a reason we often call them "witch hunts". We understand that they're generally aimed at condemning people without bothering with unnecessary stuff like evidence.

But if you follow the link, you'll find that's exactly who the quote came from. ;-)

Yeah, that's the critical difference in the thinking. My calling the ingredient list "step 0" is based on the thinking that a recipe is something that tells you how make a food item. With this understanding, it makes sense that you'd consider "recipe" to mean only the actions you take that create the food item. If you already had all the ingredients in your kitchen a week ago, you wouldn't say that you started making the recipe last week. Checking the ingredient list makes nothing, so it's not a "step", it's merely a description of required initial conditions. Making the food means what you do in the kitchen when you decide what you want to eat. Buying ingredients earlier (perhaps by months because you know you'll want those ingredients some day) isn't part of making the food item. Deciding not to make a recipe because you lack a critical ingredient doesn't mean you've done the recipe's first step.

OTOH, it's reasonable that you'd interpret the ingredient list as a sort of command (though such lists never contain imperative verbs). It means "First, make sure you have the following ingredients ...." Someone who thinks that way could reasonably label the list as "step 1".

I tend to take the first approach, which is probably related to the fact that I like to keep a lot of non-perishable ingredients on hand for the food items I make often. Thus, I have a couple of bags of flour on a top kitchen shelf, several pounds of butter in a freezer in the basement, etc. I don't think of buying those ingredients as part of making a recipe. Several of the above posters apparently do, perhaps because their approach is to decide on a recipe, and then go buy the ingredients. Nothing wrong with that, if you have some good stores nearby. But it does lead to a different interpretation of that ingredient list at the top of a recipe.

And that example illustrates the usual reason for starting with step 0: The "zero" step is determining your initial state before you start doing anything. In this case, it's determining whether you should bother going on to step 1, which is pretty common. It's also common to use step 0 to list the material needed by the task.

Probably the most common real-world example is cooking recipes, which typically start with a list of ingredients. That "step" is typically not numbered, but sometimes the actual "steps" to create the food are numbered starting with 1. Or they're just in separate paragraphs, since numbering them isn't actually very useful to carry out the task. In any case, the ingredient list is usually typographically different than the rest of the recipe, and is a description of the required initial state, so it's natural to call it "step 0".

It similar to the advice I ran across years ago: If any news story talks about problems with "computers", you should always add "running MS Windows". If it were any other kind of computer, they would have told you its brand name. Since then, I've been looking for exceptions, where a computer problem bad enough to make the news was on machines using non-MS software. So far the only cases I've run across have always mentioned the brand or the OS name. I keep expecting exceptions, and maybe some day I'll spot one.

Yeah, I think you've got it. And it makes perfect sense to the "team leaders" who expect their employees to "give 110%".

Reminds me of the old observation that you can easily determine someone's software expertise from the log data showing how often they run with elevated (root, admin, whatever) privileges: The two quantities are inversely related.

I recall once impressing some people at a company that I was contracting for, when at a meeting I was asked if I needed root privileges on the machines I was using for testing. I shrugged, and said I didn't think so. When they looked puzzled, I just said that in the few cases I'd needed root privileges, I'd got them for the few minutes that I needed by using the "jcroot" account that I'd created. The IT guys got nervous looks on their faces, implying that they didn't know that was possible; the other developers were just grinning. Some time later, several IT guys showed up and wanted to know how I did it. I showed them how to use one of the exploits that hadn't been fixed on their machines. A few weeks later, they did an "upgrade" that blocked that exploit (but they didn't disable my root account). They didn't ask how many others I knew of. Maybe some of their other developers told them about a few more eventually.

I also spent a bit of time explaining that I've learned it isn't a good idea to work with more privilege than I need. The builtin security stuff is pretty good at preventing you from making dumb "typo" type mistakes that take time to fix. Yeah, this is a bit simplistic, but it's something that they could understand, and might have persuaded a few of them that they didn't need to run routinely as at admin level. Maybe, but probably not.

From what I've read, it's actually sorta the opposite. The healthcare.gov site is generally described as a bureaucratic database horror story. Multiple databases, actually, each with its own API (that's poorly documented), each one elsewhere on the Net, with unrealistic response-time "requirements" written by managers with little distributed-DB experience. And no understanding that messages between sites can't move faster than the speed of light.

Funny thing is that I've also read a number of comments recently about the zillions of cases where new decrees from Congress are handled by thousands of government web sites within a day or two. Thus, the recent "shutdown" was handled gracefully by most departments' web sites, and they were back up within a day or so when the people were called back to work.

So it's not that "the government" can't handle building and revising web sites. Thousands of departments are doing it the job routinely, and nobody notices because it usually goes smoothly.

But healthcare.gov by its very nature has attracted the attention of every politician within reach, most of which qualify as PHBs who want their name attached to the results but are otherwise clueless about this InterWeb stuff. The result is a flood of conflicting orders coming down to the grunts doing the actual web-site development, with radical changes appearing in their inboxes daily.

I'm sure that lots of readers here can identify with this situation. How often have the rest of you seen exactly this sort of mess in a corporate setting? I'm sure we can collect a lot of good horror stories. Or we can just go over to The Daily WTF and read about (or submit them) them there.

Yup, and a general response I've seen that I sorta like is: If you can say beforehand what the results of your research will be, then it isn't research, it's engineering. Of course, we need good engineering, too. But first, we have to have the scientific knowledge that good engineering is based on, and that requires scientific research (plus learning from our mistakes ;-).

In general, you can only predict the outcome of something that you know and understand. If you want to extend your knowledge and understanding, you need real research, whose results you can't know until after you've done the research.

Requiring researchers to state beforehand how the results will benefit us has only one effect: It bans actual scientific research. Of course, this might be what is intended.