Hacker News Reader

Comment by cosmiccatnap | Hacker News Reader

I like c++ but it feels maddening to learn. There was a time when I would tell people to learn C++ but now I tell them to start with C and work their way up because if the choice is between C and C++, C has become the more readable language somehow if you don't know what abstract classes, templates, and functional constructs are....even a bubble sort in C++ takes some explaining in terms of just the syntax sugar.

GO and rust are great languages and I hope they go the distance and learn some of the lessons from C and especially C++

View on HN

If what you need is C++ (which IMNSHO it is not) then starting with C is a bad idea. Here's Kate Gregory's talk, you should definitely listen to her even if you think I'm an idiot because she actually teaches people C++ and I (thankfully) do not.

https://www.youtube.com/watch?v=YnWhqhNdYyk

Now here's my rant, which is unrelated to Kate's very smart talk:

C has an excuse, because it was written in the 1970s for the PDP-11. In the 1970s struct qualifies as a fancy new feature. In the 1970s a wide pointer is very expensive. In the 1970s a linked list is often a good choice of data structure. C++ comes along quite a lot later. These things are already untrue or fast becoming untrue, but rather than risk being unpopular Bjarne's language just cargo cults C. It is almost all of C, plus more... stuff.

C++ does not fix any of the worst problems with C, because doing so would risk losing compatibility and hurt Bjarne's adoption story. As a result, with only a handful of exceptions all of that broken garbage is still there. C++ still has the almost useless built-in array type from C, it keeps weird syntax from C that was too hard to ban in the 1970s compiler but you should never use, its built-in types have the same stupid, confusing names like "long" and "double", it has this awful "macro pre-processor" which makes even trivial tooling problems very difficult and set back software quality by at least a decade.

Kate's approach avoids teaching beginners about most of this. It's still there, which is bad, but at least you aren't making them learn about it, only to them immediately tell them it's forbidden knowledge and is prohibited in your nice modern C++ codebase. Instead of starting with raw pointers, and then trying to impress upon them later that these are a bad idea, Kate gets to begin with references and then a smart owning pointer.

Struct was already a feature in Jovial in 1958, but I digress.

Plenty of very hard 1970's features at Bell Labs, weren't a problem at IBM, DEC, Xerox, Olivetti,....

As for the way C compatibility taints C++, I agree, however Bjarne made juice with the lemons he had, and if it is to do a Python 3 in the C++ world, then most would rather migrate to Rust than use such C incompatible C++.

Why wouldn't they just use the older version of C++? If you don't want non-c compatible c++ you could just stick to C++20 instead of upgrading to "C++breaking_changes".

I ask because its not like support will ever be phased out like Python 2.

A language isn't used alone, it depends on an ecosystem, and people that care to keep old compilers going.

This is totally backwards advice. If you're going to teach C/C++, it makes far more sense to start with modern c++ which takes care of so much for you. std::string, std::vector, std::unique_ptr, and std::shared_ptr all alone make C++ far more approachable (and readable!) than C. And you can just entirely avoid pointers for a while, avoiding the need to cover things like avoiding returning pointers to stack values until much, much later.

After that you can then peel back the layers and discuss things like manual memory allocations, how vectors work under the covers, etc...

But C is an awful language to start with. It's incredibly complex to actually use and full of sharp edges. The grammar simplicity betrays the extreme mental complexity to actually use it without crashing or leaking memory everywhere. Not to mention the huge overhead in just doing simple things since nothing is included, and nothing is straightforward (like containers like hashmaps - hugely complex in C, trivial as heck in every other language)

And that's before you get into the fact that you can't even just learn C. You have to also learn macros at the same time to actually do anything effectively, which is basically a second language full of its own quirks and problems. With C++ you can reasonably avoid learning macros for a long, long time.

C is more useful to a broader range of programmers than C++. If your goal is to maintain million LOC C++ projects and make that your whole career, then spending the considerable time effort in C++ is worth it. But the whole world speaks C, it's so much simller. If your goal is to wrap existing libraries or speed up a hot spot in a language like python, plain C is a no brainer.

C as an ABI is basically its own thing. And can be implementated in C++ anyway just with 'extern "C"' slapped onto the function.

But it definitely doesn't make sense to start teaching anything at this level with "here's how you design a stable API/ABI". That's a skill set that relatively few need to know

C as an ABI is basically its own thing. And can be implementated in C++ anyway just with 'extern "C"' slapped onto the function.

Yeah, so learning C is required to write a portable C++ lib/extension, so you know what can go in `extern "C"` and what can't. At that point, you might as well do the whole thing in C and benefit from the super fast compile times.

But it definitely doesn't make sense to start teaching anything at this level with "here's how you design a stable API/ABI". That's a skill set that relatively few need to know

Fair enough, computing is a big field. For me non GC'd languages are something I dip into for a particular task. The mission is to get in, write the bare minimum, and get out as soon as possible. If I wanted to "move in" as it were, the (substantial!) time investment to master C++ or Rust is probably worth it.

> Yeah, so learning C is required to write a portable C++ lib/extension, so you know what can go in `extern "C"` and what can't. At that point, you might as well do the whole thing in C and benefit from the super fast compile times.

Neither claim there is really true at all. Learning how to write a stable extern C ABI really doesn't require learning C at all, nor even actually using C. Eg, I can put C++ classes in extern C functions just fine, as long as I do so as opaque pointers. Which you need to do for C as well, or use one of the other struct versioning schemes.

And then similarly why would I bother with C's nightmare of data structures or error handling in the implementation when I can use C++ instead and have it be a walk in the park? Marginally faster compile times isn't remotely worth it when you're compiling more often to fix more bugs.

Finally no you don't need C ABI to have a portable C++ library. You only need a C ABI to have a backwards compatible library as a prebuilt (and even that isn't strictly true, see eg libc++), which is a very very small niche within a niche. Like you're only doing that if you're an OS platform. Everyone else just ships C++ APIs and it works great (eg, abseil, folly, boost, skia, etc...)

We're talking past each other here. When I say "portable" I mean easy to use the resulting lib in non C or C++ languages.

As for why would you bother? I don't know, I guess you wouldn't, because you know C++ really well. I've been paid for it before, know it OK, and at the end of the day I'm more productive in C for the problems I want to drop down to that level for.

Even as a polyglot that picks up new languages quickly and often, I think this is true of most actively maintained major languages now.

We’re in an age where major languages are expected to cross-pollinate: if there’s a cool paradigm or technique in some other major language, how do we evolve our language to support it?

That’s not a terrible thing in itself, but it means that most major languages are multi-paradigm now and become more so every release.

As a consequence, learning becomes less straightforward.

C may feel like a nice starter to you specifically because it’s been comparatively resistant to this trend. It’s got a ton of tricks to learn, but there are only a few paths through learning it.

Even with C it only looks like it, if one sticks mainly with a specific compiler and OS.

C takes on many dialects based on specialization. Compare code from the following, and you will see a range from trivial to understand to WTF. These are all real-world applications:

- Linux kernel (events) - https://github.com/torvalds/linux/blob/master/kernel/events/...

- Arm CMSIS - (16-bit math) - https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/D...

- Numerical Methods in C - (Jacobian FP) - https://github.com/saulwiggin/Numerical-Recipies-in-C/blob/m...

- GNU 'ls' Command - https://github.com/coreutils/coreutils/blob/master/src/ls.c

- Gstreamer - (De-facto media streaming) - https://github.com/GStreamer/gstreamer/blob/master/gst/gstel...

GStreamer is my favorite because it basically creates VTables like C++ but calls them Klasses (based on Gnome), and it is just a brilliant framework in general, but an utter perversion of C IMHO.

The Linux kernel does the same thing as Gstreamer with file operations etc, I r thought it pretty neat, not really a perversion at all.

I didn't know that. Cool. Also, I was being silly, because for some reason it took me a while to get my head around klass, and compared to my other listed samples, it is an oddball.

These days it makes more sense to start from the other end if you ask me, and that has been true for quite a while.

I find that my C++ style has drifted further and further into value land with time, which is a major difference to C where the same style is pretty much impossible to pull off.

From one perspective, the language gets less and less complex; but the flip side is that all the old stuff is still in there and has the potential to cause a lot of trouble if you're not familiar with the details.

Taken as a whole, it's pretty much an impossible language to master and has been for some time.

> There was a time when I would tell people to learn C++ but now I tell them to start with C and work their way up

I tell people to learn Python. When they get a hang of it then I introduce them to C and pointers. When they can demonstrate effective use of pointers without blowing up then advance to C++. If not then just keep using Python. I'd rather them learn computer science fundamentals on the easy language. Then they can learn the better language out of necessity ("i need more performance" or "i need more control over the data structure in memory" or similar) instead of shoehorning them into a language they're not ready for.

I love C++. But it's not for everyone.

Genuine question: how do you teach beginners about python's value and reference semantics if they don't know what a pointer is?

When I learned python, I knew a but of C, but was certainly no expert. I remember finding it incredibly confusing that I could pass a list or instance of a class to a function, mutate it, and the caller would see that mutation, but the same did not hold for say a float. The only way I could make sense of it was to mentally classify certain types of objects as "getting secretly passed by pointer", and others as getting evidently passed by value. Without at least a familiarity with C, I think that would have been much harder to understand.

> how do you teach beginners about python's value and reference semantics

The great thing about Python is that it's super easy to learn by example without having to troubleshoot cryptic compiler errors first. So show them a few objects. Modify those objects. Show them how to deep-copy objects and how to modify objects by reference without a deep-copy.

Once the examples have been made then start asking about how they might write their own, in Python, types that could be deep-copied or reference-modified.

Make sure to include your own questions about classes, class attributes, function parameters, initialization, and forced cleanup using either `del` or `with` -- it's handy to use a file object for examples of object destruction since that's buffered and so writes to it won't show up until it's flushed or closed (which occurs automatically when the file object is destroyed).

Then you might expand to questions like: if you have a property somewhere that points to "some reference" but the reference could change to one of several different objects or maybe even to none of the objects, how would you do that? Is the property maybe pointing to one of the other objects? There are many ways to do this and most of them are "valid" for mentoring. What are some other ways to do it and what are some of pitfalls or benefits to the other ways?

From there you can segue your way into describing what a pointer is "under the hood" if you think the student is ready for more info about pointers.

You teach them how it works in Python. You don't take a detour to an entire other language.

That's not how Python works so trying to map it onto value/reference categories actually leads you astray. There is no pass by value, all objects are shared between caller and callee. But since a float is immutable, there is no internal state you can change that can be observed by the caller. If you do x += y, i.e x = x.__iadd__(y), the distinction is actually between immutable objects where iadd returns a new object, and mutable objects, where iadd modifies x and then returns x.

> That's not how Python works so trying to map it onto value/reference categories actually leads you astray

You cannot teach physics to five year olds by, for example, starting with Euler's equations.

Python doesn't work the same way as C, sure. But it works fine enough to get a feeling for how something "might" work. Then when they move on to another language, just as graduating to a harder class, you might have to un-learn some of the things to learn how it's really done.

Reply on news.ycombinator.com