The Dark Side of C++ [pdf] • Hacker News Board

Re: The Dark Side of C++ [pdf]

#31

Post by shin_lao » Tue, Aug 03, 2010, 7:12 AM UTC

silentbicycle wrote: post #30

ramy_d wrote: post #15

it's hard to take an article like this seriously - i just want to make 2 highlights. he started using C++ when the STL didn't exist yet. This is ancient IMO, so his section on ever-changing standard is moot to me. if he didn't want to maintain the code base, then he should have kept using an older compiler. second highlight, errors messages - Debugging is the first skill programmers (re)learn, so IMO it's a pretty im…

> To close this, everything he said in his "hard to read" could be applied to any languages with mutability. Really? I dare you to make Python code as hard to read. It has mutability, too. Hell, does C code have that same amount of overloading? The worst things C offers are function pointers and preprocessor hijinks* , while C++ proudly adds whole new categories of ways to make code hard to parse or reason about . (T…

C has got macros, so it can be very hard to read too.

Generators (http://docs.python.org/tutorial/classes.html#generators) in Python can make code very hard to read as well in "hiding" a lot of complexity inside the generation.

In other words, such code:

   r = f(param)

can be a lot of different things as well.

The enter/exit clauses hide a lot of code as well, although they should be used for (de)initialization they can be abused (I've seen it).

Finally, I think you should elaborate more when you say "for what the STL accomplishes, I'd rather just use OCaml" because I don't understand what it means and I know both languages (C++ much better, admittedly).

Re: The Dark Side of C++ [pdf]

#32

Post by silentbicycle » Tue, Aug 03, 2010, 12:40 PM UTC

shin_lao wrote: post #31

silentbicycle wrote: post #30

Earlier quoted context omitted.

> To close this, everything he said in his "hard to read" could be applied to any languages with mutability. Really? I dare you to make Python code as hard to read. It has mutability, too. Hell, does C code have that same amount of overloading? The worst things C offers are function pointers and preprocessor hijinks* , while C++ proudly adds whole new categories of ways to make code hard to parse or reason about . (T…

C has got macros, so it can be very hard to read too. Generators ( http://docs.python.org/tutorial/classes.html#generators ) in Python can make code very hard to read as well in "hiding" a lot of complexity inside the generation. In other words, such code: r = f(param) can be a lot of different things as well. The enter/exit clauses hide a lot of code as well, although they should be used for (de)initialization they…

I mentioned C macros already, and I don't think Python generators are a good example - used idiomatically, they usually made code easier to read, and Python's community imposes a fairly consistent style.

About OCaml - I much prefer its way of doing parametric data structures, functors, etc.

Re: The Dark Side of C++ [pdf]

#33

Post by ramy_d » Tue, Aug 03, 2010, 3:02 PM UTC

silentbicycle wrote: post #32

shin_lao wrote: post #31

Earlier quoted context omitted.

C has got macros, so it can be very hard to read too. Generators ( http://docs.python.org/tutorial/classes.html#generators ) in Python can make code very hard to read as well in "hiding" a lot of complexity inside the generation. In other words, such code: r = f(param) can be a lot of different things as well. The enter/exit clauses hide a lot of code as well, although they should be used for (de)initialization they…

I mentioned C macros already, and I don't think Python generators are a good example - used idiomatically, they usually made code easier to read, and Python's community imposes a fairly consistent style. About OCaml - I much prefer its way of doing parametric data structures, functors, etc.

so your argument is: my programming language's concepts make it easier to read as long as you use them correctly, and all of MY friends write the same way anyway so our language is SUPER easy to read.

breaking news: it's not. the problem with your argument is you're not c++ programmer, and you saw this post on hacker news and decided to come here tell us how much better whatever language you use is to C++.

you don't seem to consider that this language is the way it is for very specific reasons. I'm trying to say that this article is VERY poorly written with very biased opinions and refuses to look at the language as whole.

I'm not saying C++ is the EASIEST language to read, it's not. And his examples could have passed off as hard to read for ANY LANGAUGE. honestly? bar = foo(bla); like who the fuck writes like that anyway?

Readability is the trade off the C++ standards committee will always make because readability will come in the way of the things most important to the language (C compatibility, speed, high level functionality) but that doesn't mean you get to take a dump on your keyboard and click the send button.

if you don't understand the issues at stake then don't release you diatribe into the conversation. C++ isn't python, or C or Ruby nor is it supposed to be. just accept it.