mikelevins

I use a lot of devices. There are 13 of them within arm's reach at the moment. I want a working environment where my "personal computer" is virtual, and it runs on whatever device I happen to be messing with, and it gives me my own personal workspace with access to my own personal stuff, without concern for which specific device I happen to be touching at the moment. Every property of computing that falls short of that is just a gratuitous obstacle to getting my work done.

The first time I thought I was approaching that kind of computing was 32 years ago. I was working on an experimental device with an experimental operating system at Apple. It didn't work out.

The second time I got closer. I was working at NeXT. I could go into any office on the NeXT campus (or into my home) and sit down to a NeXT machine and log into my personal workspace with access to all of my stuff configured the way I preferred it.

But then NeXT merged with Apple and the OS turned into the current macOS, which doesn't offer the same kind of ubiquitous computing experience at all. If anything, simple things like its ability to share files with a mixed network seems to be going backward.

So I reiterate: maybe something like this toy could eventually turn into the computing workspace I actually want, and if it has to use the web stack to do it, so be it.

"Expedient" connotes a choice that achieves a goal quickly and conveniently, possibly by sacrificing some important but difficult features, and incurring some undesirable costs or consequences.

So they're similar, but not identical. A pragmatic choice might be improved when you can afford it. An expedient choice will probably require some cleanup afterward.

I wrote bard, a Lisp that combines features of Dylan, Common Lisp, and pure-functional languages purely as a long-running experiment in what I could do to make programming more fun for myself. I subsequently used two versions of it in client projects (to prototype some solutions and to compile them to data used by the delivered product; nothing delivered to the clients depended on my weird Lisp dialect).

I wrote a tool called nym to help generate names for characters and other things in games and stories. It's enough fun in itself that I sometimes just play with it.

I wrote another tool called model-namegen to generate names with stricter constraints for science-fiction stories. Those names are mapped uniquely and reversibly to 64-bit integers used in the story to generate names for machine intelligences. I also wrote a prototype for a 3D multiplayer game called The Fabric set in the world of those stories, and wrote code to generate clusters of colored cubes for use as avatars representing the AIs. Each character's unique ID is mapped to a unique name and also to a unique 8x8x8 configuration of lighted cubes. An example name is Ixion Eleven Chrysotile, the name of the autonomous robot who is the narrator of my Fabric stories.

Following is a link to a very short movie of the avatar for the character Miriam Five Bittersweet Earth: https://evins.net/downloads/miriam-5-bittersweet-earth-2-2.m...

I wrote a couple of versions of a library for Common Lisp to make certain functional programming idioms I like more convenient for me in Lisp. They're called folio and folio2.

I wrote a library called taps that similarly makes use of Richard Waters' SERIES package for Common Lisp a bit more convenient for me. Actually, taps started as part of folio and I ended up wanting to use it on its own often enough that I broke it out separately.

I've written several little tools for calculating and keeping track of information that's useful for friends-and-family gameplay.

I've written several other libraries and applications purely for the purpose of exploring some idea or other that interests me. For example, beasties was a pond-life simulation that I used as a playground for recreational genetic programming. Panels was an experiment in user interface that used a constraint solver for laying out windows and widgets, and an append-only log of all UI events together with a query engine and a knowledgebase. Panels could display graphic representations of recent user activity and retroactively define mappings from sequences of events to user-defined handlers. It operated on the principle that everything detectable that a user did potentially had some purpose, even if we don't know what it is, so we should remember all the user's actions and offer them the opportunity to define what they meant.

I've also written a few little things primarily for the purpose of helping friends and family with this or that task.

I've spent a lot of time over the years on things like these. As you would expect, they've taken varying amounts of time and I don't really keep track of how much. I use some of them (e.g. taps and other pieces of folio) almost every day, and others intermittently. A few of them (such as beasties and panels) I haven't really touched in years now.

I'm primarily a guitar player with some ability to muddle through on piano on simple parts if I have to. The Linnstrument feels to me like a cross between a guitar and a piano. The notes are all laid out side-by-side like a piano, but in parallel rows like a guitar, and it respnds like a string instrument to wiggling your finger for tremolo or sliding it along the row for portamento.

In the default tuning the "strings" are tuned a fourth apart, like the lower 4 strings on a guitar, which helps a guitarist adapt quickly.

The sensors are quite sensitive, with very quick response, which makes it feel alive and responsive. It came with access to downloadable content that included MPE instruments for Logic Pro. I've used Logic for years, so I just made a reference project with all the supplied instruments in it and use that as a starting point for new projects that use the Linnstrument.

I quite happy with it and don't regret the price paid one bit.

Here's a little thing I made with it:

https://mic11.net/assets/audio/Ribbon.mp3

I did all the parts on the Linnstrument with Logic and my reference project.

A little later I used Norvig's Scheme implementation from chapters 22 and 23 of PAIP (https://norvig.github.io/paip-lisp/#/?id=paradigms-of-artifi...).

I liked Norvig's a little better. It starts with a simple interpreter and adds improvements step-by-step, winding up with an optimizing compiler that targets a bytecode VM.

That approach makes a lot of implementation details manifest in a way that is easy to grasp. For example, I think I understood continuations much better after seeing Norvig's account of how to implement them.

My experience was that it was a lot of fun with five or six players, but it tended to run quite long (three to five hours) and it was exhausting.

I think it’s quite educational about the legislative process. After a few games of Nomic one no longer wonders why it’s so hard for legislatures to get things done. One also gains a certain respect for the sheer stamina (and bladder control) of people who do it for a living, rather than as an occasional amusement.

I like to tell the story of one game in which a player, annoyed with the tendency of the players to lard up every proposed change with endless amendments, proposed a new rule that anyone who proposed a fourth amendment to a proposal under discussion would be doused with a glass of water. Everyone else was similarly annoyed with all the amendments, and so the new rule passed unanimously.

So that curtailed the amendments some, right? Ha ha, no. Rather, in short order everyone was soaking wet and the word "douse" had been redefined in the rules to mean dipping fingers in the glass of water and waving them in the target’s general direction.

Once I was fast and precise, with sharp close vision. Now I'm not.

Enjoy your capabilities while you have them. Decline awaits us all.

Wouldn't it be nice if there was a simple number or rule or formula? We're not that lucky. You have to pay attention, preferably with the help of sensible people who know you and have an interest in your continued well being. And yeah, that can be the luck of the draw, too.

I've worked in all permutations of your descriptions. If I believe in a project and can get good results on it, and much moreso if I'm having fun, I will work very hard. If I don't believe in it or have trouble getting good results or no one cares, then it's very hard for me to motivate myself.

Obviously, I prefer the situations where I'm highly motivated, and in fact I've worked very hard on some projects. Too hard, in fact.

The fact that a project is something you believe in, that you're highly motivated, that you can make a difference with it, or that you're having a lot of fun, doesn't make overwork healthy.

I've overworked myself a couple of times in my life. I hesitate to describe the worst case; I don't think readers will believe my description of what I did. Suffice to say that I worked on a new system project at Apple and was highly motivated to make it succeed (it didn't). I owned a small non-tech business at the same time.

I worked way too hard for a while. I didn't mind it. On the contrary, I was deliriously happy to do it. Nobody had to ask me to work hard. But it still did me harm.

I don't know for sure that working like that caused or contributed to the chronic illnesses I now have, but I do know that the literature on one of them says that it's correlated with excessive hours worked and excessive exercise. I did both. (My side business involved a lot of intense exercise.)

Oh, and if the overwork did cause or contribute to my chronic illness, then it may also have cost me a fortune. I went bankrupt in the process of getting one of those illnesses properly diagnosed and treated. So even if hard work does happen to pay really well, that doesn't necessarily make it worthwhile--not even necessarily financially worthwhile.

Again, nobody made me work like that. I did it because I was motivated and having fun. It was nevertheless very bad for me. That became clear over the months after I did it, and I may still be paying for it.

You might think that I would have learned my lesson from that episode, and that's true to some extent. I've never worked that hard again. I have worked too hard since then, though. It's a consequence of personality traits, I think. It's a trap I can too easily fall into, even though I know better. So I have to keep watch and listen to my loved ones and my doctors when they warn me that I'm trending that way.

In short: don't think that fun and motivation make you immune to the ill effects of overwork. They don't.

The type system enforces those permissions: writing to an impermissible destination is a type error. The types applicable to an entity are not necessarily knowable at compile time; some of them might change at any time.

I had a job working on such a system. It supported a type system implemented in Haskell with both static and dynamic type disciplines, where values were tagged with base types designed to be checked dynamically in hardware.

Was the programming language dynamically typed? Yes. Was the programming language statically typed? Yes.

It’s a multiplayer game in which players LARP as assassins out to kill targets that they receive secretly at the start of the game.

The game has rules that describe how to simulate various forms of weapons and tactics (e.g. using a rolled-up sheet of paper as a dagger), and the rules are intended to help make it clear to observers that it’s just a game in which no actual crimes are intended, but it still involves people behaving in ways that could be misinterpreted.

I played it some at VCU in the late 1970s. It was fun.

I quit that job the second week.

Indeed. When you were typing in your first BASIC program, my younger daughter was two years old.

They seem to be in favor of mocking people for being wrong. I don't agree. It'll result in a great deal more mockery than I have any use for.

Bard classes are not conventional object-oriented classes; they aren't even CLOS-style classes. A Bard class is a set of representations that participate in a given protocol. That being the case, a hypothetical Bard cons cell representation could be exactly the same as a TXR Lisp cons cell, or the same as a Common Lisp cons cell. In either case it need not be the only representation of a cons cell in the language.

(I feel like someone is going to object that I shouldn't use the word "class" for a concept that is so different from what it usually means in object-oriented languages, and that might be true. If someone suggests a better term for a set of representations defined by a protocol in which they all participate, I'll consider adopting it.)

That's true only because cons cells have a specific representation, but they don't have to. Bard classes are defined by protocols, not representations.

If I remember right, that's what Moon liked: because Bard's classes were defined by protocol and not representation, source code could be made of lists, and could have a place to hang metadata, without imposing that cost on other lists, because lists were not any specific representation; they were just any representation for which the list protocol was defined.

Cons cells are certainly very simple. They're so simple that, as Moon once observed to me, there's no place on them to hang metadata. For example, if your source code is made of cons cells, you might wish that they had some sort of metadata slot so that you could use it to keep track of where a given hunk of source code came from. You can't though. You have to kludge up some out-of-band solution for things like that.

We were talking about my hobby Lisp, Bard. He liked that it separated protocol from representation, so you could have Lists that were made of something other than cons cells. In fact, in Bard your Lists can be made of anything you like, as long as it participates in the List protocol. In particular, they can be made of something that has some place to hang metadata.

Rich Hickey of course also gave a bunch of Clojure's data structures places to hang metadata, possibly for similar reasons.

I wanted to describe the source-code peculiarity because it hadn't been discussed elsewhere in the comments and I think it's important in what you might call old-fashioned Lispiness. I should have chosen another place for my comment. Sorry about that.

Cons cells are not the important point--at least not for me. The important point in this context is that expressions are represented by something better (that is, more conveniently-structured) than flat text strings, and that the representation be a standard data structure in the language, and that operations on source code are implemented by APIs that are exposed as standard parts of the language.

As far as I'm concerned, if a language does that, then it's nailed this particular part of being Lispy. There are some other parts, but that discussion is outside the scope of this one.

In Common Lisp and its antecedents, a "list" is a chain of cons cells, as mentioned by some of the sibling comments, but that's not all. Another important point is that in Common Lisp and its antecedents, source code is not made of text strings; it's made of Lisp data structures--atoms and chains of cons cells.

A text file containing "Common Lisp source code" does not actually contain Common Lisp source code. It contains a text serialization of Common Lisp source code (one of many possible text serializations, actually). It isn't actually Common Lisp source code until the reader gets done with it.

This might sound like a trivial pedantic point, but it isn't. Because Common Lisp source code is made up of standard Common Lisp data types, its standard library provides everything you need to walk arbitrary source code, deconstruct it, transform it, construct it, and compile it. Those features are all built into the language in a way that they are not in most languages.

For those of us who are accustomed to using those features regularly, working with a language that lacks them is such an impoverished experience that I can understand folks objecting that "that's not a proper Lisp." I don't tend to make that objection myself, but I do understand it.

If your Lisp does not represent its source code in this way, or if it doesn't even have the data structures that source code is made of in Common Lisp and its antecedents, then there is a nontrivial sense in which it's not a Lisp--or at least not the kind of Lisp that those older ones are.

We got along great.

The early meetings at Apple for the design of the Dylan language definitely had both Lisp and Smalltalk folks participating. I wouldn't be surprised if some of the participants were FORTH folks, too.

In Spider-Man's origin story one of the first things that happens after he gains his powers is that he tries to make some money as a masked wrestler. A guy robs the box office at the wrestling venue and Spider-Man lets the guy escape because it's none of his business. The same robber later shoots and kills Spider-Man's uncle, from which Spider-Man takes the lesson expressed in the above quotation. The same lesson then colors a large fraction of the character's storylines forever after.

In such languages, you want to be able to use the entire language at any arbitrary point, including at a point where execution has halted for the moment because of some error that has occurred in some arbitrary place. The condition system provides a nice set of tools for doing that.

https://en.wikipedia.org/wiki/Alvy_Ray_Smith

She passed away in the summer of 2021.

Her distillery, Delaware Phoenix, gained some positive reviews.

There's a memorial page about her here:

https://www.thegreatawakening.org/cheryl-lins-memorial-page

If circumstances arise in which I decide that retirement is a good option, I will live pretty much the same way that I do now, except that I may undertake less activity at someone else's behest. I say "may" rather than "will" because I already do some work pro bono because people ask me to help them with something.

That's a Catch-22, of course. How will you know if it's a good fit for you unless you learn it?

So that reduces the decision to: if you are curious whether Lisp is a good fit for you, learn enough of it to find out. If you're not curious about that, don't bother.

But you might want a preview of what things make it a good fit for some people. Lisp in general, and Common Lisp in particular, is a good fit for me because its default mode of operation is to start the Lisp running and teach it by interacting with it expression-by-expression how to be the program I want to build. Common Lisp is consciously designed to work this way, and provides a host of well-designed conveniences for it. It turns out that working that way makes me happier and more productive than working any other way, so it's my favorite programming language.

Not very many other programming languages work that way, but to be fair, some do. Examples of some that do are Smalltalk, FORTH, and Factor.

Some languages and implementations provide more support than others for that style of work. The most comprehensive support for it is to be found in Common Lisp and Smalltalk implementations.

If that sounds interesting, then it's probably worth your time to learn Lisp (or one of the other languages I mentioned). If not, then I wouldn't worry about it.