3 ms·

No, I didn't miss the point of the article. I just feel, it is important to note that the proposed style of concurency is available in go and point out to how y

by _ph_ 4y ago

No, I didn't miss the point of the article. I just feel, it is important to note that the proposed style of concurency is available in go and point out to how you would implement it, if you cannot use this Python library. I would agree, it would be nice to have a similar syntactic construct in go to enforce this pattern, though it is actually possible to basically implement that with higher order functions. And yes, I think goto has a place in any language, if you are aware of how you should and how you shouldn't use it. In most cases the typical constructs of structured programming are preferrable, but not in all.

kubanczyk 4y ago
> No, I didn't miss the point of the article. I just feel, it is important to note that the proposed style of concurency is available in go Apart from the TFA covering a particular python lib, I'd like to point out how the Go philosophy worked before. Given: Situation 1: "the proposed style of concurency is available in go" so let's have a free ride and we can have linters and human reviewers trying to catch all the concurrency bugs faster than contributors are inserting them. /s Situation 2: the proposed style of concurrency is the only one available in the language. Approach 2 would make sense.
- _ph_ 4y ago
  You are missing a very importand third point: Situation 3: we have understood the value of the proposed style of concurrency and think it is the right one for most situations, consequentely an according API has been created and it is strongly recommended for all usages of concurrency that fall into the pattern. This doesn't require the removal of the primitives used to build this API from the language. No linters needed, just a bit of common sense not to use the low-level API unnneeded.
  - cb321 4y ago
    In support of your point, this largely tracks way the "goto statement" shakeout has largely gone down in a number of programming languages over the decades - "available but discouraged" as in "Please do not write simple loops with if-and-goto." Access to source inline|linked assembly is also often available. That is perhaps less of a hazard since people probably have a less easy time "convincing themselves they understand it."
    - tialaramex 4y ago
      But as the article points out, you can't use the goto statement as it existed before structured control flow. It's not "available but discouraged" it's just gone because it was a bad idea.
      - cb321 4y ago
        setjmp & longjmp still exist in C/C++. A great many latter day prog.langs also still allow assembly with its jump-oriented constructs. Lack of possibility is simply not the same as lack of use. Lack of use or even just lack of common use is all that is needed for the benefits (as long as the use is easily identified by either humans, compilers, or both).
        tialaramex 4y ago
        std::longjmp is only defined if you're jumping "up" the call stack (the function you're jumping back into was still executing), and it would actually be safe to just abandon all the objects in your scope and containing scopes that will no longer be destroyed properly. In all other cases it's Undefined Behaviour, all bets are off.
        cb321 4y ago
        I'm not sure what your point is other than to elaborate constraints upon my examples. I never said it was "safe", "well defined", or even a "good idea". Only "available" and that this is an important distinction from "actually used". Even Rust has an "unsafe" construct available. I don't really think anything of what I am saying should be contentious. Being "weakly supported" also does not imply "strictly unavailable". You can cobble together "unstructured" jumps on top of the structured exception system as in pygoto. [1] Yes, there may be logical wiggle room in some pedantic definition of "goto" or "unstructured" or "available" exactly matching what you think this article said. It is true enough for the general question of "code clarity guidance purposes" which is, in my view, the general topic both of the article and these comments. One can still meaningfully say, "Please don't use pygoto!" even though "goto" is not, exactly, "in" the language. Many aspects of what is clear/confusing/easy/hard are not what is "strictly possible", but what a prog.lang or even its social community shepherd users to do, often through stdlibs. [2] Exceptions were originally sold as "structured error handling". Many people seem to dislike exceptions for their remaining non-local properties. In a lot of ways exceptions are often "optional", but if a stdlib uses them heavily then opting out becomes as impractical as replacing the stdlb. [1] https://pypi.org/project/pygoto/ https://pypi.org/project/pygoto/ [2] nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html
tialaramex 4y ago
It's true that with Turing completeness it's in some sense only ever a matter of style. But that's not a very useful observation in practice. If you really thought the arbitrary jump "has a place in any language" you would not use basically any languages from the 1980s onwards since they all neuter this feature for a good reason as the article explains, and some of them do away with it altogether. Even C++ - a language that has never seen a gun it won't supply loaded and pointed at your feet - does not allow you to goto labels in other functions, and will run the necessary constructors/ destructors when you enter/ leave scope with a goto statement.

by _ph_ 4y ago

kubanczyk 4y ago

> No, I didn't miss the point of the article. I just feel, it is important to note that the proposed style of concurency is available in go Apart from the TFA covering a particular python lib, I'd like to point out how the Go philosophy worked before. Given: Situation 1: "the proposed style of concurency is available in go" so let's have a free ride and we can have linters and human reviewers trying to catch all the concurrency bugs faster than contributors are inserting them. /s Situation 2: the proposed style of concurrency is the only one available in the language. Approach 2 would make sense.

_ph_ 4y ago
You are missing a very importand third point: Situation 3: we have understood the value of the proposed style of concurrency and think it is the right one for most situations, consequentely an according API has been created and it is strongly recommended for all usages of concurrency that fall into the pattern. This doesn't require the removal of the primitives used to build this API from the language. No linters needed, just a bit of common sense not to use the low-level API unnneeded.
- cb321 4y ago
  In support of your point, this largely tracks way the "goto statement" shakeout has largely gone down in a number of programming languages over the decades - "available but discouraged" as in "Please do not write simple loops with if-and-goto." Access to source inline|linked assembly is also often available. That is perhaps less of a hazard since people probably have a less easy time "convincing themselves they understand it."
  - tialaramex 4y ago
    But as the article points out, you can't use the goto statement as it existed before structured control flow. It's not "available but discouraged" it's just gone because it was a bad idea.
    - cb321 4y ago
      setjmp & longjmp still exist in C/C++. A great many latter day prog.langs also still allow assembly with its jump-oriented constructs. Lack of possibility is simply not the same as lack of use. Lack of use or even just lack of common use is all that is needed for the benefits (as long as the use is easily identified by either humans, compilers, or both).
      - tialaramex 4y ago
        std::longjmp is only defined if you're jumping "up" the call stack (the function you're jumping back into was still executing), and it would actually be safe to just abandon all the objects in your scope and containing scopes that will no longer be destroyed properly. In all other cases it's Undefined Behaviour, all bets are off.
        cb321 4y ago
        I'm not sure what your point is other than to elaborate constraints upon my examples. I never said it was "safe", "well defined", or even a "good idea". Only "available" and that this is an important distinction from "actually used". Even Rust has an "unsafe" construct available. I don't really think anything of what I am saying should be contentious. Being "weakly supported" also does not imply "strictly unavailable". You can cobble together "unstructured" jumps on top of the structured exception system as in pygoto. [1] Yes, there may be logical wiggle room in some pedantic definition of "goto" or "unstructured" or "available" exactly matching what you think this article said. It is true enough for the general question of "code clarity guidance purposes" which is, in my view, the general topic both of the article and these comments. One can still meaningfully say, "Please don't use pygoto!" even though "goto" is not, exactly, "in" the language. Many aspects of what is clear/confusing/easy/hard are not what is "strictly possible", but what a prog.lang or even its social community shepherd users to do, often through stdlibs. [2] Exceptions were originally sold as "structured error handling". Many people seem to dislike exceptions for their remaining non-local properties. In a lot of ways exceptions are often "optional", but if a stdlib uses them heavily then opting out becomes as impractical as replacing the stdlb. [1] https://pypi.org/project/pygoto/ https://pypi.org/project/pygoto/ [2] nibblestew.blogspot.com/2020/03/its-not-what-programming-languages-do.html

tialaramex 4y ago

It's true that with Turing completeness it's in some sense only ever a matter of style. But that's not a very useful observation in practice. If you really thought the arbitrary jump "has a place in any language" you would not use basically any languages from the 1980s onwards since they all neuter this feature for a good reason as the article explains, and some of them do away with it altogether. Even C++ - a language that has never seen a gun it won't supply loaded and pointed at your feet - does not allow you to goto labels in other functions, and will run the necessary constructors/ destructors when you enter/ leave scope with a goto statement.