Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ in Coders at Work

gigamonkeys.com

Post reply on HN
Print view View original

41–50 of 174 posts

Re: C++ in Coders at Work

#41

Post by coliveira »

loup-vaillant wrote: post #25
Oxryly wrote: 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.

No, C is a portable assembler. C++ was created to add "high level" OO features to C. But the success of the effort is highly controversial, because there are differences between C and the OO model that are too difficult to overcome.

I think the strategy of objective-C is much cleaner, since they better separate the concerns of "writing fast code" and "writing high level OO abstractions".

Re: C++ in Coders at Work

#42

Post by jimbokun »

loup-vaillant wrote: post #25
Oxryly wrote: 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.

"we should change the hardware, so it is not C/C++ optimized, but Lisp/Python/Haskell optimized."

http://en.wikipedia.org/wiki/Lisp_machine

Re: C++ in Coders at Work

#43

Post by haberman »

alrex021 wrote: post #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…

JSON is not a programming language.

Re: C++ in Coders at Work

#44

Post by psranga »

There are parts of all languages that I find confusing, but I'm a little puzzled by the general criticism of C++ (e.g., the __getitem__ feature of Python seems to be similar in spirit to operator overloading. Do people criticize Python too?).

IMHO, C++ is an amazing extension to C which managed to increase productivity for those tasks for which C would have been the right choice (modulo non-standard compilers).

If I were writing a performance-critical system-level program today, using C++ would be no brainer. You can fake a lot of what C++ offers with macros and function pointers in C, but lose type-safety and/or performance. I am very thankful to all the people who have brought C++ to the state it is in today.

Re: C++ in Coders at Work

#45

Post by coliveira »

timr wrote: post #9

This is a disappointingly flamey article: roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days (which were admittedly horrible, but long since past). Most of the rest are from people who just skipped straight to Java, or who are so young that they never had to learn C++ at all. The comments that really drop my jaw are the people who seem to hold up Java as a…

The problem with C++ is not just bad implementation. Nowadays we have excellent, standard-compliant compilers for C++ but there are still rough edges. For example, the amount of garbage you get from template errors. You can "learn" to live with that, but it is something broken in the language, which won't be solved quickly. The amount of care you need to to write correct exception-based programs is another. And the failure of exceptions on method signatures show how we should really avoid some of C++ features.

Re: C++ in Coders at Work

#46

Post by mbrubeck »

dkarl wrote: post #28
jacquesm wrote: post #22

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…

Operator overloading in C++ is indeed more complex than it should be, thanks in part to the three different ways to pass paremeters (references, pointers, and values). It's definitely more straightforward in languages like C# or Python (or, well, just about anything else) that don't have these explicit distinctions.

Re: C++ in Coders at Work

#47

Post by dkarl »

tetha wrote: post #39
dkarl wrote: post #28

Earlier quoted context omitted.

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…

Different problem, different constraints, different solution. And, inevitably, just different ways to shoot yourself in the foot. Please explain how Common Lisp multiple inheritance relates to the question at hand, which is whether the complexity of C++ came from undisciplined language design or was inevitable given the design constraints of the language.

Re: C++ in Coders at Work

#48

Post by icefox »

timr wrote: post #9

This is a disappointingly flamey article: roughly 90% of the comments are from people who got a bad impression of C++ during the pre-standardization days (which were admittedly horrible, but long since past). Most of the rest are from people who just skipped straight to Java, or who are so young that they never had to learn C++ at all. The comments that really drop my jaw are the people who seem to hold up Java as a…

I would have to agree. I have no doubt that anyone in the early days of C++ probably had a real bad experience and was right to tell people not to use it at that time.

I personally still use C++ because of the libraries and tools. With Boost, Qt, WebKit, valgrind, gdb, and others I am simply too productive in C++.

If someone told me I could only use the c++ standard library and no other libraries I could probably switch languages pretty quick. I can only imagine what it must have been like before when you got nothing.

Re: C++ in Coders at Work

#49

Post by jimbokun »

jacquesm wrote: post #31
dkarl wrote: post #28

Earlier quoted context omitted.

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 d…

"The biggest problem I have with the language is that the code tends to obscure what is going on at the machine level."

Which totally defeats the purpose of being backward compatible with C.

Re: C++ in Coders at Work

#50

Post by coliveira »

jacquesm wrote: post #8
cturner wrote: post #2

Have there been experiments with creating a pre-compiler that checked that you were using a subset of C++? What downsides would this have (other than longer compile time)?

But which subset ? When I program in C++ (and sometimes you have to) there are features that I'll avoid like the plague, once bitten, twice shy. In fact, my subset of C++ was usually try to stay as close as you can to C and use C++ when you have to. That seemed to be a pretty safe route. Most of my C++ stuff was using Borland C++ Builder or Microsoft visual C++, I'm happy to say I no longer have to support software f…

I try to stay as close to C as possible. But C++ has many temptations. If you start using boost, for example, you will be in no time using features of C++ that are not even in the standard yet :-))
Post reply on HN