Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

71–80 of 170 posts

Re: Lisp-stick on a Python

#71
post #69
post #52

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.

Those can be implemented in Rust very easily by wrapping the recursive reference in a (safe) pointer type such as Box or Rc.

Re: Lisp-stick on a Python

#72
post #52

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…

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

#73

See 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'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

#74
post #67
post #52

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…

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…

> 3. The object model available in Common Lisp was more powerful than languages like Java/C++ because it had to fit into Lisp terms (“the art of the metaobject protocol” was the 1991 book that explained the more powerful substructure lurking underneath this object system), so a CL programmer could maybe use it to write a quick sort of aspect-oriented programming that would match your needs.

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

#75
post #52

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…

"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 all associated safety and security pitfalls, "

Typedef the array, return that. One pitfall, it's not resizable.

Re: Lisp-stick on a Python

#76
post #67
post #52

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…

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?

Re: Lisp-stick on a Python

#77

Earlier 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.

How about IDE with base codebase of 1.5M loc and tons of 3rd part packages? (emacs)? Most modern programming is not about performance, it is about managing complexity.

Re: Lisp-stick on a Python

#78

Earlier 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.

Emacs?

[0]: https://www.gnu.org/software/emacs/manual/html_mono/eww.html

Re: Lisp-stick on a Python

#79
post #73

Earlier 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.

Zero overhead exceptions are on the way so it would be natural for decorators to be next, even if it's likely way harder to implement given that decorators can basically do anything side effecty.

Re: Lisp-stick on a Python

#80
post #67

Earlier 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?

The Little Schemer would be a good resource. Some here may disagree, though. It uses a Socratic dialogue style that rubs some people the wrong way.

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)
Post reply on HN