3 ms·
How is what you describe not the core of Lisp's philosophy?
by junke 10y ago
How is what you describe not the core of Lisp's philosophy?
- wcrichton 10y agoA good point that Lisp encapsulates a lot of the extensibility I describe, but I think there's two missing parts: a strong type system and a clear story for FFI. With Haskell (or Rust or Scala or OCaml or ...) you could take advantage of static type guarantees, both for productivity as well as for generating more efficient code. That isn't to say you can't type check Lisp code, but that you could get it for free with a statically typed language. For FFI, if your eDSL is going to be generating CUDA code or whatever, then you need a clear way to translate values between the two sides. This is easy for a language like Rust and is doable for languages like Haskell, but I don't know if anything like that has been tried for Lisp.
- junke 10y agoThe typing aspect is really not a problem to me, but I get what you mean (also, "strong" typing is different from "static" typing). It seems also that staged compilation is becoming more and more used in statically typed languages. As for interfacing with low-level code, this is basically a major aspect of why Common Lisp is appreciated. Interfacing with C libraries is done routinely (CFFI: https://common-lisp.net/project/cffi/manual/html_node/index.html#SEC_Contents https://common-lisp.net/project/cffi/manual/html_node/index....). You write shaders in Lisp, you can interface with CUDA, and so on.