4 ms·

The whole "top of the power curve, all other languages are Blub" never was true. Consider Lisp and Haskell. When a Lisp user looks at Haskell, they know they'

The whole "top of the power curve, all other languages are Blub" never was true. Consider Lisp and Haskell. When a Lisp user looks at Haskell, they know they're looking down. No macros? How can you get anything done in Haskell? But when a Haskell user looks at Lisp, they also know they're looking down. No decent type system? How can you get anything done in Lisp? You have two languages, both looking down at each other, and both knowing why they're looking down. Something is wrong. I claim that what's wrong is the idea that languages can be ranked on a single-dimensional axis labeled "power". To those who think it can, I ask, power for what? For writing programs? Which programs? And don't say "general programs". I've never written a general program in my life. I've written a bunch of specific ones, though. What I actually care about is power for writing the specific program I'm trying to write. (Why would I care about power for writing the programs that I'm not trying to write?) So the really useful question is, what makes it hard to write the program that I'm trying to write? (I don't mean what problem the program is trying to solve. I mean, what things make it hard to write a program that solves that problem.) This may be a variety of things - team skills, algorithms, memory management, thread management, and so on. You can think of those things as a vector in a multidimensional space. Then, think of languages as a tree in that multidimensional space. Pick the language that is the branch that reaches the furthest in the direction of the vector that is the things that make it hard to write the program. (Oh, and libraries. The availability of libraries can make a huge difference.) Or, to state it without the metaphor: Pick the language that makes it easiest to write the program you're trying to write. For example, say you're Google, and you're writing programs that have to have large numbers of threads, and have lots of dynamic memory, and will be long-lived and worked on by a large number of people who have to be brought up to speed on the existing code. Go is a language that addresses that set of problems. Neither Lisp nor Haskell would work as well. They may be "more powerful" in some sense, but they're not more powerful for that program.

reikonomusha 2y ago
The whole point of Lisp is to allow you, the programmer, to make the language that makes it easiest to write the program you're trying to write. Said language will be syntactic abstractions in Lisp primarily built out of Lisp macros, but there are additional means available to integrate your language idea into Lisp outside of macros. So, really, Lisp is in exact agreement with your position, with one proviso: Pick the language that makes it easiest to write the program you're trying to write—and express that language in Lisp. Case in point: Lisp does have a powerful type system that rivals Haskell. Full type inference, multi-parameter type classes, parametric polymorphism. It's called Coalton[1], and it's... just another Lisp library. Whether or not you can be bothered to spend the effort to align Lisp to your domain is another question, but the mere fact it's both possible and reasonable to do is a testament to what some people mean by statements like "Lisp is powerful". [1] https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
- kazinator 2y ago
  This idea was popularized by Graham who wrote (in the very article this submission is about) that 20-25% of the Viaweb source code was macros, and made careless hyperbole like: "Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp." The idea has become oversold, and has caused some harm by giving rise to the circulation of reactionary "Lisp curse" type misinformation. Lisps are useful without the application programmer writing a single macro. Most Lisp coding style guides include a few words to discourage the writing of new macros. Macros, as such, help Lisp dialects themselves grow. That in turn helps programmers need to write fewer macros of their own. Macros are great for managing language growth and versioning. One example is that, within certain limits, it's easier to make a Lisp program work with an old version of its language implementation in which certain newer macros are missing, than to make programs in other kinds of languages work with older language implementations in which syntax is missing. Programmers using Lisp but not writing macros are certainly not missing the point of Lisp, let alone the entire point. You do not think about programs writing programs "all the time" when coding in Lisp; it is hyperbole.
  - reikonomusha 2y ago
    I disagree with you on many points. I do not claim that not using macros means that one cannot use Lisp usefully or profitably. It's a wonderful language even without macros, and I'm sure I'm preaching to the choir by listing all the reasons why. However, I do think adamantly that the "point" of Lisp really is syntactic abstraction. Why have S-expressions, code-as-data, symbolic data types, etc. otherwise? All of that is there to enable syntactic abstraction. If out-of-the-box Lisp is sufficient to express solutions to your problems reasonably, then I would wholeheartedly agree to not write macros. But if it doesn't? Well, Lisp is ready to offer a platform to make it happen. Lisp macros have been given a bad rap because of the plethora of almost useless examples of them. In any beginner book about Lisp, much ink will be spilt in little shorthands, like aif, with-gensyms, etc. Better examples would be actual, real life DSLs people use, like LOOP, lexical analyzers, web server routing, parallelization primitives, static typing, infix notation, etc. Things where gobs of functions and classes don't really capture the best way to denote the solution to a problem. Learning about macros, then being advised to never use them, to me, is miscommunication at best, a grave misunderstanding at worst.

reikonomusha 2y ago

The whole point of Lisp is to allow you, the programmer, to make the language that makes it easiest to write the program you're trying to write. Said language will be syntactic abstractions in Lisp primarily built out of Lisp macros, but there are additional means available to integrate your language idea into Lisp outside of macros. So, really, Lisp is in exact agreement with your position, with one proviso: Pick the language that makes it easiest to write the program you're trying to write—and express that language in Lisp. Case in point: Lisp does have a powerful type system that rivals Haskell. Full type inference, multi-parameter type classes, parametric polymorphism. It's called Coalton[1], and it's... just another Lisp library. Whether or not you can be bothered to spend the effort to align Lisp to your domain is another question, but the mere fact it's both possible and reasonable to do is a testament to what some people mean by statements like "Lisp is powerful". [1] https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton

kazinator 2y ago
This idea was popularized by Graham who wrote (in the very article this submission is about) that 20-25% of the Viaweb source code was macros, and made careless hyperbole like: "Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp." The idea has become oversold, and has caused some harm by giving rise to the circulation of reactionary "Lisp curse" type misinformation. Lisps are useful without the application programmer writing a single macro. Most Lisp coding style guides include a few words to discourage the writing of new macros. Macros, as such, help Lisp dialects themselves grow. That in turn helps programmers need to write fewer macros of their own. Macros are great for managing language growth and versioning. One example is that, within certain limits, it's easier to make a Lisp program work with an old version of its language implementation in which certain newer macros are missing, than to make programs in other kinds of languages work with older language implementations in which syntax is missing. Programmers using Lisp but not writing macros are certainly not missing the point of Lisp, let alone the entire point. You do not think about programs writing programs "all the time" when coding in Lisp; it is hyperbole.
- reikonomusha 2y ago
  I disagree with you on many points. I do not claim that not using macros means that one cannot use Lisp usefully or profitably. It's a wonderful language even without macros, and I'm sure I'm preaching to the choir by listing all the reasons why. However, I do think adamantly that the "point" of Lisp really is syntactic abstraction. Why have S-expressions, code-as-data, symbolic data types, etc. otherwise? All of that is there to enable syntactic abstraction. If out-of-the-box Lisp is sufficient to express solutions to your problems reasonably, then I would wholeheartedly agree to not write macros. But if it doesn't? Well, Lisp is ready to offer a platform to make it happen. Lisp macros have been given a bad rap because of the plethora of almost useless examples of them. In any beginner book about Lisp, much ink will be spilt in little shorthands, like aif, with-gensyms, etc. Better examples would be actual, real life DSLs people use, like LOOP, lexical analyzers, web server routing, parallelization primitives, static typing, infix notation, etc. Things where gobs of functions and classes don't really capture the best way to denote the solution to a problem. Learning about macros, then being advised to never use them, to me, is miscommunication at best, a grave misunderstanding at worst.