Using cin with 8-bit integers?

**whiteflags** · 12-21-2016

A beginner isn't trying to write game engines, are they now? This stuff is absolutely not necessary to know for beginners. This is an advanced topic that dives into computer architecture, an entirely different area of knowledge.

Well, I disagree that it's an entirely different area of knowledge.

What I glean from this is that it hurts to suggest someone learn about this stuff, and I don't get your point.

Beginner topics versus advanced is really just a state of mind, and I find an attitude like this can only hold people back. The very worst possible outcome, if a student followed the advice now, they would look up information on the Von Neumann architecture, and tangible machines, and not understand it immediately. Not knowing is not a sign of failure. They'll come back to it. Maybe it will be easy for them to understand and suddenly the idea of writing programs is connected to something actually real. You really never know.

**Elysia** · 12-21-2016

Originally Posted by whiteflags

What I glean from this is that it hurts to suggest someone learn about this stuff, and I don't get your point.

And that is a point I hadn't thought about, BUT it actually CAN hurt. From what I've gleaned from teachers teaching students, introducing certain (advanced) elements before others can actually make them confused or hurt their ability to code correct, readable and maintainable programs. Like teaching pointers before references.

Oh, and I've seen such confusion from students myself first-hand and heard from people at CppCon that it can hurt. That's why we want to teach C++-before-C mindset instead of C-before-C++ mindset.

Beginner topics versus advanced is really just a state of mind, and I find an attitude like this can only hold people back. The very worst possible outcome, if a student followed the advice now, they would look up information on the Von Neumann architecture, and tangible machines, and not understand it immediately. Not knowing is not a sign of failure. They'll come back to it.

Or maybe they'll think that they now have to write more efficient code at the cost of readability and maintainability.

In the end, programming languages are just tools. Complex tools. But tools don't tell their user what to do, or when they're using them wrong. A hammer can be a great tool for a builder, but a devastating tool for someone who does not know how to use it. Advanced topics take more time to understand and master and also tend to give the dangerous precedent of making a habit to the students to use these tools instead of the simpler tools. Or it makes them trying to take these advanced tools into mind when a simple tool is sufficient.

So let's just keep it simple. Let's now overwhelm new people with new info. Let them take it step-by-step, a gradual introduction into advanced topics and the complex realities later. Focus on the basics first. And advanced topics are not basics.

**whiteflags** · 12-21-2016

Or maybe they'll think that they now have to write more efficient code at the cost of readability and maintainability.

Suddenly you know what people would think.

By the way I think trading efficiency with readable, maintainable code is simply a myth that it doesn't serve you to perpetuate.

So let's just keep it simple. Let's now overwhelm new people with new info. Let them take it step-by-step, a gradual introduction into advanced topics and the complex realities later. Focus on the basics first. And advanced topics are not basics.

Yeah. Stay a beginner. Forever. And heaven forbid someone suggests you learn something else! Either now, or in the future.

**Elysia** · 12-21-2016

Originally Posted by whiteflags

Suddenly you know what people would think.

No. I never claimed that. Stop making stuff up. I shared what I've heard from other professionals and what I've experienced.

By the way I think trading efficiency with readable, maintainable code is simply a myth that it doesn't serve you to perpetuate.

Right, using const char* over std::string and making threads with atomics and locks is easy to understand, maintain and read.

Yeah. Stay a beginner. Forever. And heaven forbid someone suggests you learn something else! Either now, or in the future.

Or how about you learn the basics first, then delve into advanced stuff.

**whiteflags** · 12-21-2016

Or how about you learn the basics first, then delve into advanced stuff.

This we can agree on. I only want it to be safe to mention advanced stuff here, without you constantly believing it was a harmful thing to say. I mean, at a certain point, a beginner's going to wonder what "advanced stuff" is, and even if you are right about this being advanced, for some reason, such questions have no decent answer, and they waste people's time. And frankly, I'm only so adamant because you can hold people back with your attitude. People only have so much time to get there if they want to program a game engine, or any complicated project.

The fact is our field is unforgiving.

It is correct to not keep things simple when they are actually complicated.

**jimblumberg** · 12-21-2016

IMO, we're not talking about any advanced topic, we're talking about what is probably a prerequisite for most computer science courses. If you're going to program you really should have a basic knowledge of computer hardware.

Jim

**whiteflags** · 12-21-2016

I confess I learned about the von Neumann architecture, processors, and other various bits of hardware, in 101 courses.

**MutantJohn** · 12-21-2016

I really don't think understanding the RMW cycle of a processor helps multithreaded code. Instead, know a couple of things, threads reading from a location in memory require no locks. If there's a write involved, lock it down.

If anything, the C++11 constructs only require one to understand lifetimes and ownership which is also critical for understanding things like move semantics and forwarding references. The atomics in C++11 bring the programmer far away from the hardware.

**Elysia** · 12-21-2016

Originally Posted by jimblumberg

IMO, we're not talking about any advanced topic, we're talking about what is probably a prerequisite for most computer science courses. If you're going to program you really should have a basic knowledge of computer hardware.

Jim

I don't see "what is a register" talk happening in a programming introduction course. That happens later down the line as it is the basic knowledge required to be an engineer. But not everyone is, or aspires to be, an engineer, so for them, this stuff is not necessary to know. Which is my point. It's not basics for every developer.

Originally Posted by MutantJohn

I really don't think understanding the RMW cycle of a processor helps multithreaded code. Instead, know a couple of things, threads reading from a location in memory require no locks. If there's a write involved, lock it down.

That's a great rule of thumb, but it doesn't tell you WHY you have to do it. It also doesn't tell you what to do when multiple locks are needed or about how to optimize the code, or how to use atomics, or heavens forbid, if you have to use memory barriers. Knowing the basics means you can reason about the higher-level semantics, even though it can be difficult to do so sometimes.

**whiteflags** · 12-21-2016

Well it depends on your definition of those things too. An engineer knows what he's doing and a developer plays lego with existing code only.

**MutantJohn** · 12-21-2016

That's a great rule of thumb, but it doesn't tell you WHY you have to do it.

That's relatively easy to explain though. Threads can read and write from the same address at the same time. I don't really need to worry about RMW or other things like the CPU cache.

**jimblumberg** · 12-21-2016

I don't see "what is a register" talk happening in a programming introduction course. That happens later down the line as it is the basic knowledge required to be an engineer. But not everyone is, or aspires to be, an engineer, so for them, this stuff is not necessary to know. Which is my point. It's not basics for every developer.

When I went to school a prerequisite for any programming class was an Introduction to Computer Science class that included the basics of computers and operating systems, including what a processor was, a disk drive was, and memory was, and the basics of how these components interacted with each other. This included information on how a microprocessor retrieved information from the subsystems. This included things like bus sizes, and processor register sizes.

IMO if you don't know the basics of how a computer operates you'll never be a competent programmer. I'm not saying that you need deep in depth knowledge but you do need very basic knowledge to be a programmer.

Jim

**Elysia** · 12-21-2016

Sure, programmers needs to know basic stuff, but I don't think bus sizes and register sizes are included in the basics. As for my own experience, Introduction to Computer Science was not a prerequisite for Programming Introduction (that came later).

**MutantJohn** · 12-21-2016

Truth be told, we should be judging programmers from the quality of their code. They can know all the architecture under the Sun but that doesn't mean anything if they're writing cancer-C++.

**whiteflags** · 12-21-2016

They can write the best program in 2016 and it would be cancer C++ 20 years from now.

Just saying, both sides of this argument are shocked that the other side exists, it seems.

I don't want things to end with me being misunderstood either.

Originally Posted by Elysia

Stop making stuff up. I shared what I've heard from other professionals and what I've experienced.

Originally Posted by me

By the way I think trading efficiency with readable, maintainable code is simply a myth that it doesn't serve you to perpetuate.

Right, using const char* over std::string and making threads with atomics and locks is easy to understand, maintain and read.

First of all, who cares who you talked to, I don't know who they are or what exactly they said. How is that anything other than an appeal to authority?

Plus, I think we're talking past each other. I don't think that using const char* is more efficient than string, for example. I was trying to say that efficient code can be readable and maintainable code. That you can't pick all three adjectives; that is the myth.

I don't like assuming people will write poor code just because people know something about architectures and hardware, either.

I mean, okay, I know about that stuff to some degree but I wouldn't say my code is bad because of it. I wouldn't say that about someone else's code either. To be honest, the best "efficiency" idea I would get from the sort of information in contention, the kind of information that you seem to think is not appropriate to teach early, is using int over char or short. Maybe structuring my code so I don't write to the hard drive too many times. Tweaks like this. Aren't we maybe using a tad too much hyperbole here?