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

Hy 1.0 – Lisp dialect for Python

github.com

Post reply on HN
Print view View original

81–90 of 131 posts

Re: Hy 1.0 – Lisp dialect for Python

#81

Post by bachback »

notepad0x90 wrote: post #77

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

Code thats written in Lisp is using AST differently. It makes the process of generating machine code much easier. This in turn enables macros which is meta programming not available in non Lisp languages. However on the other hand I tried this avenue and since most modern computing is not Lisp based it severely limits its potential. I'm hoping for a Rust based Clojure or variant. Clojure has the problem its based on the java ecosystem which has severe downsides. A lisp thats based on python doesnt make much sense to me personally python isnt a good language to write other languages in. I think Zig and Rust would be the interesting choices. One attempt: https://github.com/clojure-rs/ClojureRS

See also: https://paulgraham.com/avg.html

Re: Hy 1.0 – Lisp dialect for Python

#82

Post by notepad0x90 »

bachback wrote: post #81
notepad0x90 wrote: post #77

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

Code thats written in Lisp is using AST differently. It makes the process of generating machine code much easier. This in turn enables macros which is meta programming not available in non Lisp languages. However on the other hand I tried this avenue and since most modern computing is not Lisp based it severely limits its potential. I'm hoping for a Rust based Clojure or variant. Clojure has the problem its based on…

Wouldn't it make more sense then to compile existing languages to a Lisp? From what you said, it sounds like the goal of Lisp making generation of machine code faster/easier? Or is it that forcing programmers to encode there intent into a Lisp removes guessing and optimization overhead for the compiler?

Re: Hy 1.0 – Lisp dialect for Python

#83

Post by __mharrison__ »

anovick wrote: post #29
chrisrink10 wrote: post #18

Earlier quoted context omitted.

I haven't used Hy, but I am the maintainer of a Basilisp which also compiles to Python and aims for reasonably close compatibility with Clojure if you're interested. https://github.com/basilisp-lang/basilisp

Cool project! Wondering how custom immutable data structures fit in with the Python ecosystem. Particularly, I know that NumPy arrays and Pandas Series/DataFrames are the popular data structures used in research computing in Python (for Statistics, Data Science, Machine Learning etc.). These data structures afaik are mutable, however (for performance reasons), so at least the aspect of immutability from Clojure canno…

Most pandas experts recommend against mutating (or using inplace=True) with pandas.

Re: Hy 1.0 – Lisp dialect for Python

#84

Post by BeetleB »

wrycoder wrote: post #68
BeetleB wrote: post #28

Any downsides to using Hy (over Python)? Other than my coworkers don't know Lisp? More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using Hy?

Sure - you are piling another transpilation layer on top of already slow Python. Why not just use something closer to the metal: Common Lisp, Scheme, Clojure, Racket? Especially, use a compiled language, instead of an interpreter.

I do use Racket. And over half the time I switch to Python because I don't want to author libraries that already exist in Python.

Re: Hy 1.0 – Lisp dialect for Python

#86

Post by cess11 »

notepad0x90 wrote: post #82
bachback wrote: post #81

Earlier quoted context omitted.

Code thats written in Lisp is using AST differently. It makes the process of generating machine code much easier. This in turn enables macros which is meta programming not available in non Lisp languages. However on the other hand I tried this avenue and since most modern computing is not Lisp based it severely limits its potential. I'm hoping for a Rust based Clojure or variant. Clojure has the problem its based on…

Wouldn't it make more sense then to compile existing languages to a Lisp? From what you said, it sounds like the goal of Lisp making generation of machine code faster/easier? Or is it that forcing programmers to encode there intent into a Lisp removes guessing and optimization overhead for the compiler?

You can invent another syntax with Lisp/Scheme macros if you want. When compiled or interpreted it will be macro-expanded, and then likely transpiled to an AST and then compiled into byte- or machine code.

Take a look at Racket languages for some examples.

Lisp syntax with the parens and so on means editing is inherently structural, which makes it relatively easy to reason about and restructure the code. In Python spaces have double meanings, both as separator between tokens and as a block separator, similar to e.g. {} or () in other languages. That makes structural editing relatively hard.

Re: Hy 1.0 – Lisp dialect for Python

#87

Post by bachback »

notepad0x90 wrote: post #82
bachback wrote: post #81

Earlier quoted context omitted.

Code thats written in Lisp is using AST differently. It makes the process of generating machine code much easier. This in turn enables macros which is meta programming not available in non Lisp languages. However on the other hand I tried this avenue and since most modern computing is not Lisp based it severely limits its potential. I'm hoping for a Rust based Clojure or variant. Clojure has the problem its based on…

Wouldn't it make more sense then to compile existing languages to a Lisp? From what you said, it sounds like the goal of Lisp making generation of machine code faster/easier? Or is it that forcing programmers to encode there intent into a Lisp removes guessing and optimization overhead for the compiler?

yes, you can think of Lisp almost as an intermediate language. Lisp probably lends itself well to machine code generation but I haven't done enough assembly to really know that. its not designed for that, its just a side effect of the language primitives being very very short. you can write a basic Lisp interpreter in a few hours yourself https://norvig.com/lispy.html. Creating a decent compiled language takes a lot longer than that. Lisp only requires 5 or so primitives and it doesn't have a grammar.

it is a bit ackward for humans but machines can process it better because it has less structure. for example what I thought is that Lisp could potentially be a great choice to interop with Large Language Models with, because its potentially shorter code. Good clojure code can be 5-10x shorter than python code. With LLMs size of code matters a lot.

Re: Hy 1.0 – Lisp dialect for Python

#88

Post by chr15m »

notepad0x90 wrote: post #77

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

Some concrete advantages that come from a simple, uniform, machine-readible syntax that your text editor itself can understand and manipulate:

- It makes editing and refactoring code faster. With a single keystroke you can do things like popping bits of code in or out of scope, deleting logical blocks of code etc. It's fast.

- It's hard to explain without trying it, but it is faster and less error prone to e.g. grab a section of code inside a function and break it out into a separate function. If your lisp is functional this is even smoother (hy is not as functional as it could be last time I checked).

- You never have to think about syntax. Python for example has different syntax for different operations and introduces new syntax relatively frequently. By contrast in a lisp the syntax for setting a variable looks the same as the syntax for looping and for everything else. It's all just function calls.

- If you have an nREPL set up (it's like the python repl but it's an API your editor can talk to) it makes it easier to run segments of code that are embedded inside other bits of code. E.g. you might have some complicated piece of maths or string manipulation in a function. You can run and try it out in isolation without executing the entire function.

- Metaprogramming. This is a bit overhyped for most programmers, but having the code as a data structure means you can add new language features from your own code, build DSLs, and have code that modifies other code more easily than in other languages. I try not to use metaprogramming and macros much, but I use a lot of things that smarter people than me have made with them.

These features are a bit hard to appreciate without trying them. Highly recommended!

Re: Hy 1.0 – Lisp dialect for Python

#89

Post by lispm »

chr15m wrote: post #88
notepad0x90 wrote: post #77

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

Some concrete advantages that come from a simple, uniform, machine-readible syntax that your text editor itself can understand and manipulate: - It makes editing and refactoring code faster. With a single keystroke you can do things like popping bits of code in or out of scope, deleting logical blocks of code etc. It's fast. - It's hard to explain without trying it, but it is faster and less error prone to e.g. grab…

> By contrast in a lisp the syntax for setting a variable looks the same as the syntax for looping and for everything else. It's all just function calls.

Not really.

Setting a variable in Lisp is not a function call. IF is also not a function call. Defining a function is also not a function call. Loop operations like DO, DOLIST, DOTIMES, ... are also not function calls. Lots of things are not function calls. Macro forms are also not function calls.

Post reply on HN