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

91–100 of 131 posts

Re: Hy 1.0 – Lisp dialect for Python

#91

Post by anentropic »

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…

Surely all programming languages have machine-readable syntax?

Re: Hy 1.0 – Lisp dialect for Python

#94

Post by chr15m »

anentropic wrote: post #91
chr15m wrote: post #88

Earlier quoted context omitted.

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…

Surely all programming languages have machine-readable syntax?

They do. Parsing and manipulating it is easier with a LISP and this means the tooling to do so is ubiquitous because anybody can do it.

Re: Hy 1.0 – Lisp dialect for Python

#95

Post by chr15m »

lispm wrote: post #89
chr15m wrote: post #88

Earlier quoted context omitted.

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 fo…

Yes, my apologies, I should have said "it all looks like function calls".

Re: Hy 1.0 – Lisp dialect for Python

#96

Post by Kodiologist »

aitchnyu wrote: post #85

Does it (or other lisps) interact with Python static typing?

You can add all the same type annotations as in Python, but from what I've seen, type-checkers expect Python source text and don't just use standard Python introspection, so you'll need to use `hy2py` first to actually check your program's types.

Re: Hy 1.0 – Lisp dialect for Python

#97

Post by lispm »

chr15m wrote: post #95
lispm wrote: post #89

Earlier quoted context omitted.

> 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 fo…

Yes, my apologies, I should have said "it all looks like function calls".

  (let ((a 10) (b 20) c)
    (declare (type (integer 0 *) a b c))
    (setf c (* a b))
    c)
Above is a LET expression, a variant of a lambda application.

It does not look like a function call. It looks like an operator list form, with LET as the operator. The next element is not a function call or similar, but a binding list with three variable definitions, two of them having an init value. Next to the binding list is a declaration form, with a type declaration for the local variables. Then a sequence of forms, a body, which is evaluated top down and the last value ist returned. There is a setf form, for setting a variable. The variable in the setf form is not evaluated, it will be set to the value of the second argument.

Neither LET, DECLARE, TYPE, INTEGER, or SETF are functions. They have different syntax and/or semantics from function calls.

Thus we have:

* special control flow

* a LET syntax which is not looking like a function call

* a lexical scope created by LET

* a type declaration with special syntax

* special evaluation rules, unlike evaluation of a function form

A Lisp user will need to learn that IF, WHEN, AND, ... and a lot of other operators are not functions....

Re: Hy 1.0 – Lisp dialect for Python

#98

Post by vindarel »

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.

this 100%. We have some options today to run Python from CL when necessary:

https://github.com/digikar99/py4cl2-cffi

https://github.com/marcoheisig/lang

Re: Hy 1.0 – Lisp dialect for Python

#99

Post by nerdponx »

HexDecOctBin wrote: post #20

Congrats! Two questions: 1. Does it support REPL-driven development? (condition system, breakloop, etc.) 2. Is there a standalone distribution? Distributing python in itself is a hassle, ideal situation would be to simply distribute a single Hy binary that contains all dependencies within it (either statically linked or as a zip file extracted in tmp directory).

1. It supports the same set of features that python supports, which is pretty good when it comes to things like traditional step through and postmortem debugging. And CPython Supports a lot of internal hooks if you want to do really advanced dark magic. But it doesn't have anything like the condition system or handlers/restarts.

Re: Hy 1.0 – Lisp dialect for Python

#100

Post by Phiwise_ »

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?

By analogy, programmers like LISP over other syntax for the same reason that creative children like LEGO over other toys. It's not that the pieces in the box are more beautiful than any other individual example of molded plastic, but because they are purpose-built to be the maximizing mold such that a box full of them gives more flexibility and potential than a box of any other shape you might choose. Lisp syntax is the way it is to create a human-machine interface with as much similarity between the two sides as possible, so the human approaches machine power when you write code, and the machine approaches human reasonability when you inspect running code.

For examples, McCarthy's original purpose was to demonstrate the effectiveness of a symbolic differentiation process he had dreamt up, so he devised the syntax and meta-circular evaluator of lisp to make it maximally obvious from the program text that the differentiation system was mathematically correct, while keeping it maximally obvious from the program model definition that it was computationally concrete. In response to new trends in the programming field, Lispers write mind-bending books like "Let over Lambda", "The Art of the Metaobject Protocol", or "Software Design for Flexibility" to show that, when your syntax and model is right, you can radically change how you solve problems not by rewriting your spec or switching languages but by just adding more lisp to the lisp you already have, which has the same simplicity as radically increasing the sculptures a child can make by just adding more lego to the lego they already have.

Lisps, on the other hand, tend to add features as just more convenient versions of things they can already do: Macrology for self-adapting code? Just lisp functions on lisp data structures corresponding to lisp functions. Actors for a concurrent execution model? Lisp functions as lisp data parameterized by higher-order lisp functions. Composable continuations for error handling? A lisp function exploring a lisp data structure of lisp data structures of lisp functions. It's turtles all the way down. Paul Graham points out that you can understand the social hype the presence or absence of a feature like operator overloading as a consequence of friction-ful syntaxes, while lispers care much less because replacing a function you don't prefer with one you do for your use case is straightforward in a friction-free syntax. When he decided to build a reddit clone for tech entrepreneurs he didn't need an outside data system just to get started, he only had to spin up a pool of threads for sessions to directly modify s-expression literals in memory, which he could save or modify by printing straight to disk and load by just reading the lisp syntax back into memory like all lisp code is, with no execution intermediary like languages such as the Pythons tend to have complicating things enough to make comparatively big services like a whole database for a private gossip forum worth the effort. The syntax doesn't make lisp first-order beautiful, it makes lisp the hacker's local maximum, which is second-order beautiful, and honestly isn't much harder to get into the habit of reading once you know it's worth it.

Post reply on HN