It´s tricky trying to explain Software Engineering to people who know nothing about Software. It´s difficult enough explaining it to Programmers. But explaining Programming, and Programming languages to people who know nothing about Computers is comparatively easy.
I´m giving it a shot anyway. This post attempts to explain programming to non-programmers, though even they might find an insight or two.
Anyone who's ever followed a recipe when cooking has "executed a program". A program is merely a set of data (ingredients) and an algorithm (method) for manipulating the data. So a recipe for French Toast may say something like "Take an egg, and a slice of bread. Beat the egg, then dip the bread in it until soaked. Then put the bread is a lightly greased saucepan and cook till golden brown."
The egg and bread are ingredients that get transformed by the process; but the saucepan iand stove are also ingredients too, though they don't change. They're constants.
Such things as the exact size of the egg, and the exact size of the slice of bread aren't stated. It's assumed they´re about average - and that the egg is a hen´s egg, rather than one from a Quail or an Ostrich. It's also assumed that the bread is white, that a normal-sized saucepan is available, that there´s an unstated means of heating it to a reasonable temperature, and the exact amount of grease (and type of oil) is not defined. It´s also not stated what you do with the French toast afterwards, nor that it would be a really good idea not to leave the saucepan heating on the stove after you´ve finished.
There´s an awful lot of assumed knowledge in that simple recipe. It will work very well though, provided the assumptions are valid. Attempt to follow it with a saucepan only 3 cm in radius (as some for cooking fruit for crepes are), or using Pumpernickel, or an Ant's egg, or without a stove, or using a Blast Furnace, and it is unlikely to produce useful results.
Alas, Computers do not have "Common Sense". They won´t check the assumptions unless specifically ordered to do so. Programming a Robot to cook french Toast would be non-trivial. Even getting it to pick up the toast and transfer it into the pan would be a major exercise. The Human Nervous System does some very spectacular processing when picking something up, involving the co-ordination of many muscles, feedback loops so that objects are grasped firmly, neither crushed nor too loosely, based upon the sense of touch.
Next time you cook, or even walk, think about what you´re doing: but be careful. Most functions, like walking, are performed largely automatically, rather than requiring conscious intervention. Consciousness, while immensely powerful, is slow. If you think about things too much you may end up flat on your face.
Programmers have invented a multitude of special notations for writing these complicated instructions. When you get down to the lowest level of the electronics, the computer is capable of understanding only a very few basic operations. To add 2 numbers, for example, might require several separate instructions: one to take a number form memory and put it in a "Register" or place where you can perform mathematical operations. Another instruction to take another number from memory and put in into another Register. A third instruction to take the contents of the two Registers and add them together into one of the two previously-used Registers. And a final instruction to take the result and put it somewhere in memory for later use. All of these instructions are represented by simple numbers, 348 might mean "Add Register 4 to Register 7 and put the Result in Register 4" for example. But it´s more usual to write the instructions in a slightly less cryptic form, in an Assembly Language notation. So instead of writing
348 the programmer will write
ADD R4,R7, which a simple program called an Assembler will translate to
348.
But it´s possible to make more complex programs that take much higher-level, human-understandable instructions like "Let A = A+B;", and have them automatically translated or "compiled" into machine-readable code. And that brings me to the subject of different Computer Languages.
The
Hello World collection is something of a Rosetta Stone for them. It´s traditional for neophyte programmers to learn how to write a program that does nothing but print the words "Hello World!" as their first step in learning a new language. If you have a look at the entry in the collection for, say,
Ada, you will see that there is a lot of impedimenta in even the highest level language. (By the way, there is a mistake in the example, Hello is spelt Hallo in the end Hello; bit, showing how easy it is to make an error in even the simplest task. The example won´t Compile.).
If you´re game, have a look at the
Z-80 Assembler version, which is at a very low level indeed. Most of the words in it are "Comments", text which is not processed by the assembler program, but only there to explain to a human reader what the heck is happening, and why it´s being done that way. You will see why Programmers prefer high-level languages, and why Assembler programmers tend to look down their noses on people who do things the easy way.
Another, more advanced Rosetta Stone is the one for the
Towers of Hanoi game. This game involves 3 poles, and a number of rings with holes in the middle, of differing sizes, with the largest at the bottom and the smallest at the top, all on the rightmost pole. The idea is to move the rings to the left pole, one at a time. You can move the rings to any pole you like, but at no time must a larger ring sit on top of a smaller ring.
Again, take a look at the example for
Ada, and the example for
i860 Assembler.
OK, that´s it. I´ve simplified things a bit, but not by much. You should now have a undertanding of Programming, what it is and what it isn´t. So next time some Geek tries to blind you with Science by saying "I´m translating some FORTRAN into BASIC, but I´d really like to re-do it in Assembler." you will have some idea what that means.
To the extent that her comments hold substance, as has been mentioned by 