Mothlamp Problems
68 points by notjack
68 points by notjack
18 years ago (wtf) I built what has got to be the mother of all mothlamp projects. An emulator for an imaginary trinary version of the 6502 CPU, which grew out of hand and eventually included a C (ish) compiler for this architecture and an IDE for the C(ish)-like language. Had like 5 users in Russia. Good times.
It's not until recent years I was struck with the realization that you could build stuff that actually served some sort of purpose. That's rewarding in a different way.
While this is awesome and definitely a category of project to get sucked into, to me, hypothetical practicality is inherent to a mothlamp project. It’s the type of project that, once you build it, it will solve all your problems (like the perfect programming language, editor, gui framework, etc). It’s this utility (whether real or mostly imagined) coupled with the damn near impossibility to create it on your own that is so attractive and destructive
This is the key distinguishing point from similar terms (nerdsniped, yak shaving, etc.) in my mind.
If it turns out relatively feasible to make after all, you just end up in another trap, holding a tool you cannot abandon because it just fits how you think, but nobody else can bend their mind to use it.
Guess how I know.
Good thing at least I based it on things stable enough to need approximately no maintenance at all.
I think "mothlamp" projects are probably analogous to strong learning expeditions. There's a high amount of high-value learning along the way, especially if the topic interests you, the value isn't necessarily in solving the underlying problem, it's the high rate of learning in a topic that you care about or have a high interest in. Maybe the solving the problem is just the egotistical excuse for giving yourself the time to explore and learn?
"Mothlamp" strongly implies a state of equilibrium, but what you describe involves actual self-development, in which case I don't think it would be a good descriptor.
Perhaps the OP is discounting the pedagogical value of exercises that don't result in a practical artifact. But there are many hard problems where constructing such a "toy" version of the solution is a valuable exercise, even if you intend from the outset to throw it away.
So while this is a fun coinage I would recommend caution in deploying it; just because the benefit of something is intangible doesn't mean it's not worthwhile.
I don't think I would every deploy the term if i'm honest, I don't see moths to a lamp as a particularly positive thing if I think about it. I'd call something like... react a mothlamp, in that it tends to have gravity that is inextricably hard to escape if you are for instance, a web developer. It doesn't feel like a positive term. I'm not even sure it implies equilibrium, it conjures up images of hundreds of moths inextricably trapped by a light source and bashing each other and themselves to smithereens. I would rather frame what the authors explaining with a more positive term but I don't have an alternative at hand.
It doesn't feel like a positive term. I'm not even sure it implies equilibrium, it conjures up images of hundreds of moths inextricably trapped by a light source and bashing each other and themselves to smithereens.
That's a good observation, and I think I agree; there's a strong connotation of self-harm there, not merely stasis. It's like lamenting all the equations left on a dusty chalkboard while you're thinking through a problem. Who cares how many times you erase and start over, the intellectual development is the point.
Beautiful.
Another event that can mark your last mothlamp project is when it appears people love to use it. Then, most of your time will be spent on working with people: technical support > documentation > feature requests > maintenance > complexity tradeoffs > monetization, to guarantee ongoing support > communication and promotion > employees > administration and bookkeeping > etc. No more time for new mothlamp projects.
I personally miss mothlamping, but the fact that people use my last mothlamp project to make great things makes this an acceptable tradeoff.
I had myself a good laugh that structural editing was number two on the list. I guess I am a moth now.
"If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem." Aza Raskin
I'm like this with video games. Sometimes I know I can't do something, but that's what makes me want to try one more time. Trying is a muscle you sometimes want to exercise. I like the idea of naming this dynamic though. There do seem to be certain problems that routinely lure us into this!
Hmmm, that is a curious quote. I am trying to understand how there would be any magnum opuses if people did not try to solve problems that involved creating magnum opuses. Perhaps magnum opuses were written by people who were not trying to solve the problem that involved creating the magnum opus, but instead were trying to solve the "correct problem" and then a magnum opus shook out naturally and easily from it. (I find this difficult to imagine, since I feel like most magnum opuses indicate quite direct and sustained authorial grappling with the center problem(s) of the opus.) There's the incremental approach (like a 50-foot wave surfer surfing a wave 1 foot higher each year, or old masters "solving the problem" of drawing bones for several years of apprenticeship prior to being permitted to work on the actual canvases), but I feel like the chestnuts of magnum opuses can sometimes (often?) explicitly come from solving the 'wrong problems' of the time that do directly involve creating a magnum opus (say, perhaps, phenomenology or type theory).
After giving this some thinking, I can't find a way out, so to speak, of his quote. If he really is exhorting people to not go mothlamping (or in other words, don't try to land a whale, or don't aim for the stars, stick to your lane, etc.), then it's hard for me to understand how humanity scores those big, sea change type societally-mind-altering/game-changing moments. (Not to mention the benefits of personal transformation, which several here have touched on.) It might ring practical in the small, but from a categorical imperative level, it feels more limiting and defeatist. Note that perhaps I'm being unfair to the context of his quote. For instance, perhaps he is telling a junior engineer to stop trying to rethink how our hyperlinked world wide web could be completely reconstructed with a wildly different paradigm, and rather just fix the 500 error during form submission that's in the ticket.
By natural disposition, I side more with the mothlamp post: large, uncertain quests are living in the most literal sense. To be a living being, and to live, is to occasionally wander away from what you know, what is safe, and wonder if there is a guiding star behind the cloud that is worth pursuing. I get this sense from Alan Kay as well. We could all solve the right problems all the time and just click click click along. Or we could try to solve the wrong problems sometimes, and see how we grow, change, learn, live.
I am trying to understand how there would be any magnum opuses if people did not try to solve problems that involved creating magnum opuses.
Magnum opuses from solving problems are not good things.
The same advances coming from incremental iteration of Minimal Viable Progress usually mean cleaner understanding of what is going on, and better bridges between neighbouring topics. And there can be better understanding even if the goal is not reached. Not a guarantee that the goal was worth reaching anyway. And very often the magnum opus later gets replaced with the proper way there.
Sometimes the understanding is built up over small advances, and then an old problem can get a reasonably simple explanation as the first solution. And that's beautiful.
Why do we do this to ourselves?
Because sometimes it works out.
But I can accept that. I'll be very good at dreaming by then.
And that's what you get when it doesn't. Which is not bad either.
Sometimes trying to solve an impossible problem gives you valuable insights.
A cool example of this is a bunch of people (e.g. Euler, Lagrange) working on the (unsolvable) three body problem developed a bunch of new and useful mathematics.
I think the reason structural editing is like that is that it's clear that there's something very powerful and useful there, juuuust out of reach for most.
The fact that it feels like it's just out of reach may have more than one meaning: it could be hard or impossible to reach. With the structure editing problem, I'm absolutely sure that it's just hard and not impossible.
I have been writing and rewriting the same IRC bot for 13 years now. Pretty sure that's not a "hard" problem but it's the problem I enjoy and nobody has ever seen utility in me improving 😂
If a defining feature is that moth lamps solve some kind of problem eventually, then I posit all moth lamps can be yak shaves, but not all yak shaves can be moth lamps.
The mothlamp problem I've been afflicted with, without any meaningful progress in implementation so far (like, the idea is too vast, where do I even begin..), that might pique the interest of the author of this article, due to their interest in language-agnostic toolings:
Try to imagine the landscape of a programming language ecosystem that is agnostic of syntax, semantics and runtime: which means representation of programs in {syntax, semantics, runtime}-agnostic manner, as well as representations of syntaxes, semantics, runtimes themselves (which are also agnostic at their level and so on), so that they can be tweaked on; smooth and seamless composition/cooperation of programs written for different semantics; allowing making changes from syntax all the way to the runtime, at compile-time to run-time, as far as possible and practicable (≈ a possible generalization of REPL systems images), to the point of being able to swap out the runtime at run-time (pause the program, export the program state, import it to another runtime+environment (e.g. like JVM to WASM, if it were possible), continue running from where it was paused..) etc. I could only imagine this far.. so just assume this as hypothetical/fantasy and see if you can generalize this line of thought further.
This sounds an awful lot like Racket, honestly :)
Though we're lacking some of the core runtime flexibility that would let one make a good systems language, unfortunately.
From what I've read so far, Racket has done a respectable job in the syntax front. I've yet to hear about any implementation that deals with semantics in the generality I'm imagining. I've quite a bit of difficulty imagining that aspect anyway. I wonder how much power (and difficulty) it brings when you're allowed to deal with semantics as first-class constructs, what even would be the usecases for that to begin with..
smooth and seamless composition/cooperation of programs written for different semantics
I think I have seen different dataflow-like semantics that would explode if mixed…