5 ms·

Feels appropriate to say that Hylang is in version 1.0 alpha: https://github.com/hylang/hy/releases/tag/1.0a4 https://github.com/hylang/hy/releases/tag/1.0a4

Feels appropriate to say that Hylang is in version 1.0 alpha: https://github.com/hylang/hy/releases/tag/1.0a4 https://github.com/hylang/hy/releases/tag/1.0a4 That's Lisp over Python -- you can do data science properly in Lisp now using all you favourite Python packages. I repeat you can do data science properly in Lisp now.

zqkamp 4y ago
Well, Mathematica is lispy, and there is: https://www.wolfram.com/data-science-platform/ https://www.wolfram.com/data-science-platform/ I suppose Hylang is quite slow (and possibly has leaky abstractions). Ideally the main C/C++ libraries like libtorch should be wrapped in Common Lisp and not Python.
- mark_l_watson 4y ago
  You have a few options for this: The TH package wraps Blas, etc., and has MINST, GAN, etc. examples. My preference is using py4cl to use pre-trained TensorFlow models in Common Lisp. I wrote a short book on Hy that has some deep learning examples, but I don't use Hy that often any longer. I am looking forward to the 1.0 changes.
V1ndaar 4y ago
Maybe things have changed over the years. I've played around with Hy in 2017 and in the end felt like it combines the bad parts of Python with the bad parts of a Lisp. If you're forced to use Python it's usually because of one of 2 reasons: Either you need to work with colleagues on something (in which case almost certainly they wouldn't accept a lispified version of it) or because you need some of the libraries that are already implemented. In the latter case, you might say Hy is a good option. But why bind yourself to the slowness of Python when you could just as well use some fast Lisp (e.g. Common Lisp) that interacts with a Python interpreter similar to nimpy [0] from Nim? Not sure if such a thing already exists for CL, but it should be quite feasible to write and then you get access to all your Python library needs while actually using a better language for the rest of your code. But I'm all ears on the real advantages Hy provides aside from being neat. [0]: https://github.com/yglukhov/nimpy https://github.com/yglukhov/nimpy
- medo-bear 4y ago
  > Not sure if such a thing already exists for CL couple of solutions exist for this https://github.com/bendudson/py4cl https://github.com/bendudson/py4cl https://github.com/pinterface/burgled-batteries https://github.com/pinterface/burgled-batteries
  - portroyal 4y ago
    Shining light on another; https://github.com/lem-project/async-process https://github.com/lem-project/async-process
- rich_sasha 4y ago
  For me the sad thing was that there is no equivalent of let, progn and so on. It really felt like Python with a funny syntax (plus macros). I'm not lisp enough to make a macro, but supposedly, isn't let under the hood making a lambda function and calling it? That's within the confines of possibility in Python.
  - vidjuheffex 4y ago
    Might be worth a revisit, let is in version 1.04a and progn is called 'do'. It has a rather fast rate of development, which makes coding in it a bit of a moving target.
    - rich_sasha 4y ago
      ah good to know, I'll give it another shot!
Keyframe 4y ago

zqkamp 4y ago

Well, Mathematica is lispy, and there is: https://www.wolfram.com/data-science-platform/ https://www.wolfram.com/data-science-platform/ I suppose Hylang is quite slow (and possibly has leaky abstractions). Ideally the main C/C++ libraries like libtorch should be wrapped in Common Lisp and not Python.

mark_l_watson 4y ago
You have a few options for this: The TH package wraps Blas, etc., and has MINST, GAN, etc. examples. My preference is using py4cl to use pre-trained TensorFlow models in Common Lisp. I wrote a short book on Hy that has some deep learning examples, but I don't use Hy that often any longer. I am looking forward to the 1.0 changes.

V1ndaar 4y ago

Maybe things have changed over the years. I've played around with Hy in 2017 and in the end felt like it combines the bad parts of Python with the bad parts of a Lisp. If you're forced to use Python it's usually because of one of 2 reasons: Either you need to work with colleagues on something (in which case almost certainly they wouldn't accept a lispified version of it) or because you need some of the libraries that are already implemented. In the latter case, you might say Hy is a good option. But why bind yourself to the slowness of Python when you could just as well use some fast Lisp (e.g. Common Lisp) that interacts with a Python interpreter similar to nimpy [0] from Nim? Not sure if such a thing already exists for CL, but it should be quite feasible to write and then you get access to all your Python library needs while actually using a better language for the rest of your code. But I'm all ears on the real advantages Hy provides aside from being neat. [0]: https://github.com/yglukhov/nimpy https://github.com/yglukhov/nimpy

medo-bear 4y ago
> Not sure if such a thing already exists for CL couple of solutions exist for this https://github.com/bendudson/py4cl https://github.com/bendudson/py4cl https://github.com/pinterface/burgled-batteries https://github.com/pinterface/burgled-batteries
- portroyal 4y ago
  Shining light on another; https://github.com/lem-project/async-process https://github.com/lem-project/async-process
rich_sasha 4y ago
For me the sad thing was that there is no equivalent of let, progn and so on. It really felt like Python with a funny syntax (plus macros). I'm not lisp enough to make a macro, but supposedly, isn't let under the hood making a lambda function and calling it? That's within the confines of possibility in Python.
- vidjuheffex 4y ago
  Might be worth a revisit, let is in version 1.04a and progn is called 'do'. It has a rather fast rate of development, which makes coding in it a bit of a moving target.
  - rich_sasha 4y ago
    ah good to know, I'll give it another shot!

Keyframe 4y ago