Knowing the Language
Originally software was developed line-by-line in a machine language. New programming languages were introduced to overcome the tediousness and error prone machine language, however, software was still developed line-by-line.
Edsgar Dijkstra and his colleagues recommended structured programming, which states that any application can be built with three programming language constructs:
- Sequence, which describes the processing steps to specify an algorithm.
- Condition, which selects processing based on a logical occurrence.
- Repetition, which allows for looping.
This focuses on top-down design, which essentially means breaking your software into independent pieces (or components), which can be individually developed and tested. But software was (and is) still developed line-by-line.
Object-oriented software builds onto structured programming, by stressing information hiding, encapsulating behaviour and state in a clear interface, and reusability to lower the maintenance costs. It particularity prescribes more focus on analysis and design and less focus on coding.
Similar to structured programming, object-oriented software is not tied to a programming language. Certainly programming language features help, it is a higher-level abstraction layer. For example, the C Standard Library fopen() family of functions use object-oriented concepts in C, which is not an object-oriented programming language. And similar to structured programming, it is still line-by-line.
The difference between the machine language and the "new programming languages", the difference between these programming languages and the ideas of structured design, and the difference between structured design and object oriented software is the level of abstraction. Although we are still looking at software in a line-by-line fashion, what those lines means is completely different.
I have been asked several times which programming language beginners should learn, and my answer is that it does not matter, because the important part is learning the abstractions and how to think out-side of implementation details. Most programming languages are similar in many ways, and once someone understands the abstractions of software, such as a class, a package, design patterns, etc., this provides an abstraction layer to think in when thinking about software. Implementation details such as a C++ std::list is a homogeneous list of any type verses Java's java.util.List can be heterogeneous but only of non-primitives is extraneous. When you sit down to code your design, you will deal with these issues, but when you are thinking about your problem, these details are not important. The above trend is to focus less on the coding phase, and more emphasis on analysis and design.
Towards Component-Based Software Engineering (a reference for this entry) states that the only way that we can get away from developing software line-by-line is to develop software by using components. In order to develop software like this, we are changing our abstraction layer. Instead of thinking of classes, we are now thinking of a functionality and the interaction of these components to form our application.
I think this is more of perhaps a holy-grail, where our development tools would simply take a UML diagram and a set of components, and from this, generate our applications for us, similar to the 4GLs. In the interim, however, these components must still be built line-by-line (or at least the majority of components), and some glue must be created in to join these components together. But this is not the point; the point is that we are again in a paradigm shift where our abstractions levels are changing so that we think again at a higher abstraction layer.
The more abstract that software engineers think in, the larger the problems that can be solved. Most of us do not develop software in machine language because it would take too long to create the extravagant software we have today. Each abstraction has allowed us to solve larger problems, and today, more than ever, it is not enough to simply know a programming language. Knowing programming languages does not qualify one as a software developer. Knowing how to create software is, by far, more important than programming languages.