C++
standard library, just like the rest of the C++ language specification,
is a set of interfaces and requirements. Each compiler vendor writes
their own implementation of the interfaces that satisfies those
requirements.
To add a new component to the C++ standard library, you not only have to write your own implementation, you would have to convince Microsoft, IBM, HP, Oracle, Intel, GCC, Clang, and other C++ compiler representatives that it's worth spending their developers' time to implement and test and deploy this new component. In most cases, the things that you find in the C++ standard library are the things that have been in use for a decade prior.
To add a new component to Java, you just have to implement it once.
To add a new component to the C++ standard library, you not only have to write your own implementation, you would have to convince Microsoft, IBM, HP, Oracle, Intel, GCC, Clang, and other C++ compiler representatives that it's worth spending their developers' time to implement and test and deploy this new component. In most cases, the things that you find in the C++ standard library are the things that have been in use for a decade prior.
To add a new component to Java, you just have to implement it once.
Because
it's defined by one company (formerly Sun, now Oracle) to serve its
interests with one implementation not committees representing varied
users a subset of which must implement any new standard.
A better comparison might be between the standard Java library and boost libraries which run on all popular platforms and are also defined outside a slow committee based standardization process.
A better comparison might be between the standard Java library and boost libraries which run on all popular platforms and are also defined outside a slow committee based standardization process.
Size
doesn't make up for quality. The Java standard library is big, but
sometimes it's bigger than it should have been, and that's mostly due to
the fact that Java grew depending on the commercial needs of Sun
Microsystems. The Java framework is everything that Sun Microsystems
wanted to be, and there's a lot of things that you'll never need for a
Java application. The Java frameworks also grew with technology, and
everything is there for backward compatibility. However, when you look
at the Java for devices edition (Java MicroEdition), you will see that
the standard library/framework is still quite large.
The problem is that Java has to deliver a full interface for an operating system, an interface that it extends with its own constructs. It has to have file management, it has to have threads management, it has to have a lot of stuff that would be too slow if implemented in Java (for example parsing of XML files). All these add-up.
On the other hand, for a very long time the C++ standard library defined just a set of containers and algorithms. Why? This was a design decision: you do have the freedom (and you're encouraged) to step outside the standard library and implement the things that you need, and only that. This way you won't have to pull huge constructs, remain small, remain efficient, remain fast. C++ also ensures that you don't ever pay for features that you don't need, for example reflection. All Java constructs have to support reflection (and pull the reflection engine in your application) because your code can be inspected at run time. This has tragic impact on the performance of your code.
The C++ programmer can choose not to work with the standard constructions either. I can start everything from scratch and scrap the standard library altogether. I can call only C code, and the operating system interfaces directly.
Of course, the lack of standardization is costly for the C++ developers in general, this is why the new standard (C++11/14) added support for more libraries. For example, it's the first time there is a standard model for threading: filesystem, XML parsing and other libraries are under scrutiny. But design by committee is never fast, and it will take some time until the standard library will grow to accommodate such things that are basic stuff in the higher level languages environments. With the clear advantage of choosing tried and well tested models (unlike many of the Java/C# APIs that had several iterations until they got to be the right way).
TL;DR: C++ chose to not enforce a standard library and left freedom to the developers, while Java chose productivity over performance.
The problem is that Java has to deliver a full interface for an operating system, an interface that it extends with its own constructs. It has to have file management, it has to have threads management, it has to have a lot of stuff that would be too slow if implemented in Java (for example parsing of XML files). All these add-up.
On the other hand, for a very long time the C++ standard library defined just a set of containers and algorithms. Why? This was a design decision: you do have the freedom (and you're encouraged) to step outside the standard library and implement the things that you need, and only that. This way you won't have to pull huge constructs, remain small, remain efficient, remain fast. C++ also ensures that you don't ever pay for features that you don't need, for example reflection. All Java constructs have to support reflection (and pull the reflection engine in your application) because your code can be inspected at run time. This has tragic impact on the performance of your code.
The C++ programmer can choose not to work with the standard constructions either. I can start everything from scratch and scrap the standard library altogether. I can call only C code, and the operating system interfaces directly.
Of course, the lack of standardization is costly for the C++ developers in general, this is why the new standard (C++11/14) added support for more libraries. For example, it's the first time there is a standard model for threading: filesystem, XML parsing and other libraries are under scrutiny. But design by committee is never fast, and it will take some time until the standard library will grow to accommodate such things that are basic stuff in the higher level languages environments. With the clear advantage of choosing tried and well tested models (unlike many of the Java/C# APIs that had several iterations until they got to be the right way).
TL;DR: C++ chose to not enforce a standard library and left freedom to the developers, while Java chose productivity over performance.
For all intensive purposes C++ became yet another also ran almost 20 years ago with the popular advent of Java.
The bickering, glacial, infighting multi corporate lumbering bureaucratic set of companies overseeing the standards committee insured that C++ would fail.
Gosling and Sun Microsystems, had purpose, focus and inspiration when creating Java. The Java language was not hamstrung by the now absurd backwards compatibility constraints that C++ had with C. Java efficiently addressed most of the structural problems instrinisic to C++.
These included things like the preprocessor, multiple inheritance, Java decreased dependency on the underlying OS using the Java virtual machine, etc ...
One of the other failures of C++ was the requirement that developers had to purchase third party libraries to obtain standard functionality. I had to write C++ code for 5 years. Companies like RogueWave SW had to create and sell their wares. I had to shop and search for basic tools. This as clumsy and economically inefficient just because C++ was lacking basic standard libraries. What good is an OOP language that had no reusable modules included ?
Java has addressed this problem for years by gradually adding and extending libraries to support code reuse and simplification. Yes for those who adopted Java almost two decades ago, this was a promise and hope that has been fulfilled. It was a leap of faith back then. In the mid 90's the difference between Java and C++ was far less. But it was clear to me at the time that C++ had big problems and Java offered a vision and a better road map.
Hence almost 20 years later, Java is still moving forward, C++ will never catch up.
The bickering, glacial, infighting multi corporate lumbering bureaucratic set of companies overseeing the standards committee insured that C++ would fail.
Gosling and Sun Microsystems, had purpose, focus and inspiration when creating Java. The Java language was not hamstrung by the now absurd backwards compatibility constraints that C++ had with C. Java efficiently addressed most of the structural problems instrinisic to C++.
These included things like the preprocessor, multiple inheritance, Java decreased dependency on the underlying OS using the Java virtual machine, etc ...
One of the other failures of C++ was the requirement that developers had to purchase third party libraries to obtain standard functionality. I had to write C++ code for 5 years. Companies like RogueWave SW had to create and sell their wares. I had to shop and search for basic tools. This as clumsy and economically inefficient just because C++ was lacking basic standard libraries. What good is an OOP language that had no reusable modules included ?
Java has addressed this problem for years by gradually adding and extending libraries to support code reuse and simplification. Yes for those who adopted Java almost two decades ago, this was a promise and hope that has been fulfilled. It was a leap of faith back then. In the mid 90's the difference between Java and C++ was far less. But it was clear to me at the time that C++ had big problems and Java offered a vision and a better road map.
Hence almost 20 years later, Java is still moving forward, C++ will never catch up.
No comments:
Post a Comment