5 ms·

> The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. That's the thing that

by adwn 6y ago

> The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. It's not the case that others don't see the light and don't grok the power and flexibility that those languages bring, but that those don't really matter that much in most practical use cases, and that they're even detrimental to building and maintaining a large code base with multiple developers. 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!). [1] I don't mean to imply that you're one of them, I'm talking in general.

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.
mschaef 6y ago
> That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. ... but that those don't really matter that much in most practical use cases, This statement does a good job of summarizing where I've landed on these sorts of languages, myself. Viewed in terms of Amdahl's law, the most you can improve a system by adjusting a single component is the impact of that single component. From a systems development point of view, the most impact you can have by changing programming language is to eliminate or reduce the cost of expressing your system's processes in a form the machine can understand. Notably, this still leaves open most or all the other problems that beset software projects. The requirements are still under specified, the team is still subject to staffing constraints, funding still has to be justified and acquired, legal and business and scheduling constraints are all still there, and is the business viable at all in the timeline that you have? [1] The list goes on and on... and because the language doesn't really help, the value prop for niche languages goes way down. That negativity aside, I do see potential counterarguments to this in the fact that an expressive enough language can help you improve your process to the point where you get answers faster and more reliably. But even that argument requires both a leap of faith and the willingness to take on the risks that implies. 1] Looking at this list, it's written in a way that might seem to imply startup/VC-funded project work - but that's not intentional. Those issues are also almost all faced by internal corporate development projects - either IT or for externally facing projects. > [1] I don't mean to imply that you're one of them, I'm talking in general. I didn't think you were, but thanks! :-)
cmacleod4 6y ago
Ok, you don't often need to build your own control flow constructs, but it was exactly that capability that allowed the very successful Expect utility to be built on top of Tcl - https://en.wikipedia.org/wiki/Expect https://en.wikipedia.org/wiki/Expect .

by adwn 6y ago

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.

mschaef 6y ago

> That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. ... but that those don't really matter that much in most practical use cases, This statement does a good job of summarizing where I've landed on these sorts of languages, myself. Viewed in terms of Amdahl's law, the most you can improve a system by adjusting a single component is the impact of that single component. From a systems development point of view, the most impact you can have by changing programming language is to eliminate or reduce the cost of expressing your system's processes in a form the machine can understand. Notably, this still leaves open most or all the other problems that beset software projects. The requirements are still under specified, the team is still subject to staffing constraints, funding still has to be justified and acquired, legal and business and scheduling constraints are all still there, and is the business viable at all in the timeline that you have? [1] The list goes on and on... and because the language doesn't really help, the value prop for niche languages goes way down. That negativity aside, I do see potential counterarguments to this in the fact that an expressive enough language can help you improve your process to the point where you get answers faster and more reliably. But even that argument requires both a leap of faith and the willingness to take on the risks that implies. 1] Looking at this list, it's written in a way that might seem to imply startup/VC-funded project work - but that's not intentional. Those issues are also almost all faced by internal corporate development projects - either IT or for externally facing projects. > [1] I don't mean to imply that you're one of them, I'm talking in general. I didn't think you were, but thanks! :-)

cmacleod4 6y ago

Ok, you don't often need to build your own control flow constructs, but it was exactly that capability that allowed the very successful Expect utility to be built on top of Tcl - https://en.wikipedia.org/wiki/Expect https://en.wikipedia.org/wiki/Expect .