Live data from Hacker News

C++ in Coders at Work

gigamonkeys.com

31–40 of 174 posts

Re: C++ in Coders at Work

#31
post #28

Earlier quoted context omitted.

Operator overloading all by itself is a source of plenty of headaches, in combination with multiple inheritance you can spend a good bit of time trying to find out what something should do before you can begin to figure out what it actually does. In most languages my preferred view in the debugger is the source code of the language, in C++ I almost always just looked at the assembly. It seemed the more 'clear' langua…

Is operator overloading in C++ really more complex than it should be, or did you just pay the inevitable price for dabbling in the black art of multiple inheritance? Anytime you say "in combination with multiple inheritance" you can't expect to get much sympathy ;-) C++ is definitely a language where you can get screwed by "clever" programmers who would rather be reading TC++PL than actually coding, but it's not so b…

There was a time when I made most of my income debugging other peoples programs, call it 'troubleshooter' or something like that.

It gives you an excellent overview of the various ways in which things can go wrong, and C++ figured quite prominently in the 'gotcha' department.

C has it's share of issues, double frees, failure to initialize (but most compilers catch that one nowadays), and stale pointers. With a good discipline you can work around those.

C++ can obscure the bugs in such a way that it takes you a long long time before you can 'nail' them. The biggest problem I have with the language is that the code tends to obscure what is going on at the machine level.

I guess that's a 'feature' too, but I prefer to have a more direct correspondence between program code and what goes on below the surface. That's a problem with OO in general by the way, and I think that this is part of what makes software so terribly inefficient these days.

Gigabytes of ram are barely enough to accomodate a single user os, it's really pretty weird.

Re: C++ in Coders at Work

#32
Its really fascinating to me. We had Lisp and then the road for many lead to C/C++, Java, and related and then we needed a way to express data in more human-readable form so some genius came up with XML. XML was to cumbersome (close tags, how attributes are expressed, etc.) and then JSON came into the picture. So all that to just come back to where we were in the first place.

Now I clearly understand what some of the veterans in "Coders at Work" really meant by "Very little progress, if any, has been made in the Programming space".

Re: C++ in Coders at Work

#33
post #21

Earlier quoted context omitted.

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. Also, they make fairly specific criticisms, and they have a track record of being right about such things. Java seems to be the C++ replacement of the future, with C# pulling the other way.

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. And while they're busy bitching and hating and pontificating, humble unknowns are getting things done and making the world a better place. C++ is to systems programming what PHP is to web programming: the loyal packhorse that the A-list wouldn't be seen dead on.

I completely agree. While C++ certainly isn't perfect, those of us that write real code that is used and maintained day to day can be very productive.

While I know who most of the people in the article are and respect their contributions to the world of software engineering, day to day real world pressures of delivery aren't the same as an example in a book.

A hammer isn't an elegant tool, but it gets the nail into the wood.

Re: C++ in Coders at Work

#34
post #21

Earlier quoted context omitted.

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. And while they're busy bitching and hating and pontificating, humble unknowns are getting things done and making the world a better place. C++ is to systems programming what PHP is to web programming: the loyal packhorse that the A-list wouldn't be seen dead on.

That is very true. PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. I think this is in part why the web is so disruptive, because it enables all these upstarts using very light and nimble stuff to challenge the big and established companies directly. You can pretty much tell what is enterprise stuf…

PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment.

Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java.

It is kind of weird, actually -- Java for stuff like the HR apps, and Perl for the stuff that makes us money. (If it were my decision, I would use Perl for the web apps and Haskell for the algorithmic stuff... but it's not.)

Re: C++ in Coders at Work

#35
post #26
post #5

Part of how C++ is successful is that it retains C compatibility, and C accurately models how the computer actually works (at least computers of the 70s and 80s, which is all we know how to program well). Lovely languages like lisp, python, haskell may be nicer to work with, but they do not model the underlying machine properly, and for so many problem domains that is just not acceptable. It's not just a performance…

> C accurately models how the computer actually works i don't even know on what kind of hardware my java or python programs run. neither google (appengine) nor our IT apartment tell me. so for most app developers "a computer" is not really something they work with. of course someone must write those abstractions (python, etc), and they do it in C/C++ :)

The comment was probably referring to things like "copying stuff is expensive" or "function calls are expensive", not more specific details of the machine you run on. In C++ you use pointers/references to solve the first problem, and define header-only classes for the latter. Even if you weren't aware, basic use of the the standard library will clue you in.

Re: C++ in Coders at Work

#36
post #33
post #21

Earlier quoted context omitted.

Well, the 'everyone' he is talking about are some of the most respected people in the computer world, that should count for something. And while they're busy bitching and hating and pontificating, humble unknowns are getting things done and making the world a better place. C++ is to systems programming what PHP is to web programming: the loyal packhorse that the A-list wouldn't be seen dead on.

I completely agree. While C++ certainly isn't perfect, those of us that write real code that is used and maintained day to day can be very productive. While I know who most of the people in the article are and respect their contributions to the world of software engineering, day to day real world pressures of delivery aren't the same as an example in a book. A hammer isn't an elegant tool, but it gets the nail into t…

If you code in a 'safe' way and you stay away from nifty tricks then you are in good shape. I'm sure you have a little list of stuff that you should stay away from or that you would at least discourage.

The problems usually come when people start to use all those nifty features in combinations, especially 'newbie' programmers going wild on all that high level sugar.

C/C++ is performance wise also as good as unbeatable, if you know what you're doing, which is another reason why it has such staying power.

Re: C++ in Coders at Work

#37

Earlier quoted context omitted.

That is very true. PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. I think this is in part why the web is so disruptive, because it enables all these upstarts using very light and nimble stuff to challenge the big and established companies directly. You can pretty much tell what is enterprise stuf…

PHP, Python and perl are rarely seen at corporations that existed before the web came around. Their whole IT department is set up around a different kind of environment. Not sure if this is true in general. I work at a bank. We use a lot of Perl. Banks existed long before "the web", and our Perl stuff is not a web application either. All the internal web apps are Java. It is kind of weird, actually -- Java for stuff…

> We use a lot of Perl.

That's interesting! That's the last thing I would expect from a bank actually, wonder how common that is.

But then again, is there even an 'enterprise scripting language' ?

> All the internal web apps are Java.

That's what I would expect. Sun really did some good marketing in that sphere.

Re: C++ in Coders at Work

#38
post #5

Part of how C++ is successful is that it retains C compatibility, and C accurately models how the computer actually works (at least computers of the 70s and 80s, which is all we know how to program well). Lovely languages like lisp, python, haskell may be nicer to work with, but they do not model the underlying machine properly, and for so many problem domains that is just not acceptable. It's not just a performance…

I totally agree. C++ main strength lies in its "portable assembler" nature. However, C++ also is [quite a behemoth][1], while Lisp, Python and Haskell aren't so. [1]: http://yosefk.com/c++fqa/ The answer then is obvious : we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized. Then, these languages are easier and more practical.

Lisp, Python and Haskell should never ever be separated by a mere slash; they're totally different beasts.

Re: C++ in Coders at Work

#39
post #28

Earlier quoted context omitted.

Operator overloading all by itself is a source of plenty of headaches, in combination with multiple inheritance you can spend a good bit of time trying to find out what something should do before you can begin to figure out what it actually does. In most languages my preferred view in the debugger is the source code of the language, in C++ I almost always just looked at the assembly. It seemed the more 'clear' langua…

Is operator overloading in C++ really more complex than it should be, or did you just pay the inevitable price for dabbling in the black art of multiple inheritance? Anytime you say "in combination with multiple inheritance" you can't expect to get much sympathy ;-) C++ is definitely a language where you can get screwed by "clever" programmers who would rather be reading TC++PL than actually coding, but it's not so b…

Please, use a precise term if you talk about multiple inheritance, even though in this case it is clear that C++-MI is the multiple inheritance is meant.

In general, there is at least the linearizing (Common lisp) multiple inheritance with a well defined method lookup semantics (even though there are good ways to shoot one into the foot there), and the C++-local-hackity-multiple inheritance (where the programmer has to resolve lookup ambiguities, resulting in unpredictable semantics). And this even avoids the discussions of traits, mixins and such.

Re: C++ in Coders at Work

#40
post #30
post #12

Earlier quoted context omitted.

C is a portable assembler. Sometimes that's exactly what you want. C++ is C, except that it doesn't completely suck for higher-level projects.

LLVM IR [1] is portable assembler. C is "portable" in the sense that: a.) you get direct access to your linear address space b.) gcc targets so many instruction sets that you don't have to worry about your backend unless you have a custom platform. C++ is the thing that screams "__gxx_personality_v0" at me because I always start off using gcc instead of g++. [1]: http://llvm.org/docs/LangRef.html

Calling C portable assembler is not to be taken literally, but in context of its usage, which was for the most part systems level stuff that previously would have been written in assembler, requiring expensive ports between platforms.

C changed that dramatically and helped to cut down on porting effort tremendously.

Post reply on HN