At Kodak in the 1970's, my father devised the "Bayer filter" used in digital cameras. At the time, he wrote a research system for image processing in sed.
Kodak's goal was to keep customers happy while selling less silver. Less silver means more grain, so they envisioned digital methods for reducing grain, before printing photographs at some centralized facility (obviously not the pocket I keep my phone in). So the sed program did various convolutions on rather coarse images, for playing with ideas.
My dad's other contribution that stuck was ordered dithering: Bit patterns for various gray levels that worked well next to each other, without edge artifacts at the transitions. Long ago replaced by other methods for higher resolutions, but last seen as part of the DEC logo on their product boxes.
I'm sure that choosing characters to represent gray levels in this sed program got him thinking in that direction. I've never been good at complicated, but he taught me to see simple.
This, this is actual hacking. Absolutely useless, and not at all the correct tool for the job, but exceedingly clever. Shame I can't get the code to work for me on Debian.
If you're interested in things being implemented in non-standard languages, I would check out the Make-A-LISP project on Github [1]. Someone even took it upon themselves to write an implementation in AWK :) [2]
You know how artists will use a bunch of plates (or other objects) to make a giant version of the Mona Lisa or something like that to make a photographic mosaic? It's like that. Each line makes sense, but you've got to have some real vision to make this happen, and it's really difficult (nearly impossible) to see the big picture by just looking at a small part.
It doesn't look that complicated compared to normal sed usage. It's just a series of find/replace for the most part. That said, regex is always pretty hard to read, and putting it together like this is impressive to say the least.
That's probably because you used BSD sed. Running it on my BSD sed also gives an error, presumably because it thinks the `}` is a part of the label in `binput}`.
However it works fine in GNU sed, and now that you mention it, GNU sed's extensions were not used, like the `-z` flag to slurp all input in one "line" to avoid `:input;$!{N;binput}`.
For reference, here’s a code golf challenge for maze solving. It’s an “endless” challenge (meaning none of the code submissions are viewable) but the shortest sed solution is currently 98 bytes.
Not quite as hard as the OP, though, since the conditions are slightly easier: only 3 inputs are tested, all of them are the same size, and all of them have exactly one solution.
If I remember right, my overall approach was pruning dead-ends instead of a breadth-first search.
Nice - I've been getting overly familiar with sed recently because it's one of the few tools that we can trust to be installed for our minimal-dependency NBD server. Unfortunately we also need to work across Linux, FreeBSD and OpenBSD. However I've not needed to write anything as large as this maze-solver. It's text hacks like: https://github.com/libguestfs/nbdkit/blob/b8d80d3df90eaa32ef...
tl;dr: competition counts cycles but excludes certain standard library functions, one of which is a regex matcher, so someone naturally decides to use it for much of his algorithm.
