3 ms·

> I would say that Lisp is good at two things: DSLs and ast manipulation is way easier than in other languages. If you need that, it is nice. I'm curious, when

> I would say that Lisp is good at two things: DSLs and ast manipulation is way easier than in other languages. If you need that, it is nice. I'm curious, when do we actually need that? I've been designing my own PL and one thing I realized early on was that we can either provide high level abstractions to increase the expressiveness of the language for problems that are far away from the machine (e.g., business logic which shouldn't be concerned with how you assign memory in loops), or we can let the users do that on their own. The second approach is Lispy, but that shifts the responsibility of creating abstractions to users. Users already make mistakes in trivial code; to give them the entire AST is mostly detrimental to them (it's like giving them a bigger gun to shoot themselves in the foot, if that makes sense). Everyone who reads a for loop in Python quickly groks it. But now imagine presenting it in its AST form... There's a reason much of our code doesn't look like AST—we are not computers; we think in terms of abstractions, concepts, etc. which may be cumbersome to present in AST format.

reikonomusha 2y ago
Funny, a macro serves the job you seek: (loop :for x :below 10 :do (print x)) This is a macro that presents a new abstraction/concept that's not "in AST format". It's a concept that's presented in syntax similar to any of the stock imperative languages. That's the raison d'etre of macro: to expose these concepts/abstractions/etc. in a direct manner. There are bad macros, to be sure, which are half-baked and underdocumented. That's no different a criticism from Python functions being 500 line god functions with boolean input flags, etc. Both cases are cases of bad code.
- germandiago 2y ago
  The loop macro one remarkably flexible Lisp macro. One that it could do so many things that I just let it go. Probably I did not code enough Lisp, but I am not sure it is a good idea to go so complicated. Python as an example, iteration is a concept: go over a range of things. Complemented with comprehensions that can transform/filter with regular syntax that is always the same (if, f(x) or whatever). Comapre it to this: https://lispcookbook.github.io/cl-cookbook/iteration.html https://lispcookbook.github.io/cl-cookbook/iteration.html Is that worth the trouble, seriously? For sure it is super powerful (Python looping is quite powerful also). But what is the cognitive overhead of that, with custom syntaxes included?
  - lispm 2y ago
    That cookbook article is a bad example, especially for normal users, since instead of explaining idiomatic cases of iteration, it explains several iteration constructs (where some are extremely complex) in one article: loop, iterate, for, mapcar, series, transducers Built-in, of those above, are mapcar and loop. Python iteration isn't so much about ranges, I thought. See: https://kinsta.com/blog/iterables-in-python/ https://kinsta.com/blog/iterables-in-python/
lispm 2y ago
> The second approach is Lispy, but that shifts the responsibility of creating abstractions to users. "You" can provide those syntax abstractions as macros. "You" can also use them yourself. But they then can be embedded in Lisp, you don't need to provide a new programming language version or even a new language & implementation with those abstractions. The user may be sophisticated enough to provide his/her macro abstractions.

reikonomusha 2y ago

Funny, a macro serves the job you seek: (loop :for x :below 10 :do (print x)) This is a macro that presents a new abstraction/concept that's not "in AST format". It's a concept that's presented in syntax similar to any of the stock imperative languages. That's the raison d'etre of macro: to expose these concepts/abstractions/etc. in a direct manner. There are bad macros, to be sure, which are half-baked and underdocumented. That's no different a criticism from Python functions being 500 line god functions with boolean input flags, etc. Both cases are cases of bad code.

germandiago 2y ago
The loop macro one remarkably flexible Lisp macro. One that it could do so many things that I just let it go. Probably I did not code enough Lisp, but I am not sure it is a good idea to go so complicated. Python as an example, iteration is a concept: go over a range of things. Complemented with comprehensions that can transform/filter with regular syntax that is always the same (if, f(x) or whatever). Comapre it to this: https://lispcookbook.github.io/cl-cookbook/iteration.html https://lispcookbook.github.io/cl-cookbook/iteration.html Is that worth the trouble, seriously? For sure it is super powerful (Python looping is quite powerful also). But what is the cognitive overhead of that, with custom syntaxes included?
- lispm 2y ago
  That cookbook article is a bad example, especially for normal users, since instead of explaining idiomatic cases of iteration, it explains several iteration constructs (where some are extremely complex) in one article: loop, iterate, for, mapcar, series, transducers Built-in, of those above, are mapcar and loop. Python iteration isn't so much about ranges, I thought. See: https://kinsta.com/blog/iterables-in-python/ https://kinsta.com/blog/iterables-in-python/

lispm 2y ago

> The second approach is Lispy, but that shifts the responsibility of creating abstractions to users. "You" can provide those syntax abstractions as macros. "You" can also use them yourself. But they then can be embedded in Lisp, you don't need to provide a new programming language version or even a new language & implementation with those abstractions. The user may be sophisticated enough to provide his/her macro abstractions.