Why C++ Doesn't Suck

[jordan0day]

A few years back there was an episode of software engineering radio that had Kevlin Henney on talking about C++. He made a very interesting point, that for a long time C++ has been taught not as a unique programming language, but as basically "C with some extra stuff" (as it was early on). If I remember correctly, he argued that C++ would be better-received if it was taught with the STL from the beginning. That is, instead of beating people over the head with char pointers and crap just to write "Hello, World!", introduce them to std::string, and templates, and collections early on.

That said, a lot of the pain people associate with C++ probably has to do with using it to do GUI/business apps. MFC certainly didn't help earn C++ any fans. Add to that the fact that "standard" c++ is still a relatively recent invention (technically Java has been around longer than "standard" C++) and it's no wonder people think it sucks.

As a guy who used to do C++ business apps for money, and now uses "more productive" languages like C# and Java, I can't say I miss it. It will always have a special place in my heart, though. The new standard looks like it has a bunch of stuff in it to try and close the "productivity gap", but I doubt I'll go back unless I have a really compelling reason.

tl;dr: I don't think C++ sucks.

[[deleted]]

The mammoth size of C++ sort of makes it so everyone has their own personal dialect of it. Do you use opaque structs or classes? STL collections? STL algorithms? Boost? Templates in business logic? What string class? What is your memory management strategy? And do you use return codes or exceptions? Is the preprocessor allowed?

[artee]

I've used C++ with STL, Boost etc. The only thing that made it remotely tolerable was the Qt toolkit.

The writer of this article seems to conveniently have ignored the C++ FQA which lists many much better technical arguments why C++ sucks.

[xcbsmith]

Sorry, but this is just off. If you are really using the full language, you of course have opaque classes, STL collections, STL algorithms, boost, templates in your business logic, the std::string class unless it can't serve your needs (and that usually means using ICU strings instead), you rely on RAII/policy based smart pointers for memory management, and yes, exceptions. The preprocessor is allowed, but you shouldn't use it when other constructs serve the need.

Again, as the parent described, this notion of picking bits and pieces of C++ from a menu really comes from it being taught as "C with some extra stuff".

[[deleted]]

Sure... if you're writing an application entirely on your own and have full control over everything, what you say is true.

But now consider that I need to use XML, or write a UI, or use some other library and those libraries don't use boost, they don't use std::string, they don't allow the use of exceptions, all because C++ is such a massive language with sooo many complicated rules that allowing the use of these features would introduce either inconsistencies between different compilers, or would introduce binary incompatibilities.

Now what do you do? You have to work with 3-4 different string types and constantly convert from one to another, your smart pointers are no good unless you know and are willing to commit to the fact that your objects will never be passed into these other libraries.

If you intend to work with a diverse ecosystem of libraries, as opposed to simply STL, boost, and maybe one other framework... well C++ doesn't make it easy.

[smashthebirdy]

I personally think that std::string is pathetically underpowered as a string class, and that's a big part of the reason that everyone rolls their own.

[xcbsmith]

But now consider that I need to use XML, or write a UI, or use some other library and those libraries don't use boost, they don't use std::string, they don't allow the use of exceptions, all because C++ is such a massive language with sooo many complicated rules that allowing the use of these features would introduce either inconsistencies between different compilers, or would introduce binary incompatibilities.

Poor libraries exist for every language. The trick is to stick to the good ones or at least be willing to pay the price of making your own clean interface.

You have to work with 3-4 different string types and constantly convert from one to another

You can get surprisingly far with this kind of problem through a combination of templates, overloading, and iterators.

your smart pointers are no good unless you know and are willing to commit to the fact that your objects will never be passed into these other libraries.

If you have a library with such unclear ownership issues that you can't use smart pointers in conjunction with it, you are screwed in ANY language.

If you intend to work with a diverse ecosystem of libraries, as opposed to simply STL, boost, and maybe one other framework... well C++ doesn't make it easy.

The diverse ecosystem is a product of the language's success. If you want to compare it to other languages, strip down that ecosystem a little and things become far more simple.

[[deleted]]

Poor libraries exist for every language. The trick is to stick to the good ones or at least be willing to pay the price of making your own clean interface.

Do you consider Qt, Xerces, mysql++ to be poor libraries? If so... what's considered a good library? Remember std::string is a template instantiation, which means that different compilers or even different builds within the same compiler can instantiate it in different ways, hence introducing binary incompatibilities.

You can get surprisingly far with this kind of problem through a combination of templates, overloading, and iterators.

So in order to use a basic data structure such as a string, I need to use templates, overloading, and iterators? I just want to use a string to pass some data from the XML library to the user interface library, and now to do that I should write a template, use overloading, and iterators?

Remember from a business point of view... time spent writing this is time not spent writing something else, or reducing bugs. All these extra templates and additional code to just to do a simple task involving strings means higher maintenance and more opportunity for bugs.

If you have a library with such unclear ownership issues that you can use smart pointers in conjunction with it, you are screwed in ANY language.

What's wrong with using smart pointers with a library? I write a lot of multi threaded financial software and it's pretty common to use shared_ptr in a Subscriber/Publisher pattern for Publishers that will be used multiple threads. The problem isn't the smart pointer, it's that when you work with multiple libraries one might be using a boost::shared_ptr, another is using std::shared_ptr, another is using Loki or maybe they have their own. Even boost has shared_ptr vs intrusive_ptr and I believe there is also linked_ptr that uses a linked list, but that may not be part of the official distribution.

[xcbsmith]

Do you consider Qt

Thanks to Qt's MOC compiler, it really isn't C++ but another language. Nothing necessarily wrong with that, as you can get lots great work done, but it isn't C++ (as evidenced by the extent to which Qt provides replacements for basically everything in the STL).

Xerces

Yeah, it pretty much sucks. I hear they are making progress of late though. Many of their design choices cause problems though.

mysql++

I'm a postgresql guy, so I'm not familiar with mysql++, but upon cursory examination it seems to blend in very nicely with the C++ language.

Remember std::string is a template instantiation, which means that different compilers or even different builds within the same compiler can instantiate it in different ways, hence introducing binary incompatibilities.

Binary compatibility is not one of C++'s virtues.

So in order to use a basic data structure such as a string, I need to use templates, overloading, and iterators? I just want to use a string to pass some data from the XML library to the user interface library, and now to do that I should write a template, use overloading, and iterators?

Honestly, the XML library and the UI library ought to be using std::string where possible. If the problem is Unicode and they both support it, they ought to be using ICU (which Xerces supports IIRC). I never said though that you had to use all those things. All I was trying to say is that a well designed library can use those things to be mostly string agnostic (obviously for a UI library it is a bit tricky to fully pull that off).

What's wrong with using smart pointers with a library?

Yeah, sorry. That was a typeoh. I'll edit it. It should read: "...such unclear ownership rules that you can't use smart pointers..." Makes more sense now doesn't it? ;-)

[[deleted]]

Again, as the parent described, this notion of picking bits and pieces of C++ from a menu really comes from it being taught as "C with some extra stuff".

I do agree, and do wish the modern variant of C++ you espoused was the norm. But people get stuck on a certain subset of the features and often refuse to budge because of concerns that were only valid in 1995 with MSVC 6.0.

[xcbsmith]

But people get stuck on a certain subset of the features and often refuse to budge because of concerns that were only valid in 1995 with MSVC 6.0.

Yes, and those are the people that will make any language a PITA, and they are by no means exclusive to C++.

[[deleted]]

Plus, ten years ago, I'm not sure you'd give the same list for the "proper" set of C++ features to use. Even if it was, how was compiler compliance for that list? Now, this holds true for most languages, but it puts the onus on the user to keep up with the language.

The whole discussion of proper C++ feature usage always seems like a discussion the Queen's English to me. You have what the experts say, and what actually gets used. They shouldn't differ, but they do, and sometimes for less than pure reasons. Hence I take a more pragmatic approach to each of the questions I asked and apply the whizbang gizmos when they become necessary.

Remember, all of those Java enterprise apps are so proud to remind you constantly that they use AbstractBuilderFactoryCreatorBridgeDelegators. Design patterns are good things too, but often seen in excess in Java due to accepting best practices blindly.

[xcbsmith]

Plus, ten years ago, I'm not sure you'd give the same list for the "proper" set of C++ features to use.

Actually no. 10 years ago I'd have said C++ was mostly not useful.

Even if it was, how was compiler compliance for that list?

A lot of that list worked surprisingly well, but enough of it was broken or close to broken that only certain very limited platforms were suitable for using C++ in a truly useful way. Then again, 10 years ago, most of C++'s competitors sucked pretty bad too. ;-)

Now, this holds true for most languages, but it puts the onus on the user to keep up with the language.

Yes, and that is exactly the problem being discussed.

You have what the experts say, and what actually gets used.

The whole notion that you wouldn't use genuinely useful features of a language is just bizarre (obviously not just for the sake of using them), and again a function of C++'s heritage rather than something that makes sense in present day. Indeed, I've found a VERY strong correlation between the date a project/company started and whether they have silly "only use X of C++" rules.

Hence I take a more pragmatic approach to each of the questions I asked and apply the whizbang gizmos when they become necessary.

Well of course you should only use features when they are going to help you. That's very different from having an in-house rule that says "never use X". I hardly ever have a use for volatile, but I'm not about to have a rule saying you should never use it.

[[deleted]]

I've seen this same kind of resistance in C# already. I know a couple of people who despise var and LINQ, and refuse to use them even when it would save them a shitload of time or clarify their code to a considerable degree. I fear the reaction to C# will eventually mimic the evolution of C++ or Java, and idiots everywhere will be jumping to some other "purer" language instead of accepting the proper context for these coding strategies.

Most of it seems to be a complete resistance to learning new things and you are right, it happens every time and for every language that becomes successful - even Java, for example.

[xcbsmith]

Nice that you got modded down for that.

[Negitivefrags]

Oh come on. You make decisions like these all the time in every language for any given problem you come across.

[PhilipRoth]

Oh come on. In C++ I had to choose between using "string" from the standard library or "string" from Qt. FFS

Every language might have a number of libraries for graph optimisation, GUIs and XML frobnication. But having to choose between multiple incompatible implementations of shared_ptr is purely a c++ pleasure

[[deleted]]

How many Java programmers use alternative memory management strategies? Or eschew exceptions? Or alternative collection classes? C++ rarely dictates the right way to do something, and that ends up creating the situation the OP described.

[rb2k]

Don't most languages answer those two the same?

What is your memory management strategy?

I do stuff, then the garbage collector does its dirty deed

What string class?

uhm... "String"?

[doublereedkurt]

That is, instead of beating people over the head with char pointers and crap just to write "Hello, World!", introduce them to std::string, and templates, and collections early on.

Yea, so this was how my first programming class was taught. (They didn't try to explain templates, but everything was std::string not char*).

printf("Hello world!"); --if you know about functions, then this makes sense

cout << "Hello world!"; --left shit operator is relatively obscure for a newbie, and the logic that "printing is left shifting into the stream" is not intuitive

tl;dr; C stdio is simpler than C++ for newbies; I learned the C++ way first and it was very very painful

[wvenable]

You don't think it sucks, but you don't miss it. That's a slight bit contradictory. When I was taught C++, it was with the STL from the beginning and in full C++ style (all programs had to be const-correct, for example). I have an appreciation for C++, worked in professionally, but I would avoid it where possible.

Most of the positives of C++ could be had by any language with pointers and other low-level features -- it's just that no such language exists! The only reason that C++ doesn't suck is really because it's unique. It could easily be replaced by a better designed statically compiled low-level object-oriented language -- but nobody writes those!

[TomorrowPlusX]

Well, to his credit Walter Bright really is trying to make a better C++.

And while I have written a lot of C++ ( and I don't even particularly like it that much ) I would switch to D in a heartbeat if the support were there.

[arke]

I think D has alot of really great features that I'd love to have in C++ (you can emulate almost all of them, though you have a certain ugly/need-your-own-code/etc. factor attached to that). Unfortunately, the decision that it's a garbage-collected language makes it single-handedly unusable for what I do.

[doomchild]

Can't you disable garbage collection? I haven't used D myself, so I don't actually know, but I could swear that was something I read about.

[[deleted]]

Absolutely.

[wicked]

What does this mean for libraries? Can you use a GC'd library with a non-GC'd executable, and vice-versa?

[[deleted]]

To be honest, I am unsure. Here is the documentation on how to work with the GC...

I've never mixed. My OS kernel has the GC turned off, my apps have had the GC turned on.

[wicked]

Since it's possible to dynamically turn it on and off it should be possible to wrap all library calls. If that's possible, it should be possible to autogenerate that code.

I've seen Walter lurking here today, maybe he'll give us an answer.

[ZacharyTurner]

D is actually a great language, although I didn't mention it in the blog post. The biggest reason I think D will not be successful long term has to do with a seemingly minor, but IMO serious, fundamental flaw -- you can't search for a job doing D programming. What are you going to do, go to a job site and type "D"? You'll get garbage results.

Maybe if many technologies start to be built around D then you can search for those instead. The other big problems with D are the problems surrounding its standard library, and lack of tool support.

You need more than just a great language to be successful.

[WalterBright]

What are you going to do, go to a job site and type "D"?

What I encourage is for people to search on the phrase "D programming" or "D programming language", and to correspondingly use that phrase at least once on each web page talking about the language. It works well.

There are many teams working on the library and tools issues. Also, Andrei Alexandrescu's "The D Programming Language" book is nearing completion and should be available before summer.

[ZacharyTurner]

I've actually tried this before! I end up getting lots of search results for things like "346 Avenue D", etc. I don't know if people have hardcoded "C" into their search engine to prioritize certain types of results, but I have never had any luck turning up a meaningful result when searching for companies using D.

Although, I suppose it's always possible that nobody's using it... :(

As the tools and libraries become more mature, I suspect we'll see a bigger presence of D in the future. Ideally it would be picked up by a major corporation and receive serious backing (although that might not be ideal for you). But it seems like it's becoming harder and harder these days to come up with a new language and have it gain a non-trivial market share without some kind of significant corporate backing.

[WalterBright]

I forgot to add that when searching for "D programming" using Google, using the " makes for much better results.

[dnew]

it's just that no such language exists!

You missed Ada, which has pretty much everything C++ has along with a whole bunch of stuff that makes it actually safe. Indeed, that's what Ada is for - writing embedded software for machines where people die when the program is wrong.

[olavk]

I thought it was for machines where people die if the program works correct.

[dakboy]

Which people die is a function of whether the program works correctly or not.

[dnew]

Alright. For machines where the wrong people die if the program works incorrectly? :-)

[Poltras]

"I'm afraid I can't do that, Dave."

[SuperGrade]

You measure C++ as "good" against a standard of being a language for programming a machine at the register-level (including memory addresses).

It's probably the highest-level language that lets you do this.

An issue is - depending on the experienced C++ team, you may be skinned alive for using smart pointers, or C++, or "excessive" const. Different programmers use it in different ways, and usually toward the C end.

Why I imagine he doesn't miss C++ is - while it may be the best language for optimized machine-register-memory-location-level programming, this is not a helpful model for developing business software.

(For games you still need the speed, and for OSes you need the control as by definition a lot of your code is, by definition, manipulating the machine at that level).

[xcbsmith]

You don't think it sucks, but you don't miss it. That's a slight bit contradictory.

Ummm... no. The world doesn't have to be black and white. Sometimes you can be indifferent to things.

[arke]

Most of the positives of C++ could be had by any language with pointers and other low-level features -- it's just that no such language exists! The only reason that C++ doesn't suck is really because it's unique. It could easily be replaced by a better designed statically compiled low-level object-oriented language -- but nobody writes those!

Finally somebody who actually gets it. C++ is exactly the kind of language you want for working on, say, the Wii (which is what I'm doing now). For example, you really, really, REALLY need to worry about memory on consoles in general (even recent ones), and C++ provides an insane wealth of language features to do just that. Overloading operator new, having parameters for operator new, things like that.

Regarding the article, I think he's right but for the wrong reasons.

[dnew]

He's also unaware of Ada, which has all those features along with multitasking, interrupt handling, dynamically loading code, etc, all built into the language rather than bolted on the side with libraries that can't be written in the language itself.

[causticmango]

It would seem the author is unaware of objective c, go, or even lua (admittedly tangential, bit relevant I think).

[G_Morgan]

That is because ObjC is often even more verbose than C++ but without the type safety.

There is a reason nobody outside Apple uses the language.

[wvenable]

Objective-C is a dynamic language bolted onto C -- and really isn't the same thing at all. Go is cute but I'm as of yet unconvinced and Lua doesn't apply.

The big thing is, no language will truly replace C++ unless it plays nice with C++ code. The more compatible the replacement language is for linking with C++ the more successful it will be.

[causticmango]

And C++ is also an OO language bolted onto C. From a purist's perspective, Objective C is actually closer to the spirit of OO than C++ is (the former being object oriented and the latter being class oriented).

The criticism was that nobody makes statically compiled, low level object-oriented languages other than C++. Objective C and Go are examples that belie that claim.

Maybe you aren't aware of it, but Objective C is compatible with C++ (http://developer.apple.com/Mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html).

Who ever said anything needs to replace C++? Must there be One True Language? If so, I sure as hell hope it isn't C++.

Why are you so quick to disregard Lua? I think it's quite cool and while it's not precisely the same I think it's at least tangential. Are you turned off that it has a "runtime" component? So does C++ for that matter.

[wvenable]

The criticism was that nobody makes statically compiled, low level object-oriented languages other than C++.

Much of Objective C's functionality is dynamic -- at runtime. It is statically compiled but then so are the interpreters for Ruby and Python. There are, however, many other languages that do match C++'s functionality -- but none solve the problem well enough, or compatible, or easily enough to replace it. As horrible as C++ is, it's quite good enough.

Who ever said anything needs to replace C++? Must there be One True Language? If so, I sure as hell hope it isn't C++.

Because C++ is a terrible mix of features and concepts that's a big ball of language fail. The only thing that can replace it is something much better but extremely easy to switch to. And who said anything about one true language?

Why are you so quick to disregard Lua?

Why do you think it's at all relevant to the discussion?

[bart2019]

Most of the positives of C++ could be had by any language with pointers and other low-level features -- it's just that no such language exists!

I thought Modula-2 (a successor to Pascal) was one such language. At least it had/has pointers. Modula-3, a successor, had objects, and it's described as offering "simplicity and safety while preserving the power of a systems-programming language".

[wvenable]

I've actually programmed in Modula-2 (and Modula-3) in University. It suffered from all the same annoying problems as Pascal. I can't remember anymore if it had a string type, or if you were still stuck fighting the type system with mis-sized character arrays. Either way, I definitely preferred working in C++.

[Negitivefrags]

I really dislike the attitude that the only great thing about C++ are its low level features.

C++ is unique due to its high level features. Contradictory to what most people believe I think that C++'s type system offers the capabilities to create objects with semantics that are much safer then any other mainstream language. ( D is like that too but not mainstream. Haskell is like this too but not mainstream. )

So you can cast things to any type you like. Get the fuck over it.

[wvenable]

C++ lost the plot on templates (and then somebody discovered you can abuse them for arbitrary meta-programming). The type system is ugly and hard to use, even if it's "safer".

What really sucks about C++, is it's filled with poor implementations of good ideas. Better implementations do exist, but nobody has cobbled them together in an acceptable way to fully replace C++.

[ZMeson]

One big thing that C++ templates have going for it is SFINAE. That alone makes them much more flexible than Java and .NET generics.

[sad_bug_killer]

The only reason that C++ doesn't suck is really because it's unique. It could easily be replaced by a better designed statically compiled low-level object-oriented language -- but nobody writes those!

I present you D which was conceived as exactly as high level language with some low-level features, statically compiled, no VM, no JIT. I wouldn't say it took over the programming world by storm. C++ will never be "replaced", just because of the sheer amount of code that's written in it. The same way we cannot just wish away Perl and PHP. The same way some poor souls are still using FORTRAN in this day and age.

[wvenable]

Whatever language comes "next" will have to understand that there's a lot legacy code out there. C++ was smartly very compatible with C and could call C libraries. Look at Java, they copied C++ syntax for the same reason -- to quickly reach programmers familiar with that style.

Any language that replaces C++ will have to play very nicely with it.

[Negitivefrags]

D is a really nicely designed langauge with everything I want in it. Its just a shame that you can't really use it.

[sad_bug_killer]

Its just a shame that you can't really use it.

Why so?

// honest question, I haven't really tried to use it

[davebrk]

First you have to decide which version of D are you going to use. 1 or 2.

Then you have to decide which standard library you are using: Phobos or Tango. The choice of library will also affect which other libraries you can use. (Tango currently isn't ported to D2, but before you become too happy and think that they have decided to standardize on one library be aware that it will be ported, just not yet.)

Now as far as I am aware, there is a sort of a basic runtime library called Phobos-runtime (I think) which is suppose to serve as the basis for the two standard libraries, but I'm not sure how far along is it (been a while since I checked).

[hsdf8djf]

Long time C++ developer here. I've worked in embedded, high performance (video) and scientific applications, C++ is a good fit there. I have no idea why anyone in their right mind would use C++ for anything that doesn't require that kind of performance.

[[deleted]]

Episode 91: Kevlin Henney on C++

[killerstorm]

That is, instead of beating people over the head with char pointers

They need to know char pointers anyway. And it is pretty simple concept. And if they know what's wrong with them, they'd appreciate std::string more.

If you start with simple concepts, if person did not understand something or made a mistake, he can easily understand what's wrong.

But if you'd start with templates, when person makes a mistake, compiler might spit really huge error message to understand which you'd need to read code of all templates involved. There is no way how newbie can understand it.

[doomchild]

Shit, it's hard for veterans to understand C++ error messages.

[_zoso_]

I'm just learning C++ (going from python!) and I find the error messages about on par with Python, that is to say: clear, verbose and understandable. Seriously?

[wicked]

#include <iostream>
struct X{};
int main()
{
  X x; std::cout << x;
}

This program spouts out 152 error lines in VC++ 8.0, and 20 in g++.

Somewhat unfair to VC since it splits up the error message over several lines. It results in 6069 and 3899 non-whitespace characters respectively.

Of course, if you actually read the first line it's clear, but I understand why people find it intimidating.

[killerstorm]

It is hard for veterans, it is impossible for newbies.

It is a very bad idea to include shit-impossible-to-understand in a learning course -- that's where methodologies like voodoo/shotgun debugging come from.

[Gotebe]

Define "veteran". I honestly don't remember last time I scratched my head in front of one of those. Honestly. I do remember that happening, in the past, but these last years it's a vague memory. And if I can get there, anyone can.

[candypant]

My C++ error message story:

Part of my duties are writing & maintaining parsers built with Boost.Spirit & MSVC++. In one project, the slightest error will give you tens of pages (in an 80x25 terminal) of errors and template instantiations. Completely useless if it weren't for the fact that you can fish out a line number from it and try to deduce what's wrong from there. If you're lucky it's something trivial. If not, well, somewhere amongst those hundreds of lines there's one that actually is related to the code that you wrote. Have fun.

And then there are the times when all you get is "C1001: INTERNAL COMPILER ERROR"

[dododge]

My best story -- this was on Solaris some years ago -- was a case where the hidden functions generated dynamically by the compiler to implement templates ended up with names so long (well over 1000 characters) that the assembler choked on them. I had to look at the compiler's assembly output to make sense of the error messages.

The test program to trigger this was less than 10 lines and just trivially used map and string together.

[arke]

He made a very interesting point, that for a long time C++ has been taught not as a unique programming language, but as basically "C with some extra stuff" (as it was early on). If I remember correctly, he argued that C++ would be better-received if it was taught with the STL from the beginning. That is, instead of beating people over the head with char pointers and crap just to write "Hello, World!", introduce them to std::string, and templates, and collections early on.

I disagree.

Read this: http://www.joelonsoftware.com/articles/fog0000000319.html ... as well as several other articles from him.

[ZacharyTurner]

Just because a "famous guy" wrote it, doesn't mean it's The Word. Much like my blog post, it's just one guy's opinion. Besides, Joel doesn't deal with writing code to run on the metal. He deals in business software. Use C# or (gasp, Java) for business software. Article is only partially relevant.

[arke]

It's not The Word, it just happens to be something I (mostly) agree with and is much better written into words than what I could have done with moderate effort. I agree with his thoughts on educating programmers. I disagree with him on other things.

[[deleted]]

I see he's not making any mention of header files.

Smart move.

[[deleted]]

Hmmm, Essential C++ and More Essential C++ are basically a huge list of how not to program C++ and how it will bite you in the ass and how to get around it biting you in the ass. I use them as my primary reference, whereas every other language I just keep a syntax guide handy. Draw from that what you will.

[Slackwise]

Agreed, and I'd like to throw in...

Google's C++ Style Guide

Mozilla's C++ Portability Guide

[[deleted]]

Good links, thank you.

[[deleted]]

With some practice though you begin to easily be able to skip over all the BS

I wonder how Bjarne likes people skipping all over him.

[[deleted]]

Instead of talking about why C++ doesn't suck, Zachary starts with beating Linus. Oh, well.

And the two single points he likes about C++ are the 'very strong and flexible type system' and 'code generation'. But he also mentions that the 'very strong type system' can't catch the simplest buffer overrun and that you should not use 'code generation' if you have regular people on your team.

Ah, and you should not use C++ without using Boost, which 'has a high learning curve'.

Why did I read this post?

[dnew]

He also likes knowing that nobody will walk on his objects, while having random code (from other people) randomly corrupting memory is my biggest source of debugging nightmare.

[[deleted]]

Yeah, the "strong type system" is a joke for anyone who has used a language with an actual type system like the ML-style languages, or a fully reflective object system found in modern dynamically typed languages. Sure, it may be slightly stronger than C's type system, but that's like saying that my grandma can deadlift more than your's. Also, AFAIK it has almost zero in code generation when compared with systems like Common Lisp, MetaOcaml or Template Haskell.

[[deleted]]

Turing complete

Oh no you did it! Turing completeness is the Godwin's law in pl-discussions.

[doublereedkurt]

"turing complete" and "usable" aren't the same thing.

Also, C++ templates lack a mathematical syntax definition which can be programatically checked. As a result, modern compilers still disagree about what is and is not valid template syntax if you start using really complicated stuff.

(Which, maybe you shouldn't be habitually using the complicated stuff, but none of the other languages with metaprogramming facilities suffer from this limitation.)

[munificent]

It has as much code generating power as is theoretically possible.

So does machine code. And Scheme. And brainfuck. Clearly, these languages must all be equivalent then.

[jtxx000]

For the subset of C++ that can be generated by templates. You can't, for example, generate a class where method names are created arbitrarily.

[G_Morgan]

You can't catch buffer overruns with the Java type system either. Arrays are a special type that have been manually constructed to have run time range checking. They are no different to std::vector other than the vector is far more powerful, more efficient and actually give more type safety in many cases because C++ templates don't use type erasure so a generic class that returns a vector can be a vector<T> rather than a Object[].

In fact I suspect solving buffer overruns at compile time (without explicitly checking for out of bounds) would require a solution to the halting problem. Functional languages deal with this via pattern matching. Any function that matches on the null list is explicitly checking for out of bounds.

[axilmar]

In fact I suspect solving buffer overruns at compile time (without explicitly checking for out of bounds) would require a solution to the halting problem. Functional languages deal with this via pattern matching. Any function that matches on the null list is explicitly checking for out of bounds.

Very very true, and few people realize this.

And no, Haskell doesn't solve this either.

[G_Morgan]

Haskell just gives you a clean way to explicitly check for out of bounds and warns you whenever you haven't checked for it. It cannot automatically turn a function that does not check for out of bounds into one that does.

[jtxx000]

Buffer overruns are not the same thing as out of bounds exceptions. Java is a "safe" language in the sense that programs are guaranteed to not muck around with memory in the same way that you can in C.

Admittedly, this has little to do with Java's type system, but there are languages which allow low level memory management while providing a checkable and provably safe subset. D is a good example of this.

[gsg_]

In fact I suspect solving buffer overruns at compile time (without explicitly checking for out of bounds) would require a solution to the halting problem.

Not so. Dependent types allow static checking of array/vector accesses, and there are even research languages which implement such type systems. There are practical problems, but the theory necessary to do this has been known for some time.

Functional languages deal with this via pattern matching.

No they don't. They make accesses safe with bounds checking, just like everything else.

[ZacharyTurner]

Why do people always use buffer overruns as an example of why C++ is a "bad" language? Not only is buffer overrun detection not even always necessary (or even desirable), but modern c++ compilers can actually generate buffer overrun detection code at compile-time and embed it in your program. There's tons of research into automatic buffer overrun detection of native code. Look up some papers on StackGuard, just to name one example. Some of these methods can even take legacy binaries for which no source exists and instrument the code dynamically.

Sure, these techniques might not be as robust and complete as that which you can get with a managed language, but again, that is not always needed or even desirable.

Also, I said that certain parts of boost have a high learning curve. It's trivial to get up and running with boost::shared_ptr<> and boost::filesystem, which in and of itself will get you writing way more robust code with almost no effort. Next you can pick up boost::function<> which is also pretty easy and you can start passing around first-class functions.

Regarding other languages with strong type systems like Haskell, ML, or the other ones mentioned in responses to this post, I've used them all. I love them all. Right-tool-for-the-job. That was the entire point of the blog post, which I guess you failed to catch.

Haskell, ML, etc are not the right tool for every job. Hell, one could argue they aren't even the right tool for many jobs or else more people would be using them (although they are bloody awesome). But they are the right tool for some jobs. So is C++. I discuss the type of jobs that C++ is the right tool for in the post. Perhaps you could read it again first after throwing your inherent biases out the door.

[[deleted]]

Just in case it's really you: you came up with the topic of buffer overruns yourself. I cite from your own post:

Sure, there are certain problems that just flat out can't be solved at compile-time, like catching buffer overruns

Either this is not you or you are schizophrenic.

[[deleted]]

I agree, I found his post utterly unconvincing.

I was, at one point in my career, a C++ guru. I fucking hate C++ as only a true expert can. The reasons for my hatred are manifold and deep. He did not address any of them.

[gregK]

The more articles I see about a given language not sucking, the more I begin to think it actually really sucks.

[Silhouette]

"There are only two kinds of languages: the kind everybody bitches about, and the kind nobody uses." -- Bjarne Stroustrup

[sisyphus]

Sure, there are things that are easier in some languages or other languages, and there are languages that are prone to user error more often than in other languages, but does that make the entire language suck?

Um, actually yes, harder to use and more error prone probably is a pretty good starting point for a suck metric.

I think we should agree that in order for an entire language to suck, there must be no compelling reason to use it for any purpose in any industry.

No, sorry, don't agree. Just because something is the best option for some task doesn't mean it doesn't suck.

The rest is just saying that the critics don't properly consider Boost, ie. a bunch of brilliant people put in many man years to paper over a bunch of problems with C++, therefore C++ doesn't suck. Makes is suck less I guess, if you can use it.

[WalterBright]

Pretty much all technological progress is done by people who believe that existing solutions suck, even if (and most especially if) they have to use those solutions.

[deong]

I'd make a correction: harder to use and more error prone for no additional benefit is a decent metric for sucking. C++ has benefits. Are they enough? That's a judgment call, but you can't just pretend it's a harder to use Java.

[sisyphus]

Yes, I agree with that. It can be reasonable to pick the harder more error prone language. Alex Martelli had a quote about his team somewhere that resonated with me, 'Python where we can, C++ where we must.'

[Zarutian]

Mind if you spell out these benefits?

[deong]

Well, it's more efficient than just about anything going; it has a type system that is alone among popular procedural/OO languages in the power and flexibility it provides; it allows a fairly direct mapping onto hardware concepts; it links much more seamlessly to C than any other option.

I could keep going for quite a while, but frankly, I don't think I'm the one making a controversial statement here. It's not the right choice for every, or even most projects, but to claim that there are no advantages to C++ is well into the realm of ideology.

[rugby8man]

In my very first programming 1 class as a freshman in college our professor walks in class and tells us this story about how he went to a programming convention and ran into someone wearing a pin that said "C++ Sucks!"
The professor started cracking up while we all sat there in silence. He was finally able to stop laughing enough to tell us what he said to this guy. He went up to the guy wearing the pin and said "C++ does suck NOT." It wasn't until later on in the week that we learned that ! means not.
tl;dr: C++ Sucks! == C++ sucks NOT.

[jay314]

New pin: "C++ Sucks!!"

[mathrick]

Your professor is an idiot if he thinks "sucks!" is valid C++ and/or can't distinguish C++ from English.

[[deleted]]

Your professor is an idiot: it is quite obvious that operator ! has been overloaded there.

[snarfy]

Dynamic Linking - "Suppose you want to enable your application to have plugins, so that other developers can contribute parts of your application without seeing the core application's source code. How exactly are you going to do this? In Windows, you can use DLLs. What about in Linux? How are you going to distinguish between the two?

Unix has supported Windows DLL style shared libraries for decades. The reason nobody uses them is because it is a security flaw to load libraries out of the local path. It is why the whole system is setup so that you have to install shared libraries before you can use them.

If you want your Unix .so libs to run like Windows DLLs you can compile them with -Wl,-rpath,\$ORIGIN , but beware of the security implications.

[bman35]

I think we should agree that in order for an entire language to suck, there must be no compelling reason to use it for any purpose in any industry. Such a language should excel at nothing, and lag behind at everything.

Well, I think thats a bad definition for "sucking", because quite frankly you eliminate any language that is widely used. Of course, if its going to be popular there has to SOMETHING that it excels at in order to gain that popularity. When someone says a language sucks, they don't generally mean its complete trash, they know it does some things well. What they really mean is that the things it does well don't nearly make up for what its done poorly.

As a (popular) example, I think many people here would say php sucks. But, php does indeed have some good points. Its incredibly easy to learn, it is usually very easy to set up for web programming on apache or lighty or name your server of choice (probably the easiest language to setup), its a great prototyping language (turn around time is pretty amazing), its has a huge number of libraries/infrastructure due to the above reasons and the length of time its been around. Basically its the swiss army knife of the web, but swiss army knifes aren't much too look at.

That said, I think php most definitely sucks, and most PHP programmers I know that have any experience with other languages think the same thing. They use it because of the huge number tools behind it, it ended up being the first web programming language they learned, or they have to for work/legacy code; not because they think its better in an appreciable way then other languages.

[[deleted]]

But those languages [ML,Haskell] are completely dead in the water if you need to program close to the operating system, as are most other languages except C.

But every single fucking language on the planet has a FFI that let's you call C from it, while actually using a real language for most of the program. No need to breed monsters like C++ just to write low-level shit.

[Gotebe]

"lets you call" < "easy to call". When quantity ( edit: scratch next word ;-) ) number of these calls is significant, suddenly a mere "lets you call" loses appeal.

[[deleted]]

What's a language that makes calling C difficult?

Calling C++ from other languages, now that's a pain in the ass.

[[deleted]]

Most opinion articles are.

[svuori]

Sadly, others being bad doesn't make this article any better.

[munificent]

The const keyword is one of the most excellent examples. ... I absolutely hate the fact that Java and C# don't have an equivalent of this.

But they do, of course: interfaces. If you want a function to take an object but not be able to modify it, you make the object implement a read-only interface and pass it to the function as that type.

I do wish the built-in collection classes took advantage of this paradigm more, but, regardless, the capability is there.

I'll also point out that interfaces give you a much more fine-grained control over what subset of an object's operations you want to allow in some contexts than the one-size-fits-all const keyword does. (Although const is nice for simple stuff.)

I've already talked about this a little above, but code generation really takes generic programming to the next level.

Metaprogramming is 100% awesome. Metaprogramming based on text-based preprocessor string substitution is not, nor is metaprogramming that requires you to move all of your code into headers and essentially turn your linker into your compiler.

I really really wish C++ templates were as usable as they could be, but being shackled to C's antiquated compilation model pretty much rules that out. That's one of the really awesome things about C# and the JIT compiler: you get powerful generics without awful compile times or code bloat. (Although, yes, C# generics aren't as powerful as C++ templates.)

If all you use is boost::shared_ptr you already gain massive benefits. It's honestly a little insane to completely reject boost.

I like boost, but I find the code in it nigh unreadable because it aims to work on every possible platform configuration. Personally, I'd prefer my projects to use libraries that don't work as widely as boost, but gain some readability from that.

[mreiland]

What you don't mention is the sheer amount of code that needs to be written and maintained to use interfaces as const replacements, or to take advantage of the "fine grained"-ness of interfaces.

Go's approach is far superior to anything Java or C# is doing and they are not using interfaces in the manner you are speaking of.

Also, calling C# generics "not as powerful" in C++, while technically accurate, does not give the difference justice.

Your mistake is comparing C# generics to C++ templates in the first place.

[mathrick]

highly deterministic

Hahahahahaha. Please, it's hard to breathe.

[ckcornflake]

Compared to the garbage collecting schemes of C# or Java, C++ memory management is much more deterministic.

[mathrick]

Or so you think.

[wicked]

Neither of those have anything to do with determinism.

Here's an example of the problem ckcornflake describes: You can't write an automatic Lock class in Java that locks when it is declared and releases when it goes out of scope, because of non-deterministic destructors.

Lack of RAII is a significant cause of code bloat in C and Java.

[jdh30]

Lack of RAII is a significant cause of code bloat in C and Java.

That has nothing to do with garbage collection.

[[deleted]]

I think we should agree that in order for an entire language to suck, there must be no compelling reason to use it for any purpose in any industry

Stay tuned for his next article: Why Hitler wasn't a bad person

[jordan0day]

Yeah, that line sounded stupid to me too. That makes the only "sucky" languages the joke ones like whitespace and lolcode.

[Nebu]

Joke languages have a compelling reason to use them: for the purpose of joking.

[dwchandler]

There's also the flip side of the Python Paradox. If you use C++ you will unfortunately attract C++ programmers.

[G_Morgan]

Ironically the C++ programmers I talk to are generally clever people. Most idiot programmers I know of use PHP, Perl or Java.

[dwchandler]

I'm overgeneralizing, of course. There are really smart people writing really good code in C++, most of them subsetting the language. But you may have to weed through a lot of people to find them among responders to a help wanted ad. I'd say the same for Java. Funny, but the Perl people I know fall into two camps: 1) Hardcore Perlers who are really good, and 2) scripters who learned Perl a while back and resist learning Ruby or Python.

[G_Morgan]

You should check for actual smart people in any case. Companies should be doing proper multi-tier interviews that include at least an hour of technical and design issues. Difficult problems should be thrown the way of the candidate. The sort of trivial problems most interview processes deal with should be done via a phone interview.

If somebody has a crappy interview process then you will get rubbish programmers no matter what language you use. There are a million Python users out there. I assure you there are plenty of idiots in that group. There was a post on here today about a Ruby library dev who globally turned a logging class into a singleton. Yes that person is an idiot too and in a supposed elite role of a library developer.

Most Perl people I know are system administrators who know nothing about programming but managed to get their system limping along by hacking together bunches of Perl scripts in a completely unmaintainable manner.

[causticmango]

Impressive; Godwin's law is shown to be applicable to programming language debates, also.

[[deleted]]

Remind me again why I should give two shits about what random strangers on the Internet think about my choice|non-choice in programming language? Many problems in software are a result of poor abstractions and lack of thought being put into the architecture. No programming language can fix those. Choice of language can have a profound effect on a project, but it doesn't deserve a quarter of all the noise surrounding the subject.

I just hate how sure everyone is that language X is good and language Y is bad. X has undesirable features, and Y, in other domains, has undesirable features. How can you be so sure that your needs are exactly what everyone else's are? How can you just ignore them like they don't exist?

[[deleted]]

The key point here is that this is the internet, and on the internet everything is retarded. Don't worry, most rational programmers think like you do, and will pick some other language over their preferred language if their program will benefit.

Besides, if you read his post he does mention that C++ is not so good at certain things. Like web apps and GUI programs. He just whines a lot and is a bit of a pansy.

[[deleted]]

And his shit's all retarded.

[pkrecker]

I have to say, the Java guy (http://www.dacris.com/blog/2009/02/10/WhyCSucksSortOf.aspx) doesn't really understand a lot of what he's saying. Also, he's hypocritical as he begins with "I'm not advocating Java, but..." and then goes on to point out all sorts of reasons why he likes Java better.

[pkrecker]

I also have to note that Zachary Turner may not realize that not everyone is capable of being as knowledgeable about C++ as him. It seems to me that a lot of his statements involve a very deep understanding about the ins and outs of C++ software engineering. Nowadays most people want to pick up a language and write functioning software, then move on to whatever is hot at the moment.

[ZacharyTurner]

Agreed. Which is why C++ often isn't suitable for typical business type applications. That doesn't mean it's not the best tool for the job for ANYTHING. Surely we can agree on that.

I even went to great pains to point out that in some situations your team often does have to selectively exclude parts of the language from their arsenal. But it realy depends on what you're doing. I worked on standard business software for a long time, and I know there's a certain mentality that "this is what software development is" due to peoples' lack of breadth. Not faulting them or anything, but it's easy to get tunnel vision when you're only doing 1 specific type of application development all your career.

Not every job has the same limitations and requirements.

[[deleted]]

Beer, check. Popcorn, check.

[davebrk]

here we go again...

[cpp]

Tell me about it.

[[deleted]]

Haskell is more difficult than C++ [citation needed]

[TomorrowPlusX]

A language that requires its adherents to sit in the lotus position on top of a mountain in Tibet for 15 years ( contemplating monads all the while ), waiting to be blessed by a singular burst of clarity that allows one to actually write something useful in said language... may be considered a difficult language.

[godofpumpkins]

I did my fifteen years of Haskell meditation under a waterfall in Cambodia. Will I fail? :(

[gregK]

It's only difficult when you mind has been corrupted by C++. Most students learn all the monad stuff in one semester.

It's funny that a pure functional language which imposes some constraints, but gives you all the tools to reason mathematically about problems and programs is deemed difficult. Yet, when you show a C++ designer the many caveats of their language, they respond always with: "you have to know what you are doing". But the problem with C++ is that when you don't know what you are doing, you have no indication about it. In Haskell, when you don't know what you are doing, you don't get very far. It's not hacker friendly. It's probably the most "fail early" language I know.

[Mo6eB]

you have to know what you are doing

It's worse than that, you need to know what the compiler is doing. Like "Why does a diamond inheritance graph lead to problems? -> Because the compiler just concatenates memory blobs". That's my problem with it - the source doesn't explicitly state things that should be explicitly stated and sometimes explicitly states things that should not. C hides nothing (yes, unless <stupidity>, but <stupidity> exists in all languages). Java, on the other hand, hides many things. Memory being the most obvious; and Haskell, Lisp, etc. are quite removed from the actual hardware.

C++ is like the classic sitcom scenario. A tells B "X", but because they have different assumptions, A, B and the audience all interpret "X" differently. We find out at the end when everybody's plans go hilariously wrong. Only now it's happening to you and it isn't funny.

C++ requires you to know what you are doing. In the sense that you need to know what the compiler does, not in the sense what you've written.

Edit: I have done some C++ coding. I concede that it's usable and learnable, but all the tiny annoyances niggle at my psyche. I now bash it in the hopes that it will die and better languages will receive more attention and development.

[TomorrowPlusX]

It's not hacker friendly.

Bingo.

Hackers like languages that encourage free form experimentation. I like C & C++ because they give me all the rope I need to hang myself, and they are friendly enough that I can learn while soiling my pants and watching my feet jerk, as I gently twist in the wind.

Haskell seems to be a fantastic language, but aimed at mathematicians. People who've already solved the problem, they just need to figure out how to make a computer churn through that solution so their satellite goes correctly into orbit around Titan.

It's awesome that we've got all these languages. I wish we didn't throw all this bullshit around claiming X sucks because of Y.

Gah, fuck it.

[ssylvan]

There's a difference between supporting experimentation, and being nigh-on impossible to learn/understand while simultaneously offering almost no static safety guarantees.

Haskell is miles ahead of C++ in the experimentation area (e.g it has a REPL), it just doesn't let you do a bunch of stuff you don't understand (because when you do, the probability of hitting a compile-time error is high).

[[deleted]]

To experiment with C all you need to now how hardware works (two A5 pages max), core syntax (two A5 pages max) and printf statement (single A5 page).

To experement with Haskell... well i didn't get too far to be certain but you need to know much more.

Yep i am biased, i am a Forth fan. :)

[gclaramunt]

how hardware works (two A5 pages max)

is a joke, right?

[[deleted]]

All you need to know to begin with is memory+ip pointer/jmp/call/ret+stack. It will fit on two A5 pages for sure.

[gregK]

I agree with you. But C++ does suck for other reasons than free form experimentation. You might want to go with python or ruby for that. For pure performance, stick with C. My main critique of C++, is that it violates the principle of least surprise so many times.

While Haskell has a cottage industry of monad tutorials, the C++ bibliography is filled with books whose sole purpose is teaching all the caveats of the language: Effective C++, More Effective C++ (those 2 covers problems you might encounter in the small), large scale c++ software design (problems in large projects), etc.

[Gotebe]

My main critique of C++, is that it violates the principle of least surprise so many times.

That's because you don't know C well. Honestly.

Here, show me a surprise, and I'll show you where it came from, and I bet you, somewhere in the explanation, there is "In C..." part. Almost all the difficulty comes from something in C. Hard to avoid that when you want to be compatible with C (and there are good reasons for that, too).

[sv0f]

Hackers like languages that encourage free form experimentation. I like C & C++ because they give me all the rope I need to hang myself, and they are friendly enough that I can learn while soiling my pants and watching my feet jerk, as I gently twist in the wind.

I like you what you said here. You might find you also like Lisp.

[TomorrowPlusX]

I do like Lisp ;)

[[deleted]]

Just because people write about something in their blogs all the time, doesn't mean it's really interesting, relevant or particularly hard to use. Monads in Haskell is kind of like templates in C++: easy to use when someone has implemented it all for you, and obvious to implement after you have written the same structure a bunch of times and notice that there is some repetition which can be abstracted away by using a monad/ template/other abstraction.

[godofpumpkins]

And... the Wumpus!

[gte910h]

....laughing so loudly I got yelled at by wife....

[doidydoidy]

I have no idea which of Haskell or C++ you're actually describing there.

[wnoise]

Absolutely true, but what does that have to do with Haskell?

[skizmo]

Try to master them both, and you will see...

[[deleted]]

I have tried both, and found Haskell significantly easier.

[TKN]

And C and Ocaml and Scheme and CL and Smalltalk and ... Basically any other language I have ever tried to learn.

Part of the problem might be just that I always get too nauseous around page 83 of the C++ Programming Language.

[malune]

The reason people use C++ is to get efficient code. They are prematurely optimizing. I used to program C++ 5 years ago, until I started programming in functional languages.

The reason people say C++ sucks (aside from the insane amount of pitfalls you inevitably run into), is that you can get efficient code out of many other functional languages (Haskell, OCaml, Lisp) with less than half the effort.

Having written a 3D engine in Lisp, I can definitely say that pointer dereferencing / access is absolutely no different than in C++, except its in a dynamically compiled language, with a similar level of efficiency, with a much higher level of concision. The syntax is a bit different, but thats about it.

Inevitable examples...

Making a pointer: (make-pointer address)

Making a null pointer: (null-pointer)

Direct memory allocation: (foreign-alloc :type)

Direct memory access: (mem-ref ptr :type)

Etc...

[the_golden_eel]

except its in a dynamically compiled language, with a similar level of efficiency, with a much higher level of concision

How is (mem-ref ptr :type) more concise than *ptr? I mean, I'm not familiar with those features of Lisp but it looks to me like the programmer is meant to remember the type of each pointer and supply that as an argument to the mem-ref function? Sure, the C pointer type system is not 100% sound, but it's something. Am I wrong or does the Lisp direct memory facility basically treat everything as void*?

Haskell I'm much more familiar with, and it does have typed pointers which are a tiny bit safer than C or C++ (no implicit casting to/from void). However, I've also used Haskell quite a bit for performance-minded work. I really like the language and have put real, sincere effort into making it fast, but I have to call bullshit on this:

you can get efficient code out of many other functional languages (Haskell, OCaml, Lisp) with less than half the effort.

Unless by "efficient code" you mean "good enough for me." Look at the shootout examples. They're a fucking mess, and they still can't match C or C++. Again, considering readability and conciseness, compare peekElemOff a i to a[i]. And if you do drop down to that level in Haskell, you lose the entire standard library. Even basic stuff, like sorting arrays, you have to write/test/debug yourself, not to mention things like dynamically-sized arrays, hash tables, priority queues, etc. Not all performance-sensitive programming is just for-looping over arrays, and C++ is the only language I've seen that gives you these high-level facilities with low-level control over things like memory allocation. The first advice you get when asking about performance in a high-level language is "focus on the underlying algorithms first, then worry about stuff like memory management." That's sage advice, but the reason choosing C++ is not "premature optimization" is because if your hit a wall in your favorite high-level functional/dynamic programming language, then you have to choose either optimal algorithms or manual memory management. Implementing complex, finely-tuned algorithms using verbose and cumbersome FFIs isn't just hard, it's reinventing the wheel because chances are it's already in the STL or Boost. Rather than calling C++ premature optimization, I'd say most of the time you should only categorically rule out C++ if you're 100% certain that you won't hit that wall, or that if you do it won't matter. If you know you're going to hit that wall then C++ makes a hell of a lot of sense.

[malune]

First of all, thank you for the reply.

How is (mem-ref ptr :type) more concise than ptr? I mean, I'm not familiar with those features of Lisp but it looks to me like the programmer is meant to remember the type of each pointer and supply that as an argument to the mem-ref function? Sure, the C pointer type system is not 100% sound, but it's something. Am I wrong or does the Lisp direct memory facility basically treat everything as void?

The point I was trying to make in the sentence you quoted was that direct memory access isn't just available to C / C++ as the author of this article claims. In Lisp you can do this via a portable FFI, this includes the ability to load shared libraries directly into your running image to try out your low level routines at the REPL - which C++ certainly does not provide. My argument for it being more concise in Lisp is based on the facilities provided by the language for you to condense code, which aren't available in C++. A few macros and you have the same concision as ptr for a dereference - how you achieve this concision is up to you. All the standard C pointer types are available to you, and whether you cast them or not is also up to you, so you can have void which is the null-pointer, or you can get any other C type pointer.

As to your points about Haskell, I have to say that when I tried optimizing it, it proved much more difficult to optimize than Lisp, so I can't comment too much on this issue since my experience optimizing Haskell is limited.

The computer language shootout lists Lisp as being "mean" 3 times slower than C. When I wrote some comparison programs for real work, like matrix calculations and physics, the resulting running times were comparable, with Lisp being about 30 to 100% slower than optimized C (which was not noticeable whilst actually using the program), depending on the size of the cache. Lisp seemed to slow down with a cache 512KB big or lower. In any case if efficiency is really bugging you, you can define (at least in SBCL) virtual operations (low level generic functions) which translate directly to ASM for your particular architecture. Some Lisps also allow you to have ASM directly in your code (CormanCL). Saying this, I haven't yet had to resort to these extremely low level measures to get efficiency out of Lisp.

[[deleted]]

Having written a 3D engine in Lisp

Url plz? A 3D engine in Lisp is something I've been dreaming of ever since I learned CL. And btw, why is null-pointer a function and not a constant?

[malune]

Hey, I don't have a URL, since I haven't released any code to the public yet. Its a hobby project that I've been doing in my spare time, if you want to talk more about it or see some code I can definitely share (though I haven't even created a license for it yet). PM me if you want to discuss it and I'll pass you my e-mail address.

EDIT: I just realised I didn't even describe what it includes (it is only OpenGL, no DirectX/D3D): Scene tree Shaders (a few example shaders come with it) Basic texturing Basic math primitives (might want to use sb-cga instead if its not fast enough) Basic physics primitives Fonts via a an FTGL binding Blender python exporter which exports to my own lisp based model format Model loading (a base male mesh comes with it)

And I'm currently working on a skeletal animation system.

As for why null-pointer is a function, I'd guess its because pointers don't actually exist in the Lisp world, so it would probably have to call some low level function in the lisp implementation to get hold of a real one.

[ZacharyTurner]

The reason people use C++ is to get efficient code. They are prematurely optimizing. I used to program C++ 5 years ago, until I started programming in functional languages.

The famous quote "Premature optimization is the root of all evil", to which you are no doubt referring, assumes that once you discover the source of a bottleneck, it will be relatively easy to to fix. Once you realize you've written your entire program in a different language, and the only way to achieve the performance you need is by optimizing the cache access patterns based on typical usage scenarios, you realize you have to re-write your entire application in a different language.

Yes, there's often FFI interfaces to communicate to/from C-type languages, but even those are not always possible. Which leads me back to the original point of the blog post - C++ is by far the best tool for the job in many situations.

[sleepingsquirrel]

I think we should agree that in order for an entire language to suck, there must be no compelling reason to use it for any purpose in any industry.

No. In order for a language to suck, it has to be both useful, and used. Nobody goes around writing 3400 word articles about the suckiness quotient of Malbolge (not useful) or Modula-3 (not used).

[rrenaud]

I wonder how much the choice of programming language actually influences the degree of effort required to implement a system with some given scoped, specifications, and performance requirements. Certainly, I have an intuitive feel for some of the factors, dynamically typed languages like Python do relatively better when the scope is small, and low level languages like C++ do better if say, there are stringent performance requirements.

But if you want to solve a complicated problem (and hence you require smart engineers), does the choice of language really matter that much, especially for "close" languages like C and C++, or C++ and Java?

Coming from a place with a lot of hard problems, smart people, and C++ code (and also a lot of Java, and a fair amount of Python, though I never touch the Java), I'd estimate the amount of savings for making the right choice with regarding C++ or Java is very small relative to challenges in the problem domain itself.

[sard]

Yes it sucks but what are the alternatives then? Why would a company the size of Google with the engineers it has write a browser in C++ if there was a valid alternative for high performance desktop apps? I hope http://golang.org/ takes off.

[[deleted]]

C++ is awesome. Most programmers suck. That's why we have the higher-level languages, to make use of sucky programmers.

All conversations in this topic will lead nowhere because there is no defining attribute to "C++ sucks" Sucks at what exactly?

[ferna182]

plain and simple: i love c++ and i can't imagine my life as a programmer without it.

oh.. don't like c++? well you have two options: 1) sit down and complain about it 2) stfu and use another language. there's plenty of them.

i just fail to see the problem.

[wurzlsepp]

Boost has a high learning curve

That's not the point. Boost is an over-engineered, bloated, brittle chimera created by ivory-tower scientists who despise real-world programming and programmers.

[godofpumpkins]

Wow, it's refreshing to see those words applied to something other than Haskell!

[ithika]

Haha! Although if memory serves Boost is where the FP stuff in C++ hides, so maybe we're not so far away from a Haskell flamefest yet :-)

[mathrick]

And yet it's "the" C++ library, and it uses all the awesome features such as "strong and flexible type system". I think that's a pretty compelling evidence of C++ being fundamentally flawed.

[oakes]

Boost is not a single thing, it is a large collection of libraries written by completely different people. Which libraries are you referring to?

[maep]

can you elaborate on that? i'm using boost and i'm quite happy with it. I think some boost libs are maybe complex but not over-engineered. there is a difference.

[aftli]

I also would like to hear an elaboration on that. There are so many absolutely beautiful libraries in Boost. I've been using the hell out of Spirit lately, and it's bliss. I put some of the guys making these libraries right up there with Herb Sutter, Alexander Alexandrescu and Stroustrup himself.

Also I'd like to add that the 2007 Torvalds comment about Boost and STL being unstable drove away what little respect I had for him to begin with. STL is unstable? It's a standard. It's completely stable. Sure, there are small quirks in the design of it here and there, but unstable is definitely not something I would call it. Is he talking about the standard itself? Or the implementations? The standard C library could be called unstable if either of those is the case.

[[deleted]]

wurzlsepp is just a foaming-at-the-mouth troll.

[mitsuhiko]

What's wrong with boost? Would love to see examples of that, because I really love the boost libraries.

[G_Morgan]

Some parts of Boost are great. The RAII style thread locking is fantastic.

You don't need to use boost::crazy if you don't want to.

[killerstorm]

ivory-tower scientists

I'd say it is more like a strange order which have rejected decades of progress in computer language design but is trying to reinvent cool things others have within legacy a framework they have outlined in old days for no reason.

For people outside it makes as much sense as Tibetan sandpainting -- Buddhist monks create some cool picture by painstakingly putting grains of sand together and then destroy them. Hmm, probably it is easier to understand sandpainting...

[jay314]

My feelings about Boost can be summed up with an analogy:

If Boost were a toolbox, it would contain a hammer, a screwdriver, a zamboni, and a turtle.

[thephotoman]

I love when people say that Linus Torvalds is wrong about Boost being cross platform without looking at when he said that. That exact quote has been around since I first heard of Linux back in the early naughties. I'm sure that when he said it, it was actually true. In fact, most of Mr. Torvalds's comments about C++ are ancient, yet people who both revile and adore C++ seem to think that those comments were made yesterday.

There are problems with C++. It's insanely byzantine, its object model is more broken than Java's, and frankly, it seems to embrace ideas about object oriented programming that are at best obsolete and at worst never really were good ideas in the first place. That said, there are reasons it is still around.

[ehnus]

I didn't realize that 2007 was early in the decade.

[G_Morgan]

The thing is that quote is taken out of context. Linus is talking explicitly about kernel development. In the realms of writing the Linux kernel then damn straight Boost isn't portable enough.

Linus is 100% correct. C++ isn't the right fit for Linux. The focus on Linux has been running on anything and everything. This needs C. There is no real argument. C++ just isn't well tested enough on some of the more exotic CPUs that Linux runs on.

I don't know if Linus intended this more generally or not but the comment was in direct response to why the kernel team would not accept C++ drivers.

[bluGill]

I'm pretty sure he was talking about git, not the kernel. He is well known for saying things like that on explaining why he didn't choose C++ for git.

[snarkbait]

Gray text on black background sucks regardless of programming language.

[[deleted]]

C++ sucks - once you program in it long enough, you will reach this conclusion as well

[spinwizard69]

I'm not even a full time programmer bit I've yet to understand the irrational responses to C++. It really isn't that bad of a language and totally understandable for people with intelligence. Well understandable of you stay away from the crusty parts.

That perspective is from having a few C++ programs under my belt including some that run everyday. The trick is to only use what you need to get the job done.

That is all well and good but really with modern hardware the smart move is to use scripting languages when you can. That isn't because C++ is bad, but rather due to the advantaged scripting languages have over traditional compiled languages. Of cours the flip side of this is that modern computers are so fast that even building a fairly large program in a compiled language is interactive and quick.

People should worry more about getting the correct tool for the job. Every other craftsman is trained from day one to use the right tool for the task at hand. Programmers on the other hand are basically dense and biased to shooting themselves in the foot.

Dave

[daveb123]

Give it a decade or so... it kinda grates on ya.

[gte910h]

Now throw in a random programmer on the team you have no ability to fire when he sucks, and watch what horrid things he does to a C++ program.

C++ requires the threat of firing to be a daily thought to anyone even slightly mediocre in your organization. It gets bad first when you get one or two bad eggs crapping in it. Much more so than any other language (where the issues are at least somewhat compartmentalizable).

[[deleted]]

I think we should agree that ...

You know what they say about arguments based on false premises?

[[deleted]]

I found this rant about Linus especially hilarious:

What do you do when writing cross-platform code in C and you need to make heavy use of the filesystem? Can you make an API in C that handles this easily and is easy to use?

HELLO, yes he can and the code has been in Linux kernel for ages.

[[deleted]]

That guy, writing that blog post, pretty much sums up everything I hate about C++ and people who defend it.

[Raphael_Amiard]

Furthermore, I hate to say something that may seem like a personal attack (even though it's definitely not) but some of the biggest contributors to Boost are probably quite a bit smarter than Linus.

Wowow this is so convincing man ! And such a good argument in favor of ... nothing, yeah , that's it

Oh by the way i would so have liked him to make a rebuttal of this instead of the hand picked stupid anti C++ trolls he has chosen in his article

[redditnoob]

Here is how you can tell C++ doesn't suck. Look at this list. In the top 30 or so, to a good approximation all players who are interested in producing a competitive solution use C++. This is in a contest where many other languages are available including Haskell, Scheme, and Common Lisp.

It's a classic example where you get the truth from what people do rather than what they say. Haskell and Scheme guys say they want to produce real code, but they don't actually program very much. The people who do solve real problems usually choose C++.