Why Hy? (docs.hylang.org)

Went to install the package manually to try Hy out. Figured it was a niche/small enough language that it wouldn't have its own Doom module. I was wrong.

A language is homoiconic if code in that language is written using the syntax of data literals of that language.

In the case of most Lisps, code is written using the syntax of list and symbol literals. (There are other literals too, of course.)

    (I (usually) like apples)

is a nested list literal with four symbols. You can think of symbols as "interned strings"; they're written without quotes for convenience. It's not unlike

    ["I", ["usually"], "like", "apples"]

in Python, except I had to use actual strings instead of symbols because Python doesn't ship with a standard symbol type.

This is also a nested literal list:

    (loop for i below n do (print i))

but this happens to be a list literal that can be "run" (or in Lisp parlance, evaluated) as code.

Even with PyPy, or Python libraries that are themselves written in C?

They feel all limited to me :D I only did serious CL development but neither of those two especially attract me: they are less interactive (and that's my ideal and a daily joy), I don't need the Java ecosystem, I want to be lighter on resources… I take news about Red from time to time and it's still in its early phases it seems.

    1. Error thrown
    2. Go to line of code that threw error
    3. Fix code
    4. Eval fixed code
    5. Eval the thing that threw the error again (seeing everything pass)

    2.1 Eval function as debug
    2.2 Re-eval thing that threw error
    2.3 When in debugger inspect all locals and state, find the problem

oopsy, thanks, I was thinking about let (discussed below). (yep, I tried Hy but not for long, since I needed something more than Python)

If you're (very) motivated you could try MGL or CLML! https://github.com/melisgl/mgl - https://github.com/mmaul/clml - https://github.com/CodyReichert/awesome-cl#machine-learning

MGL's auhor [won](https://github.com/melisgl/higgsml) the Higgs Boson ML Challenge.

They didn't try Allegro CL's new parallel GC (see comments). Otherwise, yeah. It depends on one's use case, I guess.

With respect to concurrency, after a lot of experience operating async Python services, the thing that I look for is a single, standard, ubiquitous concurrency model. One of the biggest pain points for operating Python systems is some transitive dependency making a synchronous I/O call and blocking the whole event loop, causing timeouts in unrelated endpoints and often bringing the whole system down (healthchecks start to fail because the endpoint is blocked and then the supervisor kills the whole process/pod/etc).

This doesn't happen in Go or (presumably) languages that run on Erlang's BEAM VM because there is no sync I/O (from the event loop's perspective, anyway).

> What I look for in a language first is how good the support is for concurrency, and especially if it has a good, modern concurrent garbage collector.

...in which case you'll definitely not want to use Python either, and so are rather far out of place in this thread.

Re-define a class and have all objects automatically get updated to reflect the changes.

Evaluate arbitrary expressions mid-stack trace.

Run into a bug, get caught in an error, re-define the offensive function interactively, and re-run the computation before that point, all without stopping and restarting.

(Example real-world use-case: You re-define one of your REST API endpoints without having to restart your server or interrupt the request-flow, be it in test or—if you so desire—in prod.)

Change the class of an object at run-time.

Re-compile and re-load individual functions from your editor with your production, git-committed code. This one is huge. You use interactive and incremental development to, well, develop! Not side-by-side with your code, but in your code as well, at a fine-enough grained level.

Common Lisp was designed to be both interactive and incremental. It's not a bolt-on feature.

Jupyter notebooks and auto-reloading have a very different feel, and (dis)incentivize different qualities and processes of development.

This set of jupyter + autoreloads + editor features might get you close, but you won't be on par to CL's level. I'm thinking about CL's interactive debugger, and about language features that were thought with interactivity in mind. On an error, you get the interactive debugger, you can explore the stack frames and get to the erroneous function, change it, recompile it, come back to the debugger and ask it to resume progress from this point, and see execution pass. You didn't have to re-run the whole operation. If we can do that in Python, I've been in my cave for too long^^ As such, this is how debugging a complex program looks like in Python vs in CL: https://lisp-journey.gitlab.io/images/debugging-python-VS-li... (Ravenpack [1] is a company that does big data analysis and that uses CL, they gave some talks, maybe you'll find more practical reasons from them)

for the second point: https://mikelevins.github.io/posts/2020-12-18-repl-driven/

There might be more CL libraries than you think: https://github.com/CodyReichert/awesome-cl but I'm not that a zealot to say you can ignore Python's ecosystem, especially in certain areas…

[1]: https://www.ravenpack.com/

I don't think it's fair that you got down-voted for not knowing what Lisp-style interactive development offers beyond what ipython or jupyter offers. Many people don't know either and the proper response would be to explain, not to down-vote.

EDIT: I was made aware of the guidelines to not comment on voting, I apologize.

In addition to the comprehensive answers of reikonomusha and vindarel, I'll give you some specific things you can't do:

Jupyter notebook: you can't run it as normal code - that is, you can't import your notebook from another file. You also can't evaluate arbitrary regions of the notebook (it's cells, the whole thing, or nothing), or nested sub-expressions. You can't evaluate code in parallel - if you have a cell calling a function foo() in a loop, and you try to redefine foo() in another cell - impossible in Juypter, trivial in CL.

iPython + autoreload: you also can't redefine a foo() in a file when it's being called in a loop, docs state "reloads modules automatically before entering the execution of code typed at the IPython prompt". You don't get any sort of interactive debug-and-fix-up when you encounter an error. And so on.

But... by using Hy you're already learning a new super niche language. If you're going to learn a new language why not ditch Python and use something good?

Ecosystem size is really the only thing I can think of.

Why is it disappointing? It’s just a suggestion (take it or leave it), and links out to an interesting and well written article.

Not so easy question, especially because it depends of the implementation, but SBCL gives pretty good static type errors and warnings. Mostly, you get warnings at the function boundaries. It isn't complete like type checking in the modern languages, but it helps catch many errors. And quickly & interactively, because we compile our functions as we write them, with a keystroke (or the whole file, and from time to time, we build the whole project from scratch). So, coming from Python, that was superbly useful to me. This, everybody uses it. We can also add gradual typing to our variables and functions. It might help for the static checks, and it also gives hints for the compiler to speed things up. We can also declare our own types, but these won't be used for compile-time inference.

For a type-racket equivalent, we now have Coalton, it's like a Haskell on top of CL: https://github.com/coalton-lang/coalton/ Its author says:

--

Take this with a grain of salt, because I’m neither a user nor expert of Typed Racket, but:

    Typed Racket focuses more on the gradual typing of a given program. It has lots of features to make that easier, such as occurrence typing. Coalton is a separate, embedded language.
    Typed Racket achieves polymorphism through subtyping and and first-order type variables. Coalton achieves polymorphism through type variables, higher-kinded types, and type classes.
    Coalton, like ML and Haskell, focuses on defining objects by their properties and supported functions. This is a proposed way of having modular, reusable code. Typed Racket, as far as I can tell, has no such features.
    Coalton code can be fully inferred, so type annotations are not necessary. Typed Racket cannot.

All in all, I think the biggest and most important take-away is that Typed Racket goes through great effort to seamlessly blend with ordinary Racket. But that means Typed Racket has to compromise on type system features that can only be supported if you’re willing to change the language itself.

Coalton puts the type system first, opting for something close to Haskell, at the expense of not being a system for gradually typing Common Lisp, and instead being a separate language altogether.

---

They use it for their open-source quantum compiler and other things.

Have you tried Hissp yet?

What problems did you encoutner implementing 'let'? Shouldn't it be equivalent to lambda expressions somehow?

    (let [a 1]
      (defn foo []
        (setv a 2))
      (foo)
      (print a))

    a = 1
    def foo():
        a = 2
    foo()
    print(a)

    a = 1
    def foo():
      x = a
    foo()

    a = 1
    def foo():
      a = a
    foo()

    > UnboundLocalError: local variable 'a' referenced before assignment

    a = 1
    def foo():
      x = a
      a = 2
    foo()

    > UnboundLocalError: local variable 'a' referenced before assignment

    >>> a = 1
    >>> def foo():
    ...     a = globals()['a']
    ...     print(a)
    ...
    >>> foo()
    1

  >>> def foo():
  ...     import __main__
  ...     a = __main__.a
  ...     print(a)
  ...
  >>> foo()
  1

  user=> (let [a 1] (defn foo [] (def a 2)) (foo) (println a))
  1
  nil

    * (let ((a 1))
        (defun foo ()
          (setq a 2))
        (foo)
        (print a))
    
    2
    2

  def f():
      a = 1
      def g():
          nonlocal a
          a = 2
      g()
      print(a)

> In truth, I've never understood the fuss about `let`. It's taken a huge amount of Hy development effort, but it adds very little

My use case is Jupyter notebooks. With normal Python scoping you quickly accumulate a lot of global variables and you might accidentally use the wrong one. With let-bindings you have variables that clean up after themselves.

I completely understand the decision and applaud the fact that Hy seems to be going of a direction of being a much finer layer than it was previously (removing things from Hy itself and moving to Hyrule, for example).

On the other side I am quite torn about the decision. I quite liked the early releases of Hy where I could write a code that was much more familiar for me as a Clojure programmer. Still need to give a try to the new releases though.

Not really. I want to understand why the language is interesting. For instance, even though I know nothing about Lisp, I can guess that it supports booleans, integers, and floats. Tuples and complex numbers are kind of interesting. But then it goes on to strings and concatenation, which I already assumed were possible in Lisp.

Cool, I'm a Hy guy; glad to meet you. Hy in its early years imitated Clojure syntax much more closely, and Clojure compatibility may've been implicitly a goal even if it never got to the point of cross-testing. These days we prefer to think of Clojure as one of several possible influences.

Agreed. If odd scoping rules are the problem, we can possibly disqualify most lisps that have ever existed. Including all of the ones that John McCarthy had a hand in building.

For my part, I had similar "this doesn't feel quite like lisp" moments with both Hy and Clojure. And I ultimately realized that it's the mere presence of the base platform that gets me. With Racket, I'm used to feeling like I'm sealed off in my own lispy bubble. With Hy and Clojure, there are always bits of Python or Java (read: Not Lisp) hiding in the background. Many differences from other well-known lisps that I know are attributable to that base platform.

And that's a catch-22 situation. Objectively, they might be (and, IMO, are) good design decisions. But they're also covered in non-lisp cooties. I don't know why I should expect otherwise. Brains are weird.

Variables are function-scoped, not block-scoped. So you can do this:

    if 2 < 3:
        s = "Math works"
    else:
        s = "Math doesn't work"
    print(s)

Fennel made a really interesting choice in rigidly sticking to the lua semantics.

I think in isolation it would be a fairly bad choice, but in practice you get a drop-in replacement for lua that fixes every problem with lua.

I wouldn't want any other lisp to work like it does but damn I consider that thing my savior at this point. I've come to really hate lua and fennel bails me out every time.

I may be wrong about this, but having tried fennel recently, doesn't it have quasiquoting now? at least according to: https://fennel-lang.org/macros

Not Intellisense, but there is jedhy: https://github.com/ekaschalk/jedhy which can do completions. Last Hy version verified working for: Hy 0.16.0

Not sure I follow the logic. That sounds like running non-repeatable unit tests by hand.

You don't really have any help from the system, it's all on you to ve sure you've tested every code path, and it doesn't produce any formal report like a linter's "No warnings" message.

Nor can other devs repeatably do the same tests and get a list of warnings to work on, you can't automatically test the whole existing codebase when new static checking comes by, etc.

It's super useful for experimenting when you aren't sure of something, and it's great to have a debug console in the debugger, but I've never been that much of a fan of interactive programming in most cases.

Plus, the same annotations used for static analysis also drive modern intellisense type tools, so even the most quick casual project can still have some pretty great documentation with almost no time cost.