I haven't just been directing my personal hacking/thinking time at massively distributed cellular automata. Remember when I said I was planning to put a bunch more work into cl-notebook1 when I had time? Well, guess what motherfuckers; we're doing this live.

I recently served on a contract for which my team had to use Jupyter Notebook, and I was pretty severely underwhelmed. I mean, the front-end has a level of polish you'd rightly never expect from a one-dev affair, and it has better cross-platform support than what I'm pulling off at the moment. But in terms of the big problems that I was tackling in the Common Lisp analog, I'm quite surprised to be ahead of the curve, even after having taken four years "off" development.

The things I was starting to think about were large problems like self-hosting, the implications of multi-user editing and how to best accomodate it, intelligent full-notebook loading and use on mobile devices. Not to mention the full-history system that I'd already built most of.

As far as I can tell, Jupyter has punted on all of the above.

So as much as I'd like to, I can't declare the situation Good Enough that I can in good conscience stop working on cl-notebook, even if the underlying languages were equivalent. Given that situation, I've been looking at the codebase and thinking about how I'd go about getting it from where it is now to being a worthy competitor to Jupyter in terms of ease-of-use. Or at the very least, to a state where I can easily start accepting pushes from other contributors.

And having pushed a commit to include general-location notebook opening, I think I've satisfied the second requirement.

There's a bunch of additional stuff noted in the READMEs TODO section, but the things that need to be settled before other people can credibly hack on this system have more or less been settled. I'd like to work out a system by which we can let notebooks materially change the client side of the system both through JavaScript and CSS additions, and I'm still debating whether we'd be better or worse off with a minibuffer added to the system, but those are relatively minor points that can be dealt with in a fairly self-contained way.

The next step for me is to start using it, and encourage other people to start contributing to the project.

:house fucking sucks. It performs poorly, coming in somewhere between hunchentoot and tornado on the woo benchmark graph, it doesn't deal with https, it doesn't easily support websockets and it's dumb in dealing with underlying system resources such as threads and static files.

... I can guarantee that'll be the effect of quickloading house on any system where you can install sbcl, clisp, lispworks, cmucl or ccl. Regardless of what package manager you use, or what architecture you're on, or whether you're running a massive, 12-processor piece of heavy iron or a RasPi, or something even more resource constrained.

After you clonegit@github.com:inaimathi/house.git into your local-projects directory, it will load, and it will fucking work without issue. Granted, the competition is superior along every other axis, but...

I want to stress that I have not failed to install the above "missing" native libraries. It's just that I use nix as a package manager, so they get installed in a directory that cffi doesn't expect. I've also tried installing the same through apt-get and still get similar errors. And don't even get me started on OS X or Windows setups of the same.

So, unfortunately, a much as :house sucks, I'm sticking with it, and working around its shortcomings. I've also got plans to submit it to quicklisp once I work up a reasonable test suite.

At that point, I won't have to take the clone step either.

And I just noticed that I started it in 2014, which puts it at 4 years old. Which means that I have both a child younger and a child older than this particular attempt at a cell-based editor. I feel fucking old.↩