Live data from Hacker News

Talking to C Programmers about C++ [video]

youtube.com

41–50 of 128 posts

Re: Talking to C Programmers about C++ [video]

#41

Earlier quoted context omitted.

No. There's everything simple about Java. The semantics of Java are actually pretty simple, at least compared to C++. What's complicated are the monstrosities people build with Java, but those aren't inherent in the language. Saying that Java is complicated because EE exists is like saying that C is complicated because Linux exists: Complexity can be built atop simplicity. And for some reason, Java is a complexity ma…

I would say that the complexity of a language and the complexity of programs within that language are inversely correlated. Java is a very simple language, but as a result, the programs written in it must be more complicated to make up for the shortcomings of the language. As an example, Java's lifetime rules are much simpler than those of C++. At some point after all references are gone, the object will be garbage c…

No, not really. Complexity is not about the language: It's about how you use it. It's not necessarily Java's featureset that makes it so complex, it's its idioms.

C++'s lifetime rules, on most variables, are this: It's allocated until you say it isn't. Some of the vars might be refcounted or GCed, but with GC you've still got the same problem on your hands as finalizers, and refcounting can't handle cycles. Manual memory management is dramatically more error-prone than finalizers ever were (unless you're using RAII, but that's not entirely idiomatic, and cannot be).

As for functions not being able to be passed as args, that's not simplicity, that's a straight up limitation. What makes a language simple is uniformity, simplicity, and consistency. Java has a good deal more of all of these than C++

Complexity in the language doesn't enable simplicity in programs, though, because now your program has to deal with 6000 different special cases.

In any case, Lisp and Scheme are possibly the simplest languages, and are celebrated for their power, clarity, and the simplicity with which they can express programs.

Re: Talking to C Programmers about C++ [video]

#42
post #19
post #16

Earlier quoted context omitted.

I have been programming in C++ for almost 17 years now and I would say I know maybe 20-25% at most. The reality of C++ is you know what is needed for the problem you need to solve. As people mostly work in the same (broad) areas for their day to day work it is unlikely you need to know outside of that scope regularly. At least not in my personal experience. Also I strongly believe nobody truly understands C++ streams…

What are the components of C++ that add up to 100%? I can count: * language basics (variables, structural statements, functions, error handling, preprocessor, how compilation works) * OOP * functional programming (which is not that complicated at all in C++) * generic programming * advanced generic programming and metaprogramming * the C standard library * the C++ standard library basics (containers, algorithms, smar…

> functional programming (which is not that complicated at all in C++)

> I think most C++ programmers have a reasonable command of all of these

These gave me a bit of a chuckle. It's true only if you've never done proper functional programming using a genuinely functional language.

It's true that you can now pass lambdas around as first-class values easily, store and manipulate them as you might in a functional language, and that's a fantastic convenience.

But that's not what functional programming is. None of the idioms you'd use in Clojure or Haskell are wise to use (yet) in C++ (although Niebler's Range library will make a big step in the right direction... in C++20, where it's currently slated for specification).

If you try to do real functional programming in C++, you'll end up with a very inefficient program that pales to writing an algorithm with a more procedural or OO idiom.

And, in my experience interacting with lots of C++ developers, most do not know what actual functional programming is all about.

Re: Talking to C Programmers about C++ [video]

#43

Earlier quoted context omitted.

No. There's everything simple about Java. The semantics of Java are actually pretty simple, at least compared to C++. What's complicated are the monstrosities people build with Java, but those aren't inherent in the language. Saying that Java is complicated because EE exists is like saying that C is complicated because Linux exists: Complexity can be built atop simplicity. And for some reason, Java is a complexity ma…

I would say that the complexity of a language and the complexity of programs within that language are inversely correlated. Java is a very simple language, but as a result, the programs written in it must be more complicated to make up for the shortcomings of the language. As an example, Java's lifetime rules are much simpler than those of C++. At some point after all references are gone, the object will be garbage c…

> Up until Java 7 and lambda functions, functions could not be passed as arguments to other functions

Wasn't lambda expressions introduced in Java 8?

Re: Talking to C Programmers about C++ [video]

#44
post #25

In my opinion, many C++ projects would be simpler, cheaper, safer, and better maintained, if were written in C (with adequate libraries, e.g. for strings, vectors, maps, threads, timers, sockets, etc.).

A vector/map of what? How do I have a map of some key to a custom structure? How do you do this simply without templates? Separate libraries? Macro hell? How do you handle types which need to free memory without destructors? Manually loop over the vector and free stuff every time one goes out of scope? That doesn't seem safer to me.

>>A vector/map of what? How do I have a map of some key to a custom structure? How do you do this simply without templates? Separate libraries? Macro hell?

Separate libraries, without "macro hell".

>>How do you handle types which need to free memory without destructors? Manually loop over the vector and free stuff every time one goes out of scope? That doesn't seem safer to me.

Providing both heap and stack based allocation. E.g. allocating a vector in the stack would require no explicit de-allocation (example: https://github.com/faragon/libsrt). For heap allocation, you would need to call some sometype_free(&a) function, obviously (there is no RAII in C).

Re: Talking to C Programmers about C++ [video]

#45
post #13

C++ is really hard. I have learned enough about it to understand that there's a lot of idiomatic ways of achieving things that I do not understand, especially with the latest standards. When someone claims to know C++, especially in a recruitment context, I tend to challenge that, since it's really hard to actually believe these days. Some people claim to know C++, but basically just write everything as if it was C.

The same is true of any language with similar history. Do you believe anyone knows Perl, Python, Ruby, Java, C#, Ada, Haskell, OCaml, VB.NET, F#, ... across all language versions, the whole standard library, and most used third party libraries? One always need to focus on a specific domain.

The obvious comparison is C — where it is common to know 95-100% of the language. (The 5% I'd pick is general disagreement about expectations of UB and "weird" pointers, like pointers to array types.)

Re: Talking to C Programmers about C++ [video]

#46

The problem with C++ is the constant introduction of unneeded features that are infinity obscure in necessity. People will say "Oh just don't use that feature" but that's not how this works. If something is there it is used. In reference to C, I don't think I know of a single feature or release that had major changes in how I wrote C. Maybe C99 and allowing me to declare in a for loop. I've been using C++ for class t…

I've been using C++ for a long time (10+ years). At one point (around C++11), I decided to really embrace the advanced features (template metaprogramming mostly) and stop trying to make the language something it wasn't.

It can be complicated, for sure. But there is a certain plesantness that comes with letting the compiler do a lot of work for you. It can almost be like the switch to python - just let the compiler figure stuff out.

This results in a lot less duplicate code, etc. The cost is some pretty bad syntax and compile time, though.

Try to keep an open mind

Re: Talking to C Programmers about C++ [video]

#47
post #43

Earlier quoted context omitted.

I would say that the complexity of a language and the complexity of programs within that language are inversely correlated. Java is a very simple language, but as a result, the programs written in it must be more complicated to make up for the shortcomings of the language. As an example, Java's lifetime rules are much simpler than those of C++. At some point after all references are gone, the object will be garbage c…

> Up until Java 7 and lambda functions, functions could not be passed as arguments to other functions Wasn't lambda expressions introduced in Java 8?

Whoops, my bad. Edited.

Re: Talking to C Programmers about C++ [video]

#48

The problem with C++ is the constant introduction of unneeded features that are infinity obscure in necessity. People will say "Oh just don't use that feature" but that's not how this works. If something is there it is used. In reference to C, I don't think I know of a single feature or release that had major changes in how I wrote C. Maybe C99 and allowing me to declare in a for loop. I've been using C++ for class t…

The problem with posts about C++ on Hacker News is that people who aren't experienced C++ programmers (you've been using C++ for a semester? do tell) feel compelled to write posts explaining the problems with C++.

As someone who's had to deal with C++ since the last century, I find that one problem with C++ is that people who aren't experienced C++ programmers can't get shit done, especially in a code base where experienced C++ programmers have demonstrated their erudition and knowledge of C++ arcana in all its glory. In fact, the intersection of people who had the patience to learn enough C++ to get shit done and people who also have the patience or basic desire to actually get shit done (as opposed to programming wanky wrappers and stuff) is annoyingly small (this however is not true everywhere, I'd expect no such problem to exist with game programmers, for example.)

The fact that a language is terrible for newcomers is a real problem, and a newcomer is a very good judge of that even if they aren't a very good judge of other aspects.

Especially loathsome are those people who teach, say, undergraduates majoring in physics some C++ as a way to introduce them to programming. You might think that someone who manages to deal with the math needed to do physics would be able to absorb C++, and often you'd think wrong; one physics undergrad told an experienced programmer after trying to understand what the fuck coutFrom the above I conclude that people who have a semester's worth of experience in C++ might not be C++ experts but they certainly know enough to burn the instructor who chose C++ in the first place at the stake.

Re: Talking to C Programmers about C++ [video]

#49
post #19
post #16

Earlier quoted context omitted.

I have been programming in C++ for almost 17 years now and I would say I know maybe 20-25% at most. The reality of C++ is you know what is needed for the problem you need to solve. As people mostly work in the same (broad) areas for their day to day work it is unlikely you need to know outside of that scope regularly. At least not in my personal experience. Also I strongly believe nobody truly understands C++ streams…

What are the components of C++ that add up to 100%? I can count: * language basics (variables, structural statements, functions, error handling, preprocessor, how compilation works) * OOP * functional programming (which is not that complicated at all in C++) * generic programming * advanced generic programming and metaprogramming * the C standard library * the C++ standard library basics (containers, algorithms, smar…

> * OOP

C++ OOP is an endless tire fire. I now have 7 years experience writing C++ "OOP" on the job and I still run into surprises when I try to do things that are easy in other languages but unnecessarily hard in C++. Plenty of examples in the C++ FQA[1].

[1] http://yosefk.com/c++fqa/inheritance-mother.html#fqa-23.5

Re: Talking to C Programmers about C++ [video]

#50

The problem with C++ is the constant introduction of unneeded features that are infinity obscure in necessity. People will say "Oh just don't use that feature" but that's not how this works. If something is there it is used. In reference to C, I don't think I know of a single feature or release that had major changes in how I wrote C. Maybe C99 and allowing me to declare in a for loop. I've been using C++ for class t…

The problem with posts about C++ on Hacker News is that people who aren't experienced C++ programmers (you've been using C++ for a semester? do tell) feel compelled to write posts explaining the problems with C++.

This problem is not limited to HN, I see it everywhere. And wrt to the notion that every feature of C++ (from simple, to complex, to highly complex) will be used, I've been using C++ professionally for ~13 years and there are certain features I've chosen to stay away from since they don't add any benefit to the problems that I solve (or to the way I solve them). And I feel fine about that bc I'm very pleased with the performance and abstractions I can create with C++.
Post reply on HN