[cl-rdbms-devel] Convenience over extensibility? Or: How to build on top of hu.dwim.rdbms?

Attila Lendvai attila.lendvai at gmail.com
Mon Nov 8 13:22:22 UTC 2010

> Maybe you don't expect an outsider to understand the "mechanics" of the code
> by reading your long names and
> merely want to aid that process of understanding. How well that is
> accomplished through the use of long names, is, of course,
> still open for question. :)

well, it certainly helps the process of understanding to have one less
indirection (e.g. not having to make the extra step to get from the
abbreviated short name to its original long form).

and don't forget that the frequency the name is "used" plays a very
important role regarding the decision about long/short names. you can
easily convince me about short names of frequently used constructs
(bind, let, ...), because even we prefer short names for them. but
these names are only a tiny portion of all the names introduced in the

the extremum on this scale, namely writing code with abbreviated short
names of infrequently used constructs is basically what code
obfuscater algorithms do.

random thought re names: once a flat-text codebase has been parsed
into a graph, then all the human given names could be dropped because
they are redundant. the machine can execute the semantics encoded the
same way without identities having human parsable character strings.

conclusion: names should/could have much less important role regarding
identity management and restoring a graph from flat-text, and much
more important role in helping human understanding of such a graph.
e.g. having a long and a short names for the same identity; the
ability to have personalized names (e.g. let shown as a special
graphical element in my editor instead of using a three letter word);

i have a lot more thought on this (partly because we worked at
intentsoft.com), but it's a bit out of scope on this list... and
writing code has much more utility than talking about writing code...

but reading your mails makes me think that you are already getting far
ahead of most people when it comes to giving good names to
abstractions. spending brain cycles to think about the problem is
already more than what most people do.


More information about the cl-rdbms-devel mailing list