There are certain basic, known principles about how people's minds go about the business of understanding, and communicating understanding by means of language, which have been known and used for many centuries. No matter how these principles are addressed, they always end up with hierarchic decomposition as being the heart of good storytelling. Perhaps the most relevant formulation is the familiar: "Tell 'em whatcha gonna tell'em. Tell 'em. Tell 'em whatcha told 'em." This is a pattern of communication almost as universal and well-entrenched as Newton's laws of motion.

The artificial intelligence people, the artificial intelligencia,... kept choosing little games to play, and little things that they could master, right? But my whole philosophy has always been give me a really tough problem that's just beyond the state-of-the-art, and give me a whole bunch of users beating on me to get it done. In other words, the real core of what being an engineer is.

A general theme for what I'm trying to convey and what actually drove me and my very industrious and creative project members over all these years, is... that there is much more to it than pictures. It has to be a picture language. There has to be meaning there, and the meaning is useful. You're trying to solve problems. So it really comes down to man machine problem solving . Better means of communication and expression is what always has driven our work.

I realized after I'd been at MIT for a while that I had never even known the semantics of the word "engineering". You see, all my relatives and contacts were medical doctors or biology and chemistry professors. In fact, I'm almost the "black sheep" in the family for not being an MD or Ph.D. because everybody was doing that sort of thing. There was no contact at all with engineering. I didn't even know what the word meant...

With all this science and physics and so forth that I absorbed. I did have one early experience with engineering, however. When we got the Book of Knowledge, I found on one page a diagram for a short-wave radio. I thought it would be neat to try to make a shortwave radio, so I arranged with all the radio repairmen in the town that whenever they were going to junk a radio, they should set it aside and I would pick it up. I got all these old radios -- really classics now -- that I stripped. I had huge transformers and loudspeakers and huge condensers -- the whole works. Boxes full of this stuff. I didn't understand it. I didn't know a thing about it. I just liked to take things apart and learn how to solder. I discovered out of my collection of parts -- with the tuning condensers (with movable plates), the knobs, and all that stuff, that I had what seemed to be needed in this one page diagram of a shortwave receiver.

Share Your Favorite Quotes

Know a quote that's missing? Help grow our collection.

Mechanical drawings and blueprints are not mere pictures, but a complete and rich language. In blueprint language, scientific, mathematical, and geometric formulations, notations, mensurations, and naming do not merely describe an object or process, they actually model it. Because of broad differences in subject, purpose, roles, and the needs of the people who use them, many forms of blueprint have evolved, but all rigorously present well structured information in understandable form.

Enhance Your Quote Experience

Enjoy ad-free browsing, unlimited collections, and advanced search features with Premium.

The first paper I ever wrote was "Gestalt Programming" and that was in 1955. The whole idea there was to replace the laborious writing out of detailed programs and all those steps by having analyzed a problem area well enough so that you had what I later came to call a "systematized solution." Then you could compose different problems of this class by just plugging together pieces of program, and they would in turn be controlled by a pushbutton language. The user would make a number of discreet selections. It's just like nowadays it's done with menus, and when you had indicated all the pieces that you wanted to put together--by these mnemonic names and words for things associated with buttons, switches, with one meaning "period," essentially, for that sentence, you see--all these things would be brought together and that would be the man/machine, manual-intervention mode of problem-solving. I took over the term from studying Gestalt psychology, meaning that everything was brought together at once, as a unit, instead of this laborious step-by-step build-up.

Computer-aided design is not automatic design, although it must include many automatic design features. By automatic design we mean design procedures which are capable of being completely specified in a form which a computer can execute without human intervention.

Neither Watt's steam engine nor Whitney's standardized parts really started the Industrial Revolution, although each has been awarded that claim, in the past. The real start was the awakening of scientific and technological thoughts during the Renaissance, with the idea that the lawful behavior of nature can be understood, analyzed, and manipulated to accomplish useful ends. That idea itself, alone, was not enough, however, for not until the creation and evolution of blueprints was it possible to express exactly how power and parts were to be combined for each specific task at hand.

The assertion that a problem unstated is a problem unsolved seem to have escaped many builders... All too often, design and implementation begins before the real needs and system functions are fully known. The results are skyrocketing costs, missed scheduled, waste and duplication, disgruntled users and endless series of patches and repairs euphemistically called "systems maintenance"

It is very difficult to define what is meant by computer-aided design since the complete definition is, in fact, the sum and substance of the total project effort which has only begun. It is much easier to describe, what is not computer-aided design as we mean it.

There is a rigorous science, just waiting to be recognized and developed, which encompasses the whole of 'the software problem,' as defined, including the hardware, software, languages, devices, logic, data, knowledge, users, users, and effectiveness, etc. for end-users, providers, enablers, commissioners, and sponsors, alike.