A programming language functions at many different levels and has many roles, and should be evaluated with respect to those levels and roles. historically, programming languages have had a limited role, that of writing executable programs. as programs have grown in complexity, this role alone has proved insuffi- cient. many design and analysis techniques have arisen to support other necessary roles. object-oriented techniques help in the analysis and design phases; object-oriented languages to support the implementation phase of oo, but in many cases these lack uniformity of concepts, integration with the development environment and commonality of purpose. traditional problematic software practices are infiltrating the object-oriented world with little thought. often these techniques appeal to management because they are outwardly organized: people are assigned organizational roles such as project manager, team leader, analyst, designer and programmer. but these techniques are simplistic and insufficient, and result in demotivated and uncreative environments. object-orientation, however, offers a better rational approach to software development. the complementary roles of analysis, design, implementation and project organization should be better integrated in the object-oriented scheme. this results in economical software production, and more creative and motivated environments. the organization of projects also required tools external to the language and compiler, like ‘make.’ a reevaluation of these tools shows that often the division of labor between them has not been done along optimal lines: firstly, programmers need to do extra bookkeeping work which could be automated; and secondly, inadequate separation of concerns has resulted in inflexible software systems. c++ is an interesting experiment in adapting the advantages of object-orientation to a traditional programming language and development environment. bjarne stroustrup should be recognized for having the insight to put the two technologies together; he ventured into oo not only before solutions were known to many issues, but before the issues were even widely recognized. he deserves better than a back full of arrows. but in retrospect, we now treat concepts such as multiple inheritance with a good deal of respect, and realize that the unix development environment with limited linker support does not provide enough compiler support for many of the features that should be in a high level language.(c++ was developed in the mid-eighties supported non-specialized tools found in the unix program development environment.) there are solutions to the problems that c++ uncovered. c++ has gone down a path in research, but now we know what the problems are and how to solve them. let’s adopt or develop such languages. fortunately, such languages have been developed, which are of industrial strength, meant for commercial projects, and are not just academic research projects. it is now up to the industry to adopt them on a wider scale. c++, however, retains the problems of the old order of software production. c++ has an advantage over c as it supports many facets of object-orientation. these can be used for some analysis and design. the processes of analysis, design, and organization, however, are still largely external to c++. c++ has not realized the important advantages of integrated software development that leads to improved economies of software production. java is an interesting development taking a different approach to c++: strict compatibility with c is not seen as a relevant goal contrary to the initial goal of c++ to be as compatible as possible with c. java is not the only c based alternative to c++ in the object-oriented world. there has also been objective-c from brad cox, and mainly used in next’s openstep environment. objective-c is more like smalltalk, in that all binding is done dynamically at run time. a language should not only be evaluated from a technical point of view, considering its syntactic and semantic features; it should also be analyzed from the viewpoint of its contribution to the entire software development process. a language should enable communication between project members acting at different levels, from management, who set enterprise level policies, to testers, who must test the result. all these people are involved in the general activity of programming, so a language should enable communication between project members separated in space and time. a single programmer is not often responsible for a task over its entire lifetime, let alone responsible for the whole development process and product.
C, C++, Computer Science, School level computer
_1471089307_57af0a9bcbda6_224923-1.jpg)
