Tag Archives: computer scientist

The Computerized Toaster

Posted on by

Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. “What
do you think this is?”

One advisor, an engineer, answered first. “It is a toaster,” he said. The king asked, “How would you design an embedded computer for it?” The engineer replied, “Using a four-bit microcontroller,
I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I’ll show you a working prototype.”

The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, “Toasters don’t just turn bread into toast, they are also used to warm frozen
waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don’t look to the future, we will have to completely redesign
the toaster in just a few years.”

“With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs,
hard-boiled eggs, poached eggs, fried eggs, and various omelet classes.”

“The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, ‘Cook yourself.’ The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs.”

“Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some
derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don’t want the eggs to get cold while the bacon is frying, so concurrent
processing is required, too.”

“We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won’t buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message ‘Booting UNIX v. 12.3’ appears on the screen. (UNIX 12.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook.”

“Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel Pentium with 16MB of memory, a 160MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!).”

The king wisely had the computer scientist beheaded, and they all lived happily ever after.

Real Computer Scientists Don’t Write Code

Posted on by

Real computer scientists don’t write code. They occasionally tinker with ‘programming systems’, but those are so high level that they hardly count (and rarely count accurately; precision is for applications.)

Real computer scientists don’t comment their code. The identifiers are so long they can’t afford the disk space.

Real computer scientists don’t write the user interfaces, they merely argue over what they should look like.

Real computer scientists don’t eat quiche. They shun Szchezuan food since the hackers discovered it. Many real computer scientists consider eating an implementation detail. (Others break down and eat with the hackers, but only if they can have ice cream for desert.)

If it doesn’t have a programming environment complete with interactive debugger, structure editor and extensive cross module type checking, real computer scientists won’t be seen tinkering with it. They may have to use it to balance their checkbooks, as their own systems can’t.

Real computer scientists don’t program in assembler. They don’t write in anything less portable than a number two pencil.

Real computer scientists don’t debug programs, they dynamically modify them. This is safer, since no one has invented a way to do anything dynamic to FORTRAN, COBOL or BASIC.

Real computer scientists like C’s structured constructs, but they are suspicious of it because its compiled. (Only Batch freaks and efficiency weirdos bother with compilers, they’re soooo un-dynamic.)

Real computer scientists play go. They have nothing against the concept of mountain climbing, but the actual climbing is an implementation detail best left to programmers.

Real computer scientists admire ADA for its overwhelming aesthetic value, but they find it difficult to actually program in, as it is much too large to implement. Most Computer scientists don’t notice this because they are still arguing over what else to add to ADA.

Real computer scientists work from 5 pm to 9 am because that’s the only time they can get the 8 gigabytes of main memory they need to edit specs. (Real work starts around 2 am when enough MIPS are free for their dynamic systems.) Real computer scientists find it hard to share 3081s when they are doing ‘REAL’ work.

Real computer scientists only write specs for languages that might run on future hardware. Nobody trusts them to write specs for anything homo sapiens will ever be able to fit on a single planet.

Real computer scientists like planning their own environments to use bit mapped graphics. Bit mapped graphics is great because no one can afford it, so their systems can be experimental.

Real computer scientists regret the existence of PL/I, PASCAL and LISP. ADA is getting there, but it is still allows people to make mistakes.

Real computer scientists love the concept of users. Users are always real impressed by the stuff computer scientists are talking about; it sure sounds better than the stuff they are being forced to use now.

Real computer scientists despise the idea of actual hardware. Hardware has limitations, software doesn’t. It’s a real shame that Turing machines are so poor at I/O.

Real computer scientists love conventions. No one is expected to lug a 3081 attached to a bit map screen to a convention, so no one will ever know how slow their systems run.