5 ms·

As cageface notes - it's not that we can't "just use Lisp" - it's that the metaprogramming leverage added by those systems isn't the form of leverage that helps

As cageface notes - it's not that we can't "just use Lisp" - it's that the metaprogramming leverage added by those systems isn't the form of leverage that helps with shipping. You can achieve "good-enough" metaprogramming with an external code generator and customized checks in the build process. The lasting power of the C preprocessor and its crude lexical macros is a testament to how far you get with this "worse is better" level expressiveness. What production teams focus on instead tends to be the meat and potatoes aspects of libraries, documentation, build time, and debug time. A new user of Rust who writes C-like code can still benefit; they'll have to learn some things while fighting the borrow checker, and they may not have exactly the libraries they need(which can often be the showstopper) but their debug time will go down and their builds are likely to get simpler, if not faster. It is true that we could use more syntax that explicitly deals with concurrency, but that's also the thing that we have little agreement on.

orbifold 7y ago
What good meta programming gives you is that a lot of language features can become library features. A good example of be Julia’s differential equation support or its XLA support. A language like Swift needs to modify its compiler to do similar things.
- cageface 7y ago
  This is often not a good thing. You now have to version the library separately from the language itself and deal with dependency issues. Also you get competing and incompatible implementations of things everyone needs. This is exactly why people bag on JS for needing 600 node modules to build anything.
  - ddragon 7y ago
    Having to handle library versions and long library dependencies isn't a result of a programmable language, it's the result of having better tools for sharing and integrating code without having to reinvent and maintain independently everything for every tool, and that's generally a good thing (even if it has extra steps to solve over having everything imaginable already in the base language). And incompatible implementations are not really exclusive to metaprogramming either. Pytorch, Tensorflow, Numpy and the Python standard libraries are not compatible by default, each has to deliberately create (or not) tools to convert from one type to the other (or build entirely on top of the other). You can argue about the Lisp Curse, in which having a lower entry barrier to make your own tool makes it easier for each create it's own "perfect" one (which is flawed/lacking to everyone else), while languages in which the sunk cost is higher would make people gravitate towards something already created and improve it with their own use case. That's definitely true, but since that's something cultural then it can probably be handled in some way (for example deciding global common interfaces for interoperability, blessed packages for each domain and the most popular extensions of the language being promoted as official language feature after enough deliberation).

orbifold 7y ago

What good meta programming gives you is that a lot of language features can become library features. A good example of be Julia’s differential equation support or its XLA support. A language like Swift needs to modify its compiler to do similar things.

cageface 7y ago
This is often not a good thing. You now have to version the library separately from the language itself and deal with dependency issues. Also you get competing and incompatible implementations of things everyone needs. This is exactly why people bag on JS for needing 600 node modules to build anything.
- ddragon 7y ago
  Having to handle library versions and long library dependencies isn't a result of a programmable language, it's the result of having better tools for sharing and integrating code without having to reinvent and maintain independently everything for every tool, and that's generally a good thing (even if it has extra steps to solve over having everything imaginable already in the base language). And incompatible implementations are not really exclusive to metaprogramming either. Pytorch, Tensorflow, Numpy and the Python standard libraries are not compatible by default, each has to deliberately create (or not) tools to convert from one type to the other (or build entirely on top of the other). You can argue about the Lisp Curse, in which having a lower entry barrier to make your own tool makes it easier for each create it's own "perfect" one (which is flawed/lacking to everyone else), while languages in which the sunk cost is higher would make people gravitate towards something already created and improve it with their own use case. That's definitely true, but since that's something cultural then it can probably be handled in some way (for example deciding global common interfaces for interoperability, blessed packages for each domain and the most popular extensions of the language being promoted as official language feature after enough deliberation).