Hacker News Reader

Comment by tseabrooks | Hacker News Reader

My only real complaint about the nature of HN is the (as perceived by me) strong anti-C++ bent, like the ones in these comments, from what seems like people who don't have lots of experience using it in the work place. Am I imagining this anti-C++ bias? Am I wrong and all the people bashing C++ have tons of C++ experience?

I'll be the first to point out the numerous flaws C++ has but it just feels like folly to make fun of the ugly chick at the party without realizing everyone at the party is covered in warts... (The is a metaphor for all programming languages having problems)

View on HN

(I'm a recovering C++ dev).

C++ has problems unique to C++: a deceptive illusion of abstraction (what Spolsky would call "leaky" abstractions) makes a bunch of idioms in the language dangerous, including virtually all "smart" pointers, iterators, exceptions, allocators, and arrays. It is uniquely difficult to write reliable code in C++.

Add to that the superficial but more practical and common complaints against C++: the ghastly compile times, the header file dependency hell that forces every class into a kabuki dance of "pImpls" and nested classes, the error messages rendered in ancient Sumerian... you know I could go on, but you get the idea.

C++ is just not a very good language. C is a fine language. If you are building a system for which C's abstractions are inadequate --- and I'll stipulate that such systems exist --- you're better off with C and a very good glue language (Lisp and Lua are two good, popular choices) than you are with a uniform C++ implementation.

"C++ is a powerful language with flexible solutions to problems that other languages don't have."

"C++: An octopus formed by nailing extra legs to a dog"

> C++ is just not a very good language. C is a fine language.

This is the attitude that I really, truly do not get.

If I want a linked list or any other common data structure in C++, I include the appropriate STL header and declare an object with the template syntax. It's two easy lines of code. If I want a data structure in C, I have to write it myself. From scratch. Every time.

C++ is a powerful high-level language. C is a low-level language where everything is explicit; I know this is "elegant" to many programmers, but really, I'm just trying to get things done, and C++ has served me far better in that practical role than C ever could.

I don't love C++; it has tons of flaws (many of which disappear if you use shared_ptr for everything). But I loathe the tedium of working in C.

> If I want a data structure in C, I have to write it myself. From scratch. Every time.

http://library.gnome.org/devel/glib/2.28/ makes C development much more pleasant. You could make the same argument against C++ if you didn't have STL.

When C was invented, half of all coding was systems programming. C does a great job of addressing that need, that's why it's a fine language.

The fact that C is not great for GUI apps does not diminish C's quality for what it is, it's just not designed for that level of abstraction.

C++ on the other hand, attempts to be designed for that level of abstraction, and so in fact you are better off writing most types of modern apps in C++ than C in absolute terms, but when compared against other languages designed for the same paradigm it falls down due to complexity overload. That doesn't mean you can't do great work in C++, but you have to really know what you're doing, which parts to avoid, etc. C++'s strength is being both fast and powerful, but most of the time you don't really need both those qualities. Game programming is a notable exception.

The "which parts to avoid" conundrum shows up as every outfit that uses it in any serious way has a different set of "which parts to avoid".

It is just a mess.

The comparison isn't between straight-C vs. straight C++. It's between C with a good glue language (say, Python or Lua) vs. straight C++.

If I want a linked list in Python, I do:

  frobs = ['foo', 'bar', 'baz'].

The equivalent C++ is:

  vector<string> frobs;
  frobs.push_back("foo");
  frobs.push_back("bar");
  frobs.push_back("baz");

The reason people like these multi-language solutions is that Python or Lua is much, much more productive than C++ (as in, many times more productive), and yet the most programs have only a very small core that needs to run fast. You can write that small core in heavily-optimized C, making it quite a bit faster than kludged-together C++, and then write everything else in Python. And the total complexity of the system is still much less than if you'd just used C++ to start.

This is not a linked list, it's a dynamic array.

http://en.wikipedia.org/wiki/Linked_list#Linked_lists_vs._dy...

That's a pedantic comment to make, given that Python doesn't care about the difference. Ruby calls the same thing an "Array".

Well you've clearly never had to worry about memory paging and the cost of indirection, like I have (actually from memory I think you must have at some point?). The difference is real and significant. Try writing a particle system using a linked-list over a vector, the speed difference will be crippling. I really feel that most of the hatred for C++ stems from people not understanding why such complexity exists in the language.

The point is that you don't have to worry about the difference in Python, because you don't use Python for the parts where performance matters. If you've got a million instances in your collection, you probably want to write your data structure and key traversal functions in C. Python has a sequence protocol, so you can easily wrap it to operate on it just like a native list (which is really a vector), but the operations that need to be fast should be in heavily-optimized C.

In every system I've written, there's been a large chunk of code that runs on startup, or implements a feature that only 1% of users care about, or performs setup for one of these expensive operations but itself only touches a few data items. This usually consumes about 90% of the code but only about 1% of the runtime. Heck, probably 50% of my code never makes it to production at all, because it's exploratory or analysis code that's intended to define the problem, not implement the solution. Why not write it in a language that makes you really productive, and spend the time saved to optimize the hell out of the remaining 10%?

The performance difference between a vector and a list has nothing at all to do with what we're talking about. Stop picking random things in the discussion to nerd out about. We get it, you're awesome. The point is that in Python the distinction isn't made.

Python has a linked list type (collections.deque), but their standard list type is a dynamic array/vector and so has entirely different performance characteristics. Treating it as a linked list could screw you. I don't think that's pedantic at all.

...which is why both the Python and C++ examples used a vector.

The post I was replying to said "If I want a linked list or any other common data structure in C++". The discussion is about how easy it is to use basic data types, not about what those data types are.

No, it does. There's a type in Python called "deque" that more closely resembles the performance characteristics of a linked list.

I agree that this is not the main point of the discussion, though.

Noob here. Where does ObjC fit into all this? I know it's primarily used in Mac development, but is there any language-specific reason it's excluded from these debates?

Imagine the good high level language, like Lisp or Lua, stepped into the teleportation chamber from _The Fly_ with C.

It is not a terrible language to write in, once you get over the verbosity; it is not, for instance, the waking nightmare that C++ is. But as a deployed system it is the worst attributes of C and of interpreted languages: a complex runtime in which many (probably most) of the errors that can creep into deployable Ruby code can bite you even though your code passed both compilation and static analysis.

Its high-level constructs for the most part share the same reliability issues that C++ has; exceptions, for instance, are not really any safer there than in C++.

Blocks are nice, but I say that having only used them within the past few months. It could just be that the zombies haven't eaten their way to my particular shelter yet. They may, for instance, turn out to be horrible to debug.

Imagine a variant of C or C++ that you have to unit test as vigilantly as Rails code, and you're not far off the mark.

The retain/copy conventions are inconsistent for Blocks. But once you're aware of those, I haven't seen any major issues in using/debugging them.

C is a good statically-typed language, but it's a bit basic.

ObjC is a good statically-typed language.

C++ is half a dozen good statically-typed languages, all fighting for supremacy like a ham actor's "multiple-personality-disorder" shtick.

ObjC can use both static and dynamic typing.

ObjC isn't statically-typed. Static typing informations only allows the compiler to warn the programmer about type mismatch. From the official docs:

"Statically typed objects have the same internal data structures as objects declared to be of type id. The type doesn't affect the object; it affects only the amount of information given to the compiler about the object and the amount of information available to those reading the source code."

Objective-C is a good statically typed language? I must admit that this is new to me...

How exactly is Obj-C "good"? Is it safer than C? Perhaps less verbose? Or maybe it's easier to use - libraries aside? Is it better because it runs on more platforms? Because it's standardized?

If all else fails, I think it must be the way that it manages to merge two completely different programming paradigms by just stapling them one onto the other.

In C++0x it is

    std::vector<std::string>> frobs = {"foo","bar","baz"};

> The comparison isn't between straight-C vs. straight C++. It's between C with a good glue language (say, Python or Lua) vs. straight C++.

You can use several glue languages with C++ rather more easily and powerfully than C. See chaiscriptor QTScript. Also luabind and perl and python C++ bindings. Introducing scripting glue languages into the equation only further strengthens C++'s advantages.

> The equivalent C++ is:

The new initializer syntax is widely supported enough now. You can write:

std::vector<std::string> frobs {"foo", "bar", "baz"};

And even if you don't have a newer compiler you can use boost assign. http://www.boost.org/doc/libs/1_46_0/libs/assign/doc/index.h...

Everybody here knows you can bind to C++ instead of C. What they're saying is, if you have Lua or Python, C is virtually certain to be enough; the higher-level architecture/object graph stuff is better dealt with in Python anyways.

This claim sure doesn't jive to me. I got a simulation that does millions of GIS calculations involving entity tracks and regions. Moving the object graph into Perl or Python would take six hour runtimes into weeks. And writing it in C would be sheer torture.

Perhaps, but I don't think the situation would be as awful as you suggest.

It is possible to write significant revenue-producing commercial software using Lua for control logic calling compiled modules, and expect it to perform every bit as fast as a similar app written 100% in a compiled language.

I'm surprised no one has mentioned Lightroom yet.

http://www.sauria.com/blog/2008/10/09/lua-in-lightroom/ http://en.wikipedia.org/wiki/Adobe_Lightroom

Umm, I regularly do what you described (glue language + low-level language) with C++ and Tcl. This is more productive than C and glue language.

I absolutely LOVE not having to reinvent wheels like hash tables. Recently, boost added an interval data structure. I just wrote a few lines to expose those functions as Tcl commands. Whammo, I could prototype all I wanted in Tcl!

Good C programmers also do not reinvent the hash table wheel.

Yes, but each programmer has his own hash table wheel, which is most probably an undocumented, unholy mess of #defines, void*'s and function pointers.

Is it still a glue language if you have more glue than material? :P

I also find it very hard to believe that using two programming languages can be easier than using one. This affects team core skills, build systems, testing, debugging(!)... pretty much everything is the more complicated the more languages you use.

If you have more glue than material, you're doing it right. Most projects are like that - that's the whole reason you're using a scripting language, so you can get the productivity benefits for the ~90% that doesn't need to be performance critical.

And it's true that the more languages you use, the more complicated things become - but C++ itself is really at least 4 languages glued together (C, object-oriented C++, template metaprogramming C++, and the STL; citation: "Effective C++") and they often don't play well together, so switching down to Python + C, you cut that in half.

STL is great. I like STL so much that, after moving from my startup (where we did C++) to a friend's (where it was all C), I backported a void*-specialized version of STLport's <map> and <vector> libraries. It took a couple hours. The pain of C++ isn't worth the benefit of the STL; fortunately, you don't have to suffer C++ to get access to its better libraries.

It is flat-out not true that you need to write data structures in C each time you use them. The programmers that do this are, in my limited experience, uniformly bad. I wouldn't even write a linked-list for fear of screwing up a corner case on deletion. There are libraries for everything, and they're plenty fast. They're just less pretty looking.

Assuming you can use STL. Many projects can't use STL because of its reliance on C++ exceptions (cf. Mozilla or Google's C++ style guides). If your legacy code or some third-party library is not exception-safe, then you can't create reliable C++ software using the STL.

OT: Zed Shaw's Tir framework

C was a great language when it was created, considering the requirements and constraints of that time. In 2011, it is unexcusably unsafe and lacking in abstraction power - C99 included.

Almost every type of operation in C is predisposed to HUMAN error (the worst kind of error) - I/O, strings, creating a data structure, declaring a variable, calling a function even basic maths can fail in unintuitive ways. [1]

No matter how many glue languages you use, C is not going to become safer or easier to use. Furthermore, C's abstractions are inadequate for most things, even the things that it's traditionally known for,such as the Linux kernel. Take a look and see how many wheels have had to be reinvented for the kernel or any large C project.

But... you probably already know all of this. It's just that you're so comfortable with it that you're willing to forgive all of its sins.

[1] https://www.securecoding.cert.org/confluence/display/seccode...

We're not discussing C vs. Lisp. We're discussing C vs. C++.

Besides tptacek's reply, see also Yossi Kreinin's C++ FQA (Frequently Questioned Answers):

http://yosefk.com/c++fqa/faq.html

Subjectively I don't feel HN as particularly anti-C++, it's more that people are younger and started programming in languages like Python and Ruby so they don't have a pro-C++ bias. If anything I feel that many people on HN are anti-Java. Personally I'm thankful for Java's existence because it managed to replace C++ in a lot of places.

The C++ FQA is pretty impressive in its detailed and thorough dislike for C++. I'm not sure if I know of anything else quite like it in that regard. The only thing that comes to mind as being close is the UNIX-HATERS Handbook.

The Unix Haters really liked Unix; the book was an act of love. Yossi clearly wants to stab C++ in the eyeball with a fork.

Sure, but the original commenter wondered whether people who dislike C++ know C++ well. Yossi no doubt knows C++ pretty well.

I take it that you haven't actually read the Unix Haters handbook. They clearly have no love for Unix.

"Each graft of a new subsystem onto the underlying core has resulted in either rejection or graft vs. host disease with its concomitant proliferation of incapacitating scar tissue. The Unix networking model is a cacophonous Babel of Unreliability that quadrupled the size of Unix’s famed compact kernel. Its window system inherited the cryptic unfriendliness of its character-based interface, while at the same time realized new ways to bring fast computers to a crawl. Its new system administration tools take more time to use than they save. Its mailer makes the U.S. Postal Service look positively stellar."

Yeah, you're right, now that I think about it, they were definitely all Win32 people. <groans>

Seriously, can you give me any example of their love of Unix. They strongly preferred Lisp machines. Please don't make up random "facts".

It is irritating to find false statements being upvoted just because noone bothers to double check them.

Yes, the whole labor of hate argument was discussed in the foreword (written by Donald Norman):

“Sure, we love your foreword,” they told me, but “The only truly irksome part is the ‘c’mon, you really love it.’ No. Really. We really do hate it. And don’t give me that ‘you deny it—y’see, that proves it’ stuff.”

Norman remains suspicious, but the preface claims: "We have all experienced much more advanced, usable, and elegant systems than Unix ever was, or ever can be."

Personally, I imagine for many of the participants, it was a labor of hate, not of love. We could chalk up any ambiguous love to Stockholm Syndrome.

Ritchie's anti-forward is the best:

I have succumbed to the temptation you offered in your preface: I do write you off as envious malcontents and romantic keepers of memories. The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.

Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome.

...

You claim to seek progress, but you succeed mainly in whining.

Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.

I know multiple people who contributed to the book personally. I think you're missing part of the joke. But I concede, I don't know all or even most of them, so perhaps many of the Unix-haters secretly do pine for Mac OS 9.

First you claim, apparently the book was an act of love, which it clearly isn't. It is as scathing as the C++ FQA. The book has a dozen authors from respected institutions and you claim to know people who contributed to the book personally but the only apparent alternative OSes you think they could have used are Windows and OS 9. I don't have too much data right now, but it certainly looks like you are making "facts" up as you go along.

I think it is very unlikely that I am making anything up as I go along to impress an anonymous stranger on Hacker News, but you can of course think whatever you'd like.

With a tiny team of very smart programmers, starting from scratch, C++ can certainly be made to work.

I wrote a web server in C from first principles back in 2001* for many of the same reasons that OKCupid seem to have done - and with a team of one good programmer that worked out really well.

* http://web.archive.org/web/20070705191513/http://www.annexia...

My strong anti-C++ bent comes from having used in in demanding production situations for 12 years. It is a beast. When Scott Meyers of http://www.amazon.com/Effective-Specific-Addison-Wesley-Prof... fame reads a book on C++ template programming and is surprised, no, astonished! at some of the things done there, and attempts to write auto_ptr and fails at least twice.

It takes way to long to learn (probably 2 years for a developer working with it 8 hours a day), and the grown ups don't like it either: http://www.amazon.com/Coders-Work-Reflections-Craft-Programm...

This isn't even an ugly chick.

There are anti-C++ bias in HN. More people here are working on the Web related projects where C++ is not popular.

  If you are an expert in the intricacies of C++, please
  consider this knowledge a kind of martial art - something
  a real master never uses.

http://yosefk.com/c++fqa/why.html

Just saying that this thread has been fascinating and illuminating for a novice C++/C programmer like myself. It reads like a decent article comparing the two languages, though I'm no expert and can't judge for sure.

This is why I read HN.

C++'s reputation was negatively affected by Microsoft's studied dominance of university CS curricula. Back in the VB days C++ was the step up and I still see it in job ads on par with Java (Sun's side of the curriculum equation), though by now I merely read it as a veiled call for university graduates who learned programming only in school, coderbots.

"Coderbots" - Why be so derogatory? There's no need to be. Who knows, maybe someday you will meet someone who only learned programming in school who is faster than you.

There's more to writing code than writing it fast.

Oh, there are lots and lots of people faster than me! My use of the term is more in line with how they were used rather than anything having to do with the core of their being.

Negative. C++ had the reputation of "computer science educated" back when the average CS grad could barely spell Microsoft.

Rather than "Microsoft ruined everything", nearly the entire commercial software industry standardized on C++, and entry-level "coderbots" was who they wanted to hire out of school.

C++ lost its sex-appeal because its simply more interesting to do web startup things than to be a junior coder at Big Software Inc.

Reply on news.ycombinator.com