When we looked at a one bit program being written, we saw the need to find a mapping between the problem domain and the system semantics that fulfil the desire. Obviously, the less rich the possible set of mappings is, the easier it will be to find a useful one, assuming it exists. Any given problem domain will have its own inherent complexity, and every instance of a problem within it will have its own unique complexities. When we have a problem, however, it is what it is. We can rarely change its definition to control its complexity (although sometimes it is both possible and desirable, and thus A Good Thing). So in search of leverage, the most effective way to get the job done, all we can play with are the system semantics.
At one end of this spectrum is the COTS product. Load it, run it, the job is done. At the other is the processor's instruction set, which allows us to organize any behaviour the hardware is physically capable of. Between these extremes are a variety of layered semantics that simplify the mapping by restricting the semantics.
In these terms, a language is any kitbag of semantics. C is a language, but so is Excel and so are GUI builders. The kitbag sits there but doesn't give you any clue how to use its contents. Languages are specialized by problem domain to offer greater chances of achieving simpler mappings to any given problem within the chosen domain. To decide if one wishes to make a choice of one semantics (language) over another, the criterion is usually to ask which requires the simpler mapping (the simpler program) to get the job done. Beyond the most trivial cases, this requires familiarity with both kits in use.
Although we can get a clear understanding of what a language is, a methodology is harder to pin down in these terms. We suggest that the reason for this is that the idea of a `methodology', as it is commonly encountered, includes the default assumption that it is a procedural approach to solving programming problems, and we know there is no such thing. What we can describe instead, for now, is something slightly different - an approach.
An approach consists of advice, given by one experienced mapper to another, about how best to tackle a kind of problem. It is an invitation to see the world in a certain way, even if it is phrased as procedural guidance. The injunction Draw a Data Flow Diagram showing weekly inputs' in a book called How To Build A Payroll System, is actually saying, Constrain your world-view to a weekly batch input system, and list the batches the world throws at you.'
This is sound advice for the builder of a payroll system, provided the work patterns it is to reward can fit into weekly batches. Like a language, the approach gets simpler the more it is specialized to a given domain. Also like a language, the approach is hard to select appropriately without an understanding of the currencies' of the available approaches, and the problem. With more clever developers writing COTS products every year, which automate an approach to form a highly domain-specific language that any idiot can work, the likely future leverage for good programmers is going to be in familiarity with deep, profound approaches, and deriving new approaches in the face of new problems. There will likely always be hordes of people using the same approach to ritualize the production of the same billing system for another client. They may well be always retraining to new methodologies'. But they are and will remain, clerical workers, and the gap in performance and rewards between clerical workers and programmers is going to widen. This is what it means to be a player in the information age.
There are some languages that are specialized to particular approaches. Smalltalk requires the user to see the world as objects. Lisp requires an unhealthy relationship with the lambda calculus that leads to proposing the dog of food instead of feeding the dog.
The point that languages are real, and approaches are real, but methodologies are a figment of our collective imaginations and do not exist must be emphasized. Confusion on this point and an unfortunate choice of approach can lead to situations where critical parts of the problem are not addressed because the approach happens not to speak of them, while those who attempt to deal with the issues are hampered by their colleagues who feel that they are acting unprofessionally' by notapplying the methodology'. This is an example of the mapper/packer communication barrier.
Interesting methodologies consist of part approach and part language. Jackson Structured Design (JSD) constrains its domain of applicability to problems with clearly identifiable features and is then able to offer quite detailed guidance on how to address instances of those kinds of problems. Keep your eyes open and JSD will serve you well in its domain. Outside its domain, however, it can cause problems because if the problem doesn't have Jackson's features, no end of kludging will make a good system out of a bad understanding. This is not Jackson's fault, as he never said that JSD was a ritualized panacea for solving all computer problems.
At the output end of JSD, we see something quite unusual, an artefact of its time. Jackson describes how to transliterate from his diagrams into code, by hand! He is clear that this is what he is doing, and explains that the automatism of this task allows us to break the rules of structured programming and use gotos. Today he would not do this - he'd just hand the diagrams over to a code generator as many others do. The point is, the diagrams of the JSD notation are best considered a programming language! Jackson has created a language that is specialized for an approach to a problem domain.
The same is true of the Booch, Rumbaugh and Unified Modelling Language approaches and languages. In fact, very interesting methodology. In Booch and Rumbaugh's earlier publications, they did not hand the diagrams over to code generators but showed that the translation of most of the diagrams was largely mechanical. Don't worry too much for now about the methods one fills in by hand - the whole point about these is they are not complicated!
The creation of a language and approach, more or less specialized for a domain, is a great achievement. In doing so, the authors must have dwelt long on how best to navigate about problems, chunk them, explore them, see them in different ways, and designed their approach and language accordingly. But many seem to get confused by the mapper/packer language barrier and feel the need to omit the emphasis on creative thinking needed to find the mapping between the problem and their language. Instead of presenting their approach as a structure, and suggesting some heuristics for seeing a problem in terms of it, they feel the need to use a procedural language, and describe actions to be taken, in the imperative voice. If someone hasn't been encouraged to think creatively, ie, construct a mental map of their problem through daydreaming and then explore it, what choice do they have but to follow this procedural misdirection, and their results will inevitably depend on luck. Jackson is good here. He specifically limits his domain and tells the reader what features to look for. The reader starts by searching the problem and looking for clues. Booch includes an interesting section on finding the objects, which if only it had gone deep and wide enough would have rendered this course unnecessary because it addresses exactly the right mapper issues. Finally, Stroustrup's book describing the C ++ object approach and language is a celebration of style, insight, structure, depth, and creativity. It is a hard book describing a complex programming language, but it is written by a great mapper at play, who seems to have no internal confusion about these issues.
Top comments (0)