Author : Ian Joyner
Page : << Previous 16 Next >>
in C if and while statements have to have
parentheses around them?)
C++ is overly complex. C is widely recognised as being a simple
language. But even this is doubtful, as it has many operators, and a
difficult precedence system. Its pointer style of programming is
difficult. Overall, C has many traps that lead to difficult to detect
errors in software. Object-oriented languages should provide
sophisticated concepts in the simplest possible framework. Where the
framework is not simple, the concepts are obscured. OOP addresses many
issues in order to facilitate the production of complex and
sophisticated programs. Many of these issues are addressed in implicit
and subtle ways, but are lost in C++. Subtle errors can be introduced
into C++ software in many ways, and furthermore, the combination of
these will cause even further problems. C++ has devices for petty
convenience, while sacrificing major conveniences and long-term
correctness and safety. C++ forces the programmer to perform many
administrative bookkeeping tasks that a compiler can easily do.
It can be considered what application domain C++ is relevant for? The
answer to this is that C++ might be used as a better C. But for what
applications is C relevant? C is relevant for low level Unix systems
programming. It is not a generally applicable language in view of its
low level nature, and its flaws. C is not applicable for large scale
production. Hence C++'s attempt to improve it. C++, however, has not
solved C's flaws, as I once hoped it would, but painfully magnified
them. Better languages exist for higher level functions such as
communications and networks, scientific work, compilers, etc. I
envisage that C has a place as a high level assembler that can be used
to implement small pieces of code on suitable platforms, where
efficiency is of prime importance. Thus the use of C would be limited
and well controlled, rather like small assembler routines are currently
used in some systems for the same purpose. Indeed the move to C++
should only be considered in the case of upgrading a body of C programs
for backwards compatibility. In the case of new projects alternatives
to C and C++ should seriously be considered.
Programming is the orchestration of change within a large state
space. Object-oriented techniques provide a method of simple division
and management of such state spaces. Managing such state spaces
requires the simplest techniques, in order to guard against detectable
inconsistencies that lead to errors in executable systems. C and C++ do
not implement the simple management of a large state space, and allow
many potential errors to go undetected. The role of a language as a
tool cannot seriously be regarded as some authoritarian that stops us
doing what we want or need to do, as many languages with type safety and
consistency checks are often viewed. Programming languages should
embody the collective wisdom of common sense practices that have been
learnt over many years, by common and painful experience. C++ lacks the
implementation of much of this wisdom. [Sakkinen 92] observes that much
of the C++ literature has few references to external work or research.
It fails to draw on the insights and progress made by many researchers.
This leads me to believe that C++ is parochial and removed from the many
advances that will make production of systems easier and more cost
effective.
It is better to detect and avoid errors than to fix them. The fixing
of errors happens many times during the development process. This slows
down the development process, and is therefore costly. Good programmers
in this context (often called 'gurus'), are those who recognise
symptoms, and recommend fixes. Good programmers in the better sense
(often called 'impractical idealistic dreamers') adopt better practices
(programming languages being a subset of these), that avoid error in the
first place.
C encourages gurus who spout false wisdom on obscure subjects.
Writing programs in C is often referred to as 'coding'. Coding is
writing obscure encryptions that will later have to be decoded, by none
else than a guru! C also encourages programming by guesswork. C
programmers often solve 'bugs' by adding extra ()s, *s and &s, without
understanding the problem. People who attain proficiency at this
guesswork, are known as, well you guessed it, gurus!!
The view that correctness checks are training wheels for students,
which gurus don't need must be dispelled. Many disciplines have
techniques to ensure correctness. For example, the metronome in music
is not just for students, but will help an advanced musician ensure that
the tempo of a piece is correct, and since playing to a metronome is
more difficult, will help sharpen the musicians performance of the
piece. The musician does not just view the metronome as an aid for
beginners, or as something that restricts him to a set beat, but as a
tool that helps produce a polished and professional performance. C
should not be seen as a language to which you graduate after you have
learnt to program in languages with safety checks. In fact changing to
C or C++ is a great step backwards. Languages with consistency and
semantic checks are essential aids to the production of professional
software.
This paper has shown many cases where C++ uses old C mechanisms to
provide things that can and should be expressed consistently within the
object-oriented paradigm. For example type casting. The move to pure
object-oriented languages will facilitate more consistent programming
and avoid many typical errors that occur in software production. C++
also makes distinctions that belong in the 'how' implementation domain.
For example, '.' vs '->, and variables and functions. These make
bookkeeping work for programmers, which should be handled by a compiler.
But then C++ fails to make distinctions that belong in the 'what'
problem domain. For example, procedures vs functions. Making
distinctions in the 'how' domain adds inconvenience to the language.
Failing to make distinctions in the 'what' domain limits the power and
expressiveness of the language. The amount of change required in C++ to
address the issues raised in this paper is seen as largely
insurmountable.
A programming language is just a tool, in the same way that an axe is
a tool. If the axe is blunt when chopping down a tree, then procedures,
processes and methodologies could be invented to make it as effective as
possible. But that leaves the real problem unsolved; that the axe that
does the real work is blunt. So it is with programming languages. To
develop a system, it must be implemented, and a programming language is
the tool to do the real work. If the language is blunt, then
procedures, processes and methodologies might alleviate the situation,
but they do not solve the problem. Once the axe is sharpened, then real
progress is made, and the procedures, processes and methodologies also
become more effective. A good axeman will have good axe wielding
technique, but given a choice of axes will choose the sharpest
implement. A poor axeman could be ineffective with even a sharp axe,
but the axe maker will still strive to produce the sharpest axe for the
good axeman. The argument that poor programmers will produce bad
programs in any language so we shouldn't bother with better languages is
fallacious.
As mentioned in the introduction, both sides of the analysis/design
vs implementation debate need to compromise in order to bridge the
semantic gap. The perpetuation of low level languages such as C into
OOP is proof that the programming community is not willing to
compromise, or sharpen its axe enough in order to bridge this costly
gap.
The critique began with certain questions, and as no work can be
absolute (particularly a programming language), it will end with more
questions that it is hoped will create more debate, and more questioning
into what we are really trying to achieve with program development.
Does C++ provide effective communication between programmers
separated in both space and time? Does C++ provide communication between
the levels of analysis, design, implementation and maintenance?
Are the compromises made by C and C++ still relevant to today's
environments, and the environments of the not very near future?
Could C++ be regarded as the PL/1 of the object-oriented world, as
PL/1 was the marriage of FORTRAN and structured ALGOL concepts, and C++
is the marriage of C with object-oriented concepts?
Are the compromises made for the restricted machines and environments
of 20 years ago still appropriate for today? Are languages based on 20
year old compromises appropriate in modern software development
environments?
Should new software developments be forced to accept such compromises?
Is C++ patching old material with new cloth, or pouring new wine into
old wineskins?
What are we really trying to achieve in programming anyway?
Ian Joyner
November 1992
C++ ARM Ellis and Stroustrup "The annotated C++ Reference Manual"
AT&T 1990.
[Capretz 87] Pierre J. Capretz "French in Action, A Beginning
Course in Language and Culture" Yale University Press.
[Cline] Marshall Cline "C++ Frequently Asked Questions"
comp.lang.c++ newsgroup.
[Crystal 87] David Crystal
Page : << Previous 16 Next >>