3 ms·

> Yes, it's great that you can write your own control flow constructs. So what? A sane language already includes those constructs, and they're known and underst

by zeveb 6y ago

> Yes, it's great that you can write your own control flow constructs. So what? A sane language already includes those constructs, and they're known and understood by all users of the language without having to first read the documentation of some third-party lib (haha, just kidding, there is none – read the code, dummy!). I do not believe that novel control statements are any different from novel functionality. A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. New functions, like new control statements, may be poorly documented. The fundamental power of computing is abstraction. Functions, macros and control structures are all different types of abstraction. The only way to build a successful, malleable large program is to abstract, and to avoid macros and new control structures is simply to require larger teams (because someone has to hand-write all the code which the computer could be writing for you) and more ad hoc approaches.

adwn 6y ago
> A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. The difference is that I write new functions on a daily basis, while I almost never need new control flow constructs. And if it turns out that such a construct would be useful, then it's almost always better to also have syntax and compiler support for it (for error checking, more descriptive parser errors, optimizations).
- mschaef 6y ago
  At least in my experience, macros are really an escape hatch of last resort, and for the reasons you mention. Semi-related: http://www.mschaef.com/defmacro-coupling http://www.mschaef.com/defmacro-coupling
- zeveb 6y ago
  > The difference is that I write new functions on a daily basis, while I almost never need new control flow constructs. I wonder if perhaps you only think you rarely need new control flow constructs because you are using languages without good support for macros. Where a Lisp or Tcl programmer might just code up a true DSL (cf. CLOS or the condition system), perhaps you just write functions, never realising how much more readable and understandable your systems could be.

by zeveb 6y ago

adwn 6y ago

> A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. The difference is that I write new functions on a daily basis, while I almost never need new control flow constructs. And if it turns out that such a construct would be useful, then it's almost always better to also have syntax and compiler support for it (for error checking, more descriptive parser errors, optimizations).

mschaef 6y ago
At least in my experience, macros are really an escape hatch of last resort, and for the reasons you mention. Semi-related: http://www.mschaef.com/defmacro-coupling http://www.mschaef.com/defmacro-coupling
zeveb 6y ago
> The difference is that I write new functions on a daily basis, while I almost never need new control flow constructs. I wonder if perhaps you only think you rarely need new control flow constructs because you are using languages without good support for macros. Where a Lisp or Tcl programmer might just code up a true DSL (cf. CLOS or the condition system), perhaps you just write functions, never realising how much more readable and understandable your systems could be.