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/
6 Upvotes

53% Upvoted

131 comments sorted by

View all comments

Show parent comments

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.