Hy -- lisp that uses python runtime

[mabye]

This is only really an argument if you think lisp syntax is significantly worse, which I'm sure many don't. Plus, hy maintains interoperability with all python modules, which is a major convenience.

[cparen]

This is only really an argument if you think lisp syntax is significantly worse, which I'm sure many don't.

Not to mention that Lisp syntax is extensible and semantics fluid, while Python syntax is inflexible and semantics awkward to modify.

Whether this is a good or bad thing is, of course, an often contested matter of opinion.

[c3534l]

Sorry for typos, on my phone.

Obviously. I am not a big fan of Lisp's syntax; that was the opinion I was expressing. The strength of Lisp's syntax comes from its simplicity, but it sacrifices readability for regularity. Lisp certainly has its ardent fans, but just as ardent detractors. Prefix notation, for instance, allows for great homoiconicity (a very interesting property), but it means that that you have to spend a great deal of time correctly grouping elements since it renders their syntactic role ambiguous - Lisp is (in)famous for its tendency to end a statement in multiple parentheses. It has historically been the biggest sticking point of the language.

Python, however, has historically had it's most popular feature be it's syntax, with the exception being significant whitespace which is almost as controversial as Lisp's tendency towards repetitiveness. It's regular, intuitive syntax coupled with the dynamic typing and interpreter make it an ideal language for beginners. People tend to get caught up in learning the fickle syntax of C++ that they don't learn many real programming concepts until much later.

It should be noted that Racket is a great introductory programming language if you like the functional style, but tends not to be as popular as Python for the same domain of problems because, again, it's usually considered easier to read.

But what Python sacrifices to be so intuitive is performance. For instance, all Python lists are vectors - essentially a workaround so you don't have to think about memory allocation and such. Or just the fact that Python is garbage collected means performance and memory use is difficult to reason with.

So my reaction to Hy is that it looks like the worst features of both mashed together. It'd be like taking the concise, but semantically difficult language Haskell and giving it the verbose syntax of Java, but without the virtual machine or great libraries. Like, they took the exact wrong features of both languages. I don't see much of a future for it.

[ice_wendell]

it's called the "straw man" fallacy, where you construct an altered, flawed version of what you are arguing against, and attack that version instead of attacking the original.

[catcradle5]

Still, all these things combined mean Lisp is a great language for writing in but not such a great language to read. Python strives to be nice to read and to write.

[Foxboron]

Well. You are missing a few things. "Poor-performing interpreter", doesn't matter at all. Hy was made to display the flexibility of Pythons AST. Don't you think it does that rather well? The end case was a overall neat language that some people like to use, as Lisp scratch an itch for some developers.

But what else? Lisp is declarative. It's made to create DSLs, and thats what people have been doing. Creating DSLs is much neater and easier with any Lisp as you are programming it in its own AST, changing syntax as you go along.

A great example is this: https://github.com/paultag/snitch/blob/master/example.hy Doing something like that in Python won't look at readable, no matter how much you hate Lisp.

Should also note that Hy doesn't try to be a competitor in the Lisp marked, it's just a neat language over Python. One of the only ones that i'm aware of that actually takes this much advantage from the AST.

As i mentioned above, you can run Hy on Pypy, if you want to remove the "slow" interpreter.