9 ms·

Ultralisp: A fast-moving Common Lisp software distribution

164 points by lerax 7y ago

rini17 7y ago
uses: - docker - mailgun - s3 facepalm
- reilly3000 7y ago
  S3 is a protocol with a myriad of compatible providers. I wish the mailer was SMTP instead of an API. I don’t fully understand the issue with Docker; it’s widely accepted for software distribution and has a multitude of alternative runtimes that require very little config modification.
  - rini17 7y ago
    S3 is defacto proprietary protocol subject to AWS whims, such as recent v4 update of signing algorithm. Docker, while not proprietary, still subject to moving fast and breaking things, which was amply criticised here on HN. Common Lisp should stay a refuge from all the rug pulling around. While it's true that quicklisp is far from bedrock, adding volatile APIs into the mix won't help.
    - ivan4th 7y ago
      From my experience, Docker helps quite a bit with CL stuff in many cases. When you use some shared libs via CFFI, things can get fragile quick, start depending on a particular shared library version on the host system etc. So your app, for instance, works fine on Debian jessie, then you have to upgrade your host system to stretch and oops, it broke here and there. You update your quicklisp dist to fix shared lib incompatibility problem and oops again, you need a week to fix stuff that broke (this reflects some problems with CL library management, too), but you need to have your app up and running on the new system yesterday. If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example.
      - rini17 7y ago
        Right, CFFI is another can of worms. It is sometimes questionable whether the time saved by reusing C code isn't lost by debugging and integration issues. For example I ended up avoiding cl-async (a wrapper over a C library) due to these. In my mind reimplementing in CL is better bet than pulling Docker.
        amirouche 7y ago
        > I ended up avoiding cl-async What do you use instead?
        rini17 7y ago
        I reimplemented the parts I needed using threads+usockets. There's no fundamental reason it can't be built directly on OS async interfaces, even without threading, instead of C library.
        ivan4th 7y ago
        Well, I did write quite a bit of CL code for money, but it's hard to get paid for reimplementing every library that one may need in CL ;(
        rini17 7y ago
        I have not meant it in such extreme way at all :( Just this: if something interferes badly with a basic CL feature such as SLIME (cl-async does), toss it.
        ivan4th 7y ago
        cl-async works pretty well with SLIME if you use its SLIME REPL integration feature that I contributed several years ago. https://github.com/orthecreedence/cl-async/blob/master/src/repl.lisp https://github.com/orthecreedence/cl-async/blob/master/src/r... It basically starts an event loop in a separate thread and then wraps all of the SLIME's evals so they're executed from within that event loop.
- dang 7y ago
  "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." "Don't be snarky." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - rini17 7y ago
    Thanks. But it will get downvoted without explanation anyway.
dreamcompiler 7y ago
I don't understand what problem this solves.
- phoe-krk 7y ago
  In the contemporary Common Lisp ecosystem, software is distributed via Quicklisp[1], which is a centralized software repository, where, once a month, a new software distribution is created, encompassing the most recent releases of all software included in the dist. This means that changes in software can take up to a month to be reflected in Quicklisp. Ultralisp is a Quicklisp-compatible distribution, except it's a bleeding-edge one. Each time a piece of software included in it releases a new version/release/commit, a new dist is created, and the modified software is available in Ultralisp within minutes. [1] https://www.quicklisp.org/ https://www.quicklisp.org/
  - dreamcompiler 7y ago
    Ah. Understood. I solve this problem by forking every Quicklisp repo I use, and telling ASDF to look in my local clones first. This also solves the problem of making it easy to submit a pull request when I fix a bug in a Quicklisp library. Also -- and this is very important to me -- it means I'm in control of which version of every library I use. I've been burned too many times by Quicklisp "updating" a library that was previously working which doesn't any more. Now I have direct git control over my version coherency and I'm a happy camper.
    - taeric 7y ago
      Is this as easy to do as it sounds? Any chance you have documented any curves along the way?
      - dreamcompiler 7y ago
        It's all manual now but not that hard. Buried in Quicklisp are the locations of all its repos. The reason I haven't automated it is I don't know if there's a Github API for "Please fork this URI into my account if that's not already done." (Plus not every repo is on Github, and not every QL repo is a proper repo.) I haven't bothered to look into automating it because I don't use that many QL libraries, so manual operation is fine for me. Happy to work with you if you want to try to automate the process.
nextos 7y ago
Slightly tangential, but I wish some Lisp would make a serious comeback and challenge mainstream languages. For this purpose, libraries are essential. So better tooling would help, and that's why Ultralisp and Quicklisp are interesting. Clojure is very nice. I have used it for several projects. But sometimes I would prefer not to rely on Java libraries so much, and cleaner stack traces. Racket may get some critical momentum now, with the whole merge with Chez. I don't have high hopes for a Common Lisp implementation, as the ecosystem has become too fragmented and stagnant. But I wish I could be surprised here. Shen introduced some great ideas to make a powerful static typing an option in Lisp [1]. [1] http://www.shenlanguage.org/ http://www.shenlanguage.org/
- andrenth 7y ago
  Re statically typed Lisp, I’m keeping an eye on Carp [1] which seems to be a quite active project. [1] https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp
  - simias 7y ago
    Common lisp meets Rust, I'm intrigued. All these new exciting programming languages over the past ~5 years or so are quit exciting. I'm starting to believe that in the not so far future we'll look back on that time period between the late 90s up to the mid 2010s as some kind of a dark age for programming, where we kept using those inelegant, inefficient, hacky languages carried by Moore's law and an incredible demand for new software being written in huge quantity extremely fast, quality be damned. Now that the gold rush starts to cool down there seem to be a lot of very interesting work to take a few steps back and do it right.
    - neilv 7y ago
      I think your dark age and gold rush theory has some truth to it. The whole industry culture and practices changed during that period, but we're starting to see things like people interested in Rust, even though it's not pitched as a faster way to make slicker generic Web sites and phone apps. I'm also hoping that Racket (which is is like a secret oasis community) will get more attention, and someone will dust off some old Paul Graham writings about startups and Lisp, and some startups (probably ones who're not just doing another cookie-cutter madlibs startup) will decide to use Racket initially. (Disclosure: I have an interest in promoting Racket, because I'd love to help build startups in Racket, and also recruit top programmers with Racket as a carrot.)
dang 7y ago
Url changed from https://github.com/ultralisp/ultralisp https://github.com/ultralisp/ultralisp to the project page.
jlarocco 7y ago
I'm not sure this is a great idea. I have a couple projects in QuickLisp, and more than once I've broken them after I pushed incremental or non-working changes to my repo, didn't go back and fix them in time, and QL pulled the broken code. Developing in branches would solve the problem, but not everybody does that on smaller informal projects. On the other hand, I've also been annoyed waiting for bug fixes to trickle through to Quicklisp, so it's not an entirely bad idea...
- phoe-krk 7y ago
  The bleeding edge isn't for everyone. But then again, neither are monthly releases.
  - svetlyak40wt 7y ago
    Pinning libraries using Qlot solve the issue of being on the bleeding edge.
  - Grue3 7y ago
    Monthly releases + a few bleeding edge libs strategically cloned into /local-projects is the best strategy.
kristianp 7y ago
Are there any kind of Semantic-Versioning like controls?
- svetlyak40wt 7y ago
  Quicklisp and ASDF do not support semver. But you can use Qlot to pin some libraries to a particular version.

164 points by lerax 7y ago

rini17 7y ago

uses: - docker - mailgun - s3 facepalm

reilly3000 7y ago
S3 is a protocol with a myriad of compatible providers. I wish the mailer was SMTP instead of an API. I don’t fully understand the issue with Docker; it’s widely accepted for software distribution and has a multitude of alternative runtimes that require very little config modification.
- rini17 7y ago
  S3 is defacto proprietary protocol subject to AWS whims, such as recent v4 update of signing algorithm. Docker, while not proprietary, still subject to moving fast and breaking things, which was amply criticised here on HN. Common Lisp should stay a refuge from all the rug pulling around. While it's true that quicklisp is far from bedrock, adding volatile APIs into the mix won't help.
  - ivan4th 7y ago
    From my experience, Docker helps quite a bit with CL stuff in many cases. When you use some shared libs via CFFI, things can get fragile quick, start depending on a particular shared library version on the host system etc. So your app, for instance, works fine on Debian jessie, then you have to upgrade your host system to stretch and oops, it broke here and there. You update your quicklisp dist to fix shared lib incompatibility problem and oops again, you need a week to fix stuff that broke (this reflects some problems with CL library management, too), but you need to have your app up and running on the new system yesterday. If you wrap your CL app in a Docker image, you can continue running it on the prev distro version till you fix it to be compatible with the newer one. And that's just one example.
    - rini17 7y ago
      Right, CFFI is another can of worms. It is sometimes questionable whether the time saved by reusing C code isn't lost by debugging and integration issues. For example I ended up avoiding cl-async (a wrapper over a C library) due to these. In my mind reimplementing in CL is better bet than pulling Docker.
      - amirouche 7y ago
        > I ended up avoiding cl-async What do you use instead?
        rini17 7y ago
        I reimplemented the parts I needed using threads+usockets. There's no fundamental reason it can't be built directly on OS async interfaces, even without threading, instead of C library.
      - ivan4th 7y ago
        Well, I did write quite a bit of CL code for money, but it's hard to get paid for reimplementing every library that one may need in CL ;(
        rini17 7y ago
        I have not meant it in such extreme way at all :( Just this: if something interferes badly with a basic CL feature such as SLIME (cl-async does), toss it.
        ivan4th 7y ago
        cl-async works pretty well with SLIME if you use its SLIME REPL integration feature that I contributed several years ago. https://github.com/orthecreedence/cl-async/blob/master/src/repl.lisp https://github.com/orthecreedence/cl-async/blob/master/src/r... It basically starts an event loop in a separate thread and then wraps all of the SLIME's evals so they're executed from within that event loop.
dang 7y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." "Don't be snarky." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- rini17 7y ago
  Thanks. But it will get downvoted without explanation anyway.

dreamcompiler 7y ago

I don't understand what problem this solves.

phoe-krk 7y ago
In the contemporary Common Lisp ecosystem, software is distributed via Quicklisp[1], which is a centralized software repository, where, once a month, a new software distribution is created, encompassing the most recent releases of all software included in the dist. This means that changes in software can take up to a month to be reflected in Quicklisp. Ultralisp is a Quicklisp-compatible distribution, except it's a bleeding-edge one. Each time a piece of software included in it releases a new version/release/commit, a new dist is created, and the modified software is available in Ultralisp within minutes. [1] https://www.quicklisp.org/ https://www.quicklisp.org/
- dreamcompiler 7y ago
  Ah. Understood. I solve this problem by forking every Quicklisp repo I use, and telling ASDF to look in my local clones first. This also solves the problem of making it easy to submit a pull request when I fix a bug in a Quicklisp library. Also -- and this is very important to me -- it means I'm in control of which version of every library I use. I've been burned too many times by Quicklisp "updating" a library that was previously working which doesn't any more. Now I have direct git control over my version coherency and I'm a happy camper.
  - taeric 7y ago
    Is this as easy to do as it sounds? Any chance you have documented any curves along the way?
    - dreamcompiler 7y ago
      It's all manual now but not that hard. Buried in Quicklisp are the locations of all its repos. The reason I haven't automated it is I don't know if there's a Github API for "Please fork this URI into my account if that's not already done." (Plus not every repo is on Github, and not every QL repo is a proper repo.) I haven't bothered to look into automating it because I don't use that many QL libraries, so manual operation is fine for me. Happy to work with you if you want to try to automate the process.

nextos 7y ago

Slightly tangential, but I wish some Lisp would make a serious comeback and challenge mainstream languages. For this purpose, libraries are essential. So better tooling would help, and that's why Ultralisp and Quicklisp are interesting. Clojure is very nice. I have used it for several projects. But sometimes I would prefer not to rely on Java libraries so much, and cleaner stack traces. Racket may get some critical momentum now, with the whole merge with Chez. I don't have high hopes for a Common Lisp implementation, as the ecosystem has become too fragmented and stagnant. But I wish I could be surprised here. Shen introduced some great ideas to make a powerful static typing an option in Lisp [1]. [1] http://www.shenlanguage.org/ http://www.shenlanguage.org/

andrenth 7y ago
Re statically typed Lisp, I’m keeping an eye on Carp [1] which seems to be a quite active project. [1] https://github.com/carp-lang/Carp https://github.com/carp-lang/Carp
- simias 7y ago
  Common lisp meets Rust, I'm intrigued. All these new exciting programming languages over the past ~5 years or so are quit exciting. I'm starting to believe that in the not so far future we'll look back on that time period between the late 90s up to the mid 2010s as some kind of a dark age for programming, where we kept using those inelegant, inefficient, hacky languages carried by Moore's law and an incredible demand for new software being written in huge quantity extremely fast, quality be damned. Now that the gold rush starts to cool down there seem to be a lot of very interesting work to take a few steps back and do it right.
  - neilv 7y ago
    I think your dark age and gold rush theory has some truth to it. The whole industry culture and practices changed during that period, but we're starting to see things like people interested in Rust, even though it's not pitched as a faster way to make slicker generic Web sites and phone apps. I'm also hoping that Racket (which is is like a secret oasis community) will get more attention, and someone will dust off some old Paul Graham writings about startups and Lisp, and some startups (probably ones who're not just doing another cookie-cutter madlibs startup) will decide to use Racket initially. (Disclosure: I have an interest in promoting Racket, because I'd love to help build startups in Racket, and also recruit top programmers with Racket as a carrot.)

dang 7y ago

Url changed from https://github.com/ultralisp/ultralisp https://github.com/ultralisp/ultralisp to the project page.

jlarocco 7y ago

I'm not sure this is a great idea. I have a couple projects in QuickLisp, and more than once I've broken them after I pushed incremental or non-working changes to my repo, didn't go back and fix them in time, and QL pulled the broken code. Developing in branches would solve the problem, but not everybody does that on smaller informal projects. On the other hand, I've also been annoyed waiting for bug fixes to trickle through to Quicklisp, so it's not an entirely bad idea...

phoe-krk 7y ago
The bleeding edge isn't for everyone. But then again, neither are monthly releases.
- svetlyak40wt 7y ago
  Pinning libraries using Qlot solve the issue of being on the bleeding edge.
- Grue3 7y ago
  Monthly releases + a few bleeding edge libs strategically cloned into /local-projects is the best strategy.

kristianp 7y ago

Are there any kind of Semantic-Versioning like controls?

svetlyak40wt 7y ago
Quicklisp and ASDF do not support semver. But you can use Qlot to pin some libraries to a particular version.