A Dearth of Useful Restrictions

A calculator which refuses to multiply numbers by thirteen is hopelessly useless.  One which instead
refuses to manipulate numbers with thirteen as a factor are worse still.  For a calculator, only the
restrictions dictated by reality make much sense, particularly the limits to size and thus accuracy.

A system which restricts its domain can be useful, but one placing few and arbitrary restrictions is
lukewarm, and I much prefer hot or cold most of the time.  Ideally, good systems will have the least
restrictions possible, but good systems can also have many intelligent restrictions.  Most systems I
see, unfortunately, are in the middle with few restrictions and fewer reasonable.  I've been dealing
in Decker lately, and it has quite a few little restrictions in some places that irk me as a Lisper,
though I understand their purpose; a table can have columns with arbitrary names, but the names _bg,
_fg, and _hideby have special meanings; similarly, function names for contraptions beginning in set_
or get_ manipulate attributes.  In Lisp, I'm accustomed to the idea of preferred shapes for names of
certain things, but always also the power to override these suggestions in some way, to the extent I
deem worthy.  APL may not allow one to make symbols, but names aren't special sans system variables.

When data ought to be meaningless, it's best to avoid carving out exceptions.  An IP address usually
holds little meaning alone, though select addresses or ranges thereof have special meanings bestowed
upon them.  For such a large address space, it's generally preferable to burn a value rather than be
forced to mark it in some way for some purpose.  The primary problem around the Internet's method of
allocation is its change over time: Such things are ideally simple, few, and specified unchanging at
the very beginning.  I've read accounts of reserved address ranges found used in the networks of the
lesser countries who care less for such things, and practical such things argue for meaninglessness.

As usual, UNIX is a striking example of improper system design for which the restrictions number few
useful and many onerous.  Under UNIX, filenames have two restrictions: They can't contain ASCII null
nor ASCII solidus.  Both restrictions are arbitrary and betray that amateurish nature of the design:
The C language can't cope with strings containing the former, for it's used as a sentinel value, and
it's easier, for the implementor, to hide meaningful data inside strings by using the latter as mark
of directories.  If the C language had real strings, and UNIX a real data structure for directories,
neither of these restrictions would appear.  Following them, files can't be named by arbitrary data,
so cases wherein they must require escaping, like conversion to sexadecimal or base sixty-four, thus
making them take up more space and adding indirection.  More recently, the idiots who think the name
of UNIX to hold any value have added an additional restriction: Filenames may not contain ASCII line
feed.  This restriction is brain-damaged and worthless since it addresses only part of an issue, and
this ignoring how it will be ignored in any case: As filenames can't be arbitrary data, it follows a
few more restrictions to keep them from holding control codes or ringing the ``bell'' may be useful,
but instead they only mandated against this smallest subset, enough to annoy and absolutely no more.

Another amusing story about UNIX is its ``file descriptors'' which are mostly meaningless, sans some
exceptions that cause all of the problems.  The story involves a programmer making sure not to close
the second ``file descriptor'' only to open a file and have it take its slot, since several programs
write blindly to it.  Under OpenBSD, where ``file descriptors'' are randomized, the first three have
their normal values, because too much software assumes their numerical values.  In Lisp, symbols are
used, and there's no problems regarding the numerical value of symbols, because the very concept has
no sense about itself.  As UNIX lacks symbols in most places needing them, it was easier at the time
to assign predictable values to many things, and the numbers see use because they're shorter, easier
to use, and the mess of languages abused under UNIX means they're sometimes the one and only option.

Perhaps related is case insensitivity.  I prefer it, finding it to be obviously correct, but Unicode
makes the matter radioactive.  Implicit in case is encoding, and Unicode's poor design requires many
large and changing tables, making it wholly unsuitable for much of anything.  The encoding of labels
in the DNS can represent case, but makes it unimportant; the addition of a very ugly encoding to let
other languages stand was a bad idea, and it occurs to me I've no clue how this interacts with case.
When I was designing a little system lately, I wanted to make it insensitive to case, but noticed it
to be more useful to place no such restrictions and rather remove any and all meaning from the data.

Every restriction is help or hindrance, and seeing each as such is necessary in all systems' design.
.