freenode/#clim - IRC Chatlog
Search
3:27:46
nyef
beach: Here's a question for you: What is the difference between the concept for Quicklisp and the concept for ASDF-INSTALL?
3:29:38
nyef
I'm going to contend that the concept for ASDF-INSTALL is "to make it easy to install common lisp software".
3:29:56
nyef
And that the concept for Quicklisp is "to make it easy to install working common lisp software".
3:32:26
nyef
ASDF-INSTALL was popular until it broke down. Quicklisp is going to remain popular until either something better comes along, or whoever is doing the curation stops without a designated successor.
3:33:16
nyef
And it's not a matter of "just software" vs. "software and curation", but a matter of "solves an actual, painful problem".
3:36:07
nyef
Well, there's two sides to this. One is that ASDF-INSTALL completely failed to cover the actual use-case that it was trying to hit.
3:37:43
nyef
And the other is that for Quicklisp to exist, someone (Xach) had to decide that there was a problem, to realize that the solution would require maintenance over time in order to continue to solve the problem, and to resolve to *do that maintenance*.
3:39:35
nyef
Yes, deciding that a problem exists is easy enough, more or less. Correctly diagnosing the problem is harder, and that was the first failure of ASDF-INSTALL.
3:40:04
nyef
The problem wasn't "how do we install lisp stuff", it was "how do we install working, usable lisp stuff".
3:41:07
nyef
But ASDF-INSTALL quickly broke down, and now I'd be surprised if the machinery still works.
3:43:27
beach
Maybe it's more likely to find a successor to Xach than to danb because Quicklisp does solve the real problem?
3:44:17
beach
By the way, I think you missed the standing ovations when Xach was at ECLM the first time after he introduced Quicklisp.
3:45:32
nyef
It's about solving the right problem, in the right way. But it's also about *selling* the solution to both users and developers. And it's about actually doing the work.
3:46:19
nyef
Another example: SBCL. "We take the parts of CMUCL that make it a Common Lisp implementation, discard the rest, make it easier to build and maintain, and turn it into the best, most standard conformant Common Lisp implementation available for unix systems."
3:48:00
nyef
But that was basically the vision: "We do Common Lisp, starting from here, and we discard the rest."
3:49:09
nyef
SBCL is still maintained, though. stassats works on it still, dougk works on it still, I work on it on occasion, Xof at the very least still does the release management.
3:51:29
nyef
Another example: There are multiple Common Lisp LispOS projects out there. I can think of three off the top of my head, one of which is still actually being developed.
3:52:54
nyef
Some sort of vision for "this is what it means to be a LispOS" beyond "it's an OS, but written in Lisp!"
3:53:44
nyef
Because most of the LispOS discussions are basically "Let's write something that's just like ,existing-os but written in Lisp!"
3:55:15
beach
I think that's the main reason they are boring to me. I don't learn anything, and I find myself in endless debates, always about the same things.
3:55:28
nyef
It's a poorly-specified vision, for which nobody buys in on either the user side or the developer side, and then there's no execution.
3:56:43
nyef
"For a LispOS, we'll need a text editor, a web browser, a file manager, and an OS kernel. And the OS kernel is the interesting bit, so let's start with that!"
3:58:31
beach
There is too much excitement about "bare metal". That's the easy part in my opinion, and once you do that, you have a debugging hell.
3:58:33
nyef
It actually proved out my original concept, which was how to do the interrupt handling, but I got far too ambitious.
4:01:07
nyef
The idea was "we have managed to get some documentation and disk images and whatnot for the TI Explorer LispM, so we should write an emulator for it!"
4:02:09
nyef
So, this idea was sold, and a number of potential developers and potential users bought into it.
4:03:37
nyef
And do absolutely *no* emulation on it. It could disassemble the initial function, and that was it.
4:04:57
nyef
I couldn't even *run* the software, due to its broken design, and my broken computer at the time (I had a failing hard drive for swap space, and the emulator was allocating *four times* the *address space* of the machine for RAM).
4:06:19
nyef
Over the course of the next year, I retyped most of the shitty PDF scan documentation as text, while the mailing list wittered on about how hard it would be to implement function calling... And started porting the codebase to run on a bare-metal PC, because they wanted to turn it into a LispOS once the emulation worked.
4:07:47
nyef
One lesson here is that if you've sold developers on a vision, and then managed to completely stymie the execution, they *will* screw it up just to have something to do.
4:08:11
beach
I am very careful these days. I try not to sell anything that I am not totally convinced about myself (which in practice means "almost nothing").
4:09:06
beach
I never encourage people to help me out with SICL, Cleavir, Second Climacs, LispOS, etc.
4:09:34
nyef
Eventually, after a couple of exchanges during which I learned enough about the world file format that I could find my way around the virtual memory tables, locate the initial function, and disassemble functions myself, I got frustrated, gave up, and set out to see exactly how hard it was to do enough function calling to make actual progress in emulation.
4:10:19
nyef
And I had to do it in a fresh codebase, because, as I said, my then-current machine literally couldn't run the existing C++ codebase. Scary kernel messages because of the failing disk and all!
4:11:25
nyef
A couple of hours in, and I packaged what I had and posted a rant to the list. Basically, "here's how hard it isn't, get off your asses and make this happen".
4:12:11
nyef
But by that point I had some momentum on execution, and couldn't leave alone. A couple days later I packaged up a second version and announced it.
4:12:43
beach
I think the lesson here is to avoid creating the excitement, hoping this excitement is enough to get others to do the work for you.
4:13:47
beach
So I meant, if you have no intention or no means of taking on that responsibility, then do not create the excitement.
4:17:20
nyef
The thing is, it took basically less than three hours to show more progress on a fresh start than the existing project had shown in a year. There were people capable of doing the work, but for whatever reason, they were all telling themselves and each other that it was "too hard", and not even investigating to see if it really was.
4:17:36
nyef
And the other thing is that after I posted that second version, I got a patch submission within a couple of days.
4:18:47
nyef
Two or three of us basically ran with my new codebase, new releases every few days, until we literally ran into a lack of information.
4:20:24
nyef
So, they had sold themselves on doing this emulator, but then also sold themselves on it being too hard to actually implement.
4:26:00
nyef
So, my little toy there was called "exploiter", and it killed Explorer III. Once it ran into the wall, as it were, I decided to gather more information by writing a microcode disassembler for the machine, and that became "nevermore", which was written in CL (originally CMUCL, but eventually SBCL).
4:27:10
beach
What are your current plans, if any, for some participation in a project that will move things forward?
4:27:58
beach
You were talking about the "failure of free Common Lisp implementations" the other day, for instance.
4:29:23
nyef
But I'm thinking that there's a sort of "next level" beyond having a solid base implementation (SBCL, CCL, whatever), and a curated software installation system (Quicklisp).
4:31:39
nyef
So I'm simultaneously trying to figure out an overall metastrategy, this vision-sales-execution thing, and trying to figure out what using CL should be like *as a concrete experience*.
4:32:20
nyef
One of the provocative questions that I'm using is "what do I not do because even the thought of making the attempt is too painful to contemplate?"
4:33:58
beach
But it is usually when trying to debug some problem, and I find that my tools are not up to the task.
4:34:50
nyef
Here's one main thing: I don't do UI work, because none of the toolkits are particularly usable.