[HN Gopher] Hissp
___________________________________________________________________
Hissp
Author : tosh
Score : 26 points
Date : 2023-12-17 09:54 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| loganrios wrote:
| I've been keeping loose tabs on this and Hy[1] for a while, but
| I've had some trouble figuring out the major differences between
| them and the use-cases for either. Would love to see an in-depth
| comparison in the form of a blog post sometime (though maybe the
| answer here is to do the research and write one up myself).
|
| 1: https://hylang.org
| epgui wrote:
| Came here with the same question!
| nerdponx wrote:
| From the perspective of language design, Hissp strives to be
| more directly homoiconic, representing s-expressions as Python
| tuples. Hy is more of an abstract sexpr-to-Python compiler,
| with s-expressions represented as custom data types, rather
| than Python primitives.
|
| From the perspective of usability, Hissp is very minimalistic
| overall. Whereas Hy is both much more Python-like in its user
| experience _and_ provides much more of a batteries-included
| experience like you 'd find in Common Lisp or Clojure (and in
| fact its standard library takes a lot of inspiration from
| both).
|
| I consider Hissp as more of an interesting experiment in
| language design than a practical programming language. Whereas
| I think Hy is very practical and I've been very happy to use it
| for various scripts over the years.
|
| That's not to say Hissp is a _bad_ project by any means. It 's
| impressive, and I admire its dedication to its own principled
| consistency. I just don't find it very practical.
|
| The downside of Hy is that they've gone through several radical
| design changes over the years, but that finally seems to be
| stabilizing.
___________________________________________________________________
(page generated 2023-12-18 23:01 UTC)