Long string to short ID

[Michael P.]

On Sat, 14 Aug 2021 12:05:27 -0400
"Lloyd R. Prentice" <lloyd@REDACTED> wrote:

> The question is, why does “My Long and Fascinating Book Title” feel like such an awkward and inefficient ID in a computer application focusing on books?

Because it is not an ID, not for the computer?
My brain-executed flexi-algo filenames
_are_no_IDs_, for no programming language and no file-system;
they are merely some human-readable (hopefully) "alternative titles".

Or do you want to do something like
    One = 1,
    X = 10,
    MCL = 1150,
    -define(Rmb_3, "Rambo 3"),
    ...
    -define(Rmb_3, "Rambo 385") % significance error included
create a programming language identifier for every domain value?

That would be like confusing parameter and argument.


> So, we program some kind of translation layer that associates “My Long and Fascinating Book Title” with “ygjre3*)7x?” — a proplist or some such. Now humans get to consume the literal title and the machine gets the weird, presumably more efficient, string.

Or simply some integer.

Here are some lines I deleted from my previous message:

next_id() ->
    Next = last_id() + 1,
    store_id(Next),
    Next.
...
    The_book = #{title => "endless sermonic book title XXVIII",
                 author => "S/O",
                 ...
    ...
    store_book(next_id(), The_book)


> The question then becomes, how much memory does the translation layer consume and how much latency is involved in the translation process?

When you use Erlang and atoms,
then you use some such translation process ... compile-timey ...
run-timey when you print atoms and list_to_known_atom() and ... better not.

Any translation from any however shortened "human readable ID"
to the full "title" performed by the fuzzy-logic pudding in some human's head
is slower and more prone to error.

And if you want to algorithmically create _alternative_titles_:
any shortening algo will be relentlessly executed by the machine,
and prone to errors even when the machine is "right".

The FAT32 filename truncation algo will explode after Z~999999,
or such. And it does not care about "human readable" ...

... apart from "keeping the head" ... to some extent ...

~M

--

To err is human,
To error machine.