Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

(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.

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++.

OT: Zed Shaw's Tir framework

Reply on news.ycombinator.com