Þ   briarpig  » thorn  » why

     I want to abate a nuisance: not having coworkers grasp my methods. My reasons are pragmatic; trust in results is limited by how others see them. My ability to scale what I do for larger projects is hampered by absence of compatible skill and experience in folks who must dovetail work with mine. Good results need a pyramid of support.

     I want how I write code to look obvious to folks. It's not enough to simply get unexpectedly high quality results in problems solved. In addition, a software ecology must deploy solutions in harmony with other pieces, and in harmony with developers reasoning about whether parts work, and reasoning about how one tells they work. A complex system often behaves in surprising ways. Confidence in parts is crucial.

     Writing working software is like conducting a good scientific experiment. But the standing of an experiment depends on whether others can repeat steps and see results. A good experiment no one else understands is little use to others. You can go only so far by yourself and then your work must join that of others or be ignored.

     So ideally I want all þ code to look trivial. If anyone who sees code like it says "yes, of course" on first sight, then also trivial is any (simple) means one uses to check expected behavior.

     I want simple parts of my development stack to look simple to others. We stack complex code on top of simpler code, and keep going until we lose track or lose control. Folks helping me often lose track long before I lose control. So I spend a lot of time hand-holding for what seems really simple tracking to me. I want folks to laugh when I ask if they need help.

     I want to use deeper development stacks, with more complex and interesting parts — not train folks, for the umpteeth time, to see memory management rules in basic technique.

     I write tools for development stacks, but they have less value when others can't make heads or tails of what they mean or what they do. It'd be ever so convenient if my tools had obvious use to others, with a role in performing experiments to verify whether code does what is expected — with clear meaning to others. Then writing more would be productive.

     In particular, it would be nice if folks accepted use of interpreted languages as internal or self-checking parts, so high level code can be used in driving low level knobs. Toy languages should seem obvious, disposable scaffolding. More than one language should not be a big deal; cheap and throw away language tools help confirm theory and data.

     Being ahead of the game in software tooling is self defeating, especially when the layer is the bottom, just a step away from address arithmetic and pointers. Process grinds to a halt if junior folks treat layers like magic that can't be understood.

     It's hard to work on fun things when folks dramatize and botch elementary mechanism. An old approach to this problem is standardized parts and software jocks. But in bespoke systems software, the fungible part should instead be obvious, malleable primitives clear to every player.

     thorn: todo, names, fd, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, hash, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, meter, list, iter, ctype

     (mu: toy, peg, imm, tag, box, symbol, token, number, bigint, class, method, reader, writer, eval, env, vm, gc, world, pcode, compiler, asm, lathe, lisp, smalltalk, design, weight, jar, card, harp, debug, profile)

     Some demos are stubs: todo is a demo guide. See toy for mu updates on language pages; names introduces naming schemes.

     An often useful part of þ needed is just basic buffering — avoiding stupid technique often used when it's the convention. Plus: it makes code go faster when buffered effectively.

     However, folks often mistakenly assume because you improve something, you did something clever, as if a default rule was first versions of things must be pretty darned good already. Depends on who did it: shoddy work is common.

     Usually folks say, "Wow! Let's patent that!"

     And I ask, "Patent what? Fixing dumb code?"

     You'd think the answer would be no, but it's often not if the area fixed is domain specific enough. The patent office will let you patent not being stupid in a particular app domain.

     I ask, what part do you want to patent? Caching? Copy on write? Scatter gather? Hashing? Parsing without copy? Refcounting? Versioning? I name a few more things, and you know, basically the whole solution is just a string of some of these together. There's nothing to it.

     Marketing folks say we're optimizing Foo apps, for some domain Foo. I'm the optimization guy, so I can make a description sound trivial, and I do.

     (A hard part seems translation of trivial description to actual code. That's trivial to me, too, even if it stumps others.)

     So I want þ to be generic — like any other familiar library — so folks stop assuming I did something clever, needing protection, in parts I cloned for them. There's nothing about streams, for example, that are specific to what you use them for.

     There's nothing domain specific about þ at all — it's just easy stuff broken up into more degrees of freedom than usual, with a little less abstraction drama.

     Stylistically, the way I code seems offensively simple to many folks when it doesn't use dramatic flourish, or doesn't close options when I can can leave them hanging. I like loose ends kept loose, just labeled. Raw and unfinished edges have their uses: you can see into them and add more parts, or tweak harmony of detail with related systems.

     All this code is available only under the BriarPig mu-babel license described fully on the rights page. You do not have permission to reprint this page in any way. Neither feeds nor repackaging is allowed. You can link this page if you want folks to read it.