3 ms·

> 'That override will work even if we stick it into a module.' That's the line where they lost me. Who wants to debug a situation where two unrelated modules c

> 'That override will work even if we stick it into a module.' That's the line where they lost me. Who wants to debug a situation where two unrelated modules clash because they wanted incompatible weird effects added to stdin? It would be better to have a situation like scala implicits, where you at least have to import the providing module to bring in the effects. Modules are only as useful as they are composable, in projects of any size.

cygx 9y ago
In Perl6, effects of importing modules are mostly lexical, ie bound to the surrounding block. However, this particular code basically just modifies a global variable (technically a dynamic one, but you get the point) - and modifications of global state will be globally visible no matter the language
- richard_todd 9y ago
  Yeah it will pretty much always boil down to mutable global state when you have "spooky action at a distance." Like, in python, there is one import cache, so I can import os, and redefine os.pipe() to be some other function. Then any other module importing os get's MY version of pipe(). That's a recipe for disaster and of course the real-world answer in all these cases is "don't do that." I love Perl5, smalltalk, lisp, etc., and I guess for that reason I feel like we have plenty of great languages where these hazards are exposed already. I'm not excited by yet another one. I'm more interested in new languages that attempt to allow crazy hacks in a contained way, so things still compose in the large.
  - bdmatatu 9y ago
    In the example, the effects of "use Jolly" are restricted to the enclosing scope, e.g. use lib <.>; { use Jolly; # inner scope } # TODO: this does not throw an error
    - richard_todd 9y ago
      I don’t have a problem with that. It can still be hard if you also want to “use Holly;” which wants some incompatible syntax hack, but at least it is lexically contained. I think the main reason this stuff tends to work out ok is that it’s so rare (in practice there aren’t enough Holly’s and Jolly’s in play so you don’t ever need to use both in the same scope).
hyperpape 9y ago
This is the case in Java as well--you can redefine standard in or standard out out in any location and it will have an effect everywhere that uses the same classloader.
- richard_todd 9y ago
  I did not mean to imply that it was a perl6-specific hazard, and in fact I lost interest because I can already do these kinds of hacks in languages that are decades old. The downsides are exactly the same, and the advice (“don’t do that in real code”) is exactly the same. In 2017, “look how dynamic things are” is not a differentiator... that part of language design space is pretty mature by now.
- raldi 9y ago
  Python, too. Let's say you import some code that does this, somewhere deep inside: try: x = 1 / int(s) except ZeroDivisionError, ValueError: print "uh oh" Oops, you just accidentally overwrote what the term ValueError means, in a way that won't get you a warning or anything. But somewhere else, far away, when you try to refer to ValueError, you're going to get really weird bugs and have no idea where they're coming from, since the stack trace will be nowhere near the code with the bug.
  - cesarb 9y ago
    That particular gotcha has been fixed in Python 3: >>> try: ... x = 1 / int(s) ... except ZeroDivisionError, ValueError: File "<stdin>", line 3 except ZeroDivisionError, ValueError: ^ SyntaxError: invalid syntax It now requires the "as" keyword. Also, AFAIK setting ValueError to something else affects only the current module; only modifying __builtins__.ValueError would affect other modules.
Ultimatt 9y ago
Modules in Perl 6 work how you might want. The author is highlighting that the effect of the evil inside the module escapes that. So it's ultimately something you should never be doing. The whole article is a list of antipatterns/footguns many people already doing P6 would likely not have imagined. I for one had not considered just how gross the one with the mixed in role on an Int changing different kinds of addition, so evil.

cygx 9y ago

In Perl6, effects of importing modules are mostly lexical, ie bound to the surrounding block. However, this particular code basically just modifies a global variable (technically a dynamic one, but you get the point) - and modifications of global state will be globally visible no matter the language

richard_todd 9y ago
Yeah it will pretty much always boil down to mutable global state when you have "spooky action at a distance." Like, in python, there is one import cache, so I can import os, and redefine os.pipe() to be some other function. Then any other module importing os get's MY version of pipe(). That's a recipe for disaster and of course the real-world answer in all these cases is "don't do that." I love Perl5, smalltalk, lisp, etc., and I guess for that reason I feel like we have plenty of great languages where these hazards are exposed already. I'm not excited by yet another one. I'm more interested in new languages that attempt to allow crazy hacks in a contained way, so things still compose in the large.
- bdmatatu 9y ago
  In the example, the effects of "use Jolly" are restricted to the enclosing scope, e.g. use lib <.>; { use Jolly; # inner scope } # TODO: this does not throw an error
  - richard_todd 9y ago
    I don’t have a problem with that. It can still be hard if you also want to “use Holly;” which wants some incompatible syntax hack, but at least it is lexically contained. I think the main reason this stuff tends to work out ok is that it’s so rare (in practice there aren’t enough Holly’s and Jolly’s in play so you don’t ever need to use both in the same scope).

hyperpape 9y ago

This is the case in Java as well--you can redefine standard in or standard out out in any location and it will have an effect everywhere that uses the same classloader.

richard_todd 9y ago
I did not mean to imply that it was a perl6-specific hazard, and in fact I lost interest because I can already do these kinds of hacks in languages that are decades old. The downsides are exactly the same, and the advice (“don’t do that in real code”) is exactly the same. In 2017, “look how dynamic things are” is not a differentiator... that part of language design space is pretty mature by now.
raldi 9y ago
Python, too. Let's say you import some code that does this, somewhere deep inside: try: x = 1 / int(s) except ZeroDivisionError, ValueError: print "uh oh" Oops, you just accidentally overwrote what the term ValueError means, in a way that won't get you a warning or anything. But somewhere else, far away, when you try to refer to ValueError, you're going to get really weird bugs and have no idea where they're coming from, since the stack trace will be nowhere near the code with the bug.
- cesarb 9y ago
  That particular gotcha has been fixed in Python 3: >>> try: ... x = 1 / int(s) ... except ZeroDivisionError, ValueError: File "<stdin>", line 3 except ZeroDivisionError, ValueError: ^ SyntaxError: invalid syntax It now requires the "as" keyword. Also, AFAIK setting ValueError to something else affects only the current module; only modifying __builtins__.ValueError would affect other modules.

Ultimatt 9y ago

Modules in Perl 6 work how you might want. The author is highlighting that the effect of the evil inside the module escapes that. So it's ultimately something you should never be doing. The whole article is a list of antipatterns/footguns many people already doing P6 would likely not have imagined. I for one had not considered just how gross the one with the mixed in role on an Int changing different kinds of addition, so evil.