Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Balkanization Of A Popular Programming Language

By Carnage4Life in Technology
Wed Apr 25, 2001 at 09:56:21 AM EST
Tags: Software (all tags)
Software

In the constantly changing world of software, programming language standards are aimed at providing stability and consistence in a dynamic industry.

Unfortunately there are many problems with standards created by standards bodies including: the standard attempts to satisfy too many interested parties and ends up so full of compromises that it is bloated yet satisfies few; the standards body is not quick enough to react to changes in the market place; or the body may be paralyzed by internal bickering over controversial decisions which may lead to seeming inactivity. The end result of the aforementioned problems is that the technology being standardized eventually is fractured as different vendors being dissatisfied with the standard do their own thing.

This is a story about one such standard and the contentious future of the programming language it represents.


Bjarne Stroustrup's "C with Classes" is one of the most popular application development languages currently in use. In the relatively short history of C++ it has flourished without an official standard (although there was the de facto ARM standard) until quite recently when in early 1998 the draft standard was ratified by the ANSI/ISO C++ Committee. The new standard made major additions to the language as well as changed old behavior of the language but was heralded by most as a welcome occurence.

Fast forward to 2001. Sun Microsystem's Java programming language begins to deliver in places where C++ has notoriously shown failings. The massive standard library which included platform independent threading and networking APIs, the elimination of memory related errors and leaks, a framework that allows for relatively easy building of medium and large scale component architectures as well as increased productivity versus languages like C have begun to make C++ look less and less attractive in comparison to the likes of Java. The main advantage C++ has over Java for most developers is performance but this may soon be irrelevant with growing hardware advances as well as improvements in Just In Time compilers.

C++'s principal designer, Bjarne Stroustrup, in an interview with Linux World early this year described the features he would like to see added to the language to make it more useful to the modern developer. He listed features like concurrency, reflection and extended type information, garbage collection, platform independent system facilities and compatibility with C99 as high on the list of potential additions to future drafts of the language. Bjarne Stroutrup has since followed up this interview with a meeting with other top C++ luminaries such as Scott Meyers, Herb Sutter and Dan Saks.


Stuck in First Gear

There is one little problem with the fact that new additions to the C++ standard are currently being proposed. The current standard is yet to be implemented fully. The C/C++ User's Journal recently had a C++ Compiler Conformance Roundup in which they declared the following:
There is no C++ compiler or library today that implements the Standard perfectly, but some are getting close.
Harsh words but true nonetheless. The C++ standard turned out to have features with more complex interrelationships and ramifications than were realized at the time the standard was being discussed. A good example of a subtle complexity that was not obvious at first glance is this discourse on namespaces which describes how Stroustrup claimed that the feature could be "imlemented in ten days" and explained to develepors "in ten minutes". Later on it turned out that the implementations at the time used for reference had gotten it wrong and in fact there isn't a compiler that has gotten it a hundred percent right.

The GCC 3.0 release criteria page displays that the C++ functionality is the major bottleneck preventing the release of GCC 3.0. What is particularly interesting is that while most other criteria have Done or Partly Done besides them to indicate their level of completion, the C++ functionality is strangely bare as if to indicate that there is still a significant amount of work to do. A Microsoft employee recently released a list of features that won't be supported in the upcoming release of Visual C++ 7.0 which means that a standards compliant Microsoft C++ compiler is still years away.

One begins to wonder if it's been almost four years since the draft discussions and yet no single compiler implements the entire standard, then when will the additions currently being proposed finally make it into the standard and then into the real world in a way that is compatible across platforms and compilers? Two years? Four? Six maybe? Where will C99, Java and C# be by then? Will C++ then have to perenially play catchup to match the usefulness of languages that have simpler grammars and thus easier to create compilers for?


"Managed" Extensions to C++ and Other Tales

The microsoft.public.dotnet.languages.vc newsgroup thread where the Microsoft employee listed the C++ features that will keep Microsoft's C++ compiler from compliance contained a number of interesting comments (143 at the last count) which seemed to have one overreaching theme. C++ standards compliance is a minor issue in Microsoft's plans when compared to the long term goal to out-Java the Java platform with the creation of .NET.

The difficulty of finding experienced compiler writers as well as the fact that the Visual C++'s team's main priority is to make sure that the Managed Extensions for C++ which allow C++ programmers to utilize the .NET framework is in place and ready to go as soon as possible makes it seem unlikely that full standards compliance will be forthcoming for quite a while. Also the fact that creating a C++ compiler and libraries which conform to the standard is more complex than for most other programming languages in existence also increases the difficulty of task.

Finally the fact that some of Microsoft's extensions seem to already tackle solutions to problems being considered by Stroustrup (e.g. garbage collection) it looks like it is even more likely that any future additions to the C++ standard will make it into Visual C++ quickly.

As for other compiler vendors and standards compliance, I leave you with this quote from Paul Mensonides on the microsoft.public.dotnet.languages.vc newsgroup obtained from the thread linked above.
As far as a split goes...what do you think that we have now? MS C++ (with managed extensions, attributed code, MFC, ATL, and a bunch of other 'extensions.') vs. Borland C++ (with VCL, MS copy-cat extensions) vs. IBM C++ (who now only supports AIX (conveniently their own OS)) vs. Comeau & EDG which is actually trying hard for compliance but they still have a huge amount of 'options' to try to make VC++ legacy code still work, etc., etc.. The split HAS happened

Java, Perl, or C: Which Language Will Be Next To Face The Spectre of Balkanization?

The C++ programming language is currently fractured and will probably remain so for a long time. C++ developers now left trying to figure out how to reconcile the different versions of C++ that they encounter from platform to platform or IDE to IDE for an indefinite amount of time. One question I am left asking myself is "Where else could this happen?"

  1. C99: The C99 standard has gotten very little industry press and very few of the C/C++ compiler writers (e.g. Microsoft, Borland, etc) have any mention of it on their sites. Also it seems few, if any, authors are writing books targetting C99 even though the standard is two years old. It is thus quite conceivable that when it does finally gain acceptance that it will face the same problems with inertia that C++ has had to deal with. At least it has a much simpler grammar and the changes are not as vast.


  2. Java: It turns out Sun may have been smart to hold on to their language and fight tooth and claw to keep anyone from altering it. With the amount of alterations and extensions Java has faced, from J++ to Generic Java it is a good thing that there was a powerful corporation to make sure the actual Java™ standard didn't get abused instead of a toothless committee that can only complain.


  3. Perl:In a talk at the Atlanta Linux showcase, Larry Wall discussed potential features for Perl 6. Amongst these potential features was
    "The language will be dynamically extensible, using modules written in Perl. So you can program in a language that looks like Python, Latin, or Java, if you want.".
    This seems to imply that the language which already can be rather undecipherable in hands of even a reasonably competent programmer can now be altered drastically almost at whim. This can only lead to fracturization but in this case it may be expected and maybe even encouraged.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Which of the following languages do you think will be fractured in the coming decade?
o C# 16%
o Java 22%
o Perl 8%
o C 8%
o Lisp 5%
o SmallTalk 2%
o Objective-C 1%
o C++ 33%

Votes: 71
Results | Other Polls

Related Links
o history of C++
o ARM
o major additions to the language
o changed old behavior of the language
o Java programming language
o Just In Time compilers
o interview with Linux World
o meeting with other top C++ luminaries
o Scott Meyers
o Herb Sutter
o Dan Saks
o C++ Compiler Conformance Roundup
o this discourse on namespaces
o GCC 3.0 release criteria page
o A Microsoft employee recently released a list of features that won't be supported
o microsoft. public.dotnet.languages.vc newsgroup
o Managed Extensions for C++
o J++
o Generic Java
o Larry Wall discussed potential features for Perl 6
o Also by Carnage4Life


Display: Sort:
The Balkanization Of A Popular Programming Language | 48 comments (45 topical, 3 editorial, 0 hidden)
Compiler Implementation (3.58 / 12) (#2)
by Bad Harmony on Wed Apr 25, 2001 at 03:23:38 AM EST

I don't think it is technically difficult to implement a standards compliant C++ compiler. It takes time, money and some talented programmers. It also requires a company or group that is willing to make standards compliance a primary goal.

I remember when many people despaired of ever seeing an Ada-83 compiler. The NYU interpreter was often described as an "existence proof". Early Ada-83 compilers were slow memory pigs, whose output code wasn't anything to write home about. The compilers evolved and improved. Unfortunately, the money went elsewhere, to C, C++ and Java. One advantage that Ada-83 had, and Ada-95 still has, is a strong emphasis on standards. For a time, the Defense Department held a trademark on Ada, preventing its use by companies who wanted to market non-compliant compilers.

How does this apply to C++? There is an ISO/ANSI standards document for C++, but as far as I can tell, no enforcement mechanism. The government used to be able to push standards by making them a requirement for bids on contracts. That doesn't seem to work as well as it used to. The commercial market has grown at a much faster rate than the government market, reducing the government's market power. To reduce costs, the government has put a greater emphasis on COTS (commercial off the shelf) products and defacto industry standards, as opposed to formal FIPS or ANSI standards.

Microsoft has the money and brainpower to produce a standards compliant C++ compiler. The problem is that standards compliance is "nice to have", not a primary requirement. This puts it low on their priority list. I can't blame them, .NET is a lot more important to the future of Microsoft than a checkbox for ISO/ANSI compliance. Due to their dominant market position, whatever compiler they ship will be the standard for Windows C++ programmers.

I would like to see standards compliant C99 compilers. The problem is there isn't much of a market for C compilers. A lot of C programmers are using C++ compilers to compile their C code, even though they are using few, if any, of the new features in C++. I'm not sure if there is even a market for C++ compilers, other than Visual C++. WATCOM C/C++ has been terminated. Visual Age C++ has retreated to only supporting IBM operating systems. Borland has all but killed their C++ compiler as a commercial product. Who's left? There is GNU for open source operating systems, and proprietary compilers for non-Microsoft commercial operating systems like Solaris.

5440' or Fight!

Oh? Are you Sure? (3.83 / 6) (#3)
by moshez on Wed Apr 25, 2001 at 04:27:39 AM EST

I don't think it is technically difficult to implement a standards compliant C++ compiler.
Then I guess Cygnus are a bunch of idiots? Of course, they aren't, and of course, it is very hard to write a standards compliant C++ compiler, because the language is huge, and very little care has been given to make compiler writing easy.

[T]he k5 troll HOWTO has been updated ... This update is dedicated to moshez, and other bitter anti-trolls.
[ Parent ]
Technical Difficulty (3.00 / 3) (#5)
by Bad Harmony on Wed Apr 25, 2001 at 04:51:03 AM EST

There is a difference between having to implement a long list of features and having to invent new techniques to solve research problems. Both are "hard", but in different ways.

5440' or Fight!
[ Parent ]

Research Problems? (4.20 / 5) (#6)
by moshez on Wed Apr 25, 2001 at 05:22:47 AM EST

Here's one simple research problem in implementing a C++ compiler: how to keep template code from being compiled and linked into the objects for each time an compilation unit uses a template? How to do correct name mangling? When to make the symbols in the object file viewable from the outside?

[T]he k5 troll HOWTO has been updated ... This update is dedicated to moshez, and other bitter anti-trolls.
[ Parent ]
Not Technically Difficult? (4.33 / 9) (#8)
by Carnage4Life on Wed Apr 25, 2001 at 09:39:42 AM EST

I don't think it is technically difficult to implement a standards compliant C++ compiler.

Then you obviously have either a.) never looked at the C++ grammar or b.) read the C++ standard. C++ is probably the most complex programming language in existence with subtle complexities that can tax even the most brilliant minds. I agree with the overall content of your post, but the above statement is simply incorrect.

Here's a question that emphasizes the difficulty of writing compilers; how many compiler writers do you know? Now compare that to the amount of people you know doing web programming, databases, operating systems, games, computer graphics, etc.

--
NEW IMPROVED K5 USER INFORMATION PAGE

Click here to find out more about your fellow K5 readers. A bug in the code was fixed and over 100 names have been added.


[ Parent ]
Well, in fairness... (3.66 / 3) (#18)
by trhurler on Wed Apr 25, 2001 at 04:11:59 PM EST

Yes, it is nearly or totally impossible to produce a truly "perfect" C++ compiler. The language is a dungheap. However, the truth is, writing compilers for reasonable languages is not that hard. It is like an operating system: it is a large task, and it has to be done very carefully if the result is to be correct, but with a few little exceptions here and there, most of it is (or can be, at any rate,) fairly straightforward code. The notable exception is optimization engines, but in my opinion a large part of the problem there is more in reading the literature than implementing the results. The authors have chosen to regard their field as a well developed science that is best described with mathematics, when in fact it is a poorly developed craft that is best described by showing what each optimization does and from whence you can derive the information necessary to carry it out correctly in a very informal manner. This is one case where math massively obfuscates what are usually very, very simple ideas.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
Not hard? Ha! (4.91 / 12) (#17)
by MarkCC on Wed Apr 25, 2001 at 02:00:01 PM EST

I don't think it is technically difficult to implement a standards compliant C++ compiler. It takes time, money and some talented programmers. It also requires a company or group that is willing to make standards compliance a primary goal.

Let me tell you, you couldn't possibly be more wrong. I worked with the IBM group that developed VisualAge C++ v4. I sat in the interminable meetings where we tried to figure out just what the heck the template section of the specification meant. We were absolutely determined to produce the first fully standards compliant C++ compiler. And the group of programmers that worked on the project is the brightest collection of people I've ever seen in one place, working under one of the finest managers I've ever seen (and he was also a great programmer; the bulk of the template system was his).

In the end, we shipped a system that we thought met the standard. It turns out that we didn't even get templates right.

C++ is a horrible language. It's insanely complex, and the specification is among the most poorly specified, overcomplex, incomprehensible ream of rubbish that I've ever seen. I don't care how much time and effort you put into it: I do not believe that there will ever be a fully compliant C++ compiler. I'm not even sure that "fully compliant" means anything when applied to C++.

You mention Ada as a counterpoint, because people thought it was unimplementable. There's a big difference with Ada, and it isn't the political and resource issues that you claim. The Ada spec, while wordy, is a complete, thorough document. It can be difficult to read, because precise specifications are difficult to read, but it very clearly specified everything. The Ada specification is, in my opinion, just about the best language spec that could possibly be developed by a committee. And that is what makes Ada implementable.

The complexity of C++ absolutely dwarfs Ada, and the specification is disorganized, jumbled incomplete, and confusing. Writing a fully compliant compiler for C++ would be at least an order of magnitude more complicated than the original Ada, and the specification is far worse.

[ Parent ]

And Ada has concurrency too! (none / 0) (#46)
by Brian N on Fri May 04, 2001 at 05:36:56 PM EST

Here! Here! For your comments on Ada. I've found Ada to be quite a bit more coherent than C++. Also it's interesting that the Ada compiler community seems much more interested in standard conformance than the C++ community. Possibly this has to do with the standards community developing a strong test suite. I worked at an Ada compiler company and it's pretty much a given that the starting place for an Ada compiler is to pass the conformance tests, extra features are then above and beyond this.

[ Parent ]
Watcom is not dead! (3.50 / 2) (#19)
by Bridge Troll on Wed Apr 25, 2001 at 05:08:06 PM EST

They are currently in the process of removing code that was licensed from other companies, and are going to release it as an Open Source project. The Site.


And besides, pounding your meat with a club is a very satisfying thing to do :) -- Sleepy
[ Parent ]
Not dead... just sleeping... (3.00 / 1) (#27)
by technik on Thu Apr 26, 2001 at 10:17:01 AM EST

Seriously, I bought Watcom C/C++ and the upgrade to 11.0 because it handled DOS, DOS with 32-bit extender, Win 3.1, OS/2, and Win32 and had a great debugger and decent libraries and documentation all for my academic price of $100. It was a fine investment and I was saddened when Sybase acquired PowerSoft and finished the task of killing Watcom. I'm glad to see that something will become of such a good product.

- technik

[ Parent ]
Essential complexity (3.66 / 3) (#40)
by Simon Kinahan on Fri Apr 27, 2001 at 09:18:03 AM EST

Writing compilers is not inherently hard, because at this point in time so much work has gone into each of the stages required that someone well versed in the literature can produce a compiler with some confidence given an adequate language specification. Indeed, some effort has been made to automate the process based on an operational semantics for the language.

The trouble with C++ is the language specification is complex in a difference sense to Adas. Ada is a complex language in that is is very big, but C++ is complex because all the different language features interact with one another in ways that most users of the language, and indeed some of its designers did not properly anticicpate. To use Brooke's terminology, C++ is essentially complex, that is it is inherently hard to understand because to understand one part, you must understand how it interacts with all the others. Ada is merely non-essentially complex, and to some extent this is because many of those who worked on it were professional language semanticists and mathemeticians who knew how to make things simple.

Projects, like writing a C++ compiler, that have high levels of essentiall complexity, inherently take longer to complete and riskier to run that those with less

Simon

If you disagree, post, don't moderate
[ Parent ]
Cathedral vs Bazaar (3.37 / 8) (#4)
by Paul Johnson on Wed Apr 25, 2001 at 04:48:39 AM EST

Its interesting to compare the development model of C++ and Java with that of Perl and Python from this point of view.

On the one hand we have the Cathedral model of ANSI standards committees who define what the language is, and then teams go away and produce compilers which comply with the spec (more or less), and which are judged by their compliance. Of course they all fail to comply in subtly different ways, leading to the "write once, debug everywhere" problem.

(Aside: I recall calling a C++ vendor back in the 80s to complain about a compiler bug, and being told that it was a compatibility bug introduced to match the behaviour of Cfront).

On the other hand we have the Bazaar model of Perl and Python where a language has no official standard. Instead there is a single open-source implementation backed up by a shared view of the Right Thing for the implementation to do. Because there is only one implementation the issue of multiple incompatible implementations goes away, and with it the need for a high-powered standards body to decide the One True Thing for implementation to do. Meanwhile the open source nature of the single implementation means that anyone can add enhancements, so programmers are not owned by a single corporation.

If I wanted to write software that was guaranteed to be easily portable between Windows or Unix I'd want to start on a language with a single open implementation.

Paul.
You are lost in a twisty maze of little standards, all different.

Not Really Cathedral vs. Bazaar (4.57 / 7) (#9)
by Carnage4Life on Wed Apr 25, 2001 at 09:55:41 AM EST

On the other hand we have the Bazaar model of Perl and Python where a language has no official standard. Instead there is a single open-source implementation backed up by a shared view of the Right Thing for the implementation to do. Because there is only one implementation the issue of multiple incompatible implementations goes away, and with it the need for a high-powered standards body to decide the One True Thing for implementation to do.

The reason that there is typically only one implementation of the languages you mentioned on a given platform is twofold.
  1. No formal documentation makes it practically impossible to create another implementation from scratch.

  2. Since most aspects of these languages are Open Source or at least free of charge, there is little incentive to expend time and capital to create another implementation which won't have a return on investment.
Even with the above difficulties there are still competing implementations of these languages on various platforms (e.g. tehre were two Win32 versions of Perl that merged to become ActivePerl).

Meanwhile the open source nature of the single implementation means that anyone can add enhancements, so programmers are not owned by a single corporation.

The fact that people can add enhancements to a language is not particular to Open Source or the bazaar style. In fact my entire article is about people adding extensions to a language that is not developed in the bazaar manner.

--
NEW IMPROVED K5 USER INFORMATION PAGE

Click here to find out more about your fellow K5 readers. A bug in the code was fixed and over 100 names have been added.


[ Parent ]
Nice theory, but your facts are not straight (2.33 / 3) (#13)
by Alhazred on Wed Apr 25, 2001 at 11:58:59 AM EST

On point one. There is a very good set of documentation for Perl. I can't speak to Python or any other similar languages like PHP, but Perl is extremely well documented. I seriously doubt it is lack of documentation which stops people from reimplementing perl.

Point 2 is on the money I would say, and this is the entire reason for open sourcing tools. Lets face it, compilers are a commodity item now. There are development tools enough to choke 500 horses out there. Thank god there doesn't need to be 10 different perls!

Your theory that there ARE in fact different Win32 perls is based on an unclear understanding of the version history of perl on win32. There is in fact only one win32 perl, and it is the same perl that is on Unix, currently the latest version being 5.6.0.

Activestate was contracted a few years ago by MS to port perl to win32. They chose to fork off from perl 5.003 and created their own branch of that which linguistically was standard perl, it just had a few quirks and a bit variant versions of some libraries.

This was percieved as not a "GOOD THING" and an effort was made to both port perl 5.004_03 to win32 and make sure the Activestate branch merged back into that. This led to now, where since 5.004 something or other perl has compiled and worked on win32 right out of the box and all the standard perl libraries (and 99% of CPAN in general) works seamlessly on win32.

Personally I seriously doubt that had these been 2 commercial vendors that this sort of easy and painless merging would have happened.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
perl documentation (5.00 / 1) (#44)
by nthomas on Tue May 01, 2001 at 01:36:10 AM EST

On point one. There is a very good set of documentation for Perl

I don't think he meant documentation about Perl, but rather, documentation on the grammar and syntax of the language itself, i.e. BNF-type language description.

No such description exists for Perl, nor will it ever exist for Perl in its current state. (Though I hear rumors that Perl 6 will have a BNF)

[ Parent ]

What do you mean? (none / 0) (#48)
by Alhazred on Thu May 10, 2001 at 09:33:38 AM EST

I can pick up my Programming Perl book and there it is... No there is not a BNF description of perl grammer, BUT since the perl interpreter is written using standard tools like lex and bison I seriously doubt that such a grammer is non-existent... I believe that the way perl's syntax works it is a tricky grammer to describe (IE it would take a lot of BNF) but its not impossible.

Besides BNF is FAR from the be-all and end-all of notations. Try writing a BNF for FORTH for instance... Can't be done. BNF only fits a narrow set of language designs which space has already been so filled with implementations that one would be wasting one's time to create another...
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
no formal documentation? (3.00 / 3) (#14)
by Ricdude on Wed Apr 25, 2001 at 12:39:45 PM EST

For python at least, there exists the reference implementation in C, as well as a Java implementation. Not a java wrapper around the compiled C interpreter, an actual parallel implementation in java. I've also seen a version for the palm pilot, which probably is relatively independent of the reference C implementation. The previous comment that "The committee decides what the language spec is, then the implementers go and build compilers" is somewhat incorrect in scope. The committee consists has representatives from various (commercial) compiler vendors, who have some concept of how this is going to be implemented in their framework, who offer feedback on various trial implementations under consideration. This isn't just the high and mighty committee's stone tablets passed on from the ivory tower, there is a feedback loop with the implementors during the specification process. This is part of the reason that the spec takes so long to publish.

[ Parent ]
Reference implementation isn't formal document. (3.75 / 4) (#16)
by Carnage4Life on Wed Apr 25, 2001 at 12:54:54 PM EST

For python at least, there exists the reference implementation in C, as well as a Java implementation. Not a java wrapper around the compiled C interpreter, an actual parallel implementation in java.

There's a difference between giving a compiler vendor a BNF and a list of requirements and giving them a binary and going "Just emulate it's behavior".

Secondly reference implementations can have bugs or be incorrect like the namespace example I gave in my article.

--
NEW IMPROVED K5 USER INFORMATION PAGE

Click here to find out more about your fellow K5 readers. A bug in the code was fixed and over 100 names have been added.


[ Parent ]
What do people do if a compiler is not compliant? (3.75 / 4) (#10)
by hading on Wed Apr 25, 2001 at 10:27:39 AM EST

So what do people in the C++ community do when a compiler is not sufficiently standards compliant and the vendor is unresponsive to the concern? In the Common Lisp community, people seem willing to scream bloody murder and threaten to switch vendors at even a hint of breaking the standard. (Of course, extension is permitted, as long as it doesn't break the standard - otherwise it would be hard to have progress.) There was a tremendous row not too long ago over Franz's (the biggest player in Common Lisp, for those who don't know) decision to ship a slightly non-ANSI image as the default in their trial product, even. I'm not really hooked into the C++ community, but I don't know if I've ever sensed a similar sense of outrage over failure to compy to the spec.



Bitch about it on news groups (3.50 / 4) (#11)
by codemonkey_uk on Wed Apr 25, 2001 at 10:36:37 AM EST

Unfortunatly, standards compliance isn't the only factor when choosing a compiler, in my area of development, games, DirectX support (on Win32), and a good optermiser are generally considerd to be more important.

For console development, you generally use gcc, or whatever compiler is in the dev kit.

So, Microsoft with DirectX and console dev kit vendors have a 'monopoly' for their respective platform, and there is not much you can do about it. :(

GCC is making headway as a competitor, but still has problems with code size bloat, and, more importantly, debugger support.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

DirectX in gcc (3.25 / 4) (#15)
by pin0cchio on Wed Apr 25, 2001 at 12:45:23 PM EST

Unfortunatly, standards compliance isn't the only factor when choosing a compiler, in my area of development, games, DirectX support (on Win32), and a good optermiser are generally considerd to be more important.

DirectX support in GCC can be had by using the DirectX SDK port to MinGW, as used in this popular DirectX wrapper. GCC's code generation is darn good; even back when GCC 2.9x was EGCS, it was better than everything but MSVC. I'm sure it's improved greatly since then.

For console development, you generally use gcc, or whatever compiler is in the dev kit.

That's correct on newer consoles, but programmers on older consoles such as NES, Super NES, and the ever-popular Game Boy Color still must use assembly language because the 8-bit processor (6502 or Z80) is too hard to generate efficient C code for, lacking even a multiply instruction. Old consoles also may have as little as 2 KB of CPU-addressable RAM. (Sega Genesis is m68k-based; it doesn't count.)


lj65
[ Parent ]
Noncompliance (4.16 / 6) (#12)
by ucblockhead on Wed Apr 25, 2001 at 11:40:50 AM EST

Much of the trouble is that very few C++ programmers are know all that much about the features that compilers tend to be noncompliant in. There are an awful lot of C++ coders, especially in the Windows world, who've never touched the STL, know nothing about the new casting operators and code basically in circa '95 C++. A big part of this is because many of these new features were already implemented in different ways by Microsoft. (Or Borland, or whoever as the case may be.) And you can hardly blame them. It was really lame to have a high-level language with no string class.

So more so in C++, bitching about standards noncompliance is the province of only a few. It is hard to get people worked up over a problem in std::string or wierd template behavior when they use CString and have never written their own templates.

I really despair of this ever changing and I think the basic problem was that some crucial features (good data structures, strings) were just added too late. By the time they were added, the language had already become popular enough for groups to add the missing features themselves. And when one group is a vendor of a monopoly OS, and they use their own versions of these features for their APIs, well, you've got issues.

The fact that the language is hugely complex, and that it takes years just to get to the level where you run into most noncompliance problems just makes it worse.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

look at things like htdig (3.50 / 4) (#20)
by eLuddite on Wed Apr 25, 2001 at 06:44:42 PM EST

So what do people in the C++ community do when a compiler is not sufficiently standards compliant and the vendor is unresponsive to the concern?

They whine and then they use it as if it were C with classes. Like they always did. C++ esoterica goes right out the window if you have any hope for cross compiler compatibility. I'm not a C++ fan but even I, who resists learning all its details, can understand open source C++ code because none of it taxes the C++ language definition. For most people, C++ standardization has become a solution looking for a problem.

---
God hates human rights.
[ Parent ]

what else can you do? (3.50 / 4) (#21)
by VZ on Wed Apr 25, 2001 at 08:10:10 PM EST

For cross-platform programming you have to restrict yourself to a subset of C++ - look at our standards to see what we have to do to ensure that the code compiles everywhere.

Hopefully, this situation should improve soon but until very recently/now the ISO C++ standard was absolutely useless for portable programming (or worse, when it breaks code written in accordance with the ARM rules)

[ Parent ]

C++ Irrelevance (3.50 / 6) (#23)
by labradore on Thu Apr 26, 2001 at 04:53:03 AM EST

Most programmers do not use anything like the entire functionality of C++. C on the other hand is a language that is used for today's applications in ways that Kerrigan and Ritchie problably did not imagine.

I have a feeling, however, that most of the C++ code in use today is basically C in the C++ syntax. Also, I have never met anyone who "likes" C++.

Since:

  1. C is well-known and well-loved
  2. C++ is universally disliked but often used and probably often mis-used because it is a superset of what programmers need to get the job done.
  3. Microsoft tells programmers: use C++ to write windows programs. That's why most programmers use C++ for PC apps. Microsoft compatible apps probably account for most of the code in use today. That's why C++ is the standard.
  4. C++ compiles slowly and usually results in (more) bloated programs.
  5. C may actually be for practical purposes a subset of what aught to be used to write most programs today.

Logically we conclude:
If someone were to come up with a language with about the same complexity as C but with enough of the C++ extentions to make it the right fit for what aught to be used to write most applications today then that would be better to use than C++.

I can only guess that some group of isolated sane programmers at Redmond came up with C# to fill that role.

It would be nice if C# or something like it became a useful and standardized language that could fit between C and C++. I wonder if this can possibly happen given that it comes from Microsoft.

-Rob

You, sir, are full of it. (3.44 / 9) (#24)
by codemonkey_uk on Thu Apr 26, 2001 at 06:14:18 AM EST

I like C++. Yes, it has its faults, but so do all programming languages.

This, however, is not the only point in your post which is blatently wrong.

  1. "C is well-known and well-loved"

    Well known, yes, well loved, I'm not so sure. The Open Source community, and embeded systems programeers, are the last bastions of modern C development. Everyone else (students and hobbiests aside) has moved on. Even game developers now predominantly use C++.

  2. "C++ is universally disliked ..."

    Really? I like it. Where are your stats? Education may be a problem for the C++ community, but your ignorance does not make it a bad language.

  3. "Microsoft tells programmers: use C++ ..."

    Actually Microsoft is telling programmers to use C# and .NET, but it doesn't matter what they say anyway, the don't know jack, or care one jot, about C++. The MS position on C++ is irrelevent.

  4. "C++ compiles slowly and usually results in (more) bloated programs"

    Slow compile times are a QoI issue, not a langauge design issue, and anyway, what do you expect from a high level langauge. The less work the programmer has to do, the more work the compiler has to do, and vice versa. Good modular design should mitiage the problems surrounding slow built times, and C++ supports many idioms, such as the pimpl idiom that help this. As for your often repeated claim that C++ produces bloated apps, I say: Myth. Back up your claim. I dare you. Last time I checked any app implemented in C could be implemeted in C++ with the exact the same overheads. On modern archetectures compliers can generate *more* efficient code for C++ than C (think error handling and zero over head exceptions, as implemeted by the MetroWorks compiler).

  5. "C may actually be for practical purposes a subset of what aught to be used to write most programs today. "

    Oh yeah? You have no idea what your talking about do you? Care to explain this for us would you?


---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
..sigh.. (4.00 / 3) (#30)
by labradore on Thu Apr 26, 2001 at 12:07:43 PM EST

  1. Of course C is well-loved. That's why it's still around. That's why C++ is based on C!
  2. Most people understand the KISS principle. As it is currently, C++ violates this principle. That's why this article was written--is it even possible to write a fully-compliant C++ compiler? Nobody knows! I got carried away when saying "is universally disliked." Do you like the fact that you can't use a lot of the intended functionality of C++ because it's just too friggin' hard to impliment properly and consistently across platforms? You admitted that open source projects tend toward C more than most projects in general. Why is this? Could it be that if given a choice many people prefer C?
  3. Like it or not, Microsoft does matter. Most code has to work with Windows. I have never had the good fortune to have an employer that didn't want all my code to at least run on Windows if not be native to it (the former being less often an option than the latter). Among other things, Yes, at this precise moment a politically correct Microsoft employee may tell you that C# and .Net are de jour. But stop and think: Why do they call it MS VC++? Because for the past 5 or 6 years C++ has been the language in the API of choice for writing windows programs. Do you seriously think that .NET programs won't be written in C++?
  4. I say that C++ is more likely to result in bloat than C. You may be a guru who knows how to pare your apps down to be lean and mean but many people just don't know how or don't want to bother. In the real world, it's better to have a tool that works well by default--not just for the experts.
  5. Have you ever tried to use the original Win32 C API? Wonder why GTK+ is so goofy compared to something like the BeOS API? C is an unnatural fit for these sorts of tasks. C++ seems to work better but most of use already agree that it really is overkill and may (unintentionally) be too complex for it's own good.
I admire the way C++ was conceived and Bjarne's intentions. It's a brilliant and sometimes beautiful language. That doesn't neccessarily mean it's good in the real world. Frequently C++ doesn't help programmers write good programs. What aught to be used is whatever works well and is as simple as possible--but not simpler.

[ Parent ]
I is a big spanner (2.00 / 2) (#32)
by codemonkey_uk on Thu Apr 26, 2001 at 01:02:36 PM EST

I realise now I misread (dispite quoting!) some of your staments. Sorry.

I still disagree with some though. Most Open Source is done on Unix, and to many people Unix means C. Add to that the lack of an ABI, and historical reasons, such as poor QoI on old compilers, and you have your answer.

My point on MS was not that they don't matter, but that the sorry mess that is their compiler, does not in itself make the langauge a sorry mess.

As for the lack of skill in C++, again, this doesn't make the language bad. Just as if I got into an F1 car and spun it into a wall, that would not make F1 cars inherently unsafe, it would make me unfit to drive F1.

At the moment large scale software development is an still an area of debate. Lanaguges like C do not scale well (don't quote the Linux kernal at me - its an exception, and a well known domain) - nobody really knows what the "right way" to do things is. Of course things will get complex, many solutions are provided for many problems. I think C++ has problems, but is basically in the right area, as far as efficiency of both the developer and application, goes.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Large Projects CAN be done in C, and done well (4.00 / 1) (#42)
by Rhamadanth on Sat Apr 28, 2001 at 03:02:57 PM EST

Have you ever played MDK II, by Bioware?

I live in Edmonton, so the good folks at Bioware came to my University, and told us about implementing and optimizing games. I made a point of asking them if it was much more difficult to implement a game in a non-object oriented fashion, and if the common thought that C is 'impossible' to use on large projects was true.

They said that no, it was just fine. It was possible for them to do everything that they wanted to. The project was large, and they managed all right. MDK II is the result, and it's a fine (if difficult :) game.

While it may be a myth that C++ generates more bloated executables than C, it's also a myth that C can't be used on big projects. A good initial design will almost always win out over language features.

Moreover, just as the overhead becomes more and more negligable (in terms of size) between C and C++ programs as they get larger, I believe the design overhead similarily comes to a convergence. On very large C++ projects, you'll have to do almost as much work on maintaining a clean design as you would if you were using C.

From a language design perspective, C++ is the worst of all possible conceivable worlds. It's really no wonder that no C++ compiler is fully complete. Hell, it was hard work writing a shitty Pascal (actually, a subset of pascal called PAL) compiler in a 3 month course. The grammar was simple, the design was (comparatively) trivial. A C++ compiler? I'd rather die than try to write one.

Lastly, I think your car analogy is a bad one. Firstly, you should not be required to have a team of the programming elite to create an arbitrary project (just as F1 drivers are the driving elite, to clarify my parallel). I fully believe it's possible to design a language that is fast, flexible, and lends itself to good design with only a moderate amount of programmer effort. Secondly, I'd hardly call C++ an F1. It's more like a stockcar that got sent in to the swiss army knife company, and they grafted everything conceivable onto it, making it 40 times bigger, and a lot more pointy.


-- The /bin/truth is out there.
[ Parent ]
Objective C (3.50 / 6) (#25)
by hammy on Thu Apr 26, 2001 at 07:48:44 AM EST

What about Objective C. This seems to be a viable alternative to C++ that is a bit nicer...

[ Parent ]
A myth (3.75 / 4) (#28)
by ucblockhead on Thu Apr 26, 2001 at 11:25:58 AM EST

C++ compiles slowly and usually results in (more) bloated programs.

This is a myth. I'm currently working on a story, with source code, that'll show this.

Part of the reason that people make this mistake is because they compile "Hello, World" under C++ and find it twice the size as "Hello, World" under C. But the reason for this is the addition of the startup library code. C++ obviously has more because it includes all of C's functionality. But as program size increases, this size differential becomes pretty meaningless.

In addition, people usually forget to turn on the optimizer before the comparison. In the particular short C program I'm looking at now (~1000 lines) g++ produces about a 24k executable while gcc produces about a 21k one. Not much of a difference, especially considering that most of the 3k difference is library startup code.

A C++ implementation of the same design is 27k, by the way. 3k for classes. Now if you forget to turn the -O flag on, the C++ version is nearly twice the size, which is one reason people make the mistake of thinking it is "bloated".


-----------------------
This is k5. We're all tools - duxup
[ Parent ]

indeed (5.00 / 1) (#31)
by hading on Thu Apr 26, 2001 at 12:29:51 PM EST

Definitely true as far as bloat is concerned. It's hard to tell without looking at a serious program. I can probably get "Hello, World" down to about 300K on the Smalltalk that I use, and perhaps around 2.6M for my Lisp enviroment. :-) That may be offputting (and seem bloated) to some people - but a real application isn't necessarily going to be much bigger. I'd hate for people to judge these languages (and I'm sure some do) based on their "Hello world" behavior.

The real message is that it's kind of useless to bash a language/environment/methodology etc. unless you've taken the time to become at least decently proficient at it and to do something significant with it. At that time, perhaps one's opinion finally becomes meaningful.



[ Parent ]
the perception of C++ bloat (4.00 / 1) (#35)
by eLuddite on Thu Apr 26, 2001 at 09:04:25 PM EST

The source of C++ bloat is C programmers looking at the asm output and going "what the!?"

Where C is a nice universal assembler, C++ is considerably too high level and suffers bias precisely because it retains C's look and feel. Thus you get a whole bunch of people using C++ as if it were a strongly typed C (blithely continuing to write printf() just the same) with classes and becoming all reactionary when they see evidence of bloat. I.e. me. I'm a C programmer and while I have no trouble with something as high level as Modula-3 or a scripting language, I instinctively recoil from C++. If you are a C++ programmer, unlearn C. If you dont know either, dont learn C first.

(I also reject the claims OOP makes for programming teams of one but that's another story.)

---
God hates human rights.
[ Parent ]

True, that. (3.00 / 1) (#34)
by ksandstr on Thu Apr 26, 2001 at 08:24:20 PM EST

Pretty much anyone who has "experience with C/C++" in their CV can be assumed not to know the difference. I've certainly seen enough C that wouldn't compile with a C compiler to know that.

Fin.
[ Parent ]
C with C++ "syntax" (3.00 / 1) (#38)
by janpod66 on Fri Apr 27, 2001 at 12:00:01 AM EST

I have a feeling, however, that most of the C++ code in use today is basically C in the C++ syntax.

I'm not sure what you mean by that. If you mean that a lot of C++ code is not object oriented, I fully agree. But non-OO code still takes advantage of most of C++. Arguably, the best parts of C++ are not its object system (which I consider largely useless), but exceptions, templates, overloading, references, type-safe linkage, and automatic resource management.

[ Parent ]

I like C++ (3.25 / 4) (#39)
by jonnyfantastik on Fri Apr 27, 2001 at 05:23:12 AM EST

Bjarne Stroustrup spoke at Columbia University today and after hearing him talk and (try to) answer my questions, I have to completely agree with the author. Bjarne Stroustrup is destroying C++. The man is a schizo, completely out of his mind. * No language can do all things for all people. * On one hand C++ is to be as fast as possible, a systems language which can write device drivers. * C++ needs a GUI api and threads api (which is just pure daydreaming, you can hardly do threads in a language in a portable manner the preserves semantics unless you take the virtual machine approach) so it can be a powerful applications programming language api. * C++ must be as efficient as possible, if not more efficient. * It's not worth it to expand the syntax of the language to include things like template parameter constraints because these can be done using existing language features and "minimal" efficiency loss. * Compatibility with C99 will be maintained at all costs. * Compatibility with C99 will be maintained within reason. Any sane person can look at these statements and see they are all clearly contradictory but Stroustrup continues to make them. Furthermore, we all know C++ is a horrible language. Let's be honest. Until you've read 'Effective C++ (Scott Meyers)', 'More Effective C++ (Scott Meyers)', 'The STL (Niccolai Josuttis)', and 'Large Scale Software Design in C++ (John Lakos), you're practically guranteed to write bad C++ code. The language has tons and tons of pitfalls and traps - most of these are because it tries to maintain compatibility with C. Yet, I still like C++. It is fast, it is efficient, and it is powerful. You can do absolutely amazing things with templates and OO and function objects and produce incredibly simple and powerful designs. It is fast. And, most of all it is not C <./b>. C - or as I like to call it, portable PDP-11 assembler - is an absolutely terrible, archaic, and primitive language. Sure it's fast, and it's also the most error-prone language ever invented. I like to call C++ 'programmer hostile' but I call C 'crap'. The way I see it, unless you're writing an operating system, a compiler, or doing real time, you have no excuse to be using C. The fact is, the way I see it, C++ is really on the decline. It's being pulled in too many directions and Microsoft knows this so it's decided simply to drop all pretense of standardization. This is a tragic. Without C++ you will not be able to write polished, large, and fast programs.

[ Parent ]
Life cycle of a language (5.00 / 1) (#45)
by mvw on Wed May 02, 2001 at 05:52:38 AM EST

Bjarne Stroustrup spoke at Columbia University today and after hearing him talk and (try to) answer my questions, I have to completely agree with the author. Bjarne Stroustrup is destroying C++. The man is a schizo, completely out of his mind.

This is a foolish judgment. He is an interesting mix of scientist, active researcher, hacker and manager. He is certainly not stupid and everything I ever read from him showed good argumention (which includes actually listening to your opponent's statements).

What I admired most of Stroustrup, was him not stopping creating and documenting a cool language, but transcending that level by cranking C++ through a standardization process. That was mature.

No language can do all things for all people.

C++ design goals were clear. And to be honest I am not convinced by your listing of goals that they contradict.

At present I am not sure what will happen to C++. I am on a Java project now and I thought a lot about, if it is possible to take the good parts of Java and add them to C++. The most important difference is the quality and size of the Java libraries in my opinion. The availability of a cross plattform GUI (AWT/Swing) is a big plus, combined with powerful IDEs. The resulting software feels very modern. For the exception of the reflection API, I see no principal obstacle, why it is not possible to create something similiar for C++.

We could even create some VM platform for C++, to allow the easy porting of a certain class of software that does not need top notch performance, but rather needs to be available on a hugh range of platform. Something like netbeans, a kind of framework for MS Devstudio like IDEs.

Netbeans illustrates some problem I see with C++. While C++ programmers love the low level plane of programming, Java programmers tend to skip that and focus on the higher abstraction planes. I use to think more in terms of object and component interactions in Java than I do in C++. My guess to why is, that I have to less often reinvent the wheel in Java than in C++, because of the rich library. Conclusion we need such a library in C++.

But who will write it?

We have no Sun in the C++ world, except Microsoft and that one is promoting C# now. The open source world might come to the rescue, or might not. I am not sure yet. Stuff like qt and KDE or attempts like boost.org might help. But will they be enough? No idea yet.

Time is a problem as well. Perhaps one day we have the perfect open source version, like gcc 3.0 :-), but will it be state of the art? Right now we are a couple of years behind in some areas. As a C++ lover I hope people can allow them enough patience to stay with this baby. Otherwise our C++ community will become the next Lisp community, exclusive and convinced of having the best solution, but not used by the majority of professionals.


Regards, Marc
[ Parent ]

nanii? (3.50 / 2) (#47)
by delmoi on Sat May 05, 2001 at 01:27:08 AM EST

C is well-known and well-loved
C++ is universally disliked but often used and probably often mis-used


What?

Well, I for one Hate plain-C, although I do enjoy C++. I can't stand programming in non-OO ways.
--
"'argumentation' is not a word, idiot." -- thelizman
[ Parent ]
Perl (3.00 / 3) (#26)
by darthaggie on Thu Apr 26, 2001 at 09:44:50 AM EST

This can only lead to fracturization but in this case it may be expected and maybe even encouraged.

This is news, how? I can still write perl 4 code and for the most part, the v5.x series interpreter will accept it. This is a feature, not a flaw. Modules similar to what is proposed for v6 already exist: use English; #English - use nice English (or awk) names for ugly punctuation variables

What the programmer using perl needs to keep in mind is this as well:

Remember First Corinthians 6:12: Everything is permissible for me -- but not everything is expedient.

This is, IMO, one of the greatest of the Perl mottos. At once I am very grateful for, and would not give up, the freedom I have in Perl; but I wish more people (including me) would remember that all actions taken in freedom are not equal. Some are good, some are bad. And part of freedom is responsibility to know which is which and to act appropriately. Of course, Perl code is not nearly of the gravity expressed by Paul to the church at Corinth (IMO). But the principles are sound, important, and applicable.

-- Chris Nandor

This may strike you as odd, but freedom requires discipline.

I am BOFH. Resistance is futile. Your network will be assimilated.
Choosing the Road, Carefully (4.54 / 11) (#29)
by ChaoticCoyote on Thu Apr 26, 2001 at 11:27:55 AM EST

A bit of background: I've been "doing" C++ since 1989, and have a few books and articles under my belt to demonstrate my fondness for the language. While I work with many other programming languages on a regular basis, C++ is my first choice when it comes to developing most applications.

Is C++ balkanizing? I think so; witness Microsoft's disinterest in supporting Standard C++ for the .NET platform. As of the first Visual Studio.Net beta, Visual C++ remains highly non-compliant with Standard C++. Unlike Java, C++ does not have anyone enforcing Standardization; while Java's draconian approach has been problematic in itself, C++'s laissez-faire approach has engendered laziness, selfishness, and complacency in compiler vendors.

Is there a 100% Standard C++ implementation on any platform? I don't know of one.

From a practical standpoint, the above question may be moot. I write Standard C++ code that works with a half-dozen compilers on several platforms; with the exception of a few features (template specialization, the export keyword), I don't feel overtly restructed by using a C++ "subset." If I really want Standard C++ under Windows, I pull out the Intel 5.0 compiler, which is closer to the ideal than is Microsoft's offering.

Is C++ too complicated for compiler writers to implement? Perhaps; I remember sitting with Walter Bright back in the Zortech days (long before templates!), listening to his frustrations with making C++ work according to "specs". I've known compiler developers at Microsoft with similar feelings. The language is rather complex, and the nuances can catch one by surprise. One the other hand, just because something is difficult doesn't mean it shouldn't be attempted.

Is the C++ community best-served by adding new features and extensions -- or would we be better off clarifying the language and promoting adherence to the Standard? I'm not quite sure; I have mixed feelings, in that I want intrinsic support for certain things (concurrency, for one). But as a developer of commercial software, I also know that products fail when they lose focus and try to be everything to everyone. I believe Java has failed in some respects because it continues to add new features without ensuring that the core language and VM are universal and strong.

Does C++ want to travel the same road as Java, by trying to be everything to everyone? Or do we need to establish a solid foundation before embarking in new directions?

We -- the users and implementors of C++ -- need to answer those questions soon, I think.


--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com


Why a standard? (none / 0) (#41)
by prostoalex on Sat Apr 28, 2001 at 12:06:51 AM EST

At the same time, when you come to the restaurant, you would like to be offered a menu, not just a meal of the day and that's it. Some things in a language need to be standardized, but later on it evolves to serve its purpose, and the purpose is different in each and every case. The more radical the differences are in the same implementation of the language, the better the project is served.

[ Parent ]
Bite me, Javakopf. (2.66 / 9) (#33)
by ksandstr on Thu Apr 26, 2001 at 08:16:54 PM EST

Goddammit, another "java is so fucken leet, everybody oughta use it for everything!!! ain't no reason not to!!! 'ees the language of the future!!! a real silver bullet!!!" trollator.

OK, I'm not going to refute your strawmen. Hell, I'm not even going to get into an argument with you -- I'll just state my reasons not to touch Javur with someone else's dick.

  • Java is a "there's exactly one way to do it, if you want to stay 100% pure" language. In practice this means that if you have like 100 connections active in a parallel network application, you're going to have 100 threads (plus a couple for JVM control) -- one for each connection. Needless to say, with a JVM that uses kernelspace threading, this is an enormous waste of resources (not to mention the waste of available process slots on systems with a compiled-in process limit). Also, don't even MENTION the so called "green threads" (I'd call them "partially co-operative userspace threads", much like GNU Pth) -- not that there is anything inherently wrong with userspace threads, but if you're going to use them you'd better code for them (i.e. yield the damn CPU after N iterations).
    Needless to say, this most certainly isn't the way stuff is done in the UNIX world.
  • Mandatory garbage collection. This means that your average JVM instance pegs at least 8 megs of non-swappable memory (because the GC is going to grovel over that RAM, looking for references), and that's not including the libraries and other runtime stuff you're going to need just to run that damn HelloWorld.main() function.
  • Java encourages sloppy memory management. If you don't want to allocate so freaking many objects whose useful lifetime is much shorter than the method they were created in, you're going to have to do some of that "instance reuse" dancing which in my book is exactly the same as manual memory management. Except that you don't have to free the pointer afterwards.
  • No matter what gee-whiz JIT JVM you run, Java is going to be slower than properly written (i.e. exception-using) C++ code. Always. Memory compaction tricks won't help -- you'll still boink the entire L2 cache when your lovely JVM grovels over your 1000s of temporary objects.

In a nutshell, I'll say that the one thing that may make Java an attractive environment for so-called "Enterprise solutions" (which is just a fancy name for something utterly disinteresting [payroll math, anybody?] that requires Really Big Iron to run) that you couldn't get a proper hacker to work on for money or love and have to hire people who think C is too hard for their little brains.
Java may also not be completely horrible for environments where you can Optimize With Hardware (i.e. the dotcoms of yesterday) because your developers are crap.

Damn. I should put this stuff on a web page, so that I could just drop an URI whenever necessary.



Fin.
What article did you read? (4.00 / 4) (#36)
by Carnage4Life on Thu Apr 26, 2001 at 10:35:01 PM EST

Goddammit, another "java is so fucken leet, everybody oughta use it for everything!!! ain't no reason not to!!! 'ees the language of the future!!! a real silver bullet!!!" trollator.

If you have beef with Java there is no need to project your insecurities at my article. My article is based on my observations of occurences in the software induistry as a whole. I did not advocate Java's use of C++ in any part of my article or even pronounce that "C++ is dead" or some similar crap.

If the fact that people are using Java so much bothers you, that has nothing with my article. If I was a Java advocate then I wouldn't be writing several articles on C++ for kuro5hin.

--
NEW IMPROVED K5 USER INFORMATION PAGE

Click here to find out more about your fellow K5 readers. A bug in the code was fixed and over 100 names have been added.


[ Parent ]
misconceptions (4.00 / 4) (#37)
by janpod66 on Thu Apr 26, 2001 at 11:56:01 PM EST

Mandatory garbage collection. This means that your average JVM instance pegs at least 8 megs of non-swappable memory (because the GC is going to grovel over that RAM, looking for references), and that's not including the libraries and other runtime stuff you're going to need just to run that damn HelloWorld.main() function.

That's, of course, complete nonsense. You don't need 8Mbyte to support a garbage collector. And even if you have an 8Mbyte heap (because you actually do have that much data), a good garbage collector usually needs to go over only a tiny fraction of that memory.

Java encourages sloppy memory management.

C++ is worse: programmers hold on to objects in C++ much longer than they need to because they simply cannot figure out when it is safe to deallocate them.

you're going to have to do some of that "instance reuse" dancing which in my book is exactly the same as manual memory management

But it isn't. First, you only need to add pools for performance critical code. Second, if you mess up with manual storage management in C++, anything can happen: the behavior of the program in undefined. If you mess up with pools in Java, the effect is strictly limited to the objects involved.

No matter what gee-whiz JIT JVM you run, Java is going to be slower than properly written (i.e. exception-using) C++ code. Always. Memory compaction tricks won't help -- you'll still boink the entire L2 cache when your lovely JVM grovels over your 1000s of temporary objects.

If you are saying that you have to "boink" (empty?) the entire L2 cache in order to garbage collect temporary objects, that's false. Besides, even if it were true, the amortized cost is likely still lower than the cache effects of calling into the C++ memory allocator many times.

And there are many other areas where a Java compiler can optimize code and a C++ compiler simply doesn't have sufficient information to do a good job. Simpler languages are easier to compile well, and that's why Java will likely win in the end for implementing equivalent functionality.

[ Parent ]

Committees are not at fault here... (4.50 / 2) (#43)
by seebs on Mon Apr 30, 2001 at 08:16:46 AM EST

I'm on an ISO committee, and it's not an intrinsic necessity that ISO committees will behave this way... but insofar as it's a necessity, it has nothing to do with it being a "standards committee" and has mostly to do with the size and nature of the user community. C++ has a very segregated user community, full of people who are quite willing to compromise as long as they get the features on their checklist.


The Balkanization Of A Popular Programming Language | 48 comments (45 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!