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

21–30 of 170 posts

Re: Lisp-stick on a Python

#21

Post by giantdude »

funklute wrote: post #15
giantdude wrote: post #10

I don't get it. I am a Smug Lisp Weenie. Lisp is not a syntactic sugar - the only reason it looks like it does is for metaprogramming. Those parens are not syntax - they indicate the underlying structure of the code, a tree which may be manipulated by Lisp macros. Why would anyone pretend to program in Lisp without any benefit? Also, Python is the worst imaginable engine for running Lisp. [correction: I see there are…

> Also, Python is the worst imaginable engine for running Lisp What exactly do you mean by this?

slow. bloated. not particularly good at managing conses. is there tail recursion?

Re: Lisp-stick on a Python

#22

Post by giantdude »

wiseowise wrote: post #13
giantdude wrote: post #10

I don't get it. I am a Smug Lisp Weenie. Lisp is not a syntactic sugar - the only reason it looks like it does is for metaprogramming. Those parens are not syntax - they indicate the underlying structure of the code, a tree which may be manipulated by Lisp macros. Why would anyone pretend to program in Lisp without any benefit? Also, Python is the worst imaginable engine for running Lisp. [correction: I see there are…

> Why would anyone pretend to program in Lisp without any benefit? Because it is superior way of writing a program. Pure, consistent and unambiguous.

It certainly is superior. Now get rid of the inferior part (python) and use SBCL. No more pretending to be a Lisper!

Re: Lisp-stick on a Python

#23

Post by ahungry »

giantdude wrote: post #10

I don't get it. I am a Smug Lisp Weenie. Lisp is not a syntactic sugar - the only reason it looks like it does is for metaprogramming. Those parens are not syntax - they indicate the underlying structure of the code, a tree which may be manipulated by Lisp macros. Why would anyone pretend to program in Lisp without any benefit? Also, Python is the worst imaginable engine for running Lisp. [correction: I see there are…

I believe homoiconicity is more related to the syntax than the underlying implementation - fans of homoiconic code use it to treat code as data (macros and eval) rather than to reason about performance concerns/having a transparency into the underlying implementation (see: Clojure).

Re: Lisp-stick on a Python

#24

Post by Foxboron »

kdmccormick wrote: post #18
wiseowise wrote: post #8

Earlier quoted context omitted.

People use Python in production, why not Hy?

There are plenty of reasons not to add a transpilation step to production code: * Looking at stack traces is suddenly so much harder and involves reverse-engineering the transpiler unless your transpiler is sophisticated enough that it can de-transpile the stack traces back to the source language. * You're adding a step to your build pipeline. * You're taking on the risk of bugs or security issues that may exist or b…

Hy isn't transpiled though, it's compiled into valid python bytecode so some of the traditional issues around transpilation doesn't apply to Hy.

Re: Lisp-stick on a Python

#26

Post by Foxboron »

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.

>I doubt anyone uses hy in production for completely other reasons, would love to be proven wrong.

When I was working on Hy, almost 10 years ago, there was a couple of Hy core devs that had managed to push some Hy code into production. I won't name names, but a known company used Hy when processing firewall rules (if i recall correctly).

I doubt that code is still being used, and I'm not aware of anyone beyond a couple of previous Hy core devs that managed to push Hy into production.

Re: Lisp-stick on a Python

#27

Post by xapata »

giantdude wrote: post #21
funklute wrote: post #15

Earlier quoted context omitted.

> Also, Python is the worst imaginable engine for running Lisp What exactly do you mean by this?

slow. bloated. not particularly good at managing conses. is there tail recursion?

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.

Re: Lisp-stick on a Python

#29

Post by giantdude »

skissane wrote: post #17
agumonkey wrote: post #11

Earlier quoted context omitted.

think of it as clojure to java, even without embodying the whole lisp ethos, it gives you a lispy base to write python code, plus extra niceties (threading -> IIRC) plus you get to benefit from paredit under emacs

Clojure is more than just a Lisp for the JVM – it is a Lisp for the JVM with a big focus on immutable data structures – whereas traditionally most Lisps put mutability first instead. There are other Java-based Lisps, such as Armed Bear Common Lisp (ABCL), which are more traditionally Lisp-like in this regard. I think Hy is more of a traditional Lisp, since it shares Python's native focus on mutable data rather than t…

That! Clojure is an elegant experiment with immutability. The implementation details of Clojure's datastructures are a pure joy to look at. JVM is an unfortunate choice as I see it, but it's a pretty solid system which is benefiting from decades of research on JIT, GC, etc, so not entirely unreasonable as a back-end.

I have few good things to say about Python, other than it sort of works. I classify it in the big-sack-of-stuff languages, along with Perl and shells. Not much elegance or style.

Re: Lisp-stick on a Python

#30

Post by xapata »

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 take the AST produced by Hy and produce Python with `ast.unparse`. https://docs.python.org/3/library/ast.html#ast.unparse
Post reply on HN