Hacker News Reader

Comment by steve8918 | Hacker News Reader

I disagree that it has anything to do with the language.

For example, I just recently started using Boost. Holy smokes, it is BEAUTIFUL, at least the parts that I've used. It just works. I've never worked with a library where I look at the example, make a guess as to how it should work, and it just works. On the other hand, the company I work at uses Boost in a completely illegible, unmaintainable way. It has nothing to do with Boost, it's whoever uses it.

To say a language such as C++ is responsible for overly complicated interfaces is just plain dumb. It's not the language it's the implementer. I can take the same $200,000 violin as Joshua Bell and make horrendous sounds from it. It doesn't mean that the violin is a piece of crap, it just means that I have no idea how to play a violin.

View on HN

> To say a language such as C++ is responsible for overly complicated interfaces is just plain dumb.

I don't agree with this. C++ is a massive language that virtually nobody understand in full. As a result it makes it hard to know how to solve problems the best way, so people solve them the way that they learned to solve things which may not be how other people learned to solve things so what looks straightforward to one is a complicated mess to the other. And the worse part is, C++ is only getting bigger.

> I don't agree with this.

I also disagree.

> C++ is a massive language that virtually nobody understand in full.

A professor (expert in C++) told me that there is not even a formal standard of C++.

I believe C++ developers make things so complicated because C++ itself is complicated. They only know C++ and hence this is the natural way they think. They believe that C++ can solve every problem (which is true, as for almost every other language) and some of them are so arrogant to claim that C++ is above everything else and that they don't need anything else. The latter could also be true, but the problem is: Whoever knows only a hammer as a tool sees every problem as a nail :-)

When you are a C++ developer but also know Lisp, Python etc. then you will write your C++ code in a different way that uses better paradigms. They are provably superior because C++ itself is learning from them and copying features, see C+11: http://en.wikipedia.org/wiki/C%2B%2B11

Unfortunately the horrible syntax of C++ remains. It was extended from C to C++ in such a way that it still reflects the underlying von-Neumann architecture. That makes C++ code so performant. Functional languages are not so performant because they prefer power of expression over von-Neumann compatibility. But they are catching up, see ATS in http://shootout.alioth.debian.org/u64q/which-programming-lan...

A professor (expert in C++) told me that there is not even a formal standard of C++.

To be fair, I'm not sure if this was a PL person or a systems person so I'm not sure how they're using the word, but there aren't formal[1] standards for almost every programming language.

[1] http://en.wikipedia.org/wiki/Formal_specification

I've met lots of people who code C++, and advocate C++.

I've met lots of people who code Java, Ruby, etc and advocate those.

I've met very few people who've shipped one product using C++ and another using Java/whatever - but those who have? They advocate using C++ sparingly if it all.

Bottom line: if you goal is to have beautiful classical music in the background for your party, then you could hire Joshua Bell, you could spend years trying to become Joshua Bell, or you could buy a fucking iPod and move on to the next problem.

I'd argue a skilled polyglot developer probably wouldn't advocate using C/C++ until necessary, optimizing for development time. Later, as performance problems arise, it can simply be another tool to employ.

I have shipped products in C++ and Java and would definitely advocate C++ over Java in almost every situation. Java manages to be more verbose and less powerful at the same time. Then again I currently use Python mostly, so I guess I am using "whatever" but I do not think Java/whatever is a valid category.

Couldn't disagree more about Boost. There are simple, elegant parts of Boost, and then there are incredibly complicated parts of Boost. Some of those complex parts also happen to be powerful (like Boost graphs). Spirit is perhaps an example of a part of Boost that doesn't justify its prolixity; Boost::Function another, and a case where C++ is really what's to blame.

I disagree that it has anything to do with the language.

Right. I've seen people way over-complicate things in Smalltalk, and Smalltalk is tiny -- like 1/4th the size of Python.

What was their background?

When your first language you learned was C++ or Java then you tend to use the same programming strategies in other languages which probably don't fit at all.

It is not enough to know a language, you have to really KNOW it :-)

the title of the article is "why do C++ folks make things so complicated", not "Why does C++ make things so complicated"

Then the title should have been "Why do bad C++ programmers make things so complicated?" Good C++ programmers can make very complicated things extremely simple.

For example, I'm working on a program where I was trying to do a mass comparison of file names between 2 directories. Essentially, I wanted to get the intersection between two sets of strings. I wondered if there was something that already did this, and after a quick google search, lo and behold, there's an STL algo that handles this, set_intersection.

So in a single line of code, I was able to solve my program that would have taken me a lot more. It wasn't complicated at all, it was extremely simple.

and now you have two problems?

I'm not sure what your anecdote is really meant to prove? Doing set intersection is fairly trivial to implement, and the C++ std library comes with an implementation. The argument is that this claim doesn't scale up, which your anecdote does not address.

Well, the problem is that whenever I try to use any of this magical features it usually turns out that it either cannot do this one tiny detail which I desperately need, make me rewrite huge part of the code to do minor change or is a computational bottleneck because my use case was apparently not in use cases used to develop it.

Reply on news.ycombinator.com