4 ms·

All these "small lisps / lisp-in-go / lisp-to-xyz" are great and I do applaud the exercise and what is produced, and I also appreciate many of of these projects

All these "small lisps / lisp-in-go / lisp-to-xyz" are great and I do applaud the exercise and what is produced, and I also appreciate many of of these projects are for learning or fun projects. BUT if by chance you or your project is one of the more "serious lisps or next-lisp-vibes" hear his: Before you even think about speed or benchmarks(size,spec,speed,lang) remember we live in a connected world that is multi-core. First prize for your home-brew lisp that would make me sit up and take notice is if it has very easy net-libraries built-in (http (client + server), websocket, sse, json etc) I think that is one of the things Go(yes I know not every like it, but the real world usage is real) got right, the std lib was very "modern" at least to the point of real-world usability. Multicore is a close second prize :) Network-libs (stupid easy ones) and the concurrency concepts is the very first thing I look for in a lang or lisp-derivatives My 2cents :)

deleted 4y ago
[deleted]
ijidak 4y ago
Hard agree. Have you found any frameworks to be particularly good at this for C/C++?
- rlp 4y ago
  Maybe libuv? It's used by node and julia. It's not a full standard library by any means, but it would give you the event loop with async/networking/io/threading.
gibsonf1 4y ago
Why do you need to build them in when you can just load your favorite libraries that do these functions with https://www.quicklisp.org/ https://www.quicklisp.org/ , especially for http the great libraries by Fukamachi: https://github.com/fukamachi https://github.com/fukamachi parallel processing: https://lparallel.org/ https://lparallel.org/ etc. I'm very grateful that common lisp does not version up (like python), but you can always load a new or newer version of libraries with no impact on your core production code. (Such as a rewrite when the language gets a new version - this never happens with Common Lisp)
- rawoke083600 4y ago
  >Why do you need to build them Many of the projects I referred to are not "QL Compatible" [0] https://www.ale-lang.org/ https://www.ale-lang.org/ [1] https://github.com/nukata/lisp-in-go https://github.com/nukata/lisp-in-go [2] https://github.com/pixie-lang/pixie https://github.com/pixie-lang/pixie [3] https://github.com/candid82/joker https://github.com/candid82/joker (Clojure like) [4] https://janet-lang.org/ https://janet-lang.org/ (more Clojure like than lisp like, but still brilliant and very polished )
astrobe_ 4y ago
Multicore is not common at all in embedded, so there is no point in supporting that in this type of project. And even if you are in "fat" embedded (Raspi etc.), you might want to use just only one core anyway so that your system can do other things efficiently (or use less power). For interpreters like this, what you should be looking for is not direct support for this or that, but how easy it is to write bindings for that interpreter. In my opinion, what Lua offers is the yardstick there. Oh, and don't stop at FFI support. FFI is IMO generally the worst option as it introduces a lot of overhead both at programming time and/or at runtime. I have a personal interpreter - it's not Lisp-based but Forth-based (rule 48: everytime Lisp is mentioned on a forum, someone mentions Forth and vice-versa) - that is very easy to extend with libraries. I actually use it sometimes to experiment with libs. I have dabbled with most of the examples you give (and more). For tiny interactive interpreters aimed at embedded (otherwise for most people there's no point in the "smallest possible thing that can..."), what you should be looking for is not spoon-fed features, but how much control you have over the runtime. Well, that's my way of thinking for non-embedded stuff too.
- rawoke083600 4y ago
  I did not meant multicore solely for the embedded product space, I aimed my wishes a little too broad it seems :) There are many such projects that looks fantastic, embedded and non-ememmbeded that quickly fails a real world use even hobby'ish world usage :/ EDIT: FAIL as in it doesnt come with nice or easy to use network libs i have to roll my own. Also that is sorta my point, I dont want to extend/built libraries in 2022 I want to built connected programs and hit the ground running.
  - astrobe_ 4y ago
    I guess it depends on what you do. I usually work at low-level, so making lib interfaces myself is acceptable, but at a higher-level, one usually have to pile libs over libs to get anything done because that's the way things are done today (complexity is perceived as a non-issue as long as you can rely on some lib), especially on desktop and especially with most things related to "the web". DIY even for language bindings would take long, be exhausting, and probably not worth it for a prototype or a throwaway script.

deleted 4y ago

[deleted]

ijidak 4y ago

Hard agree. Have you found any frameworks to be particularly good at this for C/C++?

rlp 4y ago
Maybe libuv? It's used by node and julia. It's not a full standard library by any means, but it would give you the event loop with async/networking/io/threading.

gibsonf1 4y ago

Why do you need to build them in when you can just load your favorite libraries that do these functions with https://www.quicklisp.org/ https://www.quicklisp.org/ , especially for http the great libraries by Fukamachi: https://github.com/fukamachi https://github.com/fukamachi parallel processing: https://lparallel.org/ https://lparallel.org/ etc. I'm very grateful that common lisp does not version up (like python), but you can always load a new or newer version of libraries with no impact on your core production code. (Such as a rewrite when the language gets a new version - this never happens with Common Lisp)

rawoke083600 4y ago
>Why do you need to build them Many of the projects I referred to are not "QL Compatible" [0] https://www.ale-lang.org/ https://www.ale-lang.org/ [1] https://github.com/nukata/lisp-in-go https://github.com/nukata/lisp-in-go [2] https://github.com/pixie-lang/pixie https://github.com/pixie-lang/pixie [3] https://github.com/candid82/joker https://github.com/candid82/joker (Clojure like) [4] https://janet-lang.org/ https://janet-lang.org/ (more Clojure like than lisp like, but still brilliant and very polished )

astrobe_ 4y ago

Multicore is not common at all in embedded, so there is no point in supporting that in this type of project. And even if you are in "fat" embedded (Raspi etc.), you might want to use just only one core anyway so that your system can do other things efficiently (or use less power). For interpreters like this, what you should be looking for is not direct support for this or that, but how easy it is to write bindings for that interpreter. In my opinion, what Lua offers is the yardstick there. Oh, and don't stop at FFI support. FFI is IMO generally the worst option as it introduces a lot of overhead both at programming time and/or at runtime. I have a personal interpreter - it's not Lisp-based but Forth-based (rule 48: everytime Lisp is mentioned on a forum, someone mentions Forth and vice-versa) - that is very easy to extend with libraries. I actually use it sometimes to experiment with libs. I have dabbled with most of the examples you give (and more). For tiny interactive interpreters aimed at embedded (otherwise for most people there's no point in the "smallest possible thing that can..."), what you should be looking for is not spoon-fed features, but how much control you have over the runtime. Well, that's my way of thinking for non-embedded stuff too.

rawoke083600 4y ago
I did not meant multicore solely for the embedded product space, I aimed my wishes a little too broad it seems :) There are many such projects that looks fantastic, embedded and non-ememmbeded that quickly fails a real world use even hobby'ish world usage :/ EDIT: FAIL as in it doesnt come with nice or easy to use network libs i have to roll my own. Also that is sorta my point, I dont want to extend/built libraries in 2022 I want to built connected programs and hit the ground running.
- astrobe_ 4y ago
  I guess it depends on what you do. I usually work at low-level, so making lib interfaces myself is acceptable, but at a higher-level, one usually have to pile libs over libs to get anything done because that's the way things are done today (complexity is perceived as a non-issue as long as you can rely on some lib), especially on desktop and especially with most things related to "the web". DIY even for language bindings would take long, be exhausting, and probably not worth it for a prototype or a throwaway script.