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

11–20 of 170 posts

Re: Lisp-stick on a Python

#11

Post by agumonkey »

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…

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

Re: Lisp-stick on a Python

#12

Post by lordgroff »

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'm not sure what this comment is getting at to be honest. That is the benefit: that you can do macros and manipulate out the syntax in a way you never could in Python.

Re: Lisp-stick on a Python

#13

Post by wiseowise »

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.

Re: Lisp-stick on a Python

#15

Post by funklute »

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?

Re: Lisp-stick on a Python

#16

Post by bloppe »

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.

Surprising how not everybody picked up on the superiority of this.

Re: Lisp-stick on a Python

#17

Post by skissane »

agumonkey wrote: post #11
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…

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 trying to foreground immutability.

Re: Lisp-stick on a Python

#18

Post by kdmccormick »

wiseowise wrote: post #8
lordgroff wrote: post #6

Earlier quoted context omitted.

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.

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 be introduced to the transpiler itself.

* Your developers need to learn both the source and target languages.

* If the transpiler project is abandoned, you have to begin maintaining it yourself, or you need to de-obfuscate your transpiled code enough to make it your canonical code.

I think that anyone who used CoffeeScript in the late 2000s / early 2010s understands the pain of using a transpiled language that wasn't worth the trouble.

Not to say that one should never transpile, or that Hy's not worth it or not production ready! Just that, there are things to consider, and how much you need to consider them depends on what your "production" is.

Re: Lisp-stick on a Python

#19

Post by kagevf »

lordgroff wrote: post #7
thrown_22 wrote: post #4

Question from the last time this came up: have they added let/letrec into the language yet? The last time I it looked like they had not.

Let is indeed there now.

That's good news ... I thought they had added it but were forced to remove it. I think this will make Hy a bit easier to use, especially for those who are more comfortable with CL or Scheme than Python :)

Re: Lisp-stick on a Python

#20

Post by skissane »

wiseowise wrote: post #8
lordgroff wrote: post #6

Earlier quoted context omitted.

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.

People use Python in production, why not Hy?

If you write your code in Python, many team members or new hires will already know Python and hence be able to dive right in to the code base.

If you write your code in Hy, many people are going to have no idea. Small chance they already know it. A minority of people will have some background in Lisp, and if you already know both Python and another Lisp, learning Hy should be straightforward. But for a Lisp-naive developer, it is a big speed bump.

Also there is a lot of existing tooling around Python code – static analysis, etc – which might not be able to handle Hy. Sure, it can process the transpiled Python, but that produces a lot less pleasant experience for the developer. You really want native Hy tools, which are going to be behind native Python tools.

Post reply on HN