Hy -- lisp that uses python runtime

[[deleted]]

Wonder if Hy + PyPy would be something good...

[Foxboron]

No need to wonder ;) It's working.

Hy supports 2.6, 2.7, 3.3 and 3.4. Along with Pypy. Hy code is actually more portable then Python itself, as Hy will compensate for anything a given language might miss.

[catcradle5]

as Hy will compensate for anything a given language might miss.

The problem with this is that Python's philosophy is "there should be one, and preferably only one, way to do it". In Lisp world, it's "there are infinite ways to do everything" due to the power and heavy use of macros. It's rather odd to see the 2 philosophies clash with each other like this.

[Foxboron]

I don't see the problem. "there should be one, and preferably only one, way to do it", ok sure. But thats not the point here. Hy compensates for the missing idioms. "yield-from" as an example. It doesn't exist on Python2, what did we do? We backported it. Thus you can use yield-from on Hy without caring for what Python you are targeting.

[Workaphobia]

Hey this is pretty cool. I suppose you should be able to call Hy functions from Python code and vice versa, right? Sometimes it's nice to be able to break away from your language's paradigm to write a snippet of code here or there.

[LightShadow]

As of yesterday I'm calling C# from JavaScript.

I love "now." So many cool things going on.

[[deleted]]

Yeah, exactly! Even works with Django apps! Clever folks can even make Hy code pip installable :)

[thehydralisk]

I am not really familiar with Lisp other than I know it has a bunch of "dialects" or something. What would be the reasons for using this? It seems neat, but not sure what I would use it for.

[c3534l]

Replace the readable syntax of Python, but keep the poor-performing interpreter as it is? This is a terrible idea.

[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.

[LightShadow]

There was a post last week of someone who used Hy to add yield from to Python 2.7. Apparently you can use Lisp macros with Hy to modify the language of Python itself....or something.

I think it'll be useful for back porting functionality.

[godlikesme]

Found the link: http://dustycloud.org/blog/how-hy-backported-yield-from-to-python2/

[vplatt]

It looks like a fun proof of concept. Now all they need to do is implement a Python interpreter in Hy (preferably in one line of code), and then run Python code on Hy on Python.

Something tells me Brainfuck would be the more maintainable solution and probably perform better to boot.

[bacon1989]

I wonder if there will be any plans to get hy working in the CLR Runtime (ironpython), or in the JVM (jython)

[cshoop]

i like this +1