3 ms·

I'm not sure any language ecosystem, or operating system, has built a one-size-fits-all way of specifying dependencies. In Common Lisp specifically, you can ef

I'm not sure any language ecosystem, or operating system, has built a one-size-fits-all way of specifying dependencies. In Common Lisp specifically, you can effectively integrate with libraries (C ABI), but this heavily pivots on your definition of "effectively". One person's "effective" is another person's "impossible". For instance, for me, it is effective to $ brew install lapack $ sbcl * (ql:quickload :magicl) but it is not effective for a Windows user with a Visual C++ and commercially licensed Lisp implementation installed. We can ask ourselves many questions about improving packaging and deployment, with different trade-offs. For instance, maybe we put in a lot of effort in MAGICL's build system to fetch hosted dependencies if they don't exist. But then some users wouldn't want that, so we might add a configuration option. But then some users might not discover that, so we should add a build-time error message that points the user to the configuration. Alternatively, maybe we get Common Lisp's dependency manager (ASDF and Quicklisp) to integrate with something like Conda. That's possible if you take the time to implement it and persuade the respective maintainers it's a good idea. (It doesn't help if your customer doesn't use or doesn't want Conda, but c'est la vie.) What used to be a "installing the dependencies is your problem; I'm going to keep my own library build simple" has turned into a complicated morass of configuration and communication. Some ecosystems, like Python's, have put in person-decades to make this easy, and they're still full of problems and confusion. In this specific case, MAGICL is sometimes constrained to using portable Common Lisp because a customer does not want to (1) install conda on Windows and (2) wants to build the software from source. In fact, the customer isn't even using the linear algebra library directly, they're using an application which uses the library, which is why "just use numpy" isn't an option. Imagine the pain once you find out some customers deploy this software onto air-gapped networks requiring all code that goes onto the network to be in text form and auditable. :) Now we are truly in for a doozy. If your software is actually used, especially industrially, the "real world" sometimes just has really annoying corner cases, or users that have odd setups which you don't really empathize with. While seemingly obtuse (just install the damn dependency! it's one file!), using a little math to get something "for free" to get a larger program running without dependencies doesn't seem like such a bad deal.

aragilar 4y ago
Ah, I was arguing BLAS et. al. are effectively non-reimplementable (I'm aware of ATLAS and OpenBLAS, but I'd argue they demonstrate that it's a rare thing to be able to do). I would expect if people aren't willing to use existing tools like conda, then they understand they're going to need to put in the hard yards setting up a proper build environment. Presumably if people want to build everything from scratch, then they know how to set up a correct build environment, and know that they need trustworthy libraries which are numerically correct, rather than a library which hasn't been as rigorously vetted which in a easier-to-install language. If not, I'd be curious what they would do with security/cryptographic libraries, would they be happy with someone's custom SHA256 library that they'd knocked up to avoid needing to install openssl for example. I guess I expect people to treat numerical libraries in the same way as security/cryptographic libraries, as there's just as much subtlety in how those libraries need to be implemented.

aragilar 4y ago

Ah, I was arguing BLAS et. al. are effectively non-reimplementable (I'm aware of ATLAS and OpenBLAS, but I'd argue they demonstrate that it's a rare thing to be able to do). I would expect if people aren't willing to use existing tools like conda, then they understand they're going to need to put in the hard yards setting up a proper build environment. Presumably if people want to build everything from scratch, then they know how to set up a correct build environment, and know that they need trustworthy libraries which are numerically correct, rather than a library which hasn't been as rigorously vetted which in a easier-to-install language. If not, I'd be curious what they would do with security/cryptographic libraries, would they be happy with someone's custom SHA256 library that they'd knocked up to avoid needing to install openssl for example. I guess I expect people to treat numerical libraries in the same way as security/cryptographic libraries, as there's just as much subtlety in how those libraries need to be implemented.