Saurav Banerjee On 'DMR'

EXpert Opinions : by Dennis Ritchie, James Gosling and Bjaurn Stroustrup

The C Family of Languages:

The C family of languages--C, C++, and Java--has dominated commercial programming for over 30 years. Today, all three languages are at a turning point:
o The second ISO/ANSI C standard has just been published (C99 was officially released in December 1999). C continues to be one of the most influential languages in the world, particularly in the field of embedded systems.
o The first official update to the ISO/ANSI C++ standard will be completed in October 2000. C++ is one of the most widely used commercial programming languages in the world, with unparalleled support for both object-oriented and generic programming, and continues to experience steady growth.
o Java popularity continues to grow in various areas, from client-side to server-side programming. Sun has recently decided that Java can best flourish as a de facto standard, instead of as a formal ISO/ANSI or ECMA standard, and has abandoned formal standardization efforts.
What has made the C family of languages so dominant?


Q: Why has the C family of languages become so successful and so widely used?

The use of C, was during early times (meaning the '70s and much of the '80s) considerably encouraged by its use as the lingua franca of Unix during the period that Unix was growing in the research and academic community, and then when Unix was taken up as the software basis for the workstation industry of the '80s. There were also technical and semi-technical aspects: the language turned out to be well-placed both for describing things at a high enough level so that portability across hardware was feasible, but simple enough in its requirements to make it cheap to implement.
C and C++ became popular because they were flexible, cheap, and more efficient than alternatives. C++ owes much of its initial popularity to its high degree of compatibility with C.
It was very important success of C and C++ that AT&T didn't try to monopolize these languages, but allowed its researchers to support the creation of alternative implementations. Also, AT&T fully supported ANSI and ISO standardization of C and C++ as soon as these efforts started.
Java is a very different design from the other two languages and appears to have a very different philosophy.
Just to remind people: Both C and C++ were invented in the Computer Science Research Center of Bell Labs in Murray Hill and found their initial serious use within Bell Labs and AT&T.
Among technical factors, C and C++ benefited from their closeness to machine and absence of artificial restrictions on what can be expressed. That allows low-level systems work to be done in these languages and for the full performance of a machine to be delivered to its users. Java benefited from running in its own virtual machine and from coming with a large set of libraries that decrease the time needed for a programmer to become productive. Unix gave a similar boost to C. In contrast, the C++ world suffers from fragmentation of its huge base of libraries, many of which are proprietary and supplied by competing vendors.
C++ was a language where I could write programs that were as elegant as Simula programs, yet as efficient as C programs.
The object-oriented facilities from Simula helped with the former, and the systems-programming facilities of C with the latter.
Like C, Java's goals were really around being able to build relatively specific kinds of software.
For example, one of the differences between Java and C is that Java has real arrays and the arrays get bounds-checked, and that turns out to be important for both reliability and security. If you look at the history of security breaches on the Internet, some really large fraction of them are exploiting buffer overflows, statically allocated arrays that people just go over the end of. If you look at logs of bug-fixing that people go through, it ends up being that memory integrity issues are a huge fraction of where the problems come from.
C haven't changed much in many years, and I haven't been a central player in the changes in either the 1989 or 1999 standards.
C++ haven’t changed much, still good for serious systems programming -- including work at the machine level and on resource-constrained systems .
The major shift in emphasis/style comes from finally having templates and exceptions available.
where everything is flexible and everything is dynamic, and static languages like C, where everything is statically precompiled. Java is kind of in this netherworld in between them, and given the way the world has evolved to become even more networked than before, even more conscious of security issues.
Probably the oddest aspect of C compared with other languages outside its immediate family is the declaration syntax, in which (in a way coming from Fortran) a type is mentioned, then variables decorated in a way that reflects their use in expressions.
A closely related aspect is the treatment of arrays and pointers.
C and C++ communities benefit from a genuine degree of compatibility. Also, much of work on the non-abstraction areas of C++ has been fed back into Standard C. Examples are function declarations/prototypes, const (Dennis also had a hand in their design), declarations wherever statements can appear, and the // comments.
A lot of the design of interfaces was borrowed pretty straightforwardly from Objective C, and it's got some pluses and minuses and it was a real tough balancing act.


Q: Did you ever add features that your users didn't appreciate as much as you did, and then have to deprecate or remove them later? What did you learn from the experience?


Ritchie: I added some things under some pressure from users that I don't think were done well. Enumeration types are a bit odd, bitfields are odder. The "static" keyword is very strange, expressing both a storage lifetime and what the standard calls "linkage" (external visibility). There are many odd bits here and there.
I can't remember features I added that I had to remove except for some tiny bits, like the "entry" keyword. I clearly wish I could have done something about the C declaratory syntax.
In addition, Having had templates integral to the language early on would have helped many use C++ better.
Stroustrup: When I designed C with Classes and C++, I was very keen on the idea that a class defined the environment in which the code of its member functions operate (I still am). This led to the notion of constructors that establish that environment (invariant) and acquire the resources needed. Destructors reverse that process (releasing resources).
Based on that line of thinking, C with Classes also allowed you to define a call() function that was called before entry into a member function and a return() function that was called after exit from a member function. The call()/return() mechanism was meant to allow a programmer to manage resources needed for an individual member function invocation. This allowed me to implement monitors for the first task library. A task's call() grabbed a lock and its matching return() released the lock. The idea came partly from Lisp's :before and :after methods. However, the notion wasn't perfectly general -- for example, you couldn't access arguments for a member function call from call(). Worse, I completely failed to convince people of the usefulness of this notion, so I removed call() and return() when I defined C++.
I recently revisited this issue and I wrote a template -- in Standard C++ -- that wraps calls to an object by arbitrary prefix and suffix.

There are some things that I kind of feel torn about, like operator overloading. I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++.

Q: In your experience, what are the most common mistakes developers make in [C/C++/Java]?

Ritchie: I don't really know the answer to this question. I would suppose that the low-level mistakes have to do with type errors, and especially with array subscript and pointer references
C itself does very little to help you here; you have to design a scheme.
Stroustrup: Using C++ just as if it was C or Smalltalk. That leads to seriously suboptimal C++. To use C++ well, you have to adopt some native C++ styles. These tend to be distinguished by small concrete classes and templates. A programming style that is overly influenced by C tends to use a lot of arrays, clever pointer manipulation, casts, and macros rather than standard library facilities (such as vectors, strings, and maps). A programming style that is overly influenced by Smalltalk tries to cram every class into a hierarchy and to overuse casts (and often macros). In either case, key abstractions tend to disappear in a mess of implementation details and people get themselves (unnecessarily) tied in knots with allocation, pointers, casts, and macros.
One common mistake that particularly annoys me is the use of complicated base classes with lots of data members as part of interfaces offered to application builders (users). Abstract base classes make much better interfaces to services. I have tried to root out such misuses for well over ten years: I added abstract classes in 1989 after failing to get the idea across without the support of an explicit language feature.


The idea is really simple:
class interface { // seen by users
// pure virtual functions
};
class my_implementation : public interface {
// data
// functions
// overriding functions
};
When user code sees only "interface," it is immune to changes to "my_implementation."
If common data structures or operations are needed for implementations they can be added in a base class that is visible only to implementers:
class common { // seen by implementers
// data
// functions
};
class my_implementation : public interface, protected common {
// data
// functions
// overriding functions
};
class your_implementation : public interface, protected common {
// data
// functions
// overriding functions
};
This is one of the simplest and most fundamental uses of multiple inheritance.
What many people need to get much more out of C++ is not new features, it is simply a more appropriate design and programming style.
Gosling: Probably the most pervasive mistake is not doing a tasteful job of object-oriented programming. There are these people who don't understand it at all, who just do some procedural kind of stuff and write their program as one huge class with a lot of methods in it; they try to do it in a C style. Then there are the people who go, "Ooo, objects! They're cool! Let's make gazillions of them!"

Q: In your experience, how long does it take for a novice programmer to become a reasonably proficient [C/C++/Java] developer ?

Ritchie: I don't know the answer to this question either--my stock joke on similar ones is, "Well, I never had to learn C...."
Stroustrup: That depends critically on the background of the novice, on the complexity of the task first attempted with C++, and on the teaching/learning approach.
For a novice programmer, a year and a half seems appropriate; for a programmer who is a novice to C++ and the techniques it supports half a year seems more likely.
I consider good libraries essential to provide a smooth learning curve and to properly sequence the learning of C++ concepts. For example, having the C++ standard library available makes it possible to learn the basic type, scope, and control structure concepts without having to deal with arrays, pointers, and memory management at the same time. Such fundamental, yet low-level concepts are best learned a bit later.
This is dangerous. In this context, it is a strength C++ (and of C) that the standard libraries usually are implemented in the language itself using only the facilities available to every programmer.
Gosling: The language itself tends to be a snap to learn; it's all the library stuff that takes the time, and there the best way to do it is to just start writing and using it, and when you need something, look for it.
C didn't come until later just because it's so easy to do goofy things in C; it's so easy to have an array and write "for( i = 1; i <= length; ... )" and you have to explain, "no, it's not less than or equal to length and it's not 1, it's 0 and it's less than." But of course your loop runs just fine, only maybe sometimes you'll discover that you smack the malloc header of the block immediately following the array and nobody's ever told you about that.
That's just so incredibly common in C and C++ or any language that doesn't have a really strict memory model.

Q: Are there any important features missing from the C family of languages? From [C/C++/Java]?

Stroustrup: In which sense do C, C++, and Java constitute a family of languages? C and C++ has a large common subset, and over the years serious efforts have been made to minimize the inevitable tendency of the two languages to drift apart because they are controlled by separate standards bodies. Java, however, provides no real compatibility, and similar syntactic constructs have semantics different from the C and C++ versions. Clearly, Java borrows from C and C++, but under the skin, the similarities to Modula-3 seem greater.
Undoubtedly, all three languages could be significantly improved by addition. However, I see little reason to believe that there is a single major feature that would help all three languages.
Gosling: One of the things that always bugged me about C was the weak memory model, the fact that you could cast a pointer to a character into a pointer to an integer; it just did weird things. But then you change that and it's not C any more, it's basically Java.
The other is type polymorphism, something like templates, and Java actually has something like a poor man's template system right now in that the type hierarchy has a common root for anything and everything, namely Object, but there's also a group working on doing a proper job of type polymorphism in Java. It turns out to be a really hard problem. Other issues are clearer: garbage collection is a good idea; goto is a bad idea.


Q: What things would you like to see become a part of [C/C++/Java] in the next 2-5 years? In the next 10 years? Why?

Ritchie: For C, the new 1999 standard exists but has not become readily available, and it has quite a few changes from the earlier one, though not revolutionary ones.
Stroustrup: I think that the emphasis for C++ evolution should be in library building.
Clearly, many people worry about concurrency and about interfaces to various systems (e.g. GUI, databases, operating systems, other languages, component models). This is [the] most likely area of work and creating and maintaining consistency will be the major challenge. For example, it will be important to provide a consistent view of text from C++. Having some interfaces use C-style strings, others the standard library string, and yet others notions of strings derived from the systems being interfaced to is a recipe for chaos.

Q: Is there room and/or market demand for a new language in the C family?

Ritchie: It's a little hard to imagine a language that's almost like C but enough better to displace it.
Stroustrup: I think the user community would be best served by a single language providing low level support for systems programming. I think C++ would serve well there and I see no technical problems merging C and C++.
Java doesn't provide support for low-level systems programming so it must rely on other languages (such as assembler, C, or C++). Conversely, for C or C++ to be useful for safe downloading into another machine, we need either hardware support (my preferred long-term solution for all languages), a C++ virtual machine.
So, is there room for another language beyond C, C++, and Java? There is certainly room for more languages.


Q: Which types of applications are well suited for [C/C++/Java]? Which are not?


Stroustrup: C++ has inherent strength in applications with a systems component, especially where there are constraints on resources (such as run time and memory). From that base, C++ provides significant support for organizing larger programs for easier maintenance and evolution.
Gosling: Java is certainly well-suited for anything that involves networks and in places where security is a concern. There are some things that it really was never targeted for, although people are certainly doing them. Writing device drivers tends to be kind of awkward, although it's surprising how many people have gone and done a number of fairly obvious things to make device driver writing in Java more straightforward.


Q: Are languages getting easier or more difficult to learn and use? Do you see any progressive usability trends among C, C++, and Java as those languages have appeared and/or added features over time?

Stroustrup: Languages are getting easier to use. For example, C++ with standard-library facilities (such as string, vector, and algorithms) is far easier to use than C++ using C-style strings, arrays, and C standard library functions to solve the same problems.
Java attempts to restrict programmers to a single style of programming. This makes Java easier to use within that domain, but leads to ugly workarounds when the edges of that style are approached. The need for casting when using Java containers is an obvious example.



Personal Preferences
Q: We all have different reasons why we've chosen to be in the software industry. What was it that drew you to the software field? What makes it cool?


Ritchie: I started out interested in physics, and still maintain an amateur interest in keeping up with what's happening at its edges. Sometime in college and early grad school, I spent a lot of time in theoretical computer science (Turing machines, complexity theory). Meanwhile I also became more fascinated with real computers and, I suppose, the immediacy of the experience they provided: when you write a program, you can see what it does right away. All of these things connect with each other in interesting ways. Being involved with this sort of activity was what motivated me. Somehow I didn't think of what I was doing as joining the Software Industry, although, even in 1968, I guess it was.
Stroustrup: I'm not sure exactly what brought me to computers. I saw computers as a practical and useful outlet for scientific interests. I really like building things. When you build you get feedback from the tools, from the program/system, and from users. That's what pushes the imagination beyond what is obvious and beyond the preconceptions and doctrine of an individual, an academic field, or an organization. I like Kristen Nygaard's notion of programming as a means of understanding something.
Gosling: I don't know what it is about my genetic structure, but I just like to build stuff. In some sense whether I'm building software or building a chair or building dinner -- also known as cooking -- I get a kick out of just creating stuff. One of the things that's nice about software is that you can create just about the most amazingly sophisticated complex things and you can do it fairly quickly. If I was a watchmaker, I'm sure I'd get frustrated with how hard it was to create things with lots of gears and pulleys; and yet, just looking at a good watch, you take off the back and it's just so cool. I don't know why it's cool, it just feels really cool to me. With software you can put as many as gears and cams and whatever in there as you want, and things just get complex. In some sense the thing I like most about software is the thing I end up spending most of my time fighting against, which is complexity.


Q: What was the first programming language you ever used?

Ritchie:Around 1962, I went to a non-course talk about Cobol (by Jean Sammet), and took a course that involved programming both analog computers using a plugboard and writing Univac I machine language (no assembler). Also about this time, I visited the IBM office in Cambridge (MA) and they gave me manuals about Fortran, which I read avidly.
Stroustrup: My first programming language was Algol60 on a GIER computer. The GIER was a 1960s Danish computer with 1K 42 bit (I think, plus a few extra bits for hardware testing) words.
Gosling: The first programming language I ever used was a language called Focal 5. Focal stood for "formula calculi." It was a scripting language for PDP-8's. I wrote most of my earliest programs using Focal 5. It's a language whose complete compiler and runtime system can be implemented in under 24 hours. It's actually a nice little language, way simpler than Basic.

Q: What languages, or features of languages, inspired you?


Stroustrup: In addition to Simula67, my favorite language at the time was Algol68. I think that "Algol68 with Classes" would have been a better language than "C with Classes."
Gosling: Lisp, the thing that influenced me the most was the incredible difference garbage collection made. Using Simula and being a local maintainer of the Simula compiler was really what introduced me to objects and got me thinking about objects. Using languages like Pascal got me really thinking about modeling. Languages like Modula-3 really pushed things like exception mechanisms. I've used a lot of languages, and a lot of them have been influential. You can go through everything in Java and say, "this came from there, and this came from there."

Q: What was the first program you ever wrote? On what hardware?


Ritchie:The first on a real computer was the Univac I program. (As I learned a year or so later, the exercise was in fact to implement some of the APL operators--Iverson was around then).
Stroustrup: I don't recall, but it must have been some computer science 101 exercise in Algol60 on a GIER computer. The first programs that I did for real -- that is, for others to use -- were business programs written in assembler for Burroughs office computers. I financed most of my Danish masters degree that way.

Q: Is there a programming language that is the best choice for all (or nearly all) application development? If yes, which language is it, and what makes it best? If not, what would it take to create such a language?


Ritchie: No, this is silly.

Stroustrup: No. People differ too much for that and their applications differ too much. The notion of a perfect and almost perfect language is the dream of immature programmers and marketeers. Naturally, every language designer tries both to strengthen his language to better serve its core community and to broaden its appeal, but being everything to everybody is not a reasonable ideal. There are genuine design choices and tradeoffs that must be made.

Q: Programmers often talk about the advantages and disadvantages of programming in a "simple language." What does that phrase mean to you, and is [C/C++/Java] a simple language in your view?


Ritchie: C (and the others for that matter) are simple in some ways, though they are also subtle; other, somewhat similar languages like Pascal are arguably simpler. What has become clear is that aspects of the environment like libraries that aren't part of the core language are much bigger and more complicated.
The 1999 C standard grew hugely more in the library part than in the language; the C++ STL and other things are big; AWT and other things associated with Java are too.
Stroustrup: Notions of "simple:" to be easy to learn, to make it easy to express ideas, and to have a one-to-one correspondence to some form of math. In those terms, none of the three languages is simple. However, once mastered, C and C++ make it easy to express quite complex and advanced ideas.


Q: What topics do you feel are missing from university computer science and engineering programs around the world that would help to improve the quality of software?

Stroustrup: In some well-respected computer science departments, you can graduate without having written any code. That ought not be possible. Nobody should graduate with a degree in computer science or computer engineering without having completed a significant programming project. Code is the base of computing and people without a "feel" for code tend to seriously misjudge what skills, tools, and time are needed to build good systems.


I think reading and writing code should be a significant part of the training of every computer professional. However much we talk about "Computer Science" and "Software Engineering", building systems still has a large practical component relating to reading, writing, and maintaining code.


No, I'm not arguing that we should just teach hacking
I argue for a balance between theoretical and practical skills.
Gosling: People have been getting a pretty good education in the technology; what they tend to not get is a good view of what goes on in an actual engineering organization:

Q: Outside the C family of languages, what language(s) do you like the best? What in particular makes them interesting to you?

Ritchie: I have to admire languages like Lisp. But, just as in the earlier question about a "simple" language, an astonishingly simple language grows in practice into something that can be fearsome.



Stroustrup: Algol68, CLOS, and ML springs to mind. In each case, what attracts me is flexibility and some very elegant code examples.


Q: What are your favorite software-related books?

Ritchie: The works of Kernighan and Pike (separately or collectively) are nice. The software book I enjoyed most is Ben Ross Schneider's Travels in Computerland.
Stroustrup: Brooks' The Mythical Man Month Booch's Object-Oriented Design, and Gamma et.al.'s Design Patterns.


Programming Language Standards
Q: Is it important to have a formal (e.g., ISO/ANSI) standard for a programming language? What are the advantages? The disadvantages?



Ritchie: At some point a formal standard tends to become necessary, particularly for language that evolved informally (certainly C, but also C++ and Java
At the same time, there are disadvantages, in that whatever clear (or cloudy) vision that the original designers might have had ends up colored by whatever strange proposals the participants in the process bring forth. Complication invariably results as a result of the compromises.
Stroustrup: In today's overheated commercial atmosphere it is essential to have a formal standard. Naturally, an ISO standard is not a complete defense, and not all of our languages, libraries, or tools can be standardized. However, without a standard, users are completely at the mercy/whim of their suppliers.
Conformance suites are widely used for ISO C and ISO C++.


Q: Is it important to have a de facto standard for a programming language? What are the advantages? The disadvantages?

Stroustrup: A de facto standard is a major advantage to its owner and its owner's friends/allies. It can also benefit third parties, such as professors, students, and small companies
Gosling: I think that in a strong sense de facto standards are the ones that really matter. It hardly matters what's actually written down in anybody's standards document; what actually matters is what people have actually implemented.

I'm a real fan of Linux; the problem is that there are so many flavors of Linux and they're all just different enough that life is really hard.


The "Century 21" Software Industry
Q: Prognostication is hard, but valuable even if it can never be 100% accurate. In your view, what are the major forces driving the kinds of software we will be writing in the future? and the way we will be writing that software?


Ritchie: The most obvious change that has occurred recently is the increase in use of "scripting languages" that are generally interpreted. These range from the basic ones like HTML to Perl, Tcl/Tk, and Javascript, and then to presentation-graphics packages for making WWW pages or slides.
Stroustrup: The future? these days it is close to impossible to even describe the present.
We have to see more emphasis on correctness, quality, and security.
I really hope 2050s software and systems will be too advanced for me to imagine today, just as a 1950s expert had little chance of predicting today's systems with any accuracy or in any detail.

Notes :

1. B. Kernighan and D. Ritchie. The C Programming Language, 2nd edition (Prentice Hall, 1998) ISBN 0131103709.
2. B. Stroustrup. The Design and Evolution of C++ (Addison-Wesley, 1994) ISBN 0201543303.
3. B. Stroustrup. The C++ Programming Language, Special Edition (Addison-Wesley, 2000) ISBN 0201700735.
4. http://www.research.att.com/~bs.
5. B. Stroustrup. "Wrapping C++ Member Function Calls" (C++ Report, 12(6), June 2000).
6. B. Stroustrup. "Learning Standard C++ as a New Language" (C/C++ Users Journal, May 1999; also in CVu 12(1) January 2000).
7. B. Kernighan and R. Pike. The Practice of Programming (Addison-Wesley, 1999) ISBN 020161586X.
8. B. Kernighan and R. Pike. The UNIX Programming Environment (Prentice Hall, 1984) ISBN 013937681X.
9. B. Kernighan and P.J. Plauger. The Elements of Programming Style (McGraw-Hill, 1988) ISBN 0070342075.
10. B. Schneider. Travels in Computerland: Or, Incompatibilities and Interfaces: A Full and True Account of the Implementation of the London Stage Information Bank, ASIN 0201067374.
11. F. Brooks. The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1995) ISBN 0201835959.
12. G. Booch. Object-Oriented Analysis and Design With Applications (Addison-Wesley, 1994) ISBN 0805353402.
13. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns : Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) ISBN 0201633612.
14. J. Bentley. Programming Pearls, Second Edition (Addison-Wesley, 1999) ISBN 0201657880.
15. R. Sedgewick. Algorithms in C, 3rd edition (Addison-Wesley, 2000) ISBN 0201849372. (There are at least ten "Algorithms" books by Sedgewick, covering different scopes or specialized for different programming languages. This is one of the most recently written/updated.)
16. A. Koenig and B. Moo. Ruminations on C++ (Addison-Wesley, 1996) ISBN 0201423391.

(Source : Internet )
N.B: This article was trimmed to fit for the theoretical enhancement of various professionals , students and others.



Saurav Banerjee, Ranchi , INFI-NITE .

techinfiniteonline@gmail.com

0 comments:

Post a Comment

EXpert Opinions : by Dennis Ritchie, James Gosling and Bjaurn Stroustrup

The C Family of Languages:

The C family of languages--C, C++, and Java--has dominated commercial programming for over 30 years. Today, all three languages are at a turning point:
o The second ISO/ANSI C standard has just been published (C99 was officially released in December 1999). C continues to be one of the most influential languages in the world, particularly in the field of embedded systems.
o The first official update to the ISO/ANSI C++ standard will be completed in October 2000. C++ is one of the most widely used commercial programming languages in the world, with unparalleled support for both object-oriented and generic programming, and continues to experience steady growth.
o Java popularity continues to grow in various areas, from client-side to server-side programming. Sun has recently decided that Java can best flourish as a de facto standard, instead of as a formal ISO/ANSI or ECMA standard, and has abandoned formal standardization efforts.
What has made the C family of languages so dominant?


Q: Why has the C family of languages become so successful and so widely used?

The use of C, was during early times (meaning the '70s and much of the '80s) considerably encouraged by its use as the lingua franca of Unix during the period that Unix was growing in the research and academic community, and then when Unix was taken up as the software basis for the workstation industry of the '80s. There were also technical and semi-technical aspects: the language turned out to be well-placed both for describing things at a high enough level so that portability across hardware was feasible, but simple enough in its requirements to make it cheap to implement.
C and C++ became popular because they were flexible, cheap, and more efficient than alternatives. C++ owes much of its initial popularity to its high degree of compatibility with C.
It was very important success of C and C++ that AT&T didn't try to monopolize these languages, but allowed its researchers to support the creation of alternative implementations. Also, AT&T fully supported ANSI and ISO standardization of C and C++ as soon as these efforts started.
Java is a very different design from the other two languages and appears to have a very different philosophy.
Just to remind people: Both C and C++ were invented in the Computer Science Research Center of Bell Labs in Murray Hill and found their initial serious use within Bell Labs and AT&T.
Among technical factors, C and C++ benefited from their closeness to machine and absence of artificial restrictions on what can be expressed. That allows low-level systems work to be done in these languages and for the full performance of a machine to be delivered to its users. Java benefited from running in its own virtual machine and from coming with a large set of libraries that decrease the time needed for a programmer to become productive. Unix gave a similar boost to C. In contrast, the C++ world suffers from fragmentation of its huge base of libraries, many of which are proprietary and supplied by competing vendors.
C++ was a language where I could write programs that were as elegant as Simula programs, yet as efficient as C programs.
The object-oriented facilities from Simula helped with the former, and the systems-programming facilities of C with the latter.
Like C, Java's goals were really around being able to build relatively specific kinds of software.
For example, one of the differences between Java and C is that Java has real arrays and the arrays get bounds-checked, and that turns out to be important for both reliability and security. If you look at the history of security breaches on the Internet, some really large fraction of them are exploiting buffer overflows, statically allocated arrays that people just go over the end of. If you look at logs of bug-fixing that people go through, it ends up being that memory integrity issues are a huge fraction of where the problems come from.
C haven't changed much in many years, and I haven't been a central player in the changes in either the 1989 or 1999 standards.
C++ haven’t changed much, still good for serious systems programming -- including work at the machine level and on resource-constrained systems .
The major shift in emphasis/style comes from finally having templates and exceptions available.
where everything is flexible and everything is dynamic, and static languages like C, where everything is statically precompiled. Java is kind of in this netherworld in between them, and given the way the world has evolved to become even more networked than before, even more conscious of security issues.
Probably the oddest aspect of C compared with other languages outside its immediate family is the declaration syntax, in which (in a way coming from Fortran) a type is mentioned, then variables decorated in a way that reflects their use in expressions.
A closely related aspect is the treatment of arrays and pointers.
C and C++ communities benefit from a genuine degree of compatibility. Also, much of work on the non-abstraction areas of C++ has been fed back into Standard C. Examples are function declarations/prototypes, const (Dennis also had a hand in their design), declarations wherever statements can appear, and the // comments.
A lot of the design of interfaces was borrowed pretty straightforwardly from Objective C, and it's got some pluses and minuses and it was a real tough balancing act.


Q: Did you ever add features that your users didn't appreciate as much as you did, and then have to deprecate or remove them later? What did you learn from the experience?


Ritchie: I added some things under some pressure from users that I don't think were done well. Enumeration types are a bit odd, bitfields are odder. The "static" keyword is very strange, expressing both a storage lifetime and what the standard calls "linkage" (external visibility). There are many odd bits here and there.
I can't remember features I added that I had to remove except for some tiny bits, like the "entry" keyword. I clearly wish I could have done something about the C declaratory syntax.
In addition, Having had templates integral to the language early on would have helped many use C++ better.
Stroustrup: When I designed C with Classes and C++, I was very keen on the idea that a class defined the environment in which the code of its member functions operate (I still am). This led to the notion of constructors that establish that environment (invariant) and acquire the resources needed. Destructors reverse that process (releasing resources).
Based on that line of thinking, C with Classes also allowed you to define a call() function that was called before entry into a member function and a return() function that was called after exit from a member function. The call()/return() mechanism was meant to allow a programmer to manage resources needed for an individual member function invocation. This allowed me to implement monitors for the first task library. A task's call() grabbed a lock and its matching return() released the lock. The idea came partly from Lisp's :before and :after methods. However, the notion wasn't perfectly general -- for example, you couldn't access arguments for a member function call from call(). Worse, I completely failed to convince people of the usefulness of this notion, so I removed call() and return() when I defined C++.
I recently revisited this issue and I wrote a template -- in Standard C++ -- that wraps calls to an object by arbitrary prefix and suffix.

There are some things that I kind of feel torn about, like operator overloading. I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++.

Q: In your experience, what are the most common mistakes developers make in [C/C++/Java]?

Ritchie: I don't really know the answer to this question. I would suppose that the low-level mistakes have to do with type errors, and especially with array subscript and pointer references
C itself does very little to help you here; you have to design a scheme.
Stroustrup: Using C++ just as if it was C or Smalltalk. That leads to seriously suboptimal C++. To use C++ well, you have to adopt some native C++ styles. These tend to be distinguished by small concrete classes and templates. A programming style that is overly influenced by C tends to use a lot of arrays, clever pointer manipulation, casts, and macros rather than standard library facilities (such as vectors, strings, and maps). A programming style that is overly influenced by Smalltalk tries to cram every class into a hierarchy and to overuse casts (and often macros). In either case, key abstractions tend to disappear in a mess of implementation details and people get themselves (unnecessarily) tied in knots with allocation, pointers, casts, and macros.
One common mistake that particularly annoys me is the use of complicated base classes with lots of data members as part of interfaces offered to application builders (users). Abstract base classes make much better interfaces to services. I have tried to root out such misuses for well over ten years: I added abstract classes in 1989 after failing to get the idea across without the support of an explicit language feature.


The idea is really simple:
class interface { // seen by users
// pure virtual functions
};
class my_implementation : public interface {
// data
// functions
// overriding functions
};
When user code sees only "interface," it is immune to changes to "my_implementation."
If common data structures or operations are needed for implementations they can be added in a base class that is visible only to implementers:
class common { // seen by implementers
// data
// functions
};
class my_implementation : public interface, protected common {
// data
// functions
// overriding functions
};
class your_implementation : public interface, protected common {
// data
// functions
// overriding functions
};
This is one of the simplest and most fundamental uses of multiple inheritance.
What many people need to get much more out of C++ is not new features, it is simply a more appropriate design and programming style.
Gosling: Probably the most pervasive mistake is not doing a tasteful job of object-oriented programming. There are these people who don't understand it at all, who just do some procedural kind of stuff and write their program as one huge class with a lot of methods in it; they try to do it in a C style. Then there are the people who go, "Ooo, objects! They're cool! Let's make gazillions of them!"

Q: In your experience, how long does it take for a novice programmer to become a reasonably proficient [C/C++/Java] developer ?

Ritchie: I don't know the answer to this question either--my stock joke on similar ones is, "Well, I never had to learn C...."
Stroustrup: That depends critically on the background of the novice, on the complexity of the task first attempted with C++, and on the teaching/learning approach.
For a novice programmer, a year and a half seems appropriate; for a programmer who is a novice to C++ and the techniques it supports half a year seems more likely.
I consider good libraries essential to provide a smooth learning curve and to properly sequence the learning of C++ concepts. For example, having the C++ standard library available makes it possible to learn the basic type, scope, and control structure concepts without having to deal with arrays, pointers, and memory management at the same time. Such fundamental, yet low-level concepts are best learned a bit later.
This is dangerous. In this context, it is a strength C++ (and of C) that the standard libraries usually are implemented in the language itself using only the facilities available to every programmer.
Gosling: The language itself tends to be a snap to learn; it's all the library stuff that takes the time, and there the best way to do it is to just start writing and using it, and when you need something, look for it.
C didn't come until later just because it's so easy to do goofy things in C; it's so easy to have an array and write "for( i = 1; i <= length; ... )" and you have to explain, "no, it's not less than or equal to length and it's not 1, it's 0 and it's less than." But of course your loop runs just fine, only maybe sometimes you'll discover that you smack the malloc header of the block immediately following the array and nobody's ever told you about that.
That's just so incredibly common in C and C++ or any language that doesn't have a really strict memory model.

Q: Are there any important features missing from the C family of languages? From [C/C++/Java]?

Stroustrup: In which sense do C, C++, and Java constitute a family of languages? C and C++ has a large common subset, and over the years serious efforts have been made to minimize the inevitable tendency of the two languages to drift apart because they are controlled by separate standards bodies. Java, however, provides no real compatibility, and similar syntactic constructs have semantics different from the C and C++ versions. Clearly, Java borrows from C and C++, but under the skin, the similarities to Modula-3 seem greater.
Undoubtedly, all three languages could be significantly improved by addition. However, I see little reason to believe that there is a single major feature that would help all three languages.
Gosling: One of the things that always bugged me about C was the weak memory model, the fact that you could cast a pointer to a character into a pointer to an integer; it just did weird things. But then you change that and it's not C any more, it's basically Java.
The other is type polymorphism, something like templates, and Java actually has something like a poor man's template system right now in that the type hierarchy has a common root for anything and everything, namely Object, but there's also a group working on doing a proper job of type polymorphism in Java. It turns out to be a really hard problem. Other issues are clearer: garbage collection is a good idea; goto is a bad idea.


Q: What things would you like to see become a part of [C/C++/Java] in the next 2-5 years? In the next 10 years? Why?

Ritchie: For C, the new 1999 standard exists but has not become readily available, and it has quite a few changes from the earlier one, though not revolutionary ones.
Stroustrup: I think that the emphasis for C++ evolution should be in library building.
Clearly, many people worry about concurrency and about interfaces to various systems (e.g. GUI, databases, operating systems, other languages, component models). This is [the] most likely area of work and creating and maintaining consistency will be the major challenge. For example, it will be important to provide a consistent view of text from C++. Having some interfaces use C-style strings, others the standard library string, and yet others notions of strings derived from the systems being interfaced to is a recipe for chaos.

Q: Is there room and/or market demand for a new language in the C family?

Ritchie: It's a little hard to imagine a language that's almost like C but enough better to displace it.
Stroustrup: I think the user community would be best served by a single language providing low level support for systems programming. I think C++ would serve well there and I see no technical problems merging C and C++.
Java doesn't provide support for low-level systems programming so it must rely on other languages (such as assembler, C, or C++). Conversely, for C or C++ to be useful for safe downloading into another machine, we need either hardware support (my preferred long-term solution for all languages), a C++ virtual machine.
So, is there room for another language beyond C, C++, and Java? There is certainly room for more languages.


Q: Which types of applications are well suited for [C/C++/Java]? Which are not?


Stroustrup: C++ has inherent strength in applications with a systems component, especially where there are constraints on resources (such as run time and memory). From that base, C++ provides significant support for organizing larger programs for easier maintenance and evolution.
Gosling: Java is certainly well-suited for anything that involves networks and in places where security is a concern. There are some things that it really was never targeted for, although people are certainly doing them. Writing device drivers tends to be kind of awkward, although it's surprising how many people have gone and done a number of fairly obvious things to make device driver writing in Java more straightforward.


Q: Are languages getting easier or more difficult to learn and use? Do you see any progressive usability trends among C, C++, and Java as those languages have appeared and/or added features over time?

Stroustrup: Languages are getting easier to use. For example, C++ with standard-library facilities (such as string, vector, and algorithms) is far easier to use than C++ using C-style strings, arrays, and C standard library functions to solve the same problems.
Java attempts to restrict programmers to a single style of programming. This makes Java easier to use within that domain, but leads to ugly workarounds when the edges of that style are approached. The need for casting when using Java containers is an obvious example.



Personal Preferences
Q: We all have different reasons why we've chosen to be in the software industry. What was it that drew you to the software field? What makes it cool?


Ritchie: I started out interested in physics, and still maintain an amateur interest in keeping up with what's happening at its edges. Sometime in college and early grad school, I spent a lot of time in theoretical computer science (Turing machines, complexity theory). Meanwhile I also became more fascinated with real computers and, I suppose, the immediacy of the experience they provided: when you write a program, you can see what it does right away. All of these things connect with each other in interesting ways. Being involved with this sort of activity was what motivated me. Somehow I didn't think of what I was doing as joining the Software Industry, although, even in 1968, I guess it was.
Stroustrup: I'm not sure exactly what brought me to computers. I saw computers as a practical and useful outlet for scientific interests. I really like building things. When you build you get feedback from the tools, from the program/system, and from users. That's what pushes the imagination beyond what is obvious and beyond the preconceptions and doctrine of an individual, an academic field, or an organization. I like Kristen Nygaard's notion of programming as a means of understanding something.
Gosling: I don't know what it is about my genetic structure, but I just like to build stuff. In some sense whether I'm building software or building a chair or building dinner -- also known as cooking -- I get a kick out of just creating stuff. One of the things that's nice about software is that you can create just about the most amazingly sophisticated complex things and you can do it fairly quickly. If I was a watchmaker, I'm sure I'd get frustrated with how hard it was to create things with lots of gears and pulleys; and yet, just looking at a good watch, you take off the back and it's just so cool. I don't know why it's cool, it just feels really cool to me. With software you can put as many as gears and cams and whatever in there as you want, and things just get complex. In some sense the thing I like most about software is the thing I end up spending most of my time fighting against, which is complexity.


Q: What was the first programming language you ever used?

Ritchie:Around 1962, I went to a non-course talk about Cobol (by Jean Sammet), and took a course that involved programming both analog computers using a plugboard and writing Univac I machine language (no assembler). Also about this time, I visited the IBM office in Cambridge (MA) and they gave me manuals about Fortran, which I read avidly.
Stroustrup: My first programming language was Algol60 on a GIER computer. The GIER was a 1960s Danish computer with 1K 42 bit (I think, plus a few extra bits for hardware testing) words.
Gosling: The first programming language I ever used was a language called Focal 5. Focal stood for "formula calculi." It was a scripting language for PDP-8's. I wrote most of my earliest programs using Focal 5. It's a language whose complete compiler and runtime system can be implemented in under 24 hours. It's actually a nice little language, way simpler than Basic.

Q: What languages, or features of languages, inspired you?


Stroustrup: In addition to Simula67, my favorite language at the time was Algol68. I think that "Algol68 with Classes" would have been a better language than "C with Classes."
Gosling: Lisp, the thing that influenced me the most was the incredible difference garbage collection made. Using Simula and being a local maintainer of the Simula compiler was really what introduced me to objects and got me thinking about objects. Using languages like Pascal got me really thinking about modeling. Languages like Modula-3 really pushed things like exception mechanisms. I've used a lot of languages, and a lot of them have been influential. You can go through everything in Java and say, "this came from there, and this came from there."

Q: What was the first program you ever wrote? On what hardware?


Ritchie:The first on a real computer was the Univac I program. (As I learned a year or so later, the exercise was in fact to implement some of the APL operators--Iverson was around then).
Stroustrup: I don't recall, but it must have been some computer science 101 exercise in Algol60 on a GIER computer. The first programs that I did for real -- that is, for others to use -- were business programs written in assembler for Burroughs office computers. I financed most of my Danish masters degree that way.

Q: Is there a programming language that is the best choice for all (or nearly all) application development? If yes, which language is it, and what makes it best? If not, what would it take to create such a language?


Ritchie: No, this is silly.

Stroustrup: No. People differ too much for that and their applications differ too much. The notion of a perfect and almost perfect language is the dream of immature programmers and marketeers. Naturally, every language designer tries both to strengthen his language to better serve its core community and to broaden its appeal, but being everything to everybody is not a reasonable ideal. There are genuine design choices and tradeoffs that must be made.

Q: Programmers often talk about the advantages and disadvantages of programming in a "simple language." What does that phrase mean to you, and is [C/C++/Java] a simple language in your view?


Ritchie: C (and the others for that matter) are simple in some ways, though they are also subtle; other, somewhat similar languages like Pascal are arguably simpler. What has become clear is that aspects of the environment like libraries that aren't part of the core language are much bigger and more complicated.
The 1999 C standard grew hugely more in the library part than in the language; the C++ STL and other things are big; AWT and other things associated with Java are too.
Stroustrup: Notions of "simple:" to be easy to learn, to make it easy to express ideas, and to have a one-to-one correspondence to some form of math. In those terms, none of the three languages is simple. However, once mastered, C and C++ make it easy to express quite complex and advanced ideas.


Q: What topics do you feel are missing from university computer science and engineering programs around the world that would help to improve the quality of software?

Stroustrup: In some well-respected computer science departments, you can graduate without having written any code. That ought not be possible. Nobody should graduate with a degree in computer science or computer engineering without having completed a significant programming project. Code is the base of computing and people without a "feel" for code tend to seriously misjudge what skills, tools, and time are needed to build good systems.


I think reading and writing code should be a significant part of the training of every computer professional. However much we talk about "Computer Science" and "Software Engineering", building systems still has a large practical component relating to reading, writing, and maintaining code.


No, I'm not arguing that we should just teach hacking
I argue for a balance between theoretical and practical skills.
Gosling: People have been getting a pretty good education in the technology; what they tend to not get is a good view of what goes on in an actual engineering organization:

Q: Outside the C family of languages, what language(s) do you like the best? What in particular makes them interesting to you?

Ritchie: I have to admire languages like Lisp. But, just as in the earlier question about a "simple" language, an astonishingly simple language grows in practice into something that can be fearsome.



Stroustrup: Algol68, CLOS, and ML springs to mind. In each case, what attracts me is flexibility and some very elegant code examples.


Q: What are your favorite software-related books?

Ritchie: The works of Kernighan and Pike (separately or collectively) are nice. The software book I enjoyed most is Ben Ross Schneider's Travels in Computerland.
Stroustrup: Brooks' The Mythical Man Month Booch's Object-Oriented Design, and Gamma et.al.'s Design Patterns.


Programming Language Standards
Q: Is it important to have a formal (e.g., ISO/ANSI) standard for a programming language? What are the advantages? The disadvantages?



Ritchie: At some point a formal standard tends to become necessary, particularly for language that evolved informally (certainly C, but also C++ and Java
At the same time, there are disadvantages, in that whatever clear (or cloudy) vision that the original designers might have had ends up colored by whatever strange proposals the participants in the process bring forth. Complication invariably results as a result of the compromises.
Stroustrup: In today's overheated commercial atmosphere it is essential to have a formal standard. Naturally, an ISO standard is not a complete defense, and not all of our languages, libraries, or tools can be standardized. However, without a standard, users are completely at the mercy/whim of their suppliers.
Conformance suites are widely used for ISO C and ISO C++.


Q: Is it important to have a de facto standard for a programming language? What are the advantages? The disadvantages?

Stroustrup: A de facto standard is a major advantage to its owner and its owner's friends/allies. It can also benefit third parties, such as professors, students, and small companies
Gosling: I think that in a strong sense de facto standards are the ones that really matter. It hardly matters what's actually written down in anybody's standards document; what actually matters is what people have actually implemented.

I'm a real fan of Linux; the problem is that there are so many flavors of Linux and they're all just different enough that life is really hard.


The "Century 21" Software Industry
Q: Prognostication is hard, but valuable even if it can never be 100% accurate. In your view, what are the major forces driving the kinds of software we will be writing in the future? and the way we will be writing that software?


Ritchie: The most obvious change that has occurred recently is the increase in use of "scripting languages" that are generally interpreted. These range from the basic ones like HTML to Perl, Tcl/Tk, and Javascript, and then to presentation-graphics packages for making WWW pages or slides.
Stroustrup: The future? these days it is close to impossible to even describe the present.
We have to see more emphasis on correctness, quality, and security.
I really hope 2050s software and systems will be too advanced for me to imagine today, just as a 1950s expert had little chance of predicting today's systems with any accuracy or in any detail.

Notes :

1. B. Kernighan and D. Ritchie. The C Programming Language, 2nd edition (Prentice Hall, 1998) ISBN 0131103709.
2. B. Stroustrup. The Design and Evolution of C++ (Addison-Wesley, 1994) ISBN 0201543303.
3. B. Stroustrup. The C++ Programming Language, Special Edition (Addison-Wesley, 2000) ISBN 0201700735.
4. http://www.research.att.com/~bs.
5. B. Stroustrup. "Wrapping C++ Member Function Calls" (C++ Report, 12(6), June 2000).
6. B. Stroustrup. "Learning Standard C++ as a New Language" (C/C++ Users Journal, May 1999; also in CVu 12(1) January 2000).
7. B. Kernighan and R. Pike. The Practice of Programming (Addison-Wesley, 1999) ISBN 020161586X.
8. B. Kernighan and R. Pike. The UNIX Programming Environment (Prentice Hall, 1984) ISBN 013937681X.
9. B. Kernighan and P.J. Plauger. The Elements of Programming Style (McGraw-Hill, 1988) ISBN 0070342075.
10. B. Schneider. Travels in Computerland: Or, Incompatibilities and Interfaces: A Full and True Account of the Implementation of the London Stage Information Bank, ASIN 0201067374.
11. F. Brooks. The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1995) ISBN 0201835959.
12. G. Booch. Object-Oriented Analysis and Design With Applications (Addison-Wesley, 1994) ISBN 0805353402.
13. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns : Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) ISBN 0201633612.
14. J. Bentley. Programming Pearls, Second Edition (Addison-Wesley, 1999) ISBN 0201657880.
15. R. Sedgewick. Algorithms in C, 3rd edition (Addison-Wesley, 2000) ISBN 0201849372. (There are at least ten "Algorithms" books by Sedgewick, covering different scopes or specialized for different programming languages. This is one of the most recently written/updated.)
16. A. Koenig and B. Moo. Ruminations on C++ (Addison-Wesley, 1996) ISBN 0201423391.

(Source : Internet )
N.B: This article was trimmed to fit for the theoretical enhancement of various professionals , students and others.



Saurav Banerjee, Ranchi , INFI-NITE .

techinfiniteonline@gmail.com

0 comments:

Post a Comment