Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

61–70 of 170 posts

Re: Lisp-stick on a Python

#61
post #27

Earlier quoted context omitted.

No, Python does not have tail recursion optimization, because Guido decided that he wanted to preserve stack frames for better tracebacks. The language team may revisit that decision someday. I assume you're referring to an optimization, because one can write tail recursion in any language that supports subroutines.

Thanks, that is what I thought, but didn't trust my memory. Yes, I did mean optimization - without it you can blow through your stack quickly (and the traceback will be long and redundant :)

Common lisp doesn't require tail call elimination either, fwiw

Re: Lisp-stick on a Python

#62
post #44

Wonder why not syntax totally common lisp so one does not need to change with switch to turn on certain or full Hy features. It is a bit confusing this partially Python partial Common Lisp then throw in a “!” for defmarco …

Hy has syntax primarily based on Clojure, but with big changes to get it closer to Python semantics. It bears little resemblance to CL for a reason.

Re: Lisp-stick on a Python

#64
post #60
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 can, without restarting my program: 1. Gather assembly level profiling information 2. Redefine & recompile a function 3. Gather new assembly level profiling I can iterate dozens of times between #2 and #3 in the time of a single incremental production build in rust (debug builds are not useful for gathering profiling data). Generally speaking it takes less than a second to recompile and load a source file, and it c…

Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

Re: Lisp-stick on a Python

#65

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.

Re: Lisp-stick on a Python

#66
post #60

Earlier quoted context omitted.

I can, without restarting my program: 1. Gather assembly level profiling information 2. Redefine & recompile a function 3. Gather new assembly level profiling I can iterate dozens of times between #2 and #3 in the time of a single incremental production build in rust (debug builds are not useful for gathering profiling data). Generally speaking it takes less than a second to recompile and load a source file, and it c…

Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

I haven't used VS in a decade, but you needed to restart your program after changing the code.

Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).

Re: Lisp-stick on a Python

#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 enough Lisp to understand this program (and the little recursive offshoots like eval-cond), there is nothing else that you have to learn about Lisp. You officially have read the whole language reference and it is all down to libraries after that. Compare e.g. with trying to write Rust in Rust where I don't think it could be such a short program, so it takes years to feel like you fully understand Rust.

Indirectly this also means that lisps are very close at hand for “I want to add a scripting language onto this thing but I don't want to, say, embed the whole Lua interpreter” and it allows you to store user programs in a JSON column, say. You also can adapt this to serialize environments so that you can send a read-only lexical closure from computer to computer, plenty of situations like that.

Aside from the most famous, you have things like this:

1. The heart of logic programming is also only about 50 lines of Scheme if you want to read that:

https://github.com/jasonhemann/microKanren/blob/master/micro...

2. Hygienic macros in Rust probably owe their existence to their appearance in Lisps.

C2 asks the same question here: https://wiki.c2.com/?LispShowOffExamples with answers like

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.

4. Over there a link shows how in 16 LOC you can implement a new domain-specific language to define and run finite state machines: http://www.findinglisp.com/blog/2004/06/automaton-cleanup.ht...

Re: Lisp-stick on a Python

#68
post #66

Earlier quoted context omitted.

Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

I haven't used VS in a decade, but you needed to restart your program after changing the code. Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).

Ten years ago, VS already had the "Edit and Continue" feature. But it's not very good compared to what you get in a Lisp environment. It's slow, there are restrictions on where/when it can be used, and it's possible for the edit operation to fail.

Re: Lisp-stick on a Python

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

Re: Lisp-stick on a Python

#70
post #66

Earlier quoted context omitted.

Doesn’t VS do that too though? Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

I haven't used VS in a decade, but you needed to restart your program after changing the code. Also, C++ linkage, while far faster than rust isn't the fastest thing, and compilation can be slow too (particularly with the popularity of header-only libraries).

No you don’t. Edit and continue in Visual Studio even works with C++ and it worked 20 years ago. It’s improved a lot recently.
Post reply on HN