4 ms·

> This is obviously nonsense. ... Why would that be any different in code that deals with concurrency?? I know you're speaking more broadly about abstraction a

> This is obviously nonsense. ... Why would that be any different in code that deals with concurrency?? I know you're speaking more broadly about abstraction as well as concurrency, but I share the GP's instincts on this. Because of the limitations (or rather the lack of limitations) in languages like C++ or Java its very easy write code that undoes any useful work a concurrency abstraction might provide. These abstractions are still useful! But they still require above average knowledge of their internals compared to say data-structures. With concurrency, things just don't compose that well without a ton of implicit best practices. The most trivial example is using a FooServiceClient from multiple threads and that ends up secretly holding long-lived locks internally essentially serializing your whole server. It happens accidentally all the time.

wrsh07 6y ago
You and the post I'm responding to are saying slightly different things. They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives" I disagree with the premise. When you use a tool, you don't need to understand the internals, but depending on documentation, error messages, and the surrounding community you can learn what's going on under the hood as you need to. When I use a library I don't plan one way or the other to become a deep expert or stay a beginner. I develop the knowledge I need to solve my problems. The tool is useful at all points in my own progression - from being a good place to learn about and practice using concurrency to being a codebase I can browse to learn more about how the primitives work. You're saying "concurrency is harder than other abstractions, so in order to use it correctly you actually need to understand what's going on" I also disagree with that premise. There are lots of hard things in programming. Concurrency is one of them, but so is memory management. There are footguns all over. It's possible to misuse most abstractions, and the reasoning could often be chalked up to "not understanding underlying primitives" I think this is all besides the point. If you run into problems when using your tool, you will have to learn how to fix or debug them. If in the case of serializing your whole application: either your application didn't need to be parallelized or you will debug why it's not scaling like it should be. That step, the debugging what's wrong... it's going to make you learn a little bit more about what's going on under-the-hood. I think all of us agree about that. So what are you and the original post I was responding to saying? I think the first post was saying something like "you should learn concurrency primitives; if you know concurrency primitives, then this library is overly pedantic." I don't really know what you're saying. I'm saying: use whatever entry point you want to solve your problems. It seems very likely to me that the abstractions provided here will make sense to some people (eg maybe they've learned idiomatic go concurrency or used kotlin coroutines), but they might be brand new to others. If the examples are sufficient for you to get concurrent code working, then that is really great! I'm not sure why people insist that we learn things one way or in some specific order. I don't see their research indicating that bottom up is better for retention (or something else), they are simply positing without fact that their way is best. I disagree.
- de_nied 6y ago
  > You and the post I'm responding to are saying slightly different things. I (GP) was actually saying exactly what kjeetgill was saying. I think you are misunderstanding our points. > They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives" What I said was that this library is geared towards people (not beginners, anyone) who do not understand and don't plan on learning the concepts that are extremely important and fundamental in the use of a language. You make good points with abstraction, but what I said was based on the context. The context is that we're talking about something (concurrency) that fundamental in knowing when using something else (C++). As I stated in my original reply, "A concurrency library is useful to have to avoid boiler plate code...." I agree with you that libraries are good for abstraction for things we either repeat or already know. They are not good when used as substitutes for the lack of knowledge, when that knowledge is as foundational as concurrency is in C++. > I also disagree with that premise. There are lots of hard things in programming. Concurrency is one of them, but so is memory management. There are footguns all over. It's possible to misuse most abstractions, and the reasoning could often be chalked up to "not understanding underlying primitives" The actual variable we're using here to determine of what should be understood and what's not that important to be understood is how closely the two subject matters are related and (here it comes, my favorite word) fundamental to each other. > I think the first post was saying something like "you should learn concurrency primitives; if you know concurrency primitives, then this library is overly pedantic." I might be sounding like a broken record, but just to make sure I'm clear on what I meant. Use the library by all means, unless it's to avoid learning something fundamental (buzzword of the day folks).
  - wrsh07 6y ago
    Thanks for clarifying! I'm trying to push back against this notion that libraries are bad. That people should learn programming one specific way. I think this idea is often well-intentioned. For JavaScript, it has been "you don't need jquery" for a long time. And you probably don't need jquery, but I generally think you should feel free to use tools that help you accomplish your goals. I agree that learning concurrency primitives in c++ is useful and rewarding, but pedagogically I don't endorse any particular entry point to parallelism. That said, once you've found that you do need concurrency for your task, yes, absolutely learn the fundamentals. They're called fundamentals for a reason.

wrsh07 6y ago

You and the post I'm responding to are saying slightly different things. They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives" I disagree with the premise. When you use a tool, you don't need to understand the internals, but depending on documentation, error messages, and the surrounding community you can learn what's going on under the hood as you need to. When I use a library I don't plan one way or the other to become a deep expert or stay a beginner. I develop the knowledge I need to solve my problems. The tool is useful at all points in my own progression - from being a good place to learn about and practice using concurrency to being a codebase I can browse to learn more about how the primitives work. You're saying "concurrency is harder than other abstractions, so in order to use it correctly you actually need to understand what's going on" I also disagree with that premise. There are lots of hard things in programming. Concurrency is one of them, but so is memory management. There are footguns all over. It's possible to misuse most abstractions, and the reasoning could often be chalked up to "not understanding underlying primitives" I think this is all besides the point. If you run into problems when using your tool, you will have to learn how to fix or debug them. If in the case of serializing your whole application: either your application didn't need to be parallelized or you will debug why it's not scaling like it should be. That step, the debugging what's wrong... it's going to make you learn a little bit more about what's going on under-the-hood. I think all of us agree about that. So what are you and the original post I was responding to saying? I think the first post was saying something like "you should learn concurrency primitives; if you know concurrency primitives, then this library is overly pedantic." I don't really know what you're saying. I'm saying: use whatever entry point you want to solve your problems. It seems very likely to me that the abstractions provided here will make sense to some people (eg maybe they've learned idiomatic go concurrency or used kotlin coroutines), but they might be brand new to others. If the examples are sufficient for you to get concurrent code working, then that is really great! I'm not sure why people insist that we learn things one way or in some specific order. I don't see their research indicating that bottom up is better for retention (or something else), they are simply positing without fact that their way is best. I disagree.

de_nied 6y ago
> You and the post I'm responding to are saying slightly different things. I (GP) was actually saying exactly what kjeetgill was saying. I think you are misunderstanding our points. > They say "this seems to be geared towards beginners who are not intending to understand the underlying primitives" What I said was that this library is geared towards people (not beginners, anyone) who do not understand and don't plan on learning the concepts that are extremely important and fundamental in the use of a language. You make good points with abstraction, but what I said was based on the context. The context is that we're talking about something (concurrency) that fundamental in knowing when using something else (C++). As I stated in my original reply, "A concurrency library is useful to have to avoid boiler plate code...." I agree with you that libraries are good for abstraction for things we either repeat or already know. They are not good when used as substitutes for the lack of knowledge, when that knowledge is as foundational as concurrency is in C++. > I also disagree with that premise. There are lots of hard things in programming. Concurrency is one of them, but so is memory management. There are footguns all over. It's possible to misuse most abstractions, and the reasoning could often be chalked up to "not understanding underlying primitives" The actual variable we're using here to determine of what should be understood and what's not that important to be understood is how closely the two subject matters are related and (here it comes, my favorite word) fundamental to each other. > I think the first post was saying something like "you should learn concurrency primitives; if you know concurrency primitives, then this library is overly pedantic." I might be sounding like a broken record, but just to make sure I'm clear on what I meant. Use the library by all means, unless it's to avoid learning something fundamental (buzzword of the day folks).
- wrsh07 6y ago
  Thanks for clarifying! I'm trying to push back against this notion that libraries are bad. That people should learn programming one specific way. I think this idea is often well-intentioned. For JavaScript, it has been "you don't need jquery" for a long time. And you probably don't need jquery, but I generally think you should feel free to use tools that help you accomplish your goals. I agree that learning concurrency primitives in c++ is useful and rewarding, but pedagogically I don't endorse any particular entry point to parallelism. That said, once you've found that you do need concurrency for your task, yes, absolutely learn the fundamentals. They're called fundamentals for a reason.