Hacker News Reader

Hi. I appreciate your candor, although I'm not sure what I've done to inspire such contempt. You're correct that the entire point of the post was to deep dive into a rabbit hole. I acknowledged that and also acknowledged that the standardese is unnecessary most of the time, to avoid any miscommunication in my intent. I did this point out how large the language is and, more to the point, to point out how potentially complex it can be, compared to C. If you've ever had to spend entire weekends running through students' broken C code at scale, and see all the interesting ways one can complicate seemingly simple things, then I think you'd agree that giving them more ways to confuse themselves in a fast-paced academic environment is not the way forward. If you have had that experience and didn't have any problems, then you are fortunate to work with such fast learners! (Not to imply the students I've had are dumb in anyway, many are very bright!)

C might be okay to learn for academic purposes but it's an absolute nightmare to use building real things.

Things like strings and pointers are nightmarish in C. Segfaults aplenty.

I've never encountered a segmentation fault since switching to modern C++. Just because you use C++ doesn't mean you have to use the entirety of it.

> how potentially complex it can be

Welp, time to go back to BASIC everyone. Or Go

Powerful tools can be complex, who would have thought

I am not sure about the following issue: What would make your students more productive?

   - use C++, given that you stick to some convenient subset of C++ and can use stl
   - stick with C and force them to do the basics, like linked lists and string abstractions over and over again.

I guess in the olden days really good students used to develop their own library of C abstractions, and reuse them with several courses; but you can't quite do that if you have C in just one course and what's the point anyway in this day and age ?

How else would they learn about linked lists and dynamic arrays?

depends on the course, if its a data structure course then its fine to do the linked list and dynamic array, but forcing your students to do them again and again in later courses will not make them very productive, they also might not enjoy the experience too much.

This could happen for example if the data structure course was in python or java and later courses are in C.

Also you can do the darn list in many ways: single linked list, double, ring, with counter/without counter. All very important in this day and age when you should know to avoid them altogether because linked lists fucks up cache behavior.

Funny you mention that: the data structures course I took let us use any language we wanted. I chose python because I thought “hey python’s easier than C!” So I started making some tree implementation from scratch, and I kept having problems because I didn’t understand Python’s name binding system at the time, because I had no mental model of pointers or references or objects really. (Of course it was a shallowcopy/deepcopy issue). The next assignment I did in C and it was much more natural. Only later did I realize how meta and absurd it was to build custom dictionaries out of python primitives.

a dictionary in python where everything is a dictionary. That's what undergraduate courses are made for!

A huge reason people teach C/++ to beginners is to understand how the "machine" works. Yes, the model C++ uses doesn't map too well to modern assemblies, and yes, it maps even worse to the actual hardware, but its abstraction is the one everyone uses, so it's worth teaching. Teaching modern C++ doesn't do that, at all. "Modern" C++ even has garbage collection (reference counting) in the form of shared_ptr! The author makes the good point that C is much better suited to this job than C++.

Also, standards definitely shouldn't be inscrutable to programmers. Look at the ECMAScript and Go specifications, they're clear as day. Sometimes you just need to know exactly what your code is doing, and this only becomes more important in the low-level scenarios that C++ is often used for. I haven't read the C++ specification, but if it's as hard to read as everyone says it is, then there needs to be some other way to understand exactly what's going on. How else am I meant to precisely understand how my structs will be laid out, or which casts are guaranteed to be valid, or whether the language allows data pointers and function pointers to be interchangeable?

use the new stuff which fixes all the complexity

It doesn't, unfortunately it just adds to the complexity.

How so? My experience has been that it actually reduces net complexity, except in the case where you need to support different versions of the language in the same codebase.

Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.

> Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.

When writing code, yes, but in my experience, it can also make interpreting what code that overuses auto is doing (especially what variables are and what functions return) an awful lot harder in many situations, and you end up jumping all over the place to work out that "auto result = ..." is actually "uint32_t result = ..."

That's one of my personal pet peeves about more modern C++ (and other languages to some extent like Rust): they seem to be more optimised for writing code quickly (which generally only happens once), not understanding it later (i.e. you didn't write the code someone else did) and maintaining / altering it in the future, which generally happens a lot more over code's lifetime.

This is one of my worries about type inference (which C++ auto is not), but so far, the Rust code I've read has definitely been much easier to understand than the equivalent C code, and it's often much more generic. I like how Rust forces refuses to infer function signatures, which means you still always know the types of the inputs and outputs. I don't use IDEs, but I'd assume that they also make this whole thing a non-issue.

Relying on IDEs to do this type of thing really doesn't help for situations like merge conflicts (i.e. which merge tools understand languages fully?), and it doesn't completely solve the problem of easily understanding code just at a glance - you still need to go round mouse-overing or clicking on stuff to see extra detail.

is there a specific case that the uint32_t helps understanding the logic of the code?

That was a contrived example (although I've often seen auto used instead of that or even bool which I personally think are total over-uses of auto).

But knowing if something is a base type, a reference, a (smart) pointer, or an expensive-to-copy class/struct is very important when writing high-performance efficient code. Being able to see this at-a-glance by the type in the code in my experience helps tremendously with understanding what the code's doing and the implications in terms of data passing / transfer and understanding how that section of code interacts with other parts or could be changed to do other things.

I also think it allows people to be a bit sloppy and not care what's going on (i.e. with regards to whether it's by-value or by reference, etc) as they don't fully need to understand the code, and again, in high-performance computing where you seriously care about processor cycles and memory allocations, this can make a big difference if you're not careful.

Rust actually deliberately requires types to be declared, expect inside function bodies. So function return types have to be explicit. The main reason is exactly your readability argument. (Of course it also makes type inference inside the function body easier).

Yes, to be clear I wasn't accusing Rust code of having this particular problem, I was just using it as an example of a modern language where in my opinion there's a bit of an over-emphasis on brevity in terms of writing the code, as opposed to reading/understanding it and maintaining it, which I feel for long-term large projects, I'm not convinced is a total win.

I could have easily used Go or Swift as examples instead.

And to be clear, these new languages are in general improving things a lot, but I just worry there's an over-emphasis on "being able to do a lot of complex stuff which very few syntax / characters", which I don't really fully agree with (at least for large complex long-term projects).

That's not to say I'm right, but in my experience of programming over 15 years in everything from ADA, C, C++ to Java and Python, at least on large projects, the speed at which code was created was very rarely that important. Getting it right, bug-free and performant was generally much more important. In some cases newer more-condensed syntax can definitely help, but in others, it can cause trouble.

I definitely agree with most of your points.

Code is read much more often than written, and most newer languages optimize for convenience rather than readability.

In my view Rust is actually pretty verbose compared to other new languages, and feels a bit cumbersome to write. Technically it could be made quite a bit leaner syntax-wise.

I just wanted to point out that Rust and the Rust community often share your view and want to optimize for readability as well. There actually was a lot of heated discussion last year around proposals that suggested reducing readability for convenience.

Most pre-C++11 code I've seen that gets iterators from `begin()`, `end()`, and friends just typedef out their actual type anyways, so you the experience there is not that different from `auto`.

But those typedefs almost always (in my experience) contain some indication of at the very least an abbreviation of the type and some hints as to whether it's a pointer or not.

That's a lot better to go on than "auto".

You already know the type if you're calling .begin() or .end() on it. You don't care about the type of the iterator because you know it can iterate over the collection you're working with.

That's what auto fixes. It avoids coupling the concept of iterating from the specific type of the iterator which isn't important.

Similarly auto helps you achieve DRY. 'auto myFoo = std::make_unique<Foo>();'. The type wasn't removed, it just wasn't repeated twice.

But at this point auto, or things like auto, exist in nearly every major language. So you'll need to teach best practices for working with it at some point. That's a general thing that's everywhere.

> This is a ridiculous argument.

Please keep it civil. I'm sure you could refute the GP without expressing contempt.