<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html>
<head>
<meta name="Generator" content="Zarafa WebAccess v6.20.4-14107">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<title>Cvenience over extensibility? Or: How to build on top of hu.dwim.rdbms?</title>
<style type="text/css">
body
{
font-family: Arial, Verdana, Sans-Serif;
font-size: 12px;
padding: 5px 5px 5px 5px;
margin: 0px;
border-style: none;
background-color: #ffffff;
}
p, ul, li
{
margin-top: 0px;
margin-bottom: 0px;
}
</style>
</head>
<body>
<p>>> Maybe you don't expect an outsider to understand the "mechanics" of the code<br />>> by reading your long names and<br />>> merely want to aid that process of understanding. How well that is<br />>> accomplished through the use of long names, is, of course,<br />>> still open for question. :)<br />><br />><br />>well, it certainly helps the process of understanding to have one less<br />>indirection (e.g. not having to make the extra step to get from the<br />>abbreviated short name to its original long form).<br />><br /><br />Agreed.<br /><br /><br />Nonetheless, in an (my) ideal world you would be able to derive the long form from the abbreviated form by:<br /><br /> 1. knowing the outlines of your territory (files, dirs, packages, systems, context of all kinds)<br /> 2. looking at and hopefully understanding the "mechanics" of the code<br /><br /><br />Admittedly that isn't cheap, although it seems doable for an outsider. (eventually we are all outsiders)<br /><br />All in the name of circumventing names that are hard to understand. (for outsiders)<br /><br />The more I think about it I come to the conclusion that excessive use of long names are a way of "getting more intimate"<br />with your code. That helps you personally (or a small group) over the short-, midterm (maybe even long-term or<br />the rest of your life) but harms others.<br /><br />In the end, it seems to me, it all comes down to not having any standards and a practically infinite number<br />of possible meanings. (costs of sharing meaning, transaction costs)<br /><br />>and don't forget that the frequency the name is "used" plays a very<br />>important role regarding the decision about long/short names. you can<br />>easily convince me about short names of frequently used constructs<br />>(bind, let, ...), because even we prefer short names for them. but<br />>these names are only a tiny portion of all the names introduced in the<br />>codebase...<br />><br /><br />That makes sense to me.<br />Sounds like you are making a case for using long names as an asset by having the contrast between long and short.<br /><br />And the costs of sharing meaning about a name that gets used frequently are easier to justify.<br /><br />Again, opens the question as to how much long names are capable of reducing costs of sharing meaning.<br />Could they even increase the costs? I certainly made that case. Seems a little crazy from this perspective.<br /><br />Surely the more words you use to describe something the easier it gets to share what it actually means?<br />Does purpose come into play now? Maybe I should stop here.<br /><br />><br />>the extremum on this scale, namely writing code with abbreviated short<br />>names of infrequently used constructs is basically what code<br />>obfuscater algorithms do.<br />><br /><br />Right, only context is missing in this picture.<br /><br />Hm, the costs of sharing meaning often seem to be exceptionally low when it comes to context.<br /><br /><br />><br />>random thought re names: once a flat-text codebase has been parsed<br />>into a graph, then all the human given names could be dropped because<br />>they are redundant. the machine can execute the semantics encoded the<br />>same way without identities having human parsable character strings.<br />><br />>conclusion: names should/could have much less important role regarding<br />>identity management and restoring a graph from flat-text, and much<br />>more important role in helping human understanding of such a graph.<br />>e.g. having a long and a short names for the same identity; the<br />>ability to have personalized names (e.g. let shown as a special<br />>graphical element in my editor instead of using a three letter word);<br />>etc...<br />><br /><br />Absolutely<br /><br />><br />>i have a lot more thought on this (partly because we worked at<br />>intentsoft.com), but it's a bit out of scope on this list... and<br />><br /><br />Impressive, a testimony from the New York Times. Yes, this is awfully off topic.<br /><br />As a side note: The relative low level interface of hu.dwim.rdbms I was talking about,<br />on top of which as many extensions as possible can be build, seems to be already there.<br />It's just that it isn't properly exposed, in my eyes at least.<br /><br />><br />>writing code has much more utility than talking about writing code...<br />>:)<br />><br /><br />Hard to tell. On average you are probably right.<br /><br />><br />>but reading your mails makes me think that you are already getting far<br />>ahead of most people when it comes to giving good names to<br />>abstractions. spending brain cycles to think about the problem is<br />>already more than what most people do.<br />><br /><br />I take this as an compliment. (normally I refuse compliments, tells me something)<br /><br /><br /><br />Regards,<br />chris<br /><br />><br />>-- <br />> attila<br />><br />><br /><br /> </p>
!DSPAM:4cd81d6e48581330461277!
</body>
</html>