Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp-stick on a Python

docs.hylang.org

Post reply on HN
Print view View original

91–100 of 170 posts

Re: Lisp-stick on a Python

#91

Post by ericvsmith »

BiteCode_dev wrote: post #79
kortex wrote: post #73

Earlier quoted context omitted.

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.

I don't think you're likely to see zero overhead decorators any more than "zero overhead software" in general.

Take dataclasses: it adds a bunch of synthesized methods to a class, and needs to use "exec" to create them. How could that be zero overhead?

To help with this, I've proposed moving knowledge of dataclasses into the Python compiler, but even I don't think it's a great idea. For example, it would leave attrs in a disadvantaged position, and I don't want to do that.

Another option would be to move dataclasses before the code generator. Syntactic macros are one way to do that. Then there really would be zero overhead when loading the cached .pyc files. That's their appeal to me. Of course there are lots of other things that could be done with syntactic macros, which is both good and bad.

Re: Lisp-stick on a Python

#92

Post by ericvsmith »

kortex wrote: post #73
BiteCode_dev wrote: post #65

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.

I feel the same way. I'd love to use macros to implement dataclasses. But it does open the door for unreadable code.

I'm torn on the issue: I don't want to be restricted from improving dataclasses in what would be fairly obvious ways, but I'm sure the feature would be abused. But maybe this falls under the "we're all consenting adults" guideline.

Re: Lisp-stick on a Python

#93

Post by medo-bear »

p-e-w wrote: 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 program my numerical-heavy program in SBCL with much better interactivity and debugging than python can offer and with a much much better performence

as far as writing the actual code, lisp syntax allows me to perform structural editing which to me is just on another level

but as with all things in life, you should try before you buy

Re: Lisp-stick on a Python

#95

Post by recuter »

sgt3pr wrote: post #90
recuter wrote: post #88

Earlier quoted context omitted.

Lisp is absolutely superior and you should absolutely learn it but you'll never get concise examples as to why. Only jokes and anecdotes. How do you fix a waterlogged smartphone? Put out a bowl of rice, which attracts an Asian guy who will repair it for you. Languages have pedigrees. If you pretend like your company is enamored with javascript you'll get people who love fedoras and call themselves Ninjas. Big teams,…

Thank you, this made me start my day with roaring laughter.

https://www.youtube.com/watch?v=Uo3cL4nrGOk

Re: Lisp-stick on a Python

#96

Post by medo-bear »

jahewson wrote: post #72
jlarocco wrote: post #59

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.

> Or a web browser

https://nyxt.atlas.engineer/

Re: Lisp-stick on a Python

#97

Post by gpderetta »

lordgroff wrote: post #6
tomcam wrote: post #3

Earlier quoted context omitted.

I can imagine speed being a real problem in production?

You can transpile to Python. You get a bunch of necessary symbol definitions but that's about it. I doubt anyone uses hy in production for completely other reasons, would love to be proven wrong.

> You can transpile to Python

I can imagine speed being a real problem in production?

Re: Lisp-stick on a Python

#98

Post by flohofwoe »

p-e-w wrote: 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…

> whereas in Rust you just return a `Vec` and everything is taken care of

The downside is that you just performed a hidden heap allocation. If automatic memory management is desired, a garbage-collected language might have been the better choice in the first place.

Re: Lisp-stick on a Python

#99

Post by medo-bear »

jimbob45 wrote: post #64
aidenn0 wrote: 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?

> Also if you’re talking about performance or memory profiling, why are you using a Lisp in the first place?

common lisp can actually be really good performance-wise. its one of the things that made me switch from using python+c/cpp for my numerical work

Re: Lisp-stick on a Python

#100

Post by medo-bear »

aidenn0 wrote: post #60
p-e-w wrote: 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…

> Redefine & recompile a function

not just functions, but whole classes too

Post reply on HN