I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
Any sort of self-referential data structure, e.g. doubly linked lists.
Lisp-stick on a Python
71–80 of 170 posts
Re: Lisp-stick on a Python
#72I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
Considering Lisp was here first, shouldn't the real question be "why use Rust/C++/Python when there's Lisp?" You can't even create a real closure in Rust. I'd love to see 10 lines of Rust that showed me something that: 1. I can't easily do in Lisp. 2. Actually matters in practice.
Re: Lisp-stick on a Python
#73See also PEP 638 – Syntactic Macros https://peps.python.org/pep-0638/
Giving people the ability to create more useless unsupported DSL in a world where people think YAML dialects in the CI was a good idea will damage Python in the long run. And I say that while I wished I could use macro several times in Python because the syntax was lacking.
I mean maybe the council will go with it, but I'm bearish.
I do really like the idea of jit macros and zero-overhead decorators though.
Re: Lisp-stick on a Python
#74I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
I mean the famous example is of course, (define (eval exp env) (cond ((number? exp) exp) ((string? exp) exp) ((symbol? exp) (lookup exp env) ((eq? (car exp) 'quote) (cadr exp)) ((eq? (car exp) 'lambda) (list 'closure (cdr exp) env)) ((eq? (car exp) 'cond) (eval-cond (cdr exp)) (else (apply (eval (car exp) env) (eval-list (cdr exp) env))))) which uses a Lisp to define itself. This means roughly that if you understand…
In addition to that, Lisps are sufficiently flexible that before CLOS itself was developed people were extending Lisp in Lisp to try out different object oriented models that fed into what became CLOS. That's hard to accomplish in most other languages, if it's even possible without going to a third party tool or digging into the compiler itself.
Re: Lisp-stick on a Python
#75I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
Typedef the array, return that. One pitfall, it's not resizable.
Re: Lisp-stick on a Python
#76I've been hearing claims my entire programming career about how Lisp is supposedly "superior" to mainstream programming languages, but I've never seen a concise code example that actually demonstrates this. For instance, it's easy to demonstrate how Rust is superior to C: Just show a short piece of code where an array is returned from a function. In C, this will involve raw pointers and manual memory management with…
I mean the famous example is of course, (define (eval exp env) (cond ((number? exp) exp) ((string? exp) exp) ((symbol? exp) (lookup exp env) ((eq? (car exp) 'quote) (cadr exp)) ((eq? (car exp) 'lambda) (list 'closure (cdr exp) env)) ((eq? (car exp) 'cond) (eval-cond (cdr exp)) (else (apply (eval (car exp) env) (eval-list (cdr exp) env))))) which uses a Lisp to define itself. This means roughly that if you understand…
Any recommendations on good resources for learning Lisp to a degree that this program is understandable?
Re: Lisp-stick on a Python
#77Earlier quoted context omitted.
Considering Lisp was here first, shouldn't the real question be "why use Rust/C++/Python when there's Lisp?" You can't even create a real closure in Rust. I'd love to see 10 lines of Rust that showed me something that: 1. I can't easily do in Lisp. 2. Actually matters in practice.
This a trick question because 10 line programs are trivial. Please show me a high performance hardware-accelerated 3D game engine written in lisp. Or a web browser.
Re: Lisp-stick on a Python
#78Earlier quoted context omitted.
Considering Lisp was here first, shouldn't the real question be "why use Rust/C++/Python when there's Lisp?" You can't even create a real closure in Rust. I'd love to see 10 lines of Rust that showed me something that: 1. I can't easily do in Lisp. 2. Actually matters in practice.
This a trick question because 10 line programs are trivial. Please show me a high performance hardware-accelerated 3D game engine written in lisp. Or a web browser.
Re: Lisp-stick on a Python
#79Earlier quoted context omitted.
Giving people the ability to create more useless unsupported DSL in a world where people think YAML dialects in the CI was a good idea will damage Python in the long run. And I say that while I wished I could use macro several times in Python because the syntax was lacking.
I'm likened to agree. As much fun as syntactic macros in python would be, and despite all the doors it would open, it would really kick up the potential complexity. Heck, folks were complaining about pattern matching and the walrus operator. I mean maybe the council will go with it, but I'm bearish. I do really like the idea of jit macros and zero-overhead decorators though.
Re: Lisp-stick on a Python
#80Earlier quoted context omitted.
I mean the famous example is of course, (define (eval exp env) (cond ((number? exp) exp) ((string? exp) exp) ((symbol? exp) (lookup exp env) ((eq? (car exp) 'quote) (cadr exp)) ((eq? (car exp) 'lambda) (list 'closure (cdr exp) env)) ((eq? (car exp) 'cond) (eval-cond (cdr exp)) (else (apply (eval (car exp) env) (eval-list (cdr exp) env))))) which uses a Lisp to define itself. This means roughly that if you understand…
> This means roughly that if you understand enough Lisp to understand this program Any recommendations on good resources for learning Lisp to a degree that this program is understandable?
But here is Norvig's Python eval for a Lisp:
def eval(x, env=global_env):
"Evaluate an expression in an environment."
if isinstance(x, Symbol): # variable reference
return env.find(x)[x]
elif not isinstance(x, List):# constant
return x
op, *args = x
if op == 'quote': # quotation
return args[0]
elif op == 'if': # conditional
(test, conseq, alt) = args
exp = (conseq if eval(test, env) else alt)
return eval(exp, env)
elif op == 'define': # definition
(symbol, exp) = args
env[symbol] = eval(exp, env)
elif op == 'set!': # assignment
(symbol, exp) = args
env.find(symbol)[symbol] = eval(exp, env)
elif op == 'lambda': # procedure
(parms, body) = args
return Procedure(parms, body, env)
else: # procedure call
proc = eval(op, env)
vals = [eval(arg, env) for arg in args]
return proc(*vals)
https://norvig.com/lispy.html (most of the way down that page)