3 ms·

Looks pretty neat, for the LISPy use cases out there. I think metaprogramming is a bit of an antipattern in most use cases(The more power the programmer has, t

Looks pretty neat, for the LISPy use cases out there. I think metaprogramming is a bit of an antipattern in most use cases(The more power the programmer has, the less the compiler/linter can follow it, just because... there's more possibilities). But for the stuff it that needs it, it seems to be unbeatable, and this seems to have type annotations, which fixes one of traditional lisp's ickiest things. Plus, having access to Python's libraries should make it possible to really evaluate what LISP can do by as a language, rather than having the choice mostly made by ecosystem size for a lot of projects. I prefer a much more predefined structure that fits in better with autocomplete, and focuses more on reuse than new ideas, but I could see some pretty amazing stuff being done in this, and it being a benefit to the Python community as well.

gilch 5y ago
Static analysis becomes less important in a language with a REPL and dynamic reloading. Analyze the code by running it and inspecting the results.
- eternityforest 5y ago
  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.
  - gilch 5y ago
    I'm not suggesting anyone stop writing tests. Rather I was referring to tools like Cider, which provide intellisense-like features by analyzing runtime state without static analysis: https://docs.cider.mx/cider/usage/misc_features.html#find-references https://docs.cider.mx/cider/usage/misc_features.html#find-re...

gilch 5y ago

Static analysis becomes less important in a language with a REPL and dynamic reloading. Analyze the code by running it and inspecting the results.

eternityforest 5y ago
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.
- gilch 5y ago
  I'm not suggesting anyone stop writing tests. Rather I was referring to tools like Cider, which provide intellisense-like features by analyzing runtime state without static analysis: https://docs.cider.mx/cider/usage/misc_features.html#find-references https://docs.cider.mx/cider/usage/misc_features.html#find-re...