Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C++ Creator Confident About Its Future

Zonk posted more than 9 years ago | from the he-loves-his-baby dept.

Programming 241

bonch writes "Bjarne Stroustrup is confident about the future of C++. He says there is a backlash against new languages like Java and C#, and that developers are returning to C++." From the article: "He claimed the main reason why people are not aware of this is because C++ doesn't have a 'propaganda campaign.' Sun Microsystems has touted the use of Java in the Mars Rover program, for example, but Stroustrup asserts that C++ was also used.

cancel ×

241 comments

C++ Should Be The Only Programming Language (4, Funny)

rqqrtnb (753156) | more than 9 years ago | (#12323339)

Today's Software and IT industries are plagued by programming errors. While some of these errors are the result of illegal use of non-Microsoft software on rogue networks, the majority of problems stem from difficulties in mingling code of different programming languages. Standarization on the best-of-breed programming language, C++, would undoubtedly reduce errors in software.

In this article, I seek to dispel the myth that non-C++ languages are beneficial in proper Software Engineering. I outline how standardization on the C++ language can strengthen your corporation's bottom line. And I describe how to contact the men in Congress to have C++ use finally made legally mandatory.

C++, a programming language invented by Lucent's Bjarney Strupstrup in 1995, has been hailed as a God-send to Computer Science since its creation. Based on Richie Kerninghan's language "C+", C++ brought several previously-theoretical programming languages features to the mainstream:


Church-Rosser Compliance
Known as "multiple inheritance" in the programming world and as "being Church-Rosser" in academia, C++'s compliance to this IEEE standard immediately placed it head-and-shoulders above other languages. "Churrossity" allows programmers to use blocks of code, called "objects," in place of other blocks of code ("arrays".) The layman can think of this as "allowing 'new' code to 'run' old code." This advance has not been possible in previous logic-based languages such as Ada.

Multi-Byte Characters
C++ allowed use of "Beaster," a subset of Microsoft's COM ("Common Object Model") windowing layer. The Beaster system allows non-English-speakers such as the Welsh to use computing technology, as it could redirect the signals used to display non-English characters on a computer's monitor screen or laser printer. It is also useful in helping the blind, who speak a specialized subset of English called "ALS."

Pass-By-Text
A non-recursive pass-by-text mechanism existed in Kerninghan's C+, called "macro facility." But Strupstrup did Kerninghan one better with the "String Template Loader" variable passing mechanism, which allowed text to be passed to procedures at run-time. This sped up code execution times, as code could be compiled while the user was running the program. This eliminated speed loss caused by incompatibility from obselete computer chips (Motorola and ADM.)

The superiority of C++ over other languages should be obvious. But is switching to it from other languages possible in your corporation? Astute observers will note that the eco-terrorist group FSF produces a C++ compiler called "DJGPP." Under President Bush's War on Terror, any organization supporting a terrorist organization is recursively itself a terrorist organization.

Corporations needn't worry. Microsoft has its own C++ offering, "Visual Studio." As an added bonus, Microsoft Visual Studio is highly standards compliant. It features a visual programming interface, and several features not found elsewhere (such as a visual debugger and an AOL instant messanger client called "Windows Messaging".)

But these advantages can only be realized if code written in inferior languages can be kept from polluting the inter-web eco-space. When compilers for other languages are available, low-level managers are tempted to write code in them. Why? Often times, managers are brought up from the ranks of Software Engineers, and thus lack an Executive's sense for using the right tool for the job. When these managers write code in a jungled zoo of languages, code in one program is unable to interact with code from another program (churrossity.) Only by standardizing on C++ can all programs run together smoothly. Using C++ to eliminate software errors will jump-start the sagging technology industry. This will boost our economy as a whole, which in turn will help us to win the War on Terror.

The effort to legally mandate this has been going on for a while. But it needs your help. Even the smallest person, such as a reader of this site, can make a difference with his Congressman. Congressmen are kept highly versed in technical issues by lobbyists from Microsoft and Intel. But without strong grassroots input, the men of Congress and the Senate are powerless to heed the corporations' pleas.

Please, I urge you to visit Congress.com [congress.com] and Whitehouse.com [whitehouse.com] to help bring this important movement to its fruition.

Re:C++ Should Be The Only Programming Language (0)

Anonymous Coward | more than 9 years ago | (#12323799)

Since maybe like the Middle Ages, there have been many differing opinions on hustle and bustle. This cannot be denied. It is my intention to sit down and play video games for several hours.

First, moving around quickly, and with purpose, is a true sign of character. Secondarily, bustle(e.g. hustle) yields more product for the working types. "Hustle and bustle are like my right and left arms," said Li'l Spicy in his famous "Hustle and Bustle Are Like My Right and Left Arms" speech. Webster's defines bustle as "excited and often noisy activity; a stir." A stir, indeed. Finally, sometimes gross stuff can be funny.

In conclusion, I, "The Yellow Dart," think I have done a great job illustrating the many differing opinions about hustle and bustle, may they both rest in peace. Also, I think Strong Bad should decrease The Cheat's allowance.

plagiarism (5, Informative)

cronian (322433) | more than 9 years ago | (#12323951)

Isn't this copied from http://www.adequacy.org/public/stories/2002.7.4.18 3710.3582.html?

creator of the C++ programming language (2, Interesting)

Atrax (249401) | more than 9 years ago | (#12323347)

Creator?

OK, mod me troll, but surely C++ is by definition an 'extension' of C?

So, creator is a big word. Or perhaps the lack of context is the problem? Or maybe I'm just a language nazi?

mod me pedant....

Re: creator of the C++ programming language (1)

javax (598925) | more than 9 years ago | (#12323390)

well yes, author would have been a better choice imho.

Re: creator of the C++ programming language (2, Insightful)

Slow Smurf (839532) | more than 9 years ago | (#12323400)

It went from a non object oriented language to an object oriented one, seems like creating to me.

(though yes, you can of course use OO in C, it just sucks)

Re: creator of the C++ programming language (2, Funny)

jhoger (519683) | more than 9 years ago | (#12323447)

Using OO sucks in C++

At least in C your bugs are all yours.

-- John.

Re: creator of the C++ programming language (2, Funny)

david.given (6740) | more than 9 years ago | (#12324242)

At least in C your bugs are all yours.

All These Bugs Are Yours --- Except .net. Attempt No Coding There.

*cough* sorry.

Re: creator of the C++ programming language (1)

nacturation (646836) | more than 9 years ago | (#12324839)

Using OO sucks in C++

At least in C your bugs are all yours.


So when using libraries in C++, all your bugs are belong to us?

Re: creator of the C++ programming language (1)

FidelCatsro (861135) | more than 9 years ago | (#12323600)

He created an object oriented extension to C called C++(we call sun the creator of java and java is basicaly an extension to C also) , so he is the creator of C++.
Creator is the correct word or designer , architect take your pick its all fine.

Re: creator of the C++ programming language (1)

black mariah (654971) | more than 9 years ago | (#12323768)

The differences in C and C++ are extensive. About the only thing they truly share are braces and semicolons to end lines. Calling C++ and extension of C is like calling a battleship and extension of a yacht. Sure, they're both boatlike but that's about where the similarities end.

Not an extension (3, Informative)

rjh (40933) | more than 9 years ago | (#12324147)

C++ started out as an extension of C, but the two quickly diverged. C++ is not a superset of C; it's an entirely different language nowadays with a syntax clearly borrowed from C.

A trivial conversion exists between any ISO C90 program and ISO C++, but then again, we have FORTRAN-to-C translators and nobody thinks C is an extension of FORTRAN.

Stroustrup would also likely be a little uncomfortable with the appellation "creator". While he's certainly been one of the pivotal figures in C++, Stroustrup has always been quick to recognize the contributions of other people and the work of the ISO standardization committee.

While it would be nice... (4, Insightful)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#12323429)

it seems that with corporate support, Java and .NET technologies, as well as Perl, PHP and Python are the major languages for the future, not C++.

Apart from PHP and Perl, the above languages are usually very strict in their object-oriented ways, and thus prevent loose syntax and clumsy errors. But this nannying produces only poorer developers who rely on the language rather than their own abilities to code effectively.

A return to C++ would be nice, especially in educational institutions, as it provides all the necessities of modern languages, bar effective string-handling, while maintaining the simplicity of older languages.

While Java and .NET may be the future for enterprise software, developers should learn C/C++ first, and not Java, as those who can program effectively in C and/or C++ tend to code better in Java and .NET, while the reverse is not true.

Re:While it would be nice... (0)

Anonymous Coward | more than 9 years ago | (#12323538)

While Java and .NET may be the future for enterprise software, developers should learn C/C++ first, and not Java, as those who can program effectively in C and/or C++ tend to code better in Java and .NET, while the reverse is not true.

So provide some facts please, rather than your bullshit opinion.

Re:While it would be nice... (2, Insightful)

FidelCatsro (861135) | more than 9 years ago | (#12323631)

You dont hammer a nail with a screwdriver , and you dont program an OS in Java.
C++ fills a rather difrent void and there is place for all , it really depends what you want. Right tool for the job as always applys

Re:While it would be nice... (2, Insightful)

aCapitalist (552761) | more than 9 years ago | (#12324534)

..., and you dont program an OS in Java.
C++ fills a rather difrent void and there is place for all


How many operating systems are coded in C++? I know a lot that have been coded in C, but none that have been coded in C++.

Re:While it would be nice... (1)

FidelCatsro (861135) | more than 9 years ago | (#12324566)

That comment had nothing really to do with C++ other than it being another language ,it was related to the hamering a nail with a screwdriver simile.

I probably should have said
You dont hammer a nail witha screwdriver , and you dont program a modern "First person shoot'em'up" in java.
But the point remains the same

Re:While it would be nice... (1)

aCapitalist (552761) | more than 9 years ago | (#12324680)

I agree with your point that C++ fills a void. And no matter how many times I've cursed the language (I've written more lines of C++ in my professional career than any other language), I still think it was stupid that de Icaza chose C over C++.

Re:While it would be nice... (1)

FidelCatsro (861135) | more than 9 years ago | (#12324755)

C and C++ each fill a void but those two voids all too often cross over .
Also I guess its which of the two your more comfertable with , perhaps c++ would be a better all purpose choise , but if he has more experiance with C, it can more than make up for any short-commings.

Re:While it would be nice... (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12324823)

BeOS was written in C++

Re:While it would be nice... (2, Interesting)

UnknownSoldier (67820) | more than 9 years ago | (#12324844)

> BeOS was written in C++

The kernel wasn't, but all the 'Kits' above it was.

Re:While it would be nice... (3, Insightful)

Chris_Jefferson (581445) | more than 9 years ago | (#12323697)

bar effective string-handling

out of interest, what's wrong with std::string?

Re:While it would be nice... (4, Insightful)

Lally Singh (3427) | more than 9 years ago | (#12324018)

It's an actual C++ feature. 90% of the people on this site that say they know C++ know C with classes.

Re:While it would be nice... (1)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#12324071)

Actually, you are right. There isn't anything wrong with std::string. However, a regexp feature, a la Perl, would be nice.

Re:While it would be nice... (0)

Anonymous Coward | more than 9 years ago | (#12324328)

Regex classes have been added to C++ in TR1, which will eventually become the next C++ standard in 2005 or 2006.

GCC 4 even has working implementations of all the TR1 stuff already (mostly based on code in boost).

See the docs about what other goodies are in the std::tr1 namespace. New smart pointers, regexes, better I/O, and so on. The stuff many people have been wishing for :)

Re:While it would be nice... (1)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#12324357)

I haven't been keeping up with C++ in a while because of school, which is fixated on Java. I'm still a C/C++ fan at heart.

Thx for the heads up. I can't wait for GCC 4 (Cygwin) with tr1.

Re:While it would be nice... (4, Informative)

mobydobius (237311) | more than 9 years ago | (#12324415)

if you really are interested in c++ regex, you should get to know Boost [boost.org] . It is a fantastic set of libraries that play nice with the standard c++ library, and includes regexes, parser generators, threads, algebra and probability packages, serialization, custom memory handling, and more.

Re:While it would be nice... (1)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#12324487)

I actually like Boost, but it would be nice to have it as part of the standard itself. C++ is woefully lacking in features that newer languages likes Java and C# have by default.

I haven't fiddled around with Boost threads though. How would you rate them against protothreads?

Re:While it would be nice... (1)

mobydobius (237311) | more than 9 years ago | (#12324579)

never used protothreads. im not an expert thread programmer, and i like boost::thread because i find the interface and usage pattern recommendations simple enough to follow, but not dumb enough not to do useful things with it. it doesn't aim to be a cutting edge thread library, but a library that encapsulates stable thread notions, and can be used to build higher level ideas.

iso c++ standard moves slow to be sure. since much of boost is a proving ground for the standard, and since it has its own review process that seems stringent enough, i find it can be used along with std as a "better" standard library.

Re:While it would be nice... (1)

Unordained (262962) | more than 9 years ago | (#12324928)

I've never understood this. What's with people's fascination with the libraries provided with a language? On the one hand, we have people complaining about how awful C++ is in terms of "language design" (by which they're referring to the actual grammar of the language, what you can/can't do with it) and on the other, people complaining about what libraries come with it. I always thought that, given that most languages are capable of importing any new libraries you give them, the vocabulary wasn't an issue: if they don't provide you with function XYZ that you can imagine and want, then you just write it yourself, or find someone else who did. That's all we're doing anyway: every program we write is just an addition to the namespace. I always thought the strength of a language was at least in part determined by how easy it was to extend: did it give you everything you needed to build new functions, classes, etc.?

People pick their development platforms no longer (did they ever?) so much on the language itself but what functions are "easily accessible" (the fewest lines of #include-like code) to them. Yes, there's a productivity issue, but ... dang. That's just harsh. You could have the best "language" in the world, and yet nobody would notice it until it came "standard" with a library the size of java's. (Which, by the way, is enormous, and I doubt I'd ever find what I was looking for in such quantities of code anyway.) You could have the worst language in the world, or at least a terribly half-assed one, and it'd still be used if it came with all the functions people happen to want at the moment (which is distressingly related to what technologies are "hot" at any particular point in time.) We talk about how great Java and PHP and Perl's basic libraries are, yet we have sites dedicated to sharing code that isn't included by default (CPAN, that new O'Reilly equivalent for Java, PEAR, etc.) ... so obviously, despite their size, they're still not "quite enough" ...

Are we ever going to go ahead and figure a way to make sure libraries we write in one language are available (easily) in others, so we can get down to the business of picking languages based on language features? C provided us with a basic interoperability which I don't think we have for object-oriented languages (OO is a vague concept anyhow) ... but it's hurting us to be rewriting the -same- algorithms, for the -same- purposes, for each different language.

Note that parts of the Boost library may be included in future C++ standards, according to their website. Not like that addresses my issues, but for those who like Boost, it's something. Now if, Boost were available to all languages ...

Re:While it would be nice... (1)

MrDomino (799876) | more than 9 years ago | (#12324178)

It's clunky, and something of a workaround; strings are still treated as char * types internally unless stated otherwise, so you have to jump through some hoops to get proper string manipulation. You can't, for instance, do this:

std::string s = "Hello, " + "World";

C++ interprets that as adding two pointers to type char together, which does nothing useful whatsoever. Instead, you have to do this:

std::string s = (std::string)"Hello, " + (std::string)"World";

Further, string manipulation is inconsistent; many of even the C++ standard library functions don't handle strings themselves. Ever tried initializing an fstream to a string? You can't do it; you have to use the string's c_str() method.

I program in C++ a lot and do appreciate a lot of the language's strengths (templates are brilliant for implementing data structures), but there are definitely some things that it is not good at, and string handling is one of them.

Re:While it would be nice... (0)

Anonymous Coward | more than 9 years ago | (#12324337)

using std::string;
string s = string("Hello, ") + "World";

Works just fine.

Re:While it would be nice... (0)

MrDomino (799876) | more than 9 years ago | (#12324390)

The point is that you have to cast to a string in order to get string functionality. That only one cast is needed instead of two is beside the point; it's still clunky, and languages with built-in string support are much better about string manipulation than C++.

Re:While it would be nice... (0)

Anonymous Coward | more than 9 years ago | (#12324499)

Please re-read the post. That is not a cast but creation of an anonymous object and then concating a const char* array.

std::string (1)

Anonymous Brave Guy (457657) | more than 9 years ago | (#12324613)

out of interest, what's wrong with std::string?

A fairer question might be what's right about it. ;-)

Seriously, the string-handling in standard C++ suffers horribly from design-by-committee.

To give the most obvious example, there's no way to write a literal std::string, which in turn means that basic syntax like "a"+"b" doesn't work, even though the + operator is used to concatenate std::string objects.

There are also glaring inconsistencies in usage, because of all the history using char*, and then numerous class libraries inventing their own string type. Take a look at the I/O streams interfaces in C++: you can't even pass a std::string as a filename without converting to a C-style string first.

Then there's the interface, which is a bit Jack-of-all-trades, and bloated with it.

And of course, even with a real string type now -- surely a prerequisite for claiming any meaningful string support at all! -- C++ still doesn't provide standard support for basic string processing using regular expressions. Compared to a more text-focussed language like Perl, well, there's no comparison.

Fortunately, a number of these sillies are in line to be fixed in the next revision of C++, but for now, the language's string support is pretty much a joke.

Re:While it would be nice... (1)

slamb (119285) | more than 9 years ago | (#12324677)

out of interest, what's wrong with std::string?

It doesn't support Unicode well. Specifically,

  • It doesn't support variable-length character encodings like UTF-8 or UTF-16.
  • wchar_t is not a standard size. (It may be two or four bytes, depending on your platform.) So you need to define your own ucs4_t specialization to portably hold wide characters.
  • There's no decent transcoder in the standard. boost has utf8_codecvt_facet [rrsd.com] , but currently it's for internal use only. (With a class like this, you could use std::string with above ucs4_t and still do UTF-8 I/O.)

The best workaround I've found is to require Glibmm. It's a huge dependency, but it has a UTF-8 string class [gtkmm.org] and appropriate conversion functions.

But fuck workarounds. I'd rather just code in a language with a standardized string class that doesn't suck. This sort of thing is why my largest C++ project [slamb.org] is stagnating while I write code in other languages.

Re:While it would be nice... (1)

BigZaphod (12942) | more than 9 years ago | (#12323701)

"But this nannying produces only poorer developers who rely on the language rather than their own abilities to code effectively."

I know this is shockingly off-topic, but it is interesting how stating something like that seems pretty obvious and logical when talking about computer programs. The reason I mention this is that your comment could very easily be applied to western (or at least American) culture in general. We have become a culture of safety where anything even remotely dangerous is banned or sectioned off. Everything has guardrails now.

After spending some time in middle-to-eastern Europe, the differences in thinking in that regard are quire amazing. Everything is so "safe" in America for fear that people will hurt themselves and go on a suing rampage. I think it is creating some pretty pathetic and petty people which isn't going to bode well in the future.

Re:While it would be nice... (3, Insightful)

the eric conspiracy (20178) | more than 9 years ago | (#12323862)

A return to C++ would be nice, especially in educational institutions, as it provides all the necessities of modern languages, bar effective string-handling, while maintaining the simplicity of older languages.

. You may complain about Java etc. being inefficient or coddling developers, but the design of C++ is strictly a case of bolting object orientation onto a procedural language in a very crude manner, then throwing in the kitchen sink just so that it has feature xyz. It collapses of it's own weight. C was/is fine with it's minimalist approach and economy of expression. Java and other GC languages have thei place because by handling GC they markedly improve programmer productivity.

But C++ is an abomination - a siamese twin floor wax/desert topping that should have been seperated into C and a real OO language years ago. I can't imagine why it survives at all. It is like one of those Cadillacs from the 60's with the giant tail fins and 400 pounds of chrome, and no consistency of design. It is so bad that it took a decade just to get compilers that worked properly - and from what I've seen there are still a lot of C++ compilers out there that fail to completely implement the language.

Re:While it would be nice... (1)

0x461FAB0BD7D2 (812236) | more than 9 years ago | (#12324037)

Personally, I believe it survives because it mixes the robustness of object-oriented languages with the minimalistic procedural approach. It survives because its design is adept at conforming to anything thrown at it.

Java, for one, doesn't allow for RAD. It requires a structured design and systematic coding. People have invented scripting languages based on Java, and this highlights Java's serious lack of flexibility. The problems with .NET are obvious - it's tied to one platform and the framework required is quite substantial.

While C++ may be an abomination in terms of language theory, it serves the purpose it was intended for - to meld the C programming language with the OOP paradigm.

Nice troll. (4, Insightful)

rjh (40933) | more than 9 years ago | (#12324118)

It is so bad that it took a decade just to get compilers that worked properly
The C++ Standard wasn't finalized until 1998. We're seven years out from the Standard, and we've had good compilers for more than a couple of years now. GCC 3.0 is where I draw the line for "good C++ compilers", but Intel and other firms had good C++ compilers for a similarly long time.
But C++ is an abomination--
Most C++ enthusiasts, myself included, will agree with you. In some ways, C++ is a lot like Perl. Larry Wall said about Perl, "The language is such a mess because the problem space is such a mess." The same applies to C++.
I can't imagine why it survives at all.
If you can't imagine why it survives at all, that strongly suggests you've never bothered to learn why it's survived.
no consistency of design
You've clearly never read the C++ standard, where one design goal guides all of the C++ specification: "you don't pay for what you don't use".

You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.

Re:Nice troll. (1)

brpr (826904) | more than 9 years ago | (#12324756)

The C++ Standard wasn't finalized until 1998. We're seven years out from the Standard, and we've had good compilers for more than a couple of years now. GCC 3.0 is where I draw the line for "good C++ compilers", but Intel and other firms had good C++ compilers for a similarly long time.

gcc 3.0? Are you serious? That version was chock full of bugs.

Most C++ enthusiasts, myself included, will agree with you. In some ways, C++ is a lot like Perl. Larry Wall said about Perl, "The language is such a mess because the problem space is such a mess." The same applies to C++.

The messiness of C++ has little or nothing to do with the "problem space". This is a really poor excuse for bad design. One of the measures of a good language is its ability to solve messy problems without the need to write messy code. One obvious example of a messy C++ (non-)feature which doesn't help to solve any problems is the reliance on header files. Watch how this destroys any hope of separate compilation when mixed with templates.

You've also clearly never done serious programming with the Standard Template Library, where the algorithms are written so generically--and so consistently across different data types--that they can be plugged together in an almost limitless number of configurations.

The STL has a consistent design, but the base C++ language doesn't. Important distinction. The STL is a decent library but it was hardly revolutionary. Type-safe generics were not a new technology at the time.

Re:Nice troll. (2, Informative)

rjh (40933) | more than 9 years ago | (#12324819)

The STL has a consistent design, but the base C++ language doesn't.
The STL is part of the base C++ language. Read the Standard.
The STL is a decent library
Damning with faint praise. Have you ever used the STL for more than a trivial 5,000-line app?
but it was hardly revolutionary. Type-safe generics were not a new technology at the time.
C++ generics predate Ada95's strong generics mechanism by quite some time. In fact, the inventor of generics--Stepanov--used C++ as his testbed for ideas. C++ generics go back to the early 1980s.

Re:Nice troll. (1)

brpr (826904) | more than 9 years ago | (#12324875)

The STL is part of the base C++ language. Read the Standard.

Don't be pedantic. I meant that the basic language, i.e. the basic syntax and semantics of C++ minus any libraries/whatever, is badly designed. The STL is not, but it suffers from the underlying bad design.

Damning with faint praise. Have you ever used the STL for more than a trivial 5,000-line app?

Yes. It's OK but not great. It's much easier to do generic data structures in, say, Haskell. Generics feel tacked on in C++, but in Haskell/ML/etc. they're completely integrated into the language, making it natural to write pretty much every algorithm generically. In C++, you always have to make a tradeoff. Is it worth the pain of using templates just to get a little extra genericity which you might never need?

C++ generics predate Ada95's strong generics mechanism by quite some time. In fact, the inventor of generics--Stepanov--used C++ as his testbed for ideas. C++ generics go back to the early 1980s.

Languages which implement generic types go back to the early to mid 1970s. ML, for example, was developed around 1973, and its type inference mechanism is far in advance of anything C++ has.

Look! A funny. (5, Funny)

tb3 (313150) | more than 9 years ago | (#12323446)

"...Stroustrup asserts that C++ was also used.
I bet he also trys to catch all the code NASA uses.

C++: too complex (3, Insightful)

Anonymous Coward | more than 9 years ago | (#12323458)

I never saw the point of C++.

I've been programming a while. Familiar with Lisp, Smalltalk, etc. My first "favorite" language was C, which had a certain simplicity that appealed to me. I also liked Objective C.

When I first saw C++ it seemed complicated and half-baked. Objective C was SO much nicer. And one C++ program would work with one compiler, but not another. The language was in a state of flux apparently. So I ignored it, thinking it would be finished later.

By the time I looked at it again, computers were fast enough so that "scripting" languages like Python were practical for big projects, and elegant enough to write good programs in. C++ was still a gigantic clunky mess. I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused. And any language that "mangles" things should be avoided I think. :-)

Also Java looked like "what C++ should've been".

And now the programming world seems to be returning to a desire for simplicity, elegance, "Agility", and C++ just doesn't cut it. My favorite language today for practical work is Ruby, with the occasional C extension.

So, to me, C++ is an obsolete language.

Re:C++: too complex (4, Insightful)

Anonymous Coward | more than 9 years ago | (#12323521)

You can not match the cleaniness and performance of C++ in regular C. To do the same things you do in C++ in C while maintaining the same performance looks ugly and complex. C just doesn't have enough functionality.

Ruby is slow even for scripting languages. It's fine for many things, but if you need performance Ruby doesn't cut it. And if you really need performance no scripting can cut it and you gotta use something better.

Nothing can equal the power along with performance that C++ gives you. It's not perfect and has some serious issues, but it's the best we have in terms of performance combined with power.

Re:C++: too complex (0)

Anonymous Coward | more than 9 years ago | (#12323664)

Who moded the parent up ? its a classical troll , look it up .

Ousterhout's Dichotomy (2)

DavidNWelton (142216) | more than 9 years ago | (#12323693)


Ruby is slow even for scripting languages. It's fine for many things, but if you need performance Ruby doesn't cut it. And if you really need performance no scripting can cut it and you gotta use something better.


The ideal way of doing things is to write as much as you can in the scripting language. This is almost always faster and more efficient in terms of programmer time. Then, you go back and redo the speed critical bits and pieces in C or C++.

When this dawned on me, I really began to appreciate Tcl a lot more than I had in the past. It's C API lets you do a ton of fun things. Multiple interpreters, stacked channels, all kinds of access to variables and commands. And the original source code is extremely legible should you ever get the urge to hack on it directly.

Re:Ousterhout's Dichotomy (0)

Anonymous Coward | more than 9 years ago | (#12324048)


How do you debug Tcl? IIRC, you have to *ask* it for error information.

Multi-language approaches (2, Insightful)

Anonymous Brave Guy (457657) | more than 9 years ago | (#12324822)

The ideal way of doing things is to write as much as you can in the scripting language. This is almost always faster and more efficient in terms of programmer time. Then, you go back and redo the speed critical bits and pieces in C or C++.

I've heard that a lot, and certainly the argument has merit.

Where it sometimes breaks down, IMHO, is that learning a new language isn't free. It's a myth that any good programmer can learn a new language in a week. Sure, they can learn the basic syntax, and if they're familiar with the particular paradigms they're using (by which I mean OOP, functional programming, whatever) then they'll be able to apply those principles fairly readily. But there's a world of difference between that and the kind of clean, idiomatic, easily maintainable code than a good programmer with a lot of experience in the specific language(s) he's using would write.

I predict that this is going to be one of the bigger factors holding back $SCRIPTING_LANGUAGE from wider usage for a long time. There are simply too many almost isomorphic scripting languages with a significant, but still small, user base, and while they offer similar advantages, you can't just switch a whole dev team from one to another for the reason above.

I think this is also a big reason C++ remains popular, particularly with stronger programmers who make the effort to learn its idioms, who for some probably related reason rarely seem to encounter all these dreadful weaknesses C++ is supposed to have... In a nutshell, C++ is a single language with sufficient tools to work effectively with both low-level details and high-level designs, and perhaps a strong programmer with such a tool will be more effective than a programmer with two more suitable tools, but only moderate skill with either.

Re:C++: too complex (1)

Bloater (12932) | more than 9 years ago | (#12324503)

> I remember seeing those "What's wrong with this program?" ads with C++ examples and being utterly confused.

Q: "What's wrong with this program?"

A: "It's written in C++."

Re:C++: too complex (1)

aCapitalist (552761) | more than 9 years ago | (#12324735)

Listen, C++ is complicated because it's a 3 paradigm language. In the hands of someone that knows what they're doing it can produce nice code.

If you want to talk about half-baked, let's compare Gnome/Gtk+ to Qt/KDE. You have performance issues that would only be solved with something like C or C++, and when it comes to technical superiority there is no doubt that Qt and KDE are better.

Frankly, many unix heads and others are just afraid to learn something more complicated, but much more powerful. You can do many neat and useful things with templates. Just look at Boost.

C++ has a long future... (4, Informative)

DavidNWelton (142216) | more than 9 years ago | (#12323484)

...like any language that has had its time in the limelight. There are millions upon millions of lines of code written in it, and a lot of that isn't just going to be rewritten from one day to the next, no matter how much buzz and hype Sun and MS spew forth about their new languages.

I wrote an article about the economics of programming languages that talks about this and other issues that concern the adoption and lifecycle of languages, although be forewarned that the login system is a bit fiddly:

http://www.byte.com/documents/s=9553/byt1113845246 791/0418_welton.html [byte.com]

Stroustrup disconnected from reality. (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12323552)

From TFA:

Data from analyst firm Evans Data, which carries out regular developer surveys, appears to contradict Stroustrup's claim that C++ is growing. Evans Data has found that the percentage of developers using C++ has steadily declined over the last six years--from 76 percent in the spring 1998 to 46 percent in fall 2004. But it expects the rate of decline in C++ developers to be "considerably slower" in the next few years.

To those who have not programmed in C++ enough... (4, Informative)

pauljlucas (529435) | more than 9 years ago | (#12323637)

... especially Java zealots, try reading Modern C++ Design [bookpool.com] by Alexandrescu. It'll blow your mind. Java generics don't even come close.

Re:To those who have not programmed in C++ enough. (0)

Anonymous Coward | more than 9 years ago | (#12323699)

Java Generics is not even an attempt to come close to template programming. BTW, this book is quite neat but misses more advanced topics about templates. Take a look at the boost libs.

Ah, and, I heard you can shoot your leg off with C++. Blowing my mind? Maybe worth a try.

Re:To those who have not programmed in C++ enough. (1)

SunFan (845761) | more than 9 years ago | (#12323978)

Here's a question for everyone: Which is better? An expertly designed and elegant C++ program with all the proper abstractions, frameworks, and methodologies that 1% of software developers can comprehend quickly, or a C program with a flat set of files, simple structs, and a few shell scripts to build it, which everyone understands (and can even debug)?

Trying to answering this question tears me apart, because I so much like the _idea_ of elegant OO software design. However, I generally find that I can work my way through a C program much more quickly than a comparable-complexity C++ program.
Perhaps it's just me.

Re:To those who have not programmed in C++ enough. (3, Informative)

the eric conspiracy (20178) | more than 9 years ago | (#12324049)

Here's a question for everyone: Which is better? An expertly designed and elegant C++ program with all the proper abstractions, frameworks, and methodologies that 1% of software developers can comprehend quickly, or a C program with a flat set of files, simple structs, and a few shell scripts to build it, which everyone understands (and can even debug)?

The simple flat file C program that everyone can debug is also a small program. OO really comes into it's own when you get over 20,000 lines of code. Then the kiss C style starts breaking down.

Re:To those who have not programmed in C++ enough. (2, Insightful)

SunFan (845761) | more than 9 years ago | (#12324098)


With well-organized header files and a little documentation, I've had no problems with C up to 100K lines. The main advantage, IMO, is that C is just so damn simple to "execute" in my mind, and it is very intuitive to step through in a debugger. The only real catch for me is tracking down memory leaks at times.

Now, for programs with millions of LOC, I don't think any language will be easier than another, just because the program's own complexity overwhelms everything else. Just ask people how quickly they can get up to speed on OO.org, KDE, Mozilla, or GNOME (they all suck for casual developers).

Re:To those who have not programmed in C++ enough. (1)

peacelife (228905) | more than 9 years ago | (#12324398)

Now, for programs with millions of LOC, I don't think any language will be easier than another, just because the program's own complexity overwhelms everything else.
Come on, I can't believe you said that. So wouldn't it make any difference if, say, Mozilla was in assembly?
Just ask people how quickly they can get up to speed on OO.org, KDE, Mozilla, or GNOME
Thats funny. Of the four you mentioned, three (OO.org, KDE, mozilla) are in C++. GNOME is in C, but they need to use too many unwieldy kludges, and hence their enthusiasm for mono.

C++ is an extremely powerful language, but it is not a friendly one. It takes some time to grasp all its features, but the time is well worth it. For example, I am familiar with a constrained optimization program from ILOG, written in C++. It is very powerful and fast. I can't imagine in any other language. Of course, it can be implemented in any language, but not with the same ease of use.

Re:To those who have not programmed in C++ enough. (1)

MemoryDragon (544441) | more than 9 years ago | (#12324110)

That is a general problem, I did most of the stuff in the last years trying to cover with good OO design and patterns, but I constantly find myself in a mess of too many classes to cover a domain, functionality which is split over several classes, which are layered. Many classlibs I have seen have similar problems, due to the fact that excessive pattern usage enforces heaps and heaps of classes covering domains, which probably could be easier covered by a few hacks within a procedural domain.

I am not against OO and patterns, in fact I lovem them, but from a maintainability standpoint they easily can become a nightmare. But that is not a problem of c++ it is a software enigneering problem per se.

Re:To those who have not programmed in C++ enough. (0)

Anonymous Coward | more than 9 years ago | (#12324140)


Yeah, one thing is that some people spend so much time trying to understand and memorize design patterns they can also not spend enough time learning the problem domain. The result is poorly applied patterns that overlap or don't really fit the problem at hand. The cure is worse than the disease.

Consider alternatives! (0)

Anonymous Coward | more than 9 years ago | (#12324483)

If you want code that is clear and well organized I'd suggest you leave the C/C++ area completely. They are (together with Perl) famous for redundancy and obfuscation. The expressiveness of C is not that good and it is much too easy to harm yourself with it. Bigger C-projects are not very maintable, or if they are then *even though* they are C-projects. What C++ gained in expressiveness it also gained in obfuscation.

<advertisement>
The language is very baroque and while I'd say that RAII is a definate achievement it does not justify the use of C++. If you aim for high quality, maintable programs I would recommend to use Ada95. It is expressive, has threading primites built in, excellent embedded and realtime support, generics, exceptions, fixed-point precission, ...
Do yourself a favour and visit http://www.gnat.com or http://www.adaic.org to learn more.
</advertisment>

Re:To those who have not programmed in C++ enough. (1)

Anonymous Brave Guy (457657) | more than 9 years ago | (#12324860)

An expertly designed and elegant C++ program with all the proper abstractions, frameworks, and methodologies that 1% of software developers can comprehend quickly, or a C program with a flat set of files, simple structs, and a few shell scripts to build it, which everyone understands (and can even debug)?

That's a slightly loaded question, don't you think? ;-)

Any high-level design tools are a double-edged sword. When used well, they allow you to express designs more simply and clearly. When used poorly, they simply add another layer of complication onto whatever you had anyway. You can do this in any language that offers such tools.

FWIW, I've found that often the languages where you couldn't write obfuscated code if you really wanted to also lack the power to express clean designs cleanly as well. IMHO, this is one of the biggest problems with C++'s "successors" C# and, particularly, Java.

Ruby, etc.... (2, Interesting)

Casandro (751346) | more than 9 years ago | (#12323669)

I wonder why people bother with things like C# or Java. They don't seem to offer any big advantages over C++. On the other hand, all I've heared of C++ and all I've seen of it and learned of C basically was horrible. I mean mucking around with pointers is something that can be fun, but it definitely doesn't have the beauty you need for doing real work. However there are alternatives. Just look at Ruby, a completely object-based language. You can do thinks like "Hello World".length, or -113.abs . You do not need to care about creating and destroying objects since everything is done in a really nice way. It is extremely powerfull, enabling you to examine and modify your own program code at runtime. And it's even clean at that. I definitely wouldn't want to start any new projects in C# or Java, but C++ also wouldn't be my first choice.

Re:Ruby, etc.... (1)

Ulrich Hobelmann (861309) | more than 9 years ago | (#12323777)

Dead right.
All those C dialects just add features that you mostly don't need. Ok, the C++ object syntax (
foo = 5;
instead of
obj->foo = 5;
in C) is nice.

Still, the real shortcomings of C aren't fixed, such as braindead syntax, only a single return value for functions (but a function can have 5 parameters; why?), lack of tailcall optimization, braindead calling conventions...

You might even say that
public static final synchronized Bla
makes the syntax even more braindead.

I don't really know Ruby, but at least it does OO righter than Java&Co (like Smalltalk, too). My language of choice these days is Common Lisp [gigamonkeys.com] .

Re:Ruby, etc.... (1)

Casandro (751346) | more than 9 years ago | (#12323920)

Yes, there is a niche for C and that is rather high speed fixed length data-processing. But I don't know the niche for C++ yet. OK, KDE is written in C++, but otherwise I wouldn't start anything in that language, mainly because reality shows that it's hard to write programs properly in that language. New messages about buffer overflows only possible in C(++).

Before some people complain that C is so much more efficient than all the rest. Just look at how strings are typically done in C and tell me if it's really efficient to use 1kilobyte for a string that typically is just a few bytes long, just so you won't run into buffer overflows?

Re:Ruby, etc.... (1)

KtHM (732769) | more than 9 years ago | (#12323971)

IIRC, most game programming is done in C++. I know Half Life 2 was written in C++.

Good point (1)

Casandro (751346) | more than 9 years ago | (#12324026)

Honestly game programming is a good niche for C++. Games typically don't run for a long time. They work with fixed sized inputs and need to be fast.

Re:Ruby, etc.... (0)

Anonymous Coward | more than 9 years ago | (#12324012)

tell me if it's really efficient to use 1kilobyte for a string that typically is just a few bytes long, just so you won't run into buffer overflows?

I prefer to check the lengths of the input...or use a library allowing for dynamic strings. Such things are possible in C.

Re:Ruby, etc.... (1)

Ulrich Hobelmann (861309) | more than 9 years ago | (#12324193)

Especially in C++ you would rather use string classes instead of char pointers, so buffer overflows easily disappear. People only have to make the jump, port their char pointer code to use better string functions.

Why do you think that C strings use 1k per string? A string uses as much memory as you allocate for it. I typically use an input buffer, and when a string is completely parsed, copy it somewhere. A string of size 30 uses 30 bytes and 4 bytes for its length (or alternatively 31b for the typical C string + padding).

Re:Ruby, etc.... (1)

Casandro (751346) | more than 9 years ago | (#12324497)

Well the problem here is between reality and the ideal. Of course one could use the better string functions, but (almost) daily reports about buffer overruns tell another story. In classical C programmers probably tend to oversize their strings instead of properly sizing them. It's just less work and you are on the save size.

Graphics Work (1)

Vicissidude (878310) | more than 9 years ago | (#12324411)

If you want to do any real graphics work, including games, then C++ is the only language out there. Anything else is just too damn slow.

Re:Graphics Work (1)

Casandro (751346) | more than 9 years ago | (#12324588)

Yes, it's also rather save to do graphics in C(++). However I disagree that it's the only language for such things out there. First of all, languages like Pascal or Fortran, the later mostly used on supercomputers, are often compiled by C-compilers and therefore can easily reach the same level of efficiency. However a high-level language with high-level frameworks create one serious problem: The programmer doesn't see where he does something suboptimal. For example when you are programming in Assembler, you typically know very well, when your program is running occupying floating-point units or staying in fixed point. In some languages that's hard to judge. Furthermore 3d-engines now are made to support arbitrary geometries, even though the game won't need them. In previous times, before 3d-accelerator boards became widely avaliable, the coder tried it's best to match the graphics with the technical possibilities to get as good as possible graphics with the little CPU-time it had. If you look at old games from the early till mid 90s you will be impressed how much they got out of those little CPUs. It's really a shame when I see a variation of the "turning torus" demo on a modern PC "only" doing 200 fps with accelerated graphics, when my 486 could already do the same demo with 60fps.

Re:Ruby, etc.... (0)

Anonymous Coward | more than 9 years ago | (#12324028)

"Still, the real shortcomings of C aren't fixed, such as braindead syntax, only a single return value for functions (but a function can have 5 parameters; why?), lack of tailcall optimization, braindead calling conventions..."

Uh, what's wrong with the concept x = f(a,b,c,d,e)?
C does allow any number of parameters, but less parameters means more of them can fit into CPU registers (e.g., i0-i7 on SPARC).

Return values in C dialects (1)

Ulrich Hobelmann (861309) | more than 9 years ago | (#12324174)

Well, any number of parameters can go into a function, but only one can be returned. That's braindead. Python, ML, Lisp can all do better.

If the parameters and return values are passed in registers or RAM (e.g. on the register-starved x86) is irrelevant to the question (just an implementation detail).

Re:Ruby, etc.... (1)

fred9653 (703082) | more than 9 years ago | (#12323986)

It doesn't matter... but you can do this in C#
System.Console.WriteLine( "HALLO!".Length );
System.Console.WriteLine( 114.ToString("ABC{0}DEF") );
Anyway... "USE THE RIGHT TOOL FOR THE JOB!" A device driver in Rugby? An office suite in assembler? Every language/platform has good things and bad things... and there are many intersections in their application where a developer can decide which language to use for the job.

Re:Ruby, etc.... (1)

Casandro (751346) | more than 9 years ago | (#12324075)

Of course one must use the right tools for the job. But honestly, once you have seen Ruby, you want to do many things in it. The problem today is that programmers have no choice. Either because of company limitations, or because they just don't know of the alternatives. Programmers today only learn C(++), Visual Basic (what's that good for?) and perhaps Java or C#. They don't learn the really different languages like Prolog or Lisp. And that's where choosing the right language is important. There are problems like XML-decoding or native language parsing where you can write your programs in Prolog in just a fraction of the time needed in C or Assembler or C# or Java or whatever.

Re:Ruby, etc.... (1)

HyperChicken (794660) | more than 9 years ago | (#12324133)

Um... Sir, question: How is "Hello World".length any better than length("Hello World")? Or how is -133.abs any better than abs(-133)?

Re:Ruby, etc.... (1)

Casandro (751346) | more than 9 years ago | (#12324476)

>Um... Sir, question: How is "Hello World".length
>any better than length("Hello World")? Or how is
>-133.abs any better than abs(-133)?

Good question. The point is, that everything is an object, numbers, lists, even program blocks are objects. Therefore, for example, it's rather simple to make iterative functions. You just pass a program block as a parameter to a message and the method can then call that parameter. (I might have gotten the terminology wrong.) Best of all it's all done in a clean form.

Then there are things like lists of all the object-instances in your program. You can iterate over it, find the type of each one, no matter if it's an integer or an object reflecting a large database. You can then find out more about that object, even if it didn't exist when you were programming that part of code.

Of course that's also theoretically possible with C(++), but there it involves doing a lot of dirty stuff like shifting pointers to get arbitrary access to your programm's memory. In Ruby it's all nice and clean. The -123.abs is just a consequence of it. I mean there are no procedures or functions anymore. It's all in the objects. And everything is an object.

Re:Ruby, etc.... (0)

Anonymous Coward | more than 9 years ago | (#12324557)

So whitespace is objects too? Waste of resources, I say!

Re:Ruby, etc.... (1)

Anonymous Brave Guy (457657) | more than 9 years ago | (#12324981)

Just look at Ruby, a completely object-based language.

Mistake number one...

You can do thinks like "Hello World".length, or -113.abs .

And how is this an advantage over

length "Hello World"
or even
strlen("Hello World")
in real life? Do you often find yourself taking the length of a string literal in real code anyway?
I mean mucking around with pointers is something that can be fun, but it definitely doesn't have the beauty you need for doing real work.

It does, however, have the practicality you need for a lot of real work. I write C++ code that works with complex graph-like data structures for a living, and we use pointers all the time. Expressing the same structures, with the same fine control of data size (which matters when your graphs can easily have millions of nodes) would be more difficult in languages that obscure the concept.

And [Ruby] is even clean at that.

OK, I confess: I've looked into Ruby seriously twice, and found it awkward and unnatural both times. I've programmed a lot of different languages in my time, from assembler and C to C++ and Java to Perl and Python to OCaml and Haskell. I've never seen a language that tries as hard to force the programmer into its mindset, rather than trying to provide tools for the programmer to express their intent, as Ruby does.

The reason I don't use it (3, Interesting)

prash_n_rao (465747) | more than 9 years ago | (#12323675)

I program for the PC only as a hobby. At work I use only C and program only embedded systems. My industry is strongly and almost universally prejudiced against C++ as they believe it will result in slow applications.

The basic reason I don't use C++ is the lack of sensible libraries as part of the standard. A programmer desirous of learning cross platform GUI programming has to rely on libraries that are not a part of the standard. I haven't poked around that field for a while now, but IIRC, each system had its quirks and arcane additions. For example, MFC (not cross platform) and QT have implemented their own version of various containers, string classes, etc. MFC relies heavily on arcane macros, QT relies on a weird (from a pure C++ point of view) MOC. I understand they both had good reasons for doing that when C++ was still evolving. But today, it is just a hinderance when trying to write "clean" code.

Another disadvantage of not having a great collection of libraries in the standard is that people won't know about them unless they dig around a lot. Introductory text books won't cover them, help files in the system won't cover them (if they do, a beginner in that field might not even know what to look for and where to look).

Do you want a OO library for accessing the serial port? OK... which OS? Windows: use MFC. Linux: google around until you find something on sourceforge. What about some GUI and audio libraries? again, similar method. Fine... now the application has used various libraries from various places. The source now looks like it was done by a person with multiple personality disorder, with each library having its own design and coding approach. Now that you have built an application with ten different sources of libraries, you have to keep track of all of them for bug-fixes, performance enhancementes. Each with its own quirky impact on your application. I went through all this, and eventually gave up C++ in favour of Java.

And this is just the beginning of my woes with C++.

Re:The reason I don't use it (3, Insightful)

Jordy (440) | more than 9 years ago | (#12324475)

You know, you don't have to use a C++ GUI library when writing a C++ application.

Seems sort of silly to state that C++ doesn't have a good set of libraries when you can use any C library you wish. I do it all the time. There is no reason to create a C++ resolver library when a simple one exists in C already.

C++ has a very simple philosophy, you don't pay for what you don't use. You can write C and occassionally use std::string if you want to. Nothing stops you from doing it. There is no rule that says, "thou shalt use operator overloading."

Re:The reason I don't use it (1)

neonstz (79215) | more than 9 years ago | (#12324828)

A week ago, Bjarne Stroustrup was giving a talk about the work on the next C++ standard.

One interesting thing that he mentioned, was that C++ was quite popular for embedded programming. Templates is a very nice way to make the compiled code small and run fast (if you got a good C++ compiler of course).

I've always liked C++ (5, Insightful)

renehollan (138013) | more than 9 years ago | (#12323766)

I've coded in various assembly languages, scripting languages (though I forget Perl as fast as I decide that it's appropriate for some piece of glue and am constant relearning it), C, C++, C#, and yes, even COBOL in the dim past (using COBOL to provide indexed file support to Pascal applications via COMPASS trampolines on an old Cyber 835 running NOS was, well, a scizophrenic programming experience). I tend to like the richness of C++.

However, it's a double-edged sword. It has been said that C lets you shoot yourself in the foot. C++ provides a dozen ways to shoot yourself in both feet and your own back, simultaneously. Be carefull.

Many have tried to design languages to protect the programmer from themselves, i.e. by providing native garbage collection, disallowing bald pointers, etc. However, this is short-sighted. It presumes what is "hard" and prevents the skilled programmer from replacing the default implementation. C++ new and delete member functions provide no-fuss custom memory management... and probably account for probably half of those ways of shooting one's self in both feet and back.

A language that is complete in the sense of permitting the coding of fundemental facilities is seductive. It provides an assurance that one can implement "low-level" stuff like memory management, or even the bulk of an O/S kernel in it. The lack of I/O facilities in C, for example, is an intentional feature, and not an oversight. Never have to learn another language again.

Other languages may provide the convenience of built-in capabilities that are useful for a particular task at hand: awk, perl, and the rash of modern scripting languages come to mind. When the shoe fits, the adaptable programmer will take the path of least resistance. Languages like Java and C# attempt to bridge the general-purpose languages with the protection and features offered by application-specific ones, the latter via extensive run-time libraries (.NET, anyone?). They tend to return to the pseudo-compiled small-interpreter model to provide hardware portability.

The problem is, that one has do do things the C# "way", or the .NET "way", or the Java "way". Multiple inheritance? Oooh, it's so hard to implement right, and can be so confusing, and, admitedly can be expensive at run-time, so we'll not provide it. Mixin becomes a hack, with language keyword support. Over time, syntactic sugar in the language provides clever support for things like iterators, but binds language features to what should be artbitrary types (Lists are special in C#, for example).

Well, I want it all.

A programming language that will let me shoot myself in the foot any way from Sunday if I dare to try... but, with the flexibility to let me say, "Nope. No bald pointers here." Segregation of programmable expressiveness by program, not language, design.

A programming language that is mutable, so I can invent my own brand of syntactic sugar, and the support to let me quickly find out what mutations a particular piece of code uses.

A programming language that lets me choose when to evaluate things. Do I want this figured out at compile time? Link time? Load time? Run time? Sorry, C++ templates, though Turing-complete are about as maintainable as APL, if one uses them for anythng clever.

It's too bad Mary2 never caught on.

Many will argue that mutable languages result in unmaintainable code: which mutation is in force? I would counter that programs written in non-mutable languages are equally unmaintainable if one does not understand the design of the application. Sure, one can see the "trees", but not the forest: I know x = a + b adds a and b to yield x, but what is that for? The effort to undestand what mutations are in effect is likely similar to the effort to understand an application's design. Except, one has the advantage of a known meta-syntax for expressing the mutatations, instead of having to rely on a design document (which may not exist), likely poorly written or out of date. Code in non-mutable language can't express design effectively, only implementation. Separation of interface and implementation is but one small aspect of design, for example. Like I said, "can't express design effectively."

Yup, looking at code in a familiar language can produce a false sense of understanding the design, and so misunderstanding it. It is from this that software rots, and people fix the "obvious". Far, far better, IMHO, for the tricky bits to be sufficiently obscure that one has to learn the sematics and syntax before one edits with false confidence and bravado. Don't mess with what you don't understand, and don't make it easy for people to think they understand when they likely do not.

Over time, the more useful mutation will fall into defacto-standard use, rather like standard code or template libraries. That is how languages should evolve.

Re:I've always liked C++ (0)

Anonymous Coward | more than 9 years ago | (#12324825)

There have been languages designed to not allow for such easy self destructions as they are usual in C/C++, *without* compromising expressive power. You may not have guessed it but I think of Ada 95 here. Even better some language constructs such as the type system or the threading primitives are even *more* expressive than in C++.

Some backlash in academics as well.. (4, Interesting)

BigZaphod (12942) | more than 9 years ago | (#12323848)

When I was in college for my CS degree, the focus shift away from C/C++ and towards Java was beginning. I was lucky in that my early CS programs were still in C++. However, the classes right behind me as I moved through were getting shifted over to Java one by one. I did not like that at all. It just felt wrong. I figured maybe I was just being biased since I learned C/C++ pretty much on my own without the aid of classes.

After graduating with my BS in CS, I was out in the field for a few years. I spent some time at a C++ Windows shop which was trying to become gung-ho about C# and the various .NET technologies. The magazines all had big pushes for Java, C#, VB.NET, etc.

I left that place and moved into a contracting position where I help admin a data center. The attitude there is much different, to say the least. :-) Everyday we have to deal with huge bloated Java web applications that melt CPUs, eat RAM, and are so slow it takes boxes with 11 CPUs just to service a few thousand customers. The distaste for Java that begins in our department has been filtering up the layers and is starting to become apparent to some of the people who build these projects. When you line up a huge app in PHP next to one written in Java, why is it that the PHP one can easily outperform it on less hardware and require less people to maintain it? That all translates to big $$$$ not to mention application stability and performance.

I'm also now studying for a master's degree in CS. Since I had been away a few years, I was not surprised when I came back to see Java everywhere in the undergrad classes (this at a different school than before). What did surprise me is the attitude of one of my new professors. He taught a projects class where the whole point of the class is to build/do something by the end of the term. It doesn't matter what as long as it fit the basic subject area of the class. After that, you're pretty much on your own (or in a group, if you want). Since this was a different school than where I got my BS, I didn't know this professor. I had seen him wearing a Java shirt a few times, so I was prepared to have to deal with some friction when I went to suggest that I wanted to do my project with C++. One day I stayed after class to chat with him and get to know him a bit. I was shocked to discover that he had done a lot of postdoctoral research using Java and about Java and found it lacking in many very important areas (specifically in high performance scientific computing applications). As we were walking out of the building, he was asking me about my background in programming and computers, so I was giving him a mini life story sort of thing. I mentioned my C/C++ upbringing and how in my college days the Java shift had begun and I didn't quite feel comfortable with that and how I see it seemed to have happened everywhere. That's when he took a careful look around the hallway, leaned in, and said in a hushed tone, "Switching to Java for the undergrads is the worst decision this department ever made."

I was pretty stunned to hear that from a professor considering what was going on just a few years previous. I hope that sentiment grows and CS departments take back their programs from corporate interests and marketing machines. Perhaps there is hope...

Re:Some backlash in academics as well.. (1)

MemoryDragon (544441) | more than 9 years ago | (#12324068)

Sort of a sidecomment, if a java server needs 11 CPUs you definitely have a problem on your hand which is caused by poor program design.

I have two java server installations here one serves around 2500 users with around 100.000 hits per month, almost no CPU cycles used, and basically running constantly without any crashes or bigger load on the database (although it uses an OODB/RDB mapper, but omits stuff like EJB, but uses a portlet engine). On the same app server around 10 other webapps with similar loads run within the same VM

The othe one a CMS which has a handful of users, and hammers ram and the DB like no other second program I have seen. Both fulfill similar domains, but the one with the almost nil CPU load simply has a simple clean design the other one tries to access the DB via a VFS (speaking of extreme overdesign)

Sure Java has its problems, RAM is for instance one, if you are a webhoster, I can clearly see why you hate java with a tomcat which needs a good 128MB+ for a medium sized app, but on the other hand if a webapp is well designed it is fast, and blows speedwise everything out of the water, and basically runs without crashes from day1 to infinity. I am not even talking here about clustering and other niftyness you can get out of the box.

Id rather (5, Interesting)

MemoryDragon (544441) | more than 9 years ago | (#12323989)

See objective C with GnuStep as base for the next gen C based frameworks and low level languages, than having that monster without decent classlib C++ rising again.

Sorry, been there, done that, but the widespread usage of C++ was one of the biggest history jokes ever. A language, as bloated as a language could be, with lots of cool features on the language level, but ommitting the two most important aspects, a good standardized classlib which covers all important application scope aspects, and a language which is actually usable without having to fight with it for years before being able to master it to a certain degree. There was a reason why people flooded to java in 97-98, it was less the hype, it was more the fact, that people tried to implement big long running systems in C++ and saw it was not really feasable in a decent timeframe, due to constantly crashing problems thanks to the missing boundary checks, memory leaks thanks to the missing garbage collector, and general programming errors and unreadable code, thanks to the byzantine bloatware the language in fact really is. Add to that the compiler bugs caused by the 1200 pages of language specs and you could see why people were fleeing from C++.

And up to date, whenever I have to talk about C++ I only can give the advice, limit yourself in the usage of features and only use a readable subset of it (which would be similar to java and C#), try to omit the C heritage entirely if possible, do not use preprocessors, do not use extensive operator overloading or templating. And check out the KDE/Qt API, they so far have been the only ones to master the language on a design level which in fact results in readable and maintainable code.

High School's should teach C++ (5, Insightful)

deian (736923) | more than 9 years ago | (#12324180)

I'v been coding in Perl, Java, C and C++ for the past few years and although I prefer using perl and bash I must say that I've learned to think like a programmer having learned C++ first.

I also eneded up taking a C++ course in High School, and I found that many of my classmates started to think and analyze problems differently. A year later the school changed from C++ to Java ( because the CollegeBoard changed it's CS exams to Java). I also took that class and I noticed that the kids that only took Java, even after completing the course did not learn much - and especially not to think like programmers. I think that this is most likely because Java has so many libraries within that the kids never actually learn what occurs in the "back end." Many fail to understand what a string is, and the majority did not understand algorithms at all, I dont want to mention efficency. Although Java is probablly used more widely, I think that for beginners to learn to think like programmers it would be better to learn a language from which they can learn the basics behind programming, and although I would suggest PASCAL (better for learning algorithms) ,C++ should be taught before Java.

Learning DSA with Java is a bit funny, how is having a garbage collector efficent and how will that inspire programmers to write more cautius and efficent code?

Just my opinion, I'd like to learn more.

Re:High School's should teach C++ (0)

Anonymous Coward | more than 9 years ago | (#12324314)

Sounds like you would have benefited from your high school teaching English.

High School's should teach C++
I'v
eneded
it's [CS exams]
efficency
probablly
efficent
cautius

Re:High School's should teach C++ (1)

deian (736923) | more than 9 years ago | (#12324388)

I didn't think that /. comments are to be written to impress you with their English abilities. I am not writing a paper to check what spelling errors and stupid mistakes I make while writing a comment - as long as the message is clear enough I am satisfied.

Re:High School's should teach C++ (0)

Anonymous Coward | more than 9 years ago | (#12324416)

You wouldn't give a presentation with gravy down your shirt. Why would you try to make a point (that you want others to take seriously) with such scant regard to spelling?

Sometimes C++ programmers miss the point (1, Informative)

flannelboy (344272) | more than 9 years ago | (#12324336)

OK, mod me flamebait, but I've read the same comments over and over again on Slashdot. To reiterate everything that is always said when this conversation comes up:


C++ is faster than java / C#

C++ has better templates

There is so much C++ out there that no one should ever use another language, or they will be forced into reinventing the wheel

Using a "simpler" language like java means that you will hire crappy programmers. Don't do that - use C++ and hire really good programmers.


Having worked on Wall St. as a programmer for 15 years or so, I'm sorry to say to all the people who constantly make that argument that they are officially behind the times.


The real reason to use java?


Compilation times

Compilation times

Compilation times


When programmers are a major cost (believe me, at Wall St. firms, they are a huge cost compared with the cost of machines), you should optimize the amount of time they spend waiting for compiles. We have a C++ library that is around 250,000 lines of code, that compiles in around 2 hours (and this is after a lot of work to try to make the compilation as fast as possible). We also have a 1,200,000 line java library that compiles in around 3 minutes. Any way you play it, programmers still spend a lot of time in the write code / compile / test cycle. In fact, this is where they spend most of their time.


In terms of performance, that is largely a myth that is no longer true. We run pricing simulations in java (which is about as computationally intensive as it gets) and we are able to do so at the same speed is the equivalent C++ code. In fact, the java code is a bit faster now, as the tools for finding the bottlenecks are much faster.


The hiring market? This is largely moving towards java. Many schools are not teaching C++ any more.


The work problem? In java, you spend much more of your time working on the business problem, and much less time trying to figure out why GCC arcane error message on file X means that your template is out of whack in file Y. Or in C++, trying to locate the source of a core dump (getting java.lang.NullPointerException is SOO much better).


Now, mod me flame.


Re:Sometimes C++ programmers miss the point (1)

rudy_wayne (414635) | more than 9 years ago | (#12324437)


+5 Flamebait.

+6 Flambay.

Re:Sometimes C++ programmers miss the point (0)

Anonymous Coward | more than 9 years ago | (#12324492)

I ate your apple. Yum!

Language Just A Tool (1)

Vicissidude (878310) | more than 9 years ago | (#12324485)

I think a lot of people in this discussion are missing the point. C++ and Java are just tools for learning and doing computer science. The whole point of a degree program is not to learn how to program, but to learn the theories and ideas of development. Learning to program is a side-effect.

Tools like C++ and Java will age and eventually get replaced. You'll need to learn a new language next year and something else the year after that. The theories and ideas learned in CS courses will last you a lifetime. That is why people without degrees have serious gaps in their knowledge and what makes the degree so powerful in the first place.

Closed-mindedness abounds (3, Insightful)

mattgreen (701203) | more than 9 years ago | (#12324606)

C++ takes quite a bit of flak on here, mostly because it doesn't try to be a 'pure' language. It is obvious that people don't understand it by the comments. (Then again, if people only talked about what they understood, the net would be a very quiet place.)

News flash: most software that I've seen and written benefits from multiple paradigms: procedural for basic algorithm implementation, OOP for the architecture, and generic programming as glue code (generic programming annihilates OOP in terms of code reuse, and you typically don't pay a performance penalty for it.) There are other paradigms, but I don't have enough experience to comment on the efficiency of them. C++ is one of the few languages that gives the aforementioned paradigms a presence and trusts the programmer to choose. You may think this is 'bloated,' but nothing is further from the truth: the overall mantra of C++ is, "you only pay for what you use."

You can bitch all you want about the importance of language purity and point to languages like Smalltalk or Java as an example of how software should be coded. I'll ask you to point me to popular desktop software that is written in these languages. C++ is the archetype of a hardcore language - a huge learning curve, but insanely powerful in the right hands. It is also really dangerous in the wrong hands.

Like operating systems, all programming languages suck in some way. Its up to you to choose the least sucky one for the problem at hand. I enjoy writing native, minimal dependency desktop applications in a language that has excellent tool support, can interface directly with OS APIs, and doesn't talk down to me. C++ fits the bill most closely, but I've been told I'd like O'Caml as well.

C++ isn't going anywhere. The fact that so many people don't understand it or the place that it occupies only strengthens my resume.

Welcome back! (0)

Anonymous Coward | more than 9 years ago | (#12324853)

Dear C++ Returnee,

Welcome back! Let me assure you, the reasons you have left C++ in the first place are still present and awaiting your command.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...