David and All, (01)
Note this thread has the subtitle "[was: Fixed labels in software?]"
because David originally posted it to me as an off-line note. (02)
We agreed to repost it to the list. (03)
Don't get confused looking for the thread "Fixed labels in software?" on-line. (04)
On Mon, Feb 15, 2010 at 4:44 AM, David Eddy <deddy@xxxxxxxxxxxxx> wrote:
> On Feb 14, 2010, at 2:09 AM, Rob Freeman wrote:
>>
>> There is even less need to use fixed labels in computer software.
>> Certainly not at the application level.
>
> Please to explain this.
>
> It has been my experience that there are names/labels EVERYWHERE in
> computers & software... variable names, column names on reports, folders,
> files, subroutines, methods, programs, schemas, ad infinitum. When
> names/labels are done poorly (which is most of the time), then it makes
> understanding more difficult. (05)
Most of those labels are an attempt to make code more accessible to
humans. I don't think there are many at, say, the assembly level, and
even those could probably be eliminated. (06)
Maybe one or two are necessary for really primitive operations.
Basically addresses. (07)
> I would ask... if one does not have fixed labels at the application level
> (I'm meaning: in the programs and all the artifacts around the programs that
> are the application). (08)
I don't think you need to use them. They are there for people. Humans
have problems making sense of a lot of detail. Macros, higher level
languages, labels, are a crude attempt to make a big morass of tiny,
but powerful, operations more accessible to humans. (09)
> Are you saying that names/labels are not relevant to ontology efforts & get
> in the way of ontology discussions? (010)
Names and labels are useful, even essential, for people. What gets in
the way is arguing about them. (011)
We just have to accept that they are inherently subjective. Most
arguments evaporate if you accept that. You can get on with finding
where there is overlap between the labels you are used to, and the
labels someone else is used to. (012)
> Or is there some means to avoid opaque, difficult-to-understand, ambiguous
> labels in software? (013)
I think you could avoid the opaqueness, but then you would have to
have some way to make the labels more ambiguous. Perverse, I know. (014)
The key problem is that, given that no labeling/formalization can be
complete, labels must be either ambiguous or partial. (015)
Humans very sensibly wanting completeness, use language in a way which
makes their labels ambiguous. (016)
Then they come to computer code and all the labels behave in rigidly
unambiguous ways. It trips them up. (017)
You can hear this in the old programmer's lament "Code always does
what you say, just not necessarily what you want." That's the real
problem. (018)
Humans interpret labels to match their intentions. Anything which
doesn't interpret in this way they regard as dumb. And they are right. (019)
At root this rigid unambiguity is what makes software labels opaque,
not ambiguity. (020)
Actually, because the terms used in actual code are usually quite
rigorously defined, software is one of the few places where you will
find unambiguous labels. (021)
Larry Wall, being trained a linguist, deliberately built some
contextual ambiguity into the labels of Perl, but only in a limited
way. It still trips you up, because it does not interpret in a human
way. (022)
Though really Larry Wall deserves credit for turning the problem
around and recognizing ambiguity as something you might want in
labels. (023)
Different computer languages, having different formalizations, will
have different meanings for the same labels, of course. (024)
The trade-off there is that because rigid formalizations are always
partial, there will be some meanings which are difficult to express in
any such formal language. You'll need to express some meanings in
explicit code. (025)
But programmers know this, and match their language to their task. (026)
Still, some of the meaning will always be in code, and difficult for
humans to interpret too. (027)
The ideal language would interpret labels in a way closely similar to
the ways humans do, according to context and perceived intentions.
Then most of the code would be hidden in the interpretation process.
You could "code" using labels alone, and programming might be much
like talking to another human. (028)
We could probably move towards that quite rapidly if we accepted our
labels need to be ambiguous, and focused our efforts on the
interpretation process, not on searching for ideal labels. (029)
-Rob (030)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (031)
|