Hacker News Reader

Comment by nostrademons | Hacker News Reader

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.

View on HN

In C++0x it is

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

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

ObjC can use both static and dynamic typing.

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.

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.

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.

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.

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

Reply on news.ycombinator.com