5 ms·

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

by 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
In exchange for giving up go-to we gained a lot because it turns out that programme structure enables us to successfully write more complicated programs. There's no practical difference between what you claim is "weakly supported" (if I carefully read the assembly for each build to find the correct values to plug in for a jump instruction I can use in-line assembler from a language like Rust to "go-to" somewhere else) and "strictly unavailable". In the case of C++ and Rust they'll both tell you what you want to do is "Undefined behaviour" although Rust also ropes it off with unsafe. Doesn't work? Too bad. Keeping the flexibility you desire so much would have been tremendously expensive. It would mean all the programs real people write are slower and harder to understand just to support some unspecified "alternative" and so, as we see, nobody did it. And that's how this insight applies to concurrency. Modern languages are much superior for being able to assume go-to isn't a thing, and the argument says they'd be much superior for being able to assume Go statement style concurrency isn't a thing. The difference is that (aside from you apparently) it has been generally accepted that go-to was a bad idea, while prohibiting something like the go statement or Rust's thread::spawn are not yet seen in the same light. The contention is that if we did that we'd be able to understand more sophisticated concurrent programs. Seems reasonable to me.
- cb321 4y ago
  > flexibility you desire so much .. (aside from you apparently) Not only did I never advocate for broad usage, I explicitly said I didn't (as did @_ph_) and never expressed some love for goto or even "keeping it" whatever that means given it's often practically "possible". I neither use nor advocate Go, nor Rust, nor similar concurrency primitives in Nim, nor goto. Sheesh. Weird flaming attacks on strawmen there. You should probably just be ignored. Oh well. >no practical difference One practical difference is that safer/easier higher-level constructs can be written more easily in terms of lower-level - which @_ph_ was specifically suggesting a few posts up subthread. I hear the Rust ecosystem has a lot of usage of "unsafe". Making "possible" things "too hard" can force core compiler teams into provide 1-size-fits-all solutions. All approaches have trade-offs. Google|MSFT|.. can fund compiler teams to do whatever. You may hire a bunch of kids out of college and don't want them to have too much power because they have yet to learn the responsibility Spider-Man picked up as a Teen Scientist. >much superior for being able to assume go-to isn't Compilers can usually analyze what the program is doing and observe "no go-to: do the better thing". They can even encourage users by saying "optimization only works if not doing PDQ" (like only tail calls get turned into iterations). APIs can always have caveats like "Incompatible with XYZ". If usage is rare and easy to identify (as I said) the situation is essentially the same from a clarity/expense of developing complex systems point of view, but I am just repeating myself to seemingly deaf ears. To be more concrete, people don't use either setjmp or goto much in C++ because other higher level things are easier/they are taught not to. There are usually many unused dark corners of any prog.lang more than a few years old. They have a cost, but it isn't as monumental as you make it out to be and so removing it does not produce the major savings you imagine (relative to discouraging/making rare). >Rust's thread::spawn not So don't call it. Write a structured concurrency lib. If there aren't already 5 crates. >are not yet seen in the same light Seen by who? You? You speak for all systems programmers & professors now? The article author does? Or did 4 years ago? I would grant there are education problems on this and many other topics. Maybe you calibrate your "not seen" against a pool of underexposed people? >be able to understand more sophisticated concurrent Just use a higher-level API? I don't see a strong argument (either by you or in the article) that only prog.language support can "sell" this approach/keep things clean. @_ph_ suggested a lib. All I did was say history supported his side point and you started jumping all over me. There are many abstractions you need for more sophisticated/complex systems..not just this. "Must..get..compiler..team..onboard!" jitters are usually misplaced. If one feels that way often about syntax needing to follow semantics, then I suggest Lisp or Racket or Nim or something where you don't have to wait for compiler teams. It may be for "other Python reasons" that Smith claims you cannot get "safety" without prog.lang support, but Python is really just one lang and famously not good at safety in general. libdill [1] did this pretty manually as a C library (with, sure, probably a lot of other "C problems") back in 2016 - years before this article (which yes, mentions it in a snarky footnote). Pretty sure the ideas are all ancient. The same footnote mentions some Rust crates you could evaluate if that's what you like. Core concept systematization may well date back to Henry Ford's assembly lines (or earlier, but probably not, say, Aristotle!). So, ok..Maybe it's catching on now in more application areas/stdlibs/a prog.lang or 3. I'd even agree that's probably a good thing. I never thought otherwise. I don't think I said anything to suggest that I did. ----------------------- Look - I'm glad "fork-join, abstraction, and clean nesting" seem to have new fans in Smith, in @tialaramex, and in the world. To many, it may seem like "news". To many others, it is not "news" at all. Nor is the challenge of getting users to use safer, higher-level constructs when "cheats" are "always kinda possible" or maybe more sadly "what some popular intro/demo code uses". Bad examples propagating are a problem - not only in software even. There are surely interesting questions around the topic. I never challenged that, either. Best wishes [1] http://libdill.org/structured-concurrency.html http://libdill.org/structured-concurrency.html

by cb321 4y ago

tialaramex 4y ago

In exchange for giving up go-to we gained a lot because it turns out that programme structure enables us to successfully write more complicated programs. There's no practical difference between what you claim is "weakly supported" (if I carefully read the assembly for each build to find the correct values to plug in for a jump instruction I can use in-line assembler from a language like Rust to "go-to" somewhere else) and "strictly unavailable". In the case of C++ and Rust they'll both tell you what you want to do is "Undefined behaviour" although Rust also ropes it off with unsafe. Doesn't work? Too bad. Keeping the flexibility you desire so much would have been tremendously expensive. It would mean all the programs real people write are slower and harder to understand just to support some unspecified "alternative" and so, as we see, nobody did it. And that's how this insight applies to concurrency. Modern languages are much superior for being able to assume go-to isn't a thing, and the argument says they'd be much superior for being able to assume Go statement style concurrency isn't a thing. The difference is that (aside from you apparently) it has been generally accepted that go-to was a bad idea, while prohibiting something like the go statement or Rust's thread::spawn are not yet seen in the same light. The contention is that if we did that we'd be able to understand more sophisticated concurrent programs. Seems reasonable to me.

cb321 4y ago
> flexibility you desire so much .. (aside from you apparently) Not only did I never advocate for broad usage, I explicitly said I didn't (as did @_ph_) and never expressed some love for goto or even "keeping it" whatever that means given it's often practically "possible". I neither use nor advocate Go, nor Rust, nor similar concurrency primitives in Nim, nor goto. Sheesh. Weird flaming attacks on strawmen there. You should probably just be ignored. Oh well. >no practical difference One practical difference is that safer/easier higher-level constructs can be written more easily in terms of lower-level - which @_ph_ was specifically suggesting a few posts up subthread. I hear the Rust ecosystem has a lot of usage of "unsafe". Making "possible" things "too hard" can force core compiler teams into provide 1-size-fits-all solutions. All approaches have trade-offs. Google|MSFT|.. can fund compiler teams to do whatever. You may hire a bunch of kids out of college and don't want them to have too much power because they have yet to learn the responsibility Spider-Man picked up as a Teen Scientist. >much superior for being able to assume go-to isn't Compilers can usually analyze what the program is doing and observe "no go-to: do the better thing". They can even encourage users by saying "optimization only works if not doing PDQ" (like only tail calls get turned into iterations). APIs can always have caveats like "Incompatible with XYZ". If usage is rare and easy to identify (as I said) the situation is essentially the same from a clarity/expense of developing complex systems point of view, but I am just repeating myself to seemingly deaf ears. To be more concrete, people don't use either setjmp or goto much in C++ because other higher level things are easier/they are taught not to. There are usually many unused dark corners of any prog.lang more than a few years old. They have a cost, but it isn't as monumental as you make it out to be and so removing it does not produce the major savings you imagine (relative to discouraging/making rare). >Rust's thread::spawn not So don't call it. Write a structured concurrency lib. If there aren't already 5 crates. >are not yet seen in the same light Seen by who? You? You speak for all systems programmers & professors now? The article author does? Or did 4 years ago? I would grant there are education problems on this and many other topics. Maybe you calibrate your "not seen" against a pool of underexposed people? >be able to understand more sophisticated concurrent Just use a higher-level API? I don't see a strong argument (either by you or in the article) that only prog.language support can "sell" this approach/keep things clean. @_ph_ suggested a lib. All I did was say history supported his side point and you started jumping all over me. There are many abstractions you need for more sophisticated/complex systems..not just this. "Must..get..compiler..team..onboard!" jitters are usually misplaced. If one feels that way often about syntax needing to follow semantics, then I suggest Lisp or Racket or Nim or something where you don't have to wait for compiler teams. It may be for "other Python reasons" that Smith claims you cannot get "safety" without prog.lang support, but Python is really just one lang and famously not good at safety in general. libdill [1] did this pretty manually as a C library (with, sure, probably a lot of other "C problems") back in 2016 - years before this article (which yes, mentions it in a snarky footnote). Pretty sure the ideas are all ancient. The same footnote mentions some Rust crates you could evaluate if that's what you like. Core concept systematization may well date back to Henry Ford's assembly lines (or earlier, but probably not, say, Aristotle!). So, ok..Maybe it's catching on now in more application areas/stdlibs/a prog.lang or 3. I'd even agree that's probably a good thing. I never thought otherwise. I don't think I said anything to suggest that I did. ----------------------- Look - I'm glad "fork-join, abstraction, and clean nesting" seem to have new fans in Smith, in @tialaramex, and in the world. To many, it may seem like "news". To many others, it is not "news" at all. Nor is the challenge of getting users to use safer, higher-level constructs when "cheats" are "always kinda possible" or maybe more sadly "what some popular intro/demo code uses". Bad examples propagating are a problem - not only in software even. There are surely interesting questions around the topic. I never challenged that, either. Best wishes [1] http://libdill.org/structured-concurrency.html http://libdill.org/structured-concurrency.html