Live data from Hacker News

C++: Is It Really a Cruel Joke? (2003)

webhome.phy.duke.edu

131–140 of 155 posts

Re: C++: Is It Really a Cruel Joke? (2003)

#131
post #76

Earlier quoted context omitted.

There are plenty of languages in use that people genuinely enjoy using [1]. A lot of complexity in languages tends to be completely incidental. It's often not inherent in the problem the language solves, and it's just a design decision somebody made based on their aesthetic and experience at the time. A lot of people seem to take pride in memorizing these quirks, but they're just that. There's nothing fundamentally i…

I can think of only two C++ "quirks" that meet the definition of "just mental clutter; nothing fundamentally interesting about them." 1. Nested templates closing brackets conflicting with `>>` operator, necessitating `> >`. This was fixed in C++ 11. 2. Syntax for declaring an automatic variable conflicts with the syntax for C function type: `Thing mything();`. Those two certainly seem to be "unforced errors" where th…

Honestly, I haven't used C++ in ages, and I believe you that there great rationalizations for a lot of its behaviors. That's beside the point in my mind though. The end result is a very large and complex language that's very error prone.

C++ goes completely against the principle of least astonishment.There is a huge amount of mental overhead to reading and writing code in it. All that distracts you from the problem you're actually solving and directly translates into long development times, defects, and maintainability nightmares.

I don't think the complexity of the language ultimately justifies the goals it's trying to accomplish.

Re: C++: Is It Really a Cruel Joke? (2003)

#132
post #45

I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..

You mentioned “compiled” without “…to native code”.

If that’s what you meant, C# fits quite well. The language is safe, very high-level but has easy ways to use C interop or pointer arithmetic, performance is adequate for many practical applications, asynchronous IO and multithreading are IMO best in the class, tons of libraries, good documentation, many users.

The main downside is limited options for cross-platform GUI. On windows it’s very good, on mobile platforms OK, for the rest of them (Linux esp. embedded, OSX) there’re no good options that I know of.

Another one is runtime size, current version is around 25-30 MB. No installation is required, but for some applications that’s still too much.

Re: C++: Is It Really a Cruel Joke? (2003)

#133
post #40

Dr. Stroustrup took a lot of pain to ensure the language was useful and did not break backward compatibility. He also always maintained that if you don't use a feature you shouldn't pay for it (in terms of performance). Eventually, it became even more popular and there is now a whole organisation behind the international standards for the language. The book "The Design and Evolution of C++" helps one understand why s…

If I had any real complaint about the execution of C++ it would probably just be the backwards compatibility with C. Don't get me wrong: I love C, and also I don't think it would've been possible for C++ to have gained so much relevance so fast had it not started as C with Classes. However, it does feel like a lot of kludges in C++ come from its legacy. Something that often confuses beginners is the sheer number of w…

That's why the sheer insanity of Objective C++ intrigues me.

I always speculated that Jobs went up to the engineers, "hey, we use a lot of Objective C in OS X, right?"

"Yes, sir, Mr. Jobs."

"Well, everyone else, namely Adobe, is using C++ and we need them writing apps for the Mac. We've gotta have those apps. So we're going to need to support that."

"Um, yes sir, Mr. Jobs, we'll get right on that."

He leaves, and they look around nervously. "He's pulling our leg, right?"

Re: C++: Is It Really a Cruel Joke? (2003)

#134

From the "interview" of "Stroustrup": > ... You know, when we had our first C++ compiler, at AT&T, I compiled 'Hello World', and couldn't believe the size of the executable. 2.1MB > Interviewer: What? Well, compilers have come a long way, since then. > Stroustrup: They have? Try it on the latest version of g++ - you won't get much change out of half a megabyte. So, for grins, I did, with the gcc7 port from macports,…

#include int main(){ printf("Hello World"); return 0; } >5649591 -rwxr-xr-x 1 user user 8288 Jul 5 21:49 a.out What am I doing wrong?

Did you use -O3 or some other optimizations?

Re: C++: Is It Really a Cruel Joke? (2003)

#135
post #130
post #105

Earlier quoted context omitted.

1) Specifically which of those C++ programs? Innuendo is not OK. 2) Even with cheating in scare quotes, name-calling is not OK.

It's not innuendo when you consider the inherent problems with benchmarks. Once you have an algorithm, it's so hard to define what an objective benchmark is that you should assume the implementation is cheating, even if you wrote it. I say this from personal experience; in one case I was doing timing studies to solve performance problems, and wound up fooling myself by measuring the wrong thing! In this case, is it f…

> …when you consider the inherent problems with benchmarks…

dralley's comment does not do that.

There's nothing difficult here: simply say that those X of N leading C++ programs use SIMD intrinsics, when the corresponding Rust programs do not.

dralley might even say that SIMD intrinsics have been available in Rust nightly for years.

dralley might even say that someone has contributed a Rust program that does use SIMD intrinsics, but that program was slower than other Rust programs:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Perhaps if C++ [or Rust] is providing SIMD intrinsics that is not in-itself a magical silver bullet.

Re: C++: Is It Really a Cruel Joke? (2003)

#136
post #94

Earlier quoted context omitted.

This is just my situation, but I gave up on Cython when I started moving forward with it (distributed graph algorithms). I found that I had more things to learn. With Nim, it took me half a day (after seeing the language for the first time) to get a basic numerical process going and another few days for distributed data communication involving messaging and postgres/mongo (Nim has a modern JavaScript (ES6) promise/as…

I find that strange, but I concede you know your use case better. I work on a very similar type of application that manages async workers who process large distributed NLP tasks. Writing it in Cython was extremely easy, because for the modules that have zero need for static typing, such as the part using async/await in Python 3, or when we supplement with gevent, I can just write those parts in plain Python and it’s…

Hi - thanks for outlining your case. My Cython know-how is limited to qualify any kind of comparison with Cython. Its just that my attempt with Nim went surprisingly smooth for me. Coming from some of the older languages I use and love, the reliability of the newer Nim is pleasing and coding is fun. I ended up eliminating all Python code from my back-end. Because Nim is statically compiled I can deploy pieces of it anywhere just like a compiled C program, without dependencies, and it means a lot in my particular situation.

Re: C++: Is It Really a Cruel Joke? (2003)

#138
post #47

Earlier quoted context omitted.

The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have…

> Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointe…

> string-to-hash map

string-to-int hash map

Re: C++: Is It Really a Cruel Joke? (2003)

#139
post #45

I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..

People often think of C++ as a Object Oriented Language. That's understandable, as it was the key feature back in the earliest days. OOP got hyped and over used. Now OOP is (almost) considered harmful in C++ community. If you look at modern C++ libraries (like boost), you will see a lot of templates and free functions, and not a lot of inheritance or dynamic polymorphism.

> If you look at modern C++ libraries (like boost), you will see a lot of templates and free functions,

I mean, people were already calling for more templates and free functions in 1997. It's not modern by any stretch of mind, it's just normal C++.

Post reply on HN