One primary goal in the þ runtime — as well as everything built on top — is the generation of evidence to support inferences about system behavior based on evidence oriented reasoning, to create informed insights with some degree of Popperian falsifiability. Evidence for insights is a required feature. (But, it might be added lazily.)
profiling
Profiling tools provide one standard form of evidence about actual system behavior. But its focus is often only speed performance, so that frequency is emphasized only with respect to hot spot analysis (ie things done more times have more effect when optimized). However, some kinds of profiling are still useful even if speed is not an issue.
counting
For purposes of evidence, a more useful kind of profiling might count everything, so you could see how many times an expected thing happened, or more interestingly, didn't happen. Many theories about what code actually did during a test run can be evaluated by examining counts of relevant events that occurred (or didn't) during a target time span.
(In the presence of multithreading, a decision must be made about whether counts changed by more than one thread concurrently should be kept carefully multithread safe. In many cases, with a very high density of counting, the answer must be no to reduce the overhead involved, even when relatively efficient atomic integers are used. It's often acceptable to risk loss of a few count increments during simultaneous updates, if an exact number isn't critical.)
tedium
While counting is fairly easy, it can be fantastically tedious, and statistics being updated in code can partially obfuscate more important business. Even more tedious still is making counted statistics available on demand in a sufficiently immediate way so debugging can be informed by stats. However, without good stats, development decisions can be based on false information, and so rendered sterile.
metering
For systems subject to denial of service problems, even from legitimate users, metering of cycles and space consumed by an activity can drive decisions to continue supporting a user's requests. Metering can be used to throttle resources used, if they aren't turned off completely. (Going lame on an attacker can be more productive than definite rejection, which provides more information than sub-par service.)
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
thorn: todo, names, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, meter, list, iter, ctype
The new mu menu links future toy language pages. Many demos are stubs; see todo for a thorn demo guide, or toy for mu updates. Also see names for an overview of naming schemes.
Software developers can be prone to fantasy about what software is actually doing. Curiously, in absence of evidence, many practitioners assume a system acts exactly as hoped. Since exposure to evidence can signal bad news, it's often avoided to prolong blissful ignorance.
double standards
The benefit of the doubt is often applied with a double standard, so Fred assumes his code is fine, but assumes Barney's code probably isn't as good. When something odd happens, Fred wants Barney to prove Barney's code is working right, even if there's nothing wrong.
proof
How is Barney going to prove his code works? The absence of direct evidence of failure isn't enough to convince Fred. When Fred is puzzled by system behavior — even if it's just a surprising emergent outcome — he wants an explanation to include a finger blaming Barney, since otherwise Fred's code might be in question.
evidence
Evidence is much easier to supply than proof. But providing evidence about code behavior is a requirement above and beyond just making code work minimally. In complex systems, merely correct code is not enough to diagnose unexpected observations. Sometimes providing enough evidence can be almost as much work as an initial effort to solve a problem. (You've been warned.)
isolation
Unit tests and other sorts of standalone tools are very useful for isolating evidence about specific sub questions. A server running under full load might do a zillion things when processing a request. (Yes, zillion is a technical term in this context.) So, is a surprising result a bug? Or an emergent effect from expected interaction of parts?
Often you can't tell unless you try things in isolation. Let's say Barney writes a URL parser, and Fred tries a hairy example URL in a test, and something surprising happens. Was it the URL parser? In this case, you need to run the URL through the parser in isolation, and see what happens with a specific datum.
falsification
With a big enough bag of evidence tools, you can walk through questions and hypotheses one at a time, ruling out cases as quickly as possible (which is important when there's a zillion things to check). Often the answer to most questions is no (no, the URL parser isn't broken on this URL), so the goal is to falsify questions quickly, without dithering or blame, to find the facts.
evidence « Þ
