[HN Gopher] Lisp-stick on a Python
___________________________________________________________________
Lisp-stick on a Python
Author : tosh
Score : 57 points
Date : 2022-11-14 20:58 UTC (2 hours ago)
(HTM) web link (docs.hylang.org)
(TXT) w3m dump (docs.hylang.org)
| teewuane wrote:
| What am I looking at here? And what is it for?
| Foxboron wrote:
| If someone thinks the Hy mascot, Cuddles the Cuttlefish, looks
| awfully familiar to a certain crustacean mascot, you would be
| correct!
|
| They are both drawn by Karen Rustad Tolva!
|
| https://www.aldeka.net/
| ashok-syd wrote:
| She has great Art and Designs - thanks for sharing the link to
| her bio/portfolio
| giantdude wrote:
| 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 some kind of macros...]
| wiseowise wrote:
| > Why would anyone pretend to program in Lisp without any
| benefit?
|
| Because it is superior way of writing a program. Pure,
| consistent and unambiguous.
| bloppe wrote:
| Surprising how not everybody picked up on the superiority of
| this.
| giantdude wrote:
| It certainly is superior. Now get rid of the inferior part
| (python) and use SBCL. No more pretending to be a Lisper!
| funklute wrote:
| > Also, Python is the worst imaginable engine for running Lisp
|
| What exactly do you mean by this?
| giantdude wrote:
| slow. bloated. not particularly good at managing conses. is
| there tail recursion?
| xapata wrote:
| 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.
| giantdude wrote:
| 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 :)
| Jtsummers wrote:
| > because one can write tail recursion in any language
| that supports subroutines.
|
| If only! For anyone else who got saddled with some
| FORTRAN 77 code, you may or may not have recursion
| available even with subroutines. It wasn't required by
| the language standard, but some implementations supported
| it. Not the one I "got" to use (and quickly moved on
| from) a while back, though.
| ahungry wrote:
| 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).
| agumonkey wrote:
| 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
| skissane wrote:
| 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.
| giantdude wrote:
| 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.
| lordgroff wrote:
| 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.
| thrown_22 wrote:
| 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.
| alschwalm wrote:
| Looks like it: https://docs.hylang.org/en/stable/api.html#let
|
| I recall hearing it had been implemented a while back, seems
| like it's true!
| thrown_22 wrote:
| Nice. They do seem to have filled out the language nicely.
| lordgroff wrote:
| Let is indeed there now.
| kagevf wrote:
| 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 :)
| [deleted]
| bragr wrote:
| Hylang is a great way to dip your toes into Lisp style languages
| IMHO since you have the entire python ecosystem at your
| fingertips. It was very eye opening to rewrite some scripts in
| Hy. I'm not sure if I'm ultimately a fan of lisp, but I had a lot
| of fun learning Hy a while back after discovering it in another
| HN post.
| tomcam wrote:
| I can imagine speed being a real problem in production?
| lordgroff wrote:
| 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.
| wiseowise wrote:
| People use Python in production, why not Hy?
| kdmccormick wrote:
| 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.
| Foxboron wrote:
| 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.
| skissane wrote:
| 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.
| xapata wrote:
| You can take the AST produced by Hy and produce Python with
| `ast.unparse`.
| https://docs.python.org/3/library/ast.html#ast.unparse
| Foxboron wrote:
| >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.
___________________________________________________________________
(page generated 2022-11-14 23:00 UTC)