Hacker News Reader

Comment by WalterBright | Hacker News Reader

> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security.

Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all.

As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to let go of the old decisions.

(There's always some major and vocal user who has build their entire store around some ancient feature.)

For example, why does C++ still support EBCDIC?

View on HN

> Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all.

Yeah, after I wrote that I realized it wasn't quite right. C++ is designed by compiler-writer wannabes. Architecture astronauts[1] on standards committees. They think they understand how compilers should work, and that adding support for this or that should be easy. "You just need to..." is their favorite opening. I see plenty of this in distributed storage, too. "It's so simple, I'd do it myself, but it's not worth my time, you go do what I said." The C++ designers seem hung up on an abstract model of machines and compilers that's a poor match for any real machine or compiler ever, and the actual compiler writers have to bridge the gap. Thank you for your efforts, which are Herculean in an Augean-stables kind of way.

[1] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

You can assure us based on what? If you have insider knowledge or particular credentials please share.

So far it looks like you're ranting.

  "I can assure you this is not true at all."

Was quoted, not the user you are replying to.

He assures us based on him being Walter Bright. That’s good enough for me.

Walter Bright's response is the parent of the comment in question. This one seems aimed towards the top level commentor's response, which advanced from the pained venting in the first comment (which I understand and can sympathize with) to a much more assertive tone.

From context, the comment I was responding to seemed attached to the wrong parent and seemed aimed at Walter's comment instead.

Yes, sorry for the confusion. On mobile the final sentence in the quote looked like it actually belonged to notacoward.

My comment was aimed at notacoward.

http://www.walterbright.com/

> Walter Bright is the creator and first implementer of the D programming language and has implemented compilers for several other languages. He's an expert in all areas of compiler technology, including front ends, optimizers, code generation, interpreter engines and runtime libraries. Walter regularly writes articles about compilers and programming, is known for engaging and informative presentations, and provides training in compiler development techniques. Many are surprised to discover that Walter is also the creator of the wargame Empire, which is still popular today over 30 years after its debut.

Granted it's his own site, but uh, seems legit..?

Thanks, but my reply was for notacoward. Unfortunately I can't edit or delete it any more.

Oh, er, sorry about that.

> why does C++ still support

Stop right there! There is plenty of evidence that removing features from a language is fatal to adoption. Both Perl and Python have suffered from this.

Specifically for trigraphs (apart from these, EBCDIC support doesn't affect compilers on other systems) IBM have a vote and they voted not to remove it: https://isocpp.org/files/papers/N4210.pdf

IIRC they did lose the final vote though, and trigraphs is one of the few features ever removed from C++.

I miss them - I enjoyed being able to write ??=include at the top of my files.

Hey, digraphs are still there, they are almost as much fun as trigraph!

How has Python suffered from this? They broke things going from 2 to 3... and it was still the fastest growing language from 2017. It clearly wasn't popular just because they removed features, but you can't say that removing things is fatal to adoption.

THIS is the reason IMO too. C++ has taken on the very difficult task of remaining broadly compatible with C and with legacy features while at the same time has continuously evolved over the decades, incorporating whatever was the state of the art at that time, without new features breaking old code. That is not an easy task without increasing complexity.

The book "Design and Evolution of C++" is quite interesting in that regard.

For all its warts, C++ only got adopted inside AT&T and later by almost every C compiler vendor, because it just fitted on their existing toolchains.

Even lack of modules is related to that, C++ object files needed to look just like C ones.

Now that C++ is grown up and can live on its own, it needs to pay for the crazy days of its parties going out with C. :)

Some might say the party never ended. :-)

>The book "Design and Evolution of C++" is quite interesting in that regard.

I found that book very interesting in many regards. I had bought and read it several years ago (out of interest, though I have not worked on C++ professionally).

Stroustrup goes into a lot of details about the reasons for many design decisions in the language. While I'm aware that C++ has some issues, I was really impressed by the level of thought etc., that he shows in that book, when he talks about all the reasons for doing various things the way he did them.

> incorporating whatever was the state of the art at that time

State of the art or flavor of the month? For instance, the features from functional programming that C++ and Java recently (in the last decade) added weren't anything new. When functional programming started to become more popular was when their features started showing up in C++ and Java.

If people are concerned that your language is already to large than adding elements from other programming paradigms because they're suddenly what's hot doesn't seem like a great idea. It feels like some languages are chasing the crowd, which can lead to a messy language ("OOP is all the rage now? Our language is all about OOP! Oh, functional is all the rage now? Well, we just nailed on some functional features!").

Eh, C++ can hardly be criticized to pandering to the flavor of the month.

For example, lambdas were finally added only in C++11 even though while the STL had a functional flavor since the late '90s and sorely needed lambda expressions. Only after people went out of their way to build lambdas on top of macros, expression templates and whatnot, they were finally added to the language.

It's true that isn't easy.

It's also true that it may not be necessary.

What makes a good language? One that randomly accumulates state of the art ideas about programming without breaking old code, or one that gets out of the way and allows requirements to be expressed reliably and relatively simply?

Of course C++ is used because it's fast. It's fine in limited domains like DSP.

But what is the rationale for a language that whimsically accumulates new features every couple of years, while failing to deal with basic challenges like memory management?

It's not as if it's ever going to reach a critical mass and turn into Haskell.

> For example, why does C++ still support EBCDIC?

Because there are companies like Unisys and IBM that want to sell C++ compilers to their mainframe customers.

IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-)

Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.

> No need to burden the rest of the community with it.

yeah, the problem is when IBM goes with big checks to national standard bodies and complains "muuuuhh we won't be able to assure that the systems we sold you in 1970 will still work in 20 years if the C++ standard removes support for EBCDIC" and then these standard bodies write strongly-worded letters to the ISO commitee: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n291...

I think that implying bribery here is dishonest. 6/7th of the authors of the paper are IBM employees and they are just voting according to their employer wills.

The Committee recently got rid of trigraphs (required for EBCDIC compatibility). IBM was strongly against the proposal but was finally outvoted. They do keep the functionality as a conforming extension in their compiler, but now that they have been removed from the standard, the language might evolve in ways that might make the extension non-conforming.

Trigraphs can be supported with the simple expedient of putting a filter in front of the compiler that converts the trigraph sequences to the corresponding character. It doesn't have to be in the compiler itself.

In fact, trigraphs were designed to operate this way.

That is, until the addition of raw string literals broke that.

> For example, why does C++ still support EBCDIC?

You might imagine EBCDIC was a thing of the distant past, and you'd be wrong. As of at least 2013 there was still production systems using EBCDIC being actively developed. In COBOL. And not just at IBM.

What support does C++ have for EBCDIC?

https://en.wikipedia.org/wiki/EBCDIC#Compatibility_with_ASCI...

Most programmers manipulate characters as if they were ASCII, and that code will break if presented with EBCDIC. The C++ Standard is carefully worded to not assume ASCII encoding.

C++ presumably supports other encodings, but I've never heard of another one that will work. There's RADIX50, but that will never work with C++, for the simple reason that there aren't enough characters in it.

https://en.wikipedia.org/wiki/DEC_Radix-50

You can also see the EBCDIC support in oddities like the digraph support.

Reply on news.ycombinator.com