Comment by christianbryant | Hacker News Reader

Comment by christianbryant | Hacker News Reader

Parent Full thread

christianbryant

I'm sorry, but as a user and hacker of UNIX, POSIX and all things GNU/Linux since 1996 I have to say this is just fruitless and counter-productive. Although, I will support the sentiment "Death to C++" :-)

The argument is over-simplified and rather than looking to the root of the problem tries to sweep it under the rug by also ignoring the fact that many new languages have their interpreters written in C. The root issue is that the C language needs an update, an overhaul, and that once the standard has been refreshed, C will continue to be the #1 language among programmers.

Sadly, nothing can be done for C++ and to lump C and C++ together is as upsetting as calling for programmers to cease the use of C! :-)

Last thought: There needs to also be more focus on teaching programmers how to write secure C programs. Every year new exploits are released that target insecure C programming styles, and the C community should make sure programmers are being educated on how to avoid these issues. Look to subsets like MISRA C as an example and a move in the right direction; advocating secure programming/language subsets rather than changing languages ultimately makes more sense.

If you are a c leaning c++ hater, as I used to be, I would encourage you to look at some of the more recent techniques and standards in depth. Some examples I can probably not do justice towards in a short post: stl giving you inline-able data structures, functors (and now lambdas) giving you inline-able callbacks, raii for making C's "goto cleanup block" idiom more automatic, rvalue references getting rid of a lot of the unnecessary copies of "old" c++.

There are a lot of warts in the language and a lot of people in the community writing bad code. But there is a good language emerging, and plenty for low-level hackers to appreciate.

As a hacker rather than programmer, I am pretty much stuck on the C train, so any distaste for C++ is reactionary and not borne of actual programming experience :-)

However, I have noted in my career that almost every package I regularly use and have to do something with at the build level is written in C (or Lisp). However, I do know of one project written in C++ that I respect and does great things, and that is GNU Octave.

Lambda expressions in the STL... Go figure!

I mean it when I say look into the topics in depth. Lambdas are done in a more machine code efficient way than anything else I have seen. It is basically just syntax for a functor, whose calls can be inlined right inside the callee.

Stl is similarly elegant from the narrow perspective of inlining, and getting rid of indirection that people tend to write when doing abstract data types in C. It took me a long time of hating C++ and preferring C before I was willing to see this. I still kind of prefer C but these days I am much more willing to concede that there are strengths in C++ that you can't easily match with equivalent C code.

Even though I don't program for a living, I like experimenting with code, especially when tasked to build languages I haven't tried. I will look into these aspects of C++ - learning is a lifelong process :-)

> As a hacker rather than programmer, I am pretty much stuck on the C train, so any distaste for C++ is reactionary and not borne of actual programming experience

Please; "hacker" does not mean "inexperienced amateur", as you seem to imply it means here. The typical meaning is close to the opposite:

http://www.catb.org/jargon/html/H/hacker.html

As to C++, it has undeniable positives as well as undeniable negatives (according to plenty of experienced professionals).

I wasn't implying that meaning in the slightest. Just establishing that I am not a trained programmer nor a computer scientist. Poorly composed turn of phrase, I guess.

And yet when I correct your terminology with a cited reference, I collect a couple of downvotes.

This is why it is unpleasant to correct objective errors on the internet.

That's not right. In fact, I learned a great deal from this exchange, did some reading and referenced more folks who feel the same as you. Up vote from me - I appreciate it.

Glad you learned, and thank you.

My experience with downvotes here is that all sorts of rational thought is unpopular with HN readers. They want you to be young, clueless, passive-aggressive and false-modest like them, and they are threatened when you are not displaying these traits. Take the downvotes as a badge of honor and don't get too caught up.

This is the 2nd post about Rust on HN lately that has brought to mind that the next evolution of CPython, the one that deals with the Python2/3 rift should be written in Rust.

MISRA is a bloated mess from the accounts I've seen, no doubt to encourage paying for it. If u remove all the filler and padding the substantial part may be 40 rules.

There should be a new C that obviates the substantial parts of MISRA.

In my experience, the major problem with standards like MISRA is that people read the rules, but rarely the rationale behind them, which makes every coding standard end up encouraging cargo cult bug avoidance.

Case in point: MISRA C forbids goto statements primarily because it can mess up static analysis. Yet this rule is gratuitously followed even when no static analysis tools are used, thus yielding none of the gains that you trade off for occasionally writing ugly code.

The intent with standards like MISRA C is actually to be a reference point against which certifiable audits can cite companies for infractions. That is, the standard is no good as you note, unless a desired industry certification is only attainable for a company if an audit demonstrates the programmers are indeed following the rules.

Otherwise, you're right. The value goes out the window without enforcement, without compliance.

Absolutely. If you're audited for MISRA compliance, you need to follow it point by point.

The rules themselves are not meaningless or without a point, but there are a lot of companies that adopt MISRA without actually having (in the sense of audit and certification) to be compliant. Instead of focusing on the point of every provision, they rigidly follow them even when not applicable.

But it can be worse, really. The gem of a coding standard we have at $work forbids not only goto, but also break, without MISRA's exception of one break per loop. And forbidding the use of goto and continue is cited as being done for readability reasons, rather than static analysis tools.

I absolutely agree. I worked with MISRA C back in 2001. I point to that as a move in the right direction, but not the solution. C must be revamped and ideally a number of subsets will then disappear.

Reply on news.ycombinator.com