In this Assignment, I shall be going through the stages and milestones, which lead to the development of two successful programming languages, C++ and Java. The programming language C influenced greatly C++, and therefore I felt it was necessary to delve deeply in this programming language as well. This assignment also includes the decisions taken by their respective creators and the reasoning behind them.
The C Programming Language
Between 1969 and 1973, the programming language C was under development at Bell Labs, by Dennis Ritchie.  During the same period, the operating system UNIX was under development as well. In this section, I make most of my references to texts written by Dennis Ritchie himself in the book “History of Programming Languages”.
Before C, during the late 60s, Bell Labs were passing through difficult times, mainly due to the fact that the development of the Multics project was halted because the beneficial use of the GE-645 Multics machine would not be available on time and would be too costly. However, during and after the disposal of the machine, an “informal team”, lead by Ken Thompson, began to research and develop other alternatives.
If you need assistance with writing your essay, our professional essay writing service is here to help!Essay Writing Service
Ken Thompson aimed in constructing a comfortable work environment by using any resources available to him. His design involved implementing some similar ideas of Multics, such as “an explicit notion of a process as a locus of control, a tree-structured file system, a command interpreter as a user-level program, simple representation of text files, and generalized access to devices.” However, Ken Thompson also excluded other certain aspects, including “unified access to memory and to files”. Furthermore, instead of using PL/I which was the implementation language of Multics, Thompson and his team used another programming language known as BCPL. Just like PL/I, BCPL was also a high-level language; a great advantage which Thompson did not want to let go due to its clarity and simplicity, unlike assembly language.
The B Programming Language
In 1968, Ken Thompson was faced with a problem with the PDP-7, a machine for which he had no compatible software available. Ken Thompson then created his own PDP-7 assembler, but it was in 1969, that Doug Mcllroy created the first high-level language for the system. This language was an adaptation of the programming language known as TMG, which was created for the PDP-7 by R. M. McClure. Dennis Ritchie describes TMG as “a language for writing compilers (more generally, TransMoGrifiers) in a top-down, recursive-descent style that combines context-free syntax notation with procedural elements”. TMG had been used to create the compiler of PLI for Multics. Ken Thompson then felt it was necessary for UNIX to have it’s own system programming language. After a reluctant effort to use FORTRAN, Thompson later designed a new programming language named B. The B programming language was developed mainly based on BCPL. Moreover, Dennis Ritchie describes B as “BCPL squeezed into 8K bytes of memory and filtered through Thompson’s brain”. He then mentions that most probably, its name came about by representing a “contraction” of BCPL. However, he might have chosen it as a dedication to his wife Bonnie.
Development was first completed by creating a TMG version of B, where Thompson then rewrote B in itself. Dennis Ritchie recalls that during this stage of development, Ken Thompson found the memory limitation to be a great challenge, as “each language addition inflated the compiler to barely fit”. However, each re-write, due to the beneficial feature, “reduced its size”. Dennis Ritchie continues by mentioning an example. He stated that, originally coming from ALGOL 60, B generalized assignment operators such that x =+ y was used to add x to y. The operator was then corrected to spell x += y back in 1976. Thompson was more innovative as he created new operators such as ++ and – – to increment and decrement. The position of these operators, written as postfix or prefix, would determine whether the change in value would “occur before or after noting the value of the operand”.
Instead of producing machine code, the PDP-7’s B compiler generated “threaded code”, in which the compiler’s output was made up “of a sequence of addresses of code fragments that perform the elementary operations”. In the case for B, these operations worked on a straightforward stack.
However, due to the fact the PDP-7 machine was too small and slow, not much was written using B, “except for B itself”. It only served them for experimental use. Re-writing UNIX on this machine proved to be too much of an expensive step. Furthermore, Dennis Ritchie reports that at a stage, Ken Thompson expressed the “address space crunch by offering a ‘virtual B’” which made it possible for the interpreted program to take up more than 8k bytes. This was done by “paging the code and data within the interpreter”. However, it was then concluded that it would not be feasible enough and would result in being too slow “for the common utilities”. Despite all this, some utilities were still written in B, such as an early version of the variable precision calculator known as dc.
Around this time, Dennis Ritchie also recalls working on an “ambitious” project, which mainly involved creating a genuine cross-compiler capable translating B to GE-635 machine instruction instead of thread code. Dennis Ritchie then comments that this task was only possible due to the practicality and ease of the B language.
The Unix project had proven itself so well, that they managed to get a PDP-11 at Bell Labs. By using the “the threaded technique” in order to run programs written in B on this machine, it was only necessary to write “the code fragments for the operators, and a simple assembler” in which the latter, Dennis Ritchie created himself. The “first interesting program” to be tested on the PDP-11, before any operating system software, was dc. Furthermore, around the same time, Ken Thompson managed to record the “UNIX kernel”, along with some simple commands written in PDP-11 assembly language.
Later in his paper, Dennis Ritchie mentions that apart from B’s advantage regarding its simplicity, it also had its problems mainly related to the PDP-11. He states that the machines, on which Bell Labs initially used BCPL and also B, were “word-addressed”. Furthermore, he continues by stating that these languages only handled one single data type, known as the “cell”, which would simply be “equated with the hardware machine word”. However, with the introduction of the PDP-11, a manifold of “inadequacies of B’s semantic model” were clearly visible, one of which was that its character-handling mechanisms tracking back to few changes from BCPL, were incompetent. For instance, Dennis Ritchie mentions that “using library procedures to spread packed strings into individual cells and then repack, or to access and replace individual characters” did feel strange and at times “even silly”, on a machine based on bytes.
Despite that the first model of the PDP-11 was not capable of calculating floating-point arithmetic, the producer did affirm that this feature would be available shortly. By defining special operators, floating-point operators were added to BCPL in their Multics and GCOS compilers. However, these operators were only possible on certain machines where “a single word was large enough to contain a floating-point number” and therefore could not be used on the 16-it PDP-11. Another inadequacy was that B and BCPL suffered from overhead due to pointers. This was because the languages’ basis, “by defining a pointer as an index in an array of words”, restricted pointers to be represented as “word indices”. For each pointer reference, it generated “a run-time scale conversion” from the pointer to the corresponding byte address intended by the hardware.
Due to all of these reasons, Dennis Ritchie realised that it was necessary to develop a “typing scheme” to be able to handle characters and byte addressing, and also be prepared to work with the “coming floating-point hardware”. At first, type safety and interface checking was not considered to be vital and therefore were introduced at a later date. Besides the issues with the B language, B compiler’s threaded-code technique made programs run slower than the same programs written in assembly language.
NB and C
In 1971, Dennis Ritchie started to expand the B language and called “the slightly extended language NB, for ‘new B’”. Dennis Ritchie also states that since NB was used for a very short period, no documentation was done. He continues by mentioning that he added a character type and also developed its compiler to produce PDP-11 machine code instructions. Therefore, the compiler was capable of converting programs fast and small enough to contest with assembly language. All in all, NB offered the simple types ‘int’ and ‘char’, arrays of them, and also pointers to them. The semantics of arrays found in B and BCPL stayed the same. Furthermore, inside procedures, the language interpreted pointers and array variables to be identical. Ritchie explains that “a pointer declaration created a cell differing from an array declaration only in that the programmer was expected to assign a referent, instead of letting the compiler allocate the space and initialise the cell”. The values that were held in cells, linked by “array and pointer names”, were bytes of machine addresses relating to their respective memory location. This was beneficial, as an “indirection” through a pointer required no “run-time overhead” to form the pointer from a word to “byte offset”. However, the machine code for “array subscripting” and “pointer arithmetic” was dependant on the actual type of the array or pointer. Dennis Ritchie states that although these semantics made it very easy to transition from B, problems eventually began cropping up mainly when he tried to “extend the type notation”. He continues by explaining his difficulty in implementing “structured (record) types”. At first, it seemed structures should link correspondingly onto memory in the machine. However, the major issue was that for a structure containing an array, there was no ideal location to store the pointer containing the base of the array, or a practical way to initialise it. 
The goal of Dennis Ritchie was that a structure would not just “characterise” an abstract object but also “describe a collection of bits that might be read from a directory”. He describes the solution in achieving this goal as “the crucial jump in the evolutionary chain between type-less BCPL and typed C”. Rather then having a “materialization of the pointer” located in memory, the pointer would be created only when the array name is refereed to in an expression. Moreover, values of type array, once mentioned in an expression, would change its values to pointers to direct to the objects making up the array. Despite the fact that the semantics of this new language had shiftily changed, most code written in B could still be used. Furthermore, this language also differed from its predecessors as it offered a “comprehensive type structure” and “expression in the syntax of declaration”.
After creating the “type system, the associated syntax, and the compiler”, Dennis Ritchie believed that this language deserved its own name, as when compared to NB, they were very distinctive. Therefore, he called the programming Language C, “ leaving open the question whether the name represented a progression through the alphabet or through the letters in BCPL”.
UNIX benefited greatly due to C. It made improving and maintaining UNIX very easy for any programmer who had an understanding of C.  Furthermore, it also made UNIX easily portable for newly developed computers.  This is mainly because it was unnecessary to convert the operating system to assemble language manually, but only required a C assembly compiler for that particular machine.  This compiler translates the code into machine code that the device understands.  C has gained a huge amount of success over the years and is still presently used in development. It is mainly known for its fast speed. 
The C++ Programming Language
The book “History of Programming Languages” also contains a paper written by Bjarne Stroustrup, the creator of C++. In this paper, he narrates the history of the C++ programming language, focusing more on the ideas, limitation and “people that shaped the language”.
More or less, Stroustrup begins his paper by stating that C++ was based on an “earlier version” of a programming language known as C with Classes. However, before going into further detail, he begins discussing the prehistory of all this. At Cambridge University, whilst working on his Ph.D that dealt with the study of different methods regarding the organization of software for a distributed system, Stroustrup focused on developing software “out of well-delimited modules” and also created experimental simulator “tool” in order to simulate “software running on a distributed system”. This first version of the simulator was developed in Simula and ran on the University’s IBM 360/165 mainframe.
It was very beneficial for Bjarne Stroustrup to use Simula, stating that: “the features of Simula were almost ideal for the purpose and I was particularly impressed by the way the concepts of the language helped me think about the problems in my application”. Particularly, the behaviour of classes allowed Stroustrup to link directly the application of his ideas to the language constructs easily, especially due to the fact that classes in Simula are able to behave as co-routines. He states that the use of class hierarchies enabled him to declare “variants of application level concepts”. He continues by explaining further, through an example, that different types could be described as classes deriving from other classes. The following are his exact words: “For example, different types of computers could be expressed as classes derived from class computer and different types of intermodule communication mechanisms could be expressed as classes derived from class IPC”.
Other benefits of Simula were its type scheme and the ability to detect type errors through its compiler. The detection of a type error was either caused by some “silly” mistake, or due to some “conceptual flaw” in the design, in which both cases, especially the latter, helped Stroustrup greatly. He had not experienced such beneficial use with other “more primitive ‘strong’ type systems”. Furthermore, referring to his simulator, when the program increased in size, due to Simula’s class, co-routine and precise type checking mechanisms, flaws and errors would not grow alongside. On the other hand, the implementation of Simula did not “scale in the same way” and nearly resulted in creating a disastrous program. Stroustrup concluded that Simula was ideal for writing small programs but suffered “inherently” for larger ones due to its poor run-time performance characteristics.
Today, Simula implementations have improved greatly, but at that time, in order to avoid terminating the project, Stroustrup rewrote the simulator in BCPL. He found programming in BCPL a very “horrible” experience, mainly due to its lack of type checking and run-time help. However, once the simulator was developed, the program ran competitively fast.
Once he graduated from Cambridge, Bjarne Stroustrup promised himself that he would never attempt to solve a problem with those impractical tools as he had “suffered while designing and implementing the simulator”. However he did define what is a “suitable tool” for writing system programs, which was highly significant when he was developing C++. 
In Stroustrup’s eyes, a “suitable tool” involved the following characteristics. Firstly, it would have Simula’s support for program organisation and thus include classes, the ability to form class hierarchies, concurrency mechanisms, and a good type-checking scheme relating to classes. Secondly, it must also be capable of producing programs possessing similar speed as to BCPL programs, and also allow the combination of independently compiled units into a program. Lastly, it must allow the ability to create highly portable implementations.
C with Classes
The undertaking, which eventually lead to developing C++, began in 1979, when Bjarne Stroustrup tried to understand the UNIX kernel, in order to find out the limit that could be distributed over a network of computer via a local area network (LAN). This work took place in the Computer Science Research Center of Bell Laboratories. With little time, Stroustrup faced two sub-problems, namely, “how to analyse the network traffic that would result from the kernel distribution and how to modularize the kernel”. They both required a way to describe the model structure of a complicated system and the communication trends of the modules, issues extremely similar to the kind that Stroustrup was eager to never have to face again without the suitable tools. Therefore, by referring to the criteria he had stated upon leaving Cambridge, Bjarne Stroustrup began to develop his own suitable tool. By October of 1979, he had a preprocessor called Cpre. 
Cpre was able to add “Simula-like classes to C”, and in March of 1980 this processor had been upgraded to actually support one “real project and several experiments”. Later that year, between April and October, Stroustrup mentions that he let go of the ideal of “thinking about a ‘tool’” but rather began “thinking about a ‘language’”, to develop what is known as C with Classes. However, initially, he did not consider C with Classes to be an independent language but just an expansion to C for “expressing modularity and concurrency”. C with classes did not support primitives for expression. Instead it included a mix of inheritance and offered a way to define class member functions with “special meanings” understood by the preprocessor, which was used to develop the library that handled the required “styles” of concurrency. Stroustrup emphasises on the word “styles” and that it is written in plural. He found it vital that numerous notations of concurrency are able to be expressed in the language. Backed by colleagues, other C++ users and the C++ standards committee, to this day he still believes that this was the right decision. He then continues on this topic by stating that there in “no one dominant model for concurrency support”, and making use of a library or a special purpose extension for support on a particular form of concurrency would not limit others in using different forms. Therefore, “the language provided general mechanisms for organising programs rather than support for specific application areas”.
It was not only in this instance that Bjarne Stroustrup did not force programmers to use a particular style. C is capable of computing numerous low-level operations, such as bit manipulation and choosing between different sizes of integers. Furthermore, although C++ systematically eliminates the need to use such low-level operators due to safety, they are still available for programmers to use, as Bjarne Stroustrup did not wish to restrict them in any way. In fact, quoting his exact words, he states “I strongly felt then, as I still do, that there is no one right way of writing every program, and a language designer has no business trying to force programmers to use a particular style. The language designer does, on the other hand, have an obligation to encourage and support a variety of styles and practices that have proven effective and to provide language features and tools to help programmers avoid the well known traps and pitfalls”.
Bjarne Stroustrup continues his paper by explaining further the features available to C with class, a language considered to be a stepping stone in creating C++. C with Classes does not differ greatly compared to C. Due to the fact that a preprocessor was used to implement C with Classes, the language differs only in the newly added features. He lists these features which are shown as below. Note that the last three features were implemented in 1981, whilst the others were implemented one year earlier.
“public/private access control”
“constructors and destructors”
“call and Return functions”
“type Checking and Conversion of Function arguments”
“overloading of the assignment operator”
One of the major features offered by C with Classes was the idea of classes. Stroustrup describes a class as a “user-defined data type”, meaning that it is a custom data type created by the programmer. He continues by stating that “a class specifies the type of the class members that define the representation of a variable of the type, specifies the set of operations that manipulate such objects and specifies the access users have to these members”. In other words, it simply defines the attributes and methods of a data type, including their access rights.
Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.View our services
At that time, Simula did not support local or global variables of class types, and therefore objects of classes had to be “allocated on the free store using the new operator”. After developing his simulator earlier in Cambridge, he considered Simula’s lack of support on variables of class types as a “major source of inefficiency” at run-time. Moreover, after some time, Karel Babcisky, who worked at the Norwegian Computer Centre, published information on “Simula run-time performance” that backed Stroustrup’s thinking. For this reason, Stroustrup wanted to support local and global variables of class types.
The first version of C with Classes did not support “Inline Functions”, and therefore was not initially advantageous of the language’s representation. Stroustrup, in his book, “The C++ Programming Language”, describes an inline specifier on a function as a “hint” to the compiler that it should try to create code for a call. He introduced inline functions to avoid programmers “crossing a protection barrier” that otherwise would result in not allowing the classes to be used hide representation.
Another concept, which Stroustrup thought about deeply, was the linkage model. Stroustrup starts explaining this by stating that to a certain extent, the way compiled programs might link to one another, “determines the features the language can provide”. At the time of implementing C with Classes and C++, he had taken certain decisions regarding this issue. Firstly, that “separate compilation should be possible with traditional C/FORTRAN UNIX/DOS style linkers”. Secondly, type safety should be checked on linkages. Thirdly, it is not necessary for a linkage to need some sort of database, but a database could be beneficial in order to straighten the intended implementation. Lastly, “linkage to program fragments written in other languages such as C, assembler and FORTRAN should be easy and efficient”.
Bjarne Stroustrup also added static types to his language implementation. By his experience with Simula and ALGOL 68, he considered this to be essential in supporting static types. The only difficulty for him was how to implement it. In order not to break C code, Stroustrup decided that he would allow the “call of an undeclared function” and not test type safety on such “undeclared functions”. However, this was a gaping hole in the type system and a great effort was made to lessen the problems relating to this issue. C with Classes had lost the capability to detect run-time errors caused by “simple type errors”. Due to the fact that most programmers that worked with C were reliable on type checks available, finding simple errors was tedious when programming in C with Classes. Thus, a great demand arose to strengthen C with Class’s type system. Eventually, in C++ the issue had been solved by “making a call of an undeclared function illegal”.
Derived classes were also another concept which Stroustrup implemented. However, the C with Classes language did not support Simula’s concept of virtual function until later with the introduction of C++. Similar to Simula’s prefix class notion and Smalltalk’s subclass concept, C++ also supported derived classes. However, Stroustrup gave the names “derived class” and “base class”, mainly due to the fact that he, along with others, had difficulty in recalling what was “sub” and what was “super”. Furthermore, a number of people believed it to be “counterintuitive” as a subclass usually “has more inform than its superclass”. Although there was no support of virtual functions within C with Classes, derived classes were beneficial for creating new data structures based on older ones and linking operations with the resulting types. However, programmers could have simply used an object of a derived class and consider its base class as “implementation details”.
Towards the middle of his paper, Stroustrup mentions the reasons why he chose the programming language C to extend on, rather than Pascal. Although he points out that C is not the “cleanest language ever designed nor the easiest to use”, he selected C due to its flexibility, efficiency, availability and portability.
Between 1982 and 1984, Stroustrup developed the popular programming language C++. Initially known as C84, it was later changed to C++ because C84 was described by Stroustrup as “ugly” and “institutional”.
Compared to C with Classes, C++ includes major upgrades and new features. Listed by Stroustrup, these major additions include:
“Function name and operator overloading”
“User-controlled free-store memory control”
“Improved type checking”
The ability to overload an operator was in demand by many. Stroustrup too liked the concept, and to him, “Operator overloading ‘looked neat’. Although, through his experience of ALGOL 68, he had an idea on how overloading “could be made to work”, at first he was “reluctant”, to add it to C++. The reason for this was that Overloading was known to be hard to implement and therefore resulted in compilers increasing in size. It was also known to be “inherently inefficient” and made code “incomprehensible”. However, if this reputation proved to be incorrect, Bjarne Stroustrup, at that time, admitted that overloading would solve a lot of C++ user problems. He was convinced that overloading would not result in inherent inefficiency. Furthermore, he mentions that “overloading makes code obscure” and it would make their code appear “cleaner”. He also observed the way Overloading would work with classes, and he prepared manual papers to show that the added complexity would not pose any problems. Due to all these reasons, in addition to two hours of work in implementing overloading in C front for demonstrations, Stroustrup had convinced himself to include overloading to C ++.
Among other features, the concept of referencing was added to C++. References were initially added to support overloading. C passed arguments by value. If passing an object by value would result in inefficiency, the programmer is able to pass a pointer. However, overloading operators did not permit this strategy. Therefore, due to the fact that C ++ supports both pointers and references, it does not need means for “distinguishing operations on the reference itself from operations on the object referred to”.
From the initial version of C ++ to the C++ currently available today, a lot of updates and versions were released. Version 2.0 was a great improvement. Amongst other features, it mainly introduced abstract classes and multiple inheritance. Multiple inheritance allows users to have more than one direct base class. However, Stroustrup did admit that adding multiple inheritance in version 2.0 was a mistake, as he felt that this concept was less important than adding “parametrized types”. Parametrized types were later added in version 3.0.
The Java Programming Language
The Java Programming Language was developed by a team Sun Microsystems engineers, led by James Gosling. The project started in 1991 and was released in 1995.
Back in the late 1970s, Bill Joy, the man who many still believe was the first to come up with the “idea of a programming language that later became Java”, wanted to create a language that would consist of the best features of MESA and C. Having attempted to re-write UNIX in 1980, he realised that C++ was “inadequate” to accomplish this task. He wanted a much more powerful tool that is able to write short and effective programs. This longing started to become a reality in 1991, when Sun Microsystems began to develop a language induced by Joy’s idea. The Sun’s project was initially known as the “Stealth Project” named by Scott McNealy. It was during January of that year, when James Gosling, Mike Sheradin, Patrick Naughton and Bill Joy, along with others, organized a meeting in Aspen Colorado, to discuss their ideas for this project. The main aim of the Stealth Project was to conduct research in the area of computers’ use in the “consumer electronics market. The major objective was to create a “smart” consumer electronic device that would accept instructions from a “handheld-romote-control-like device”. In Gosling’s words, he states that “the goal was … to build a system that would let us do a large, distributed, heterogeneous network of consumer electronic devices all talking to each-other”.
The Stealth Project later came to be known as the Green Project. The work that was done by the team was divided as follows: Mike Sheradin worked on business development, Patrick Naughton focused mainly on the graphics system, whilst James Gosling took the task of finding the proper language to use for the project. Before joining Sun in 1984, James Gosling created “the commercially unsuccessful NeWs windowing system as well as GOSMACS”. As described by the site, GOSMACS was “a C language implementation of GNU EMACS.
Oak Programming Language
The language James Gosling initially had chosen to use for Green Project was C++. However, after some time working on it, he found it inadequate for the required task. Therefore, he began adding extensions and changes to C++, which were described as the first building blocks in developing an independent language that would fit ideally to achieve the project’s objectives. Gosling named the language “Oak”, while he was staring at an oak tree though his office window. However, some time after, the name was abolished mainly due to the fact that the name had already been in use for another programming language. In fact Gosling stated that “the Java development team discovered that Oak was the name of a programming language that predated Sun’s language, so another name had to be chosen”.
It was later called Java. Gosling recounted that “it’s surprisingly difficult to find a good n
Cite This Work
To export a reference to this article please select a referencing stye below:
Related ServicesView all
DMCA / Removal Request
If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: