RSS Feed

The Joel on Software Discussion Group (CLOSED)

by feature creep.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2122.htm

I like the prososals on threading. But other than those how can a single person remembers all these features and the interactions of them?

Perhaps all these are required because the problems we are solving are huge and difficult. But my gut feeling is that something is wrong in this C++ picture.

Wormer is a dead man!
Marmalard: dead!
Neidermeyer Dead.

C++, not so much.

I'm sure at some point in the future C++ will not be used anymore. But without a timeframe, "C++ will be dead" is kind of a useless statement. In the longrun, we're all dead.

> But other than those how can a single person remembers all these features and the interactions of them?

You don't need to because the changes are non-breaking, backward-compatible. Also, the rate at which new features become standard is pretty slow (~years between each new version of C++).

Well, the timeframe is when all these features are admitted and are commonly used by stupid developers.

"But other than those how can a single person remembers all these features and the interactions of them?"

Well, hopefully "stupid" programmers like yourself cannot "remembers" all of them, increasing my job security.

C++0x will be out sometime around '09 and will be an improvement. It will probably enjoy usage for around a decade or so before the next revision comes out (which it will).

But you're right - who in the future could possibly want a multi paradigm programming language that allows you to program right on the metal if you want, or use high level abstractions?

This got me confused. Why improve C++ while C# is already there? And why C++ and not C?

"Why improve C++ while C# is already there?"

In addition to that, I would like to know why we need C# when Java is already there.

"In addition to that, I would like to know why we need C# when Java is already there."

This one I can answer in four letters:

ECMA

And I'd like to know why we need these newfangled programming languages in the first place when we already have ones and zeroes.

Well I pity the compiler writers. These proposal people should be required to produce a reference implementation. C++ is way too obese already and these constant refinements typically make it worse and more undefined as all sorts of unforseen effects come out years after the proposals are adapted.

I'd put my bets on D for the future. Except that D doesn't really work yet and the string implementation is bad.

Documentation for QDate class in Qt contains the following statement:

"The end of time is reached around 8000AD, by which time we expect Qt to be obsolete."

I think it can be safely generalized to include C++.

What makes you think one person needs to know all of a language for it to be useful?

"In addition to that, I would like to know why we need C# when Java is already there."

A few years ago this argument might have had some merit, but with additions like extension methods and lambdas, C# is increasingly moving towards becoming a multi paradigm language.

Yes, I'd like to see some more development on D. Not convinced it wll happen but would like to see the result.

Why C++ and not C#?

Because there is still a need for unmanaged code, and C# doesn't fill that need.

So there.

"What makes you think one person needs to know all of a language for it to be useful?"

No, I don't believe that.

But more features a language accumulate it's more difficult to get good implementations. Also even if you don't use all the features others will use them, so you have to learn about them and how they could be abused or used incorrectly.

The language features are there to help us programmers solve complex problems. We should not spend much of our time in dealing with the language and its implementations without good reasons. Bjarne is always very careful in his selection of languages features; they are included to support general programming abstractions and idioms without compromising some fundalmental design principles.

It seems like he has lost control of the process. That's very unfortunate. I don't want to see C++ become Ada -- a huge language designed by commitee used by no one because no one understands it.

"increasing my job security."

That's not a good design criteria, isn't it.

Good luck to the companies that hire you.

"But you're right - who in the future could possibly want a multi paradigm programming language that allows you to program right on the metal if you want, or use high level abstractions?"

Unluckily this language won't be C++ IF there is a choice.

C++ has been overengineered for a long time.  How many programmers actually understand the entire language even now?  Typically only a subset of the language is used.  As long as the new features are backward-compatible they'll just be ignored by compiler writers and users alike...

. I don't want to see C++ become Ada -- a huge language designed by commitee used by no one because no one understands it.

Welcome to reality and the commercial world. Most things in avionics are still written in... Ada. They have a certifiable compiler, you know. Any programming language considered for systems certified higher than DO-178B Level C in avionics has to deal with Ada competition.

You show a pretty strong dislike for C++ in this thread. Of course, from a personal point of view, that is entirely up to you (I maintain my preferences and prejudices as anyone).
But strong statements need a strong knowledge behind. To be honest, I'm missing something in this respect.

> How many programmers actually understand the entire language even now?  Typically only a subset of the language is used.

True, I'm using the language for a very long time now and learn new features even nowadays - not the syntactic level, but idioms etc. .
Personally, it is still my prefered problem solver in terms of flexibility - and discovering a new part of the tool set is no bad thing, isn't it? Especially, if you have in mind, that you are not forced to change your environment. Evenly not, when the problem or task content turns into realms, otherwise enforcing a language switch. Programming infrastructures for more than one developer are sensitive to such changes.

Essentially, I see two serious flaws inside the language:
- no real concept of parallelism
- (almost) no reflection/inspection possibilities

I think they should go back to C and start over from there.

Chuck out all the other crap^H^H^H^H stuff.

I'd like C with references, classes, templates, inline and other basic refinements.  I like it as a high level assembler.  I like to be able to grok how all the constructions turn into assembler.

Don't turn it into Haskell, Smalltalk, or Ocaml. Please. I see the fact that C++ doesn't have all the stuff in other languages as a feature not a drawback.

> "The end of time is reached around 8000AD, by which time we expect Qt to be obsolete."

BTW that's just silly (the rationale given, not the fact that you might limit dates to save on storage).  It assumes programs only store dates about now? What if you're writing a program today to simulate the next few thousand years orbital motions for example?

The English language will be dead.

Who can be expected to know all those new words they keep adding to it?

> "The end of time is reached around 8000AD, by which time we expect Qt to be obsolete."

Qt is pretty obsolete now. Still, at least they have a sense of humor.

You might want to consider using a different data type to store date/time for calculating orbital motions.  For example, if your calculations show that 4.5 billion years from now Earth will be engulfed by the Sun, I'm not quite sure knowing what day of the week it's going to be is that important.

And of course Qt is obsolete, just like C++, Java, and any other library/language/framework in use now.

I believe that C++ will not die until a similar language replaces it.  By similar I'm not referring to superficial things like semicolons and braces.  I'm talking about explicit pointers, similarity between built-in types and user-defined types, and stuff like that.  The first is usually only found in low level languages and the second in very high level languages.  Neither feature is found in java.

"I think they should go back to C and start over from there."

Yeah, they keep doing that. It's becoming a fairly familiar refrain which these days provokes me to the giggles.

"C++ is too complicated. We're going to strip out all the crap and have another go. You don't need these template things or operator overloading and you don't need function pointers and there's a bundle of other things."

Then they find that you need function pointers[1] or operator overloading[2], and generics are quite handy and then add them back in proclaiming it loudly like they're adding a new feature.

C++ is big and fat and complicated because.. erm.. that's apparently what a programming language needs to be. Java and C# have both demonstrated that. They've done things like generics /differently/ but not actually that much neater.

And their solution doesn't let you write software to run at compile-time to write more of the software for you depending on what you wanted it to do...


C++ is about as dead as Cobol is... That's been dead for a long time as well, but it's not that long since I saw projects being STARTED in Cobol...




[1] C#'s "OK, we're going to sort of fake up function pointers so you can have callbacks, but they're not a proper type" followed by the realisation that you'll need lists of them, and the creation of what basically amounts to a special type of "list of function pointers" is particularly sickening to behold.

[2] Java: "OK, OK, you can use + on strings. And maybe some other classes. But only the ones we say so, because we're smarter than you."

C# and Java are exactly where I don't want C++ to go.

It's a tough challenge to be over-simplified and bloated at the same time - but Java designers are all over it...

Like I said, I'd like my C++ to be like a high-level assembler.  If I have to lose some features to have it, like introspection type features, then I'm happy with that.

People who proclaim C++ is dead and others that try to compare it to things like Java or C# really just do not get it.

C and C++ are on a different plane than Java and C# simply because it's closer to the hardware.  At the heart of C# and even Java is C and C++.  The JRE, for example, is written in portable C and compiled for each platform you need a JRE for.  On Linux, this is the ELF specification.

The second problem I have with these comments that C++ is dead is that all major operating systems are written in C/C++ (Linux, Unix (pick one), Windows, z/OS, etc...)  If C++ is dead, then there needs to be a transition period to a new language to replace it in this domain being close to hardware.

A third reason such statements are absurd is that there are other disciplines that just don't lend themselves to Java, C#, etc... As someone above pointed out when the poster pointed out avionics electronics.  Others are embedded systems.

People who make these statements are simply narrow minded.

I rather agree with Ms Lucas -- C++ has grown big and ugly because people keep using it, and the standardization committee seems to keep listening to their complaints, and keeps extending the language to make things easier. And there's only really one outcome for a language that's treated in this way: it becomes horrid and crufty, as it is continually extended in an attempt to keep everybody happy.

The end result is usually that everybody is equally unhappy, of course, but there's no real way around that.

Fortunately, there are plenty of languages other than C++, so people can always use those instead. Unfortunately, very few of them seem to be able to strike quite the same balance between being usable and being low-level (i.e., lets you do the kind of things that you might otherwise require assembly language for, and does not require garbage collection) -- so for situations where a balance between being usable and being low-level is required it's unlikely to be unseated any time soon.

And doing the same work in C++ is much faster than in Java.  So as long as Java is arround, shops working in C++ will have a competative advantage.

And there are only a few domains where it is faster to use another language.  I like learning new languages, but most don't really improve working speed.

>>[1] C#'s "OK, we're going to sort of fake up function pointers so you can have callbacks, but they're not a proper type" followed by the realisation that you'll need lists of them, and the creation of what basically amounts to a special type of "list of function pointers" is particularly sickening to behold.<<

That sounds like your exposure to C# was fairly limited.  C# delegates are certainly a "proper type" in every sense of the word, and you can create lists of them however you like.  The event mechanism which you're referring to is merely a syntactic convenience, not a restriction.

again, you can't compare C++ to C# or Java in the context of it being dead or not.  We need C and C++ for completely different reasons that Java and C# don't solve for us.  Low level hardware is just one example and speed is another.

Assembler is not dead.  It's still around because it has to be around.  It's the only language the CPU truly understands.  Think of all those compiler writers.

I agree that C/C++ may not be the CRUD language of choice but it's dead wrong to make a blanket statement that it's dead or to compare it to a different type of language in this wide open context.  If you wish to change the context to CRUD programming, then we can have a serious debate!

It seems like people like C++ as much as they like Windows :)

I think people underestimate how good C# is. It won't be long till C# could be used for most applications where C++ could be used.

I hope it won't be dead -- that C++ programmers could work on  interesting projects. At least it looks like we will be able to create threadsafe programs. Hopefully we could have good compilers before 2020!

OO Assembler, maybe?!..