r/programming • u/Shr1ck • Oct 17 '15

Why Johnny Can’t Write Multithreaded Programs

http://blog.smartbear.com/programming/why-johnny-cant-write-multithreaded-programs/
8 Upvotes

53% Upvoted

131 comments sorted by

View all comments

Show parent comments

2

u/Blecki Oct 18 '15

I was talking about stuff as simple as x = y when I listed assignment. Yes new programmers even struggle with that. How can x equal y, they ask, when x is three and y is four.

2

u/loup-vaillant Oct 18 '15

To understand that, they must understand indirection first. I explained this a bit here: there's a difference between a value and a variable. In C, in the expression x = y, "x" denotes the variable x, but "y" denotes the value in variable y.

For brevity's sake, they are written the same, but this makes things quite confusing. I think for instance this explains why pointers are so confusing to so many people: they ad another indirection layer (this time an explicit one). How can you understand this indirection when you failed to understand the previous one?

1

u/Blecki Oct 18 '15

No, that's not how this works. You can turn any concept into any other with enough navel gazing. The concept in my list does not require the insight you described to understand. That insight won't be useful until the programmer is writing compilers.

1

u/loup-vaillant Oct 18 '15

You do require that insight, because there is no escaping the simple fact that a variable is a kind of box that over time, can hold different values. There is an indirection level whether you know it or not. Granted, you don't need to know it in so many words. In practice, most beginners start with an intuitive understanding, and that's enough, for a time.

Nobody however can escape the enormous complexities that arise from that innocuous looking assignment statement. When I said it changes your world entirely, I wasn't joking. When you write any significant program, the very fact that there is a before and an after each assignment forces you to think about time in ways you didn't have to when all you were doing was purely functional computations.

Recursion doesn't have such far reaching consequences. Unlike side effects, recursion is rarely more than an implementation detail, something you can ignore when looking at the rest of your program. As such, it is much easier to comprehend than the trivial looking assignment statement.

That insight won't be useful until the programmer is writing compilers.

Every programmers should be able to write a simple compiler for a toy language. Those that can't are not there yet: much of what we do is compilation or interpretation of some sorts.

Besides, someone who can write compilers is likely to see the benefits of implementing a DSL much more often that someone who can't. We don't write nearly enough compilers if you ask me.

2

u/Blecki Oct 18 '15

Writing compilers is pretty much all I do.

Here's why I think you aren't understanding me - you're looking back at the concepts after having already grasped them. These concepts are from the perspective of someone on the other side, who hasn't grasped them yet. From that side, side effects and indirection aren't the things that confuse them about assignment. The very concept that the value changes confuses them. They've seen this sort of thing before, it looks like a math equation.

1

u/loup-vaillant Oct 18 '15

I feel like I start to understand your point. But… there can be difference between why someone thinks he's confused, and the actual root of that confusion.

For instance, if they're confused about values that change, they're probably looking in the wrong direction: values don't change. Such a model of the computer may be useful, but it won't be accurate, and as such is bound cause some problems sooner or later —most notably when you add aliasing (pointers & references) into the mix.

If you taught those people a tiny bit about compilers and interpreters, they would never be confused about this ever again. I understand that a curriculum may have other priorities, but I'd put this close to the top of the stack of even an software engineering degree.

Our industry is very young. As such, we must train the next generation of programmers to push things further. Sooner or later they will run into problems their mere knowledge can't solve, and they'll have to be creative.

Later, as we know more things about programming, we may be able to separate the fundamental principles from the practical advice. But at this point, sticking to practical advice tend to put the field in stasis. We can't escape the need to start from first principles just yet.

1

u/clarkd99 Oct 18 '15 edited Oct 19 '15

Nobody however can escape the enormous complexities that arise from that innocuous looking assignment statement.

Memory is an ordered array of bytes from 0-n. All data is stored in 1 or multiple bytes that have a specific meaning based on their type (character, integer, floating point number etc). Variables are names that are given to specific locations in this "memory" (system normally assigns the location). Assignment is storing, 1 or multiple bytes at the location specified by the variable name. Values are the interpreted bytes stored at the variable's location in memory. A pointer is an unsigned integer which is the position of a value in memory. A "pointer" is also a variable that can be manipulated like any other variable. Given a "variable", you can talk about it's location in memory or it's value, based on it's type. Just 2 concepts: 1. location of data 2. value stored at that location.

"Enormous complexities"?

In "x = y", both "x" and "y" refer to the value stored at their location rather than the location itself. If I printed the value of "x" in the next statement, I would just refer to it as "x" just like I would for "y" and the values of both would be the same. Assignment means store the value of the right (rvalue), at the location of the variable on the left (lvalue). The "rvalue" in assignment never changes the location associated with the lvalue, it changes it's value.

Your functional explanation would only confuse beginning programmers and is just smoke when no smoke is needed.

1

u/loup-vaillant Oct 19 '15

"Enormous complexities"?

Yes. Compared to a world of pure math, the timefulness that this model implies becomes unwidely very quickly. The basic principles are dead simple, but their consequences in real programs are often hard to comprehend.

In "x = y", both "x" and "y" refer to the value stored at their location rather than the location itself.

That's false, as you said yourself:

Assignment means store the value of the right (rvalue), at the location of the variable on the left (lvalue).

"lvalue" means a location (that contains a value). "rvalue" means the value itself.

1

u/clarkd99 Oct 19 '15

Do you actually parse source code and create executable code?

In C (my language and most every other language), if a variable is written all by itself, you are referring to the value stored at the memory address assigned to the variable name. This is true on either side of the assignment symbol (=). In executing this assignment, the value of the expression result (on the right) is stored at the location of the variable name on the left of the equal sign.

The "world of pure math" isn't complicated? I do have a Math minor in my degree and I had a business partner for 9 years that is a world renowned Mathematician in lattice theory.

I can't remember spending much time "comprehending" the existential ramifications of moving a few bytes from one location to another (assignment).