There are many, many opinions on how one should start to program. While some of these opinions will undoubtably be expressed in this page, the real point is to discuss the somewhat theoretical requirements for optimal programming environments (not IDEs) for those who have never programmed before, or those who have only dabbled. Please let me know what you think of the below so that I can improve it and perhaps make it into a valuable resource.
FYI: the below is most definitely in draft stage, perhaps just in the brainstorming stage.
It is extremely important to have one or more motivating projects to work on when learning to program. The starter project will direct the choice of programming language (alternatively, choosing a programming language will narrow the reasonable starter projects). Example starter project/language combinations follow; note that ".NET" means any .NET language, including C# and VB.NET (the author prefers C#).
Every additional step required to successfully [compile and] execute programs written makes success exponentially harder. <Enter the discussion about whether an IDE is good or bad.>
Usefulness of error messages is quite important. For example, some C/C++ compilers will often produce a plethora of confusing errors when a semicolon is omitted.
Whether or not it is desirable to have an advanced debugging facility is questionable; it is possible that introducing such a feature at an early stage could foster an unhealthy dependence upon it. On the other hand, stepping through code is an excellent illustration of how the code is executing, and how one can visualize it executing in one's head.
Ability to read documentation, no matter how bad, is a crucial skill which should be developed early. A huge problem here is that documentation is typically written with a proficient programmer as the target audience.
Learning to program without a mentor or at least someone to critique one's code can be disasterous, crippling, or at least an impediment. Bad habits and fundamental mistakes are much easier to correct early.
Any decision performed by code is based on evaluating some expression, resulting in a value that can be converted to true or false. Boolean logic is often used (in which case the terms in said expression are themsleves true or false); some languages allow other data types to be converted (e.g. integers other than zero are true).
Execute one set of code if an expression is true and optionally another if it is false.
Repeatedly run a set of code while some expression is true.
Boxes in which data can be stored.
Blocks of code which can be run by other blocks of code.
Fuzzy thinking (not fuzzy logic) has no place in programming. Computers do exactly what they told, no less and no more. The only context available is the code being executed and data being processed. <This needs work.>
Humans operate in a very different way than computers; we deal with relatively few concepts at a time, concepts which can be as simple as turning on an LED or as complex as calculating taxes. On the other hand, computers simply crunch numbers, performing one [relatively] simple operation (or instruction) at a time. This difference is best overcome by abstracting functionality so that one only has to deal with the information relevant to the particular issue at hand.
In addition to limiting the amount of information one needs to process when viewing a program at a given angle, one should also limit the scope and detail of information being processed in any given block of code.
The real power of OOP is that it can model the way the mind operates quite well. It encourages one to think of programming as a series of "loosely coupled" black boxes. When was the last time you needed to understand semiconductor physics to make a call on a mobile phone? You didn't need to know the processor model, the LCD type, and so forth. All you needed to know was that it was a phone, perhaps that it was a mobile phone. OOP simply encourages thinking abstractly, encapsulating information in order to reduce the complexity one has to deal with at a given point in time, and making use of relationships between like objects in a way computers can understand innately.
Ignore the following; examples need to be provided and it needs to be reworded: OOP is often taught in a horrible manner, with useless examples that don't convince one of much besides the fact that OOP is different from other approaches.
As mentioned above, the choice of language and choice of starter project are related. There was, is, and will continue to be much debate about the best "first language". On the one hand, it would be good for syntax complexity to correspond to complexity of programming task. On the other hand, the really powerful languages tend to carry along extra syntatic baggage that confuses the beginner.
Whatever the language chosen, it is important to have access to decent examples, documentation, and people. Useful libraries are nice, but not necessary for the beginner.
As mentioned under Programming Environment, the more steps required to get something working, the harder it is to get that thing to work. If one out of five [known] combinations is guaranteed to work, finding the right combination is trivial. However, if 100 out of 50,000 combinations are known to work, one could expend quite a bit of frustration trying to find a working combination without some sort of aid. The beginner's programming language should have the proper documentation/structure to not fall into the second category.
back