4 ms·

No, this is wrong, wrong, wrong. Ok, it's actually right under one false assumption: that we are limited to using our existing text-based tools like text edito

No, this is wrong, wrong, wrong. Ok, it's actually right under one false assumption: that we are limited to using our existing text-based tools like text editors, grep and so on. As long as we use these existing tools, this advice is quite valid. However, we are absolutely not limited to existing tools, we can and should make new ones that augment how we work and allow us to reach more dryness without compromises. You could have tools that let you work with ASTs, that expand code on the fly, show you higher level information, let you debug and step through sections of code effortlessly. In the end, dryness is good, because it means you have less repetitive work to do when things change (and software is all about changing, unless you don't want to make progress). So it's very well worth investing into being able to achieve dryness more naturally without the downsides. To quote Bret Victor, stop "blindly manipulating symbols." (You don't have to do do so overnight, just as long as it's a goal you work on achieving as time goes on.)

Arnor 13y ago
Yes, it's good and important to keep code DRY. The point here is that we often come up with clever brute force means of keeping code DRY. In most cases where you're generating method names through string concatenation (to use an example from the article), you could achieve DRY code by refactoring.
brazzy 13y ago
yes, it's right, right, right. Because your clever AST savvy tools will fail in the presence of metaprogramming, unless you restrict it to patterns the tool knows. And then you're halfway towards static typing with inference. Yes, grep is primitive for this task. We have much better tools for static languages, and they are great. It will be great to get them for dynamic languages. But they will fail in pretty much exactly these cases where this primitive test fails. Because halting problem.
- MBlume 13y ago
  If your metaprogramming is happening at compile time, and your AST savvy tools are savvy enough to work on the final (all macros evaluated) form of the code, then I don't see why they should fail?
  - brazzy 13y ago
    compile-time metaprogramming is far more tractable, yes.
  - arh68 13y ago
    If you wait until the final form of the code, it would seem very difficult to trace back from function symbol to its generating/binding macro. That is, how do you know which macro bound a specific function? Hope for no ambiguities, I suppose. Maybe it's not a problem, but I'd think the main point of such a grep tool is to point back to the originating code, right? Merely detecting that a specific function symbol is bound is not quite the same.
  - mvc 13y ago
    Smuglispweeny? Unfortunately, a lot of metaprogramming is done in languages that don't even have a "compile time" never mind providing a hook to metaprogram in it.
- arh68 13y ago
  > clever AST savvy tools will fail in the presence of metaprogramming, unless you restrict it to patterns the tool knows. And then you're halfway towards static typing with inference. Common Lisp has plenty of well-defined macros with simple patterns any tool could learn, but it's definitely dynamically typed. (defstruct foo ..) generates foo-p, make-foo, copy-foo; what parser couldn't understand that? All it takes is a few good macros to really make the DRY work. Either give up like the author and repeat yourself or move past the problem with a macro. Patterns mean "I have run out of language." — Rich Hickey
  - brazzy 13y ago
    > Common Lisp has plenty of well-defined macros with simple patterns any tool could learn If the tool has to learn (i.e. be written to know about, yes?) these patterns, then it will not know about those you wrote. However, as someone else has pointed out, the compile-time execution of macros actually does make them accessible to a sufficiently sophisticated "grep", the kind of tool shurcooL asked for.
- pnathan 13y ago
  No, actually, dynamic languages can, theoretically, handle this. At least, I can introspect in a running Lisp instance quite well. By all reports Smalltalk does it quite well too. The fact that most dynamic languages were hacked together doesn't imply that the better systems also fail.
  - brazzy 13y ago
    No, actually, dynamic languages cannot handle this even theoretically. See halting problem: No realistic amount of introspection is going to automatically tell you where negative_position is defined in the second example from TFA, because method_missing can do literally anything to decide what method names it does and does not handle. And Smalltalk's #doesNotUnderstand: works exactly like that.
    - gohrt 13y ago
      In practice, you can add a sprinkle of static to your dynamic language, adding a preprocessor that requires declaration of method_missing patterns that are acceptable to the application.
    - wes-exp 13y ago
      You are confusing dynamic typing vs static typing with run-time execution vs compile-time execution. A statically typed language can do arbitrary stuff at run-time too that will not be amenable to static analysis. This has nothing to do with the type system. Furthermore, a dynamic language can be perfectly amenable to static analysis. For instance, in lisp+slime, slime-who-calls can identify callers of a particular function, even when grep would not, e.g. if the function was invoked via a turing-complete macro. The key thing here is that the AST to be analyzed does exist at compile-time; it just happens to be generated rather than hand-coded.
  - vidarh 13y ago
    Theoretically, for constrained cases yes. On the other hand, the typical Ruby ORM defines methods that corresponds to the current columns of tables in the database it is told to connect to. That fancy AST parsing tool won't be able to do anything in that case without being able to connect to your database and issue queries... You might consider this "hacked together" but those kinds of api's is a major part of the draw of Ruby for a lot of people.
twopoint718 13y ago
Totally agree. Demand better. Have your metaprogramming and be able to know where 'getPosition' was dynamically generated.
rxp 13y ago
So... does that mean that it's right? Because I don't think you can prove a point by assuming the existence of things that haven't been invented yet.

Arnor 13y ago

Yes, it's good and important to keep code DRY. The point here is that we often come up with clever brute force means of keeping code DRY. In most cases where you're generating method names through string concatenation (to use an example from the article), you could achieve DRY code by refactoring.

brazzy 13y ago

yes, it's right, right, right. Because your clever AST savvy tools will fail in the presence of metaprogramming, unless you restrict it to patterns the tool knows. And then you're halfway towards static typing with inference. Yes, grep is primitive for this task. We have much better tools for static languages, and they are great. It will be great to get them for dynamic languages. But they will fail in pretty much exactly these cases where this primitive test fails. Because halting problem.

MBlume 13y ago
If your metaprogramming is happening at compile time, and your AST savvy tools are savvy enough to work on the final (all macros evaluated) form of the code, then I don't see why they should fail?
- brazzy 13y ago
  compile-time metaprogramming is far more tractable, yes.
- arh68 13y ago
  If you wait until the final form of the code, it would seem very difficult to trace back from function symbol to its generating/binding macro. That is, how do you know which macro bound a specific function? Hope for no ambiguities, I suppose. Maybe it's not a problem, but I'd think the main point of such a grep tool is to point back to the originating code, right? Merely detecting that a specific function symbol is bound is not quite the same.
- mvc 13y ago
  Smuglispweeny? Unfortunately, a lot of metaprogramming is done in languages that don't even have a "compile time" never mind providing a hook to metaprogram in it.
arh68 13y ago
> clever AST savvy tools will fail in the presence of metaprogramming, unless you restrict it to patterns the tool knows. And then you're halfway towards static typing with inference. Common Lisp has plenty of well-defined macros with simple patterns any tool could learn, but it's definitely dynamically typed. (defstruct foo ..) generates foo-p, make-foo, copy-foo; what parser couldn't understand that? All it takes is a few good macros to really make the DRY work. Either give up like the author and repeat yourself or move past the problem with a macro. Patterns mean "I have run out of language." — Rich Hickey
- brazzy 13y ago
  > Common Lisp has plenty of well-defined macros with simple patterns any tool could learn If the tool has to learn (i.e. be written to know about, yes?) these patterns, then it will not know about those you wrote. However, as someone else has pointed out, the compile-time execution of macros actually does make them accessible to a sufficiently sophisticated "grep", the kind of tool shurcooL asked for.
pnathan 13y ago
No, actually, dynamic languages can, theoretically, handle this. At least, I can introspect in a running Lisp instance quite well. By all reports Smalltalk does it quite well too. The fact that most dynamic languages were hacked together doesn't imply that the better systems also fail.
- brazzy 13y ago
  No, actually, dynamic languages cannot handle this even theoretically. See halting problem: No realistic amount of introspection is going to automatically tell you where negative_position is defined in the second example from TFA, because method_missing can do literally anything to decide what method names it does and does not handle. And Smalltalk's #doesNotUnderstand: works exactly like that.
  - gohrt 13y ago
    In practice, you can add a sprinkle of static to your dynamic language, adding a preprocessor that requires declaration of method_missing patterns that are acceptable to the application.
  - wes-exp 13y ago
    You are confusing dynamic typing vs static typing with run-time execution vs compile-time execution. A statically typed language can do arbitrary stuff at run-time too that will not be amenable to static analysis. This has nothing to do with the type system. Furthermore, a dynamic language can be perfectly amenable to static analysis. For instance, in lisp+slime, slime-who-calls can identify callers of a particular function, even when grep would not, e.g. if the function was invoked via a turing-complete macro. The key thing here is that the AST to be analyzed does exist at compile-time; it just happens to be generated rather than hand-coded.
- vidarh 13y ago
  Theoretically, for constrained cases yes. On the other hand, the typical Ruby ORM defines methods that corresponds to the current columns of tables in the database it is told to connect to. That fancy AST parsing tool won't be able to do anything in that case without being able to connect to your database and issue queries... You might consider this "hacked together" but those kinds of api's is a major part of the draw of Ruby for a lot of people.

twopoint718 13y ago

Totally agree. Demand better. Have your metaprogramming and be able to know where 'getPosition' was dynamically generated.

rxp 13y ago

So... does that mean that it's right? Because I don't think you can prove a point by assuming the existence of things that haven't been invented yet.